Geoffrey Teale: From Development to Leadership - The Journey of Shaping a Tech-Driven Future

This transcription is AI-generated and may contain errors or inaccuracies.

Matt

My name's Matt and I will be talking with Geoffrey Teale about the importance of diversity in engineering teams and building a strong developer experience. Hey Geoffrey, first things first, before I jump to the list of questions that we discussed it, I saw that you recently changed from head of engineering to principal product engineer. And my first question is like, who is the principal product engineer? What is this role about?

Geoffrey Teale

Okay, so I mean the first thing to say is that at Upvest, all of our software engineers are called product engineers. So that's to do with having this product focus in everything that we do. As a principal engineer and the principal product engineer by extension, my role actually is to sit and look at projects across the whole of the engineering organization. So you can think of that as analogous to what staff engineers do with small groups of teams. I do for the whole organization. I'm part of a group now within upfest called the office of the CTO where we essentially look at the issues that affect all of the teams, the interactions between teams, new technology and run initiatives as an enabling team to allow the other product engineering teams basically to bring forward ideas and develop them in a way that we know will be applicable across the entire organization and meet with our compliance standards, pull in the platform team and do everything else that's required to make that a hub.

Matt

Okay, thanks for the explanation, that's interesting stuff. And during our recent quick talk, we discussed the culture differences and diversity in a fintech which is not really diverse, I mean industry, but we discuss it that this is important topic to you and you want to change this paradigm a bit. And I mean like why do you want to do it? What challenges do you see and what do you do to create the diverse teams?

Geoffrey Teale

Okay, I mean, so why do we want to do it? I think the reasons for wanting diversity in an organization are generally quite well, quite well known are end users. We don't directly have end users who are B2B to C, but the people who consume the results of what we do are diverse. Right. So if we only have one point of view represented in how we build things, there are cases that we can miss. We might build the wrong thing. And that's fundamentally very important to building a good product.

There are actually things, aspects that people don't talk about very much, which is with the reality of if you constrain your recruiting to a very small group of people, you're actually creating this kind of economic pressure that drives up the price of those people and various other things. So I mean, in reality having these domains where you don't have a great deal of diversity actually is counterproductive for building a profitable business. And I think there's also this, how would I say that? There's this reality that we have to have a view of ourselves as a company and as an employer to say that we are a good place to work. And being a good place to work means being open to all kinds of people and to make sure that we're supporting all kinds of people. And if you only have again, a single viewpoint in your recruiting, you only have a single set of ideas, it's very easy to do things that you feel are completely okay, but actually would alienate people coming in. And so that becomes a secular process.

You could try forever to be opening yourself up to new people, but unconsciously be doing things that are done about for that. So all of those reasons you have to in a sustained way actively try to build diversity. So I mean, that's the important aspect. What are the challenges? Well, you mentioned already that our domain, so the convergence of finance and technology is a particularly, I would say non diverse place, right? There's two industries that actually aren't that diverse. And I mean, I don't just mean about, you know, gender diversity.

This can also be about racial or heritage diversity, these kind of things. And there's a tension there that can build, so I mentioned already these established practices that can be unconsciously biasing you against including other people. But there's also this question, right? When you're building a startup or even a scale up organization, you genuinely need to have some people with some experience. You can't just do everything from out of the blue. You have to have people coming in who know what they're doing. And that creates a problem in itself.

Because if you're always recruiting, looking for people with experience, you can only draw them from the pool of people who already exist. And if all of people who already exist isn't diverse, then it's very hard to increase diversity. So actually one of the things that I take very seriously, and it's a hard thing to do, and I won't say that we're perfect at it at all at the beginning of that journey, is to make opportunities for people to enter at the beginning of their career. Because I think really at the fundamental part of building a path to having a more diverse future. And that actually means that you have to be ready to develop people, you have to be good at mentoring, at training and all those things. And I think actually Upburst is taking that very seriously and not Just my department, but the people team up us are taking that very seriously and putting things in place to make that happen. So I'm hopeful actually that we can do.

We're doing quite well. We recruit from a lot of nations and have quite a good deal of diversity, but by industry standards at least. But I hope that we can do better at that in the future because we're putting those things in place.

Matt

And two other topics that we discussed related to your previous role, I would say it's Death Rail and devx. So I'm getting lost sometimes in all those abbreviations. So I think during our last conversation I got lost. But those are really interesting topics. So like developer, let's start maybe through from the developer relations, like could you tell me like why you did it and maybe tell me about the practices that you did to support this initiative?

Geoffrey Teale

Yes. I mean actually developer relations is a duty that I've also brought with me into my new role. So as you've sort of mentioned, it's distinct from the developer experience part. I mean in different companies one falls within the other and there's a lot of confusion about those things. So I'm not surprised that you're confused. But okay, let's talk about developer relations. And so I've always been someone who has been involved in going and talking to people.

I've never been an engineer who sat in a room on his own heads down all the time. I've always been someone who was going out talking to people and there are reasons why you would want to do that in a development context. The reasons vary from company to company. So I think the overriding case for most people who are involved in developer relations is that they work for technology companies and they have to look to build some kind of community aspect of what they're doing, pull in developers, engage them firstly to give them actually a good experience and to feel like they're supported and helped and that there's something beyond just a blank web page with documentation that they can rely on to help them do their work. But also actually is a marketing exercise. Right. So a lot of what that entails is going out to conferences, going out to potential customers and talking to them and having this human level interaction that supports the technical interaction in other companies.

Actually this is more the case with upbest. You could say that there's a need to market ourselves to the technical brand. So we mentioned that we're a fintech company. We're actually a financial infrastructure provider. We're doing business to business stuff. All of which works really well. But when it comes to recruiting engineers, it's not a natural place to be in terms of putting your brand in front of engineers.

So unless those engineers are actually working in companies that use us would be our customers and their awareness of us is not necessarily very high. So that means that one of the things that I have to do is go out and again mentioned conferences, look at opportunities to sponsor technical conferences around technologies that we use, do public speaking, encourage within the organization activities like open source projects where you can actually demonstrate some of what the company is doing in a public way and show goodwill and also say actually this is the level that we're operating as a technical organization. So from that point of view, you can think of it as kind of a form of marketing for the company within that technical space.

Matt

It's like, I would call it like employer branding. It's like let's say something that I used to call and we used to call in our companies, but I totally get it. And regarding the devexo developer experience that the superstar, the Abinoda bring it to everybody and I think a lot of people are excited about it. But I'm just wondering in your case, do you have any advices or your own experiences what and why to implement from the devex practices?

Geoffrey Teale

Yeah, so I mean I worked in the devex space for something like seven years actually up until middle of this year when I changed roles and that there is some actual overlap in what I do now. You mentioned Abhinoda. I think there's a trend in devex right now, which I think we might come back into this subject later on as well. But people are very generally in business right now. They're very interested in metrics, they're very driven by metrics. And there have been a number of efforts, Abby and people at Microsoft and a number of new products that have come about that focus on this metric gathering, survey aspect of developer experience. I think, although that's all very good, I think there's a danger there that sort of reduces what developer experience is about just to this kind of, okay, I will measure this thing over here.

Whether that's mean time for reviews to be completed or deployment times, things like that, and focus on those things now. All of those things can lead you to useful outcomes. But actually I think you sort of have to take a step back and say, well, what is developer experience really about? And for me it's about producing the situation where it's easier for developers to do the right thing and to work well efficiently with good outcomes and be happy doing so, than to create a world in which we're just producing nice data that appeases a manager somewhere. So I think that may be a topic that I'll come back to, but it does worry me a little bit. So, I mean, actually in my experience, the biggest thing that companies didn't used to do, especially in larger companies, is that when they undertake software engineering projects or put in new technology, they go out and they bring in all these stakeholders and they say, okay, well whatever we do, this process has to go through legal, finance, whoever the stakeholders are for that project, and we have to account for all their needs. They go away and build those list of needs and start working our technical solutions to that and build that.

But in that requirements gathering phase, they often actually forget that software engineers themselves are stakeholders in that process. Right. So there's a need to build systems that are maintainable and to build processes around them that are maintainable. And particularly when we start talking about things like cloud platforms, which I've been really heavily involved in over the last 10 years or so, that that world has software engineers as end user, and it also has a sort of automatic set of competitors that companies don't think about. They go away and say, we'll build our cloud platform on either some internal cloud software in the data center, or we'll go and use a public cloud and we'll build out on top of that, add the pieces we need. But the developers often don't think about what the outcomes they're really looking for are. So I've looked at situations where cloud platforms were built with the idea that this would automatically make their development practices faster than the sort of old fashioned enterprise practices they had where they had to wait six months for someone to put a server in a rack so they could bring up their Java service. Right? And when they made that analysis, when they went through that process, they didn't stop and think that all of the other processes around this deployment of some software were still the same as they'd ever been.

Like the organization still wanted to double check everything, send an email here, have someone go on a training course for which there's a six months waiting list before they're allowed to start working on this, all these kinds of things. And so they didn't get the outcomes that they want and the developers using it weren't happy. And actually at a certain scale, the reaction to any kind of problem like that, when you are, the problem when you're blocking people from doing things, is that the engineers go to their managers and say, okay, we can't deliver because we can't get any further with these people. At some point the manager is going to say, well I've got a budget, I'm going to go and just directly buy you an account on AWS or Google Cloud and we're going to do things cloud native and we do it that way. And then all this investment and all this idea is gone. So this is also a question of protecting the investment that you make in these things and actually delivering the value. Because there was real value in that cloud platform, there was real value there in providing compliance as a product.

All sorts of things that needed to be done and would then have to be reinvented by these other teams. But if you don't focus on the developers needs, if you don't take them into account as a stakeholder, you miss all of that. And you know that that for me is the core actually of what developer experience has been about for me.

Matt

And I think another point related to that are the metrics, right? I really like the data points, I really like using the metrics. There are those DORA metrics, space metrics that are really helpful to make, to make the make the decision. But in your case, do you have some particular metrics that you're using or something that is particularly helpful to you in the decision making process?

Geoffrey Teale

So going back to that previous statement, I have used things like value stream analysis actually. So there's these kind of industry standard metrics which are for some tools you'd say time to hello while time to hello world MySpace now time to first API call. Those are quite interesting in the sense that they talk about the very first steps actually not the first steps, but the first steps after the decision to use a product. So moving from saying okay, I want to try this thing out to actually having gone through enough of the process to understand how to make the most minimal interaction with that product. And that tells you a lot because in that context I spoke about before getting up and running on that cloud platform that was measured in multiple weeks, close to a month to make your first deployment of a container into that cloud platform. And most of that time when we analyzed it was spent on actually things like email chains, dead time between people picking up things and clicking approve and all this kind of stuff. So there were lots of opportunities for automation there.

And actually the change in satisfaction the engineers had, the change in their ability to get things done and the change in the uptake of the product can all be measured. So you can see, okay Here are a series of metrics. I believe I made that hypothesis that if I change these things based on my current analysis, that the other metrics will improve. And that's a really important part about any metric. And when I say there's a danger in metrics, I think it's really easy to fool yourself that you're being empirical. You set out a nice number, you see it change, you report it. As I said to your boss, you get good feedback, pat on the head and you keep repeating that loop.

But if you're not actually checking that you're getting the outcomes that you want, rather than just this number moving, you can really sort of get skewed off on the wrong journey. And it's that you can fool yourself into thinking you're getting a signal that's not there. And that again with developers, especially in large organizations, has been a concern for me because surveying for data is very useful. I mean, I advocate going out, just asking people what problems they have. But where you have very little signal, which is often the case, it's hard to get high. Take uptake on, on surveys, for example, where you have very little data, it's really easy to get skewed by one signal. And so you have to be really careful about that.

And I think there is a scale at which analyzing metrics and in certain tool cases, like if you have GitHub or something like that, pulling some metrics in there can be useful. But you really need to know what would validate that this change in this metric is making a real substantive effect. And if you have that, you can act in confidence. If you don't, then the danger is you just fool yourself.

Matt

If I could use one word to find the subject of the 2023, especially in a big tech, is productivity or hyper productivity. So I feel like because of the layoffs we need to go get more productive. We need, we have less people, less resources, less money to build what we have to build. And I'm just wondering in your case, how do you measure, how do you help to get to this hyper productive state within your team?

Geoffrey Teale

So I mean, I think there's a lot of talk about this and you mentioned the layoffs. I mean obviously some of the context around that is to do with AI tooling. I think that's a very interesting space just because there's a lot of belief that this will deliver productivity benefits. But the data that I see coming out is very isolated to particular aspects. Like for instance, we talk about programming, we see that using a tool like COPILOT can reduce the amount of time it takes to type out solution. There's also some thinking time that it takes away. But then historically, if we look back and we look at how software engineers spend their time, actually the amount of code they produce is relatively small.

And then making changes in that code doesn't really represent the entirety of their productivity. Also, the balance between writing new code and dealing with problems in existing code is heavily weighted in most cases towards dealing with problems in existing code. And some of those tools aren't yet very good at helping those scenarios. There are things coming through, but they're not there. So I think we've seen some recent studies that suggested that companies that went down this road haven't seen the return on investment that they expected to find from those things. And actually, possibly a lot of that's just to do with training on how to use these tools and adapting. But again, the layoffs, productivity.

But I mean, when we search for productivity in engineers, if we actually go and look at the science of this stuff, what seems to come out right now is the application of autonomy, because autonomy leads to happiness. And actually happiness is a huge factor in our productivity as human beings. So there are ways of talking about that and thinking about that. I gave a presentation several years ago about what makes me happy as an engineer, and we talk a little bit about flow states and flow states, a topic that's become quite, you know, quite trendy to talk about and directly linked with this idea of hyper productivity. But the first thing to say is that flow states are quite rare. Right? So this is not a situation that you find yourself in very often.

How do you get there? Well, it has to do with two things, really. It has to do with having the space and time to do so and having the right kind of challenge in front of you. So if you have a working environment where your day is broken into lots of little chunks with meetings in between, you're never going to get into a space where you can maintain a flow state. It will not happen. So you have to make space in your organization for engineers to work in large continuous blocks. You also have to look at those challenges.

So one of the things that I've done historically is to look at engineering tasks that are coming up in the day or week ahead and give those engineering tasks a grading and say, okay, this is a task that is fairly easy. Developer X and Y have done this a million times before, but hey, there's a junior over there who's never done it and give that task to that person because there's this idea of the zone of proximal development. So that as well as being ready and having the space, the challenge has to be not really, really difficult. It can't be something that you were just going to get stuck in the mud on, but it has to be just slightly beyond what you do regularly. Something where you actually have to think about what you're doing and work your way through it. When you get that and the time to do so, then it's possible. It's not guaranteed, but it's possible that you can get into this flow state, which is characterized by lots of things like a shifted perception of time, for example, which is also part of the reason why you need to have a day that isn't interrupted.

Because once you're there, the day can flow away like nothing. If you have a situation where the challenge is too great, there's no point even trying to get people to work this way. And so then I fall back on other techniques. Pairing or mob programming generally helps people to overcome those issues. They won't hit that flow state, but they will get through them faster by discussing with other people and sharing the problem. If the things you're working on are too mundane, even if there's no junior person who's never done that before, you can also start trying to gamify these tasks a little bit and do a little bit of design for dopamine. So if we think about engineering tasks the way that developers work with unit tests, for example, where they have these big long lists of tests running when they make changes, a whole bunch of stuff goes to red crosses.

And then actually the process of repeatedly clearing down those crosses and turning them into ticks gives you this little dopamine boost. So instead of being this huge unwieldy task that will demotivate you, which is something just human nature, you need a reward that's of the same scale as the task ahead of you. It will turn it into this process of small changes that give you feedback that say, well done, well done, well done, well done. And actually, the more you do that, the more your dopamine system will become aware of that. So even without getting flow, you can motivate people to get through work very easily. And actually, people will feel happy as a result of working in this way. So there are these little tools that you can use.

Matt

I really like to talk about some controversial decision making or contrarian decision making maybe. And I'm wondering in your case, do you recall a situation when you made a contrarian decision on a product or engineering team and ended up successful. And could you tell me about it? What were the lessons learned?

Geoffrey Teale

Yeah, so I mean I have to really go back. There have been a few over the course of my career but the really big ones that I think of, I go all the way back to the 1990s when I actually first started working in organizations after university and at that time I worked for a really big multinational company. They had a variety of computer systems order mainframe and minicomputer stuff, some Windows stuff, but also a lot of proprietary UNIX stuff that was running at the time. And I started looking at some projects and I got a bit frustrated with the nature of the tools that we had. I had experience with some other things in the university context and so I just started, I didn't really know any better actually, but I just started taking some old hardware that we had lying around in the office and running Linux on it and having done that and used it as a basis for some local development things I was working on. I started to go to people and say hey, we're rolling out these licensed Unix machines to. Actually it was literally tens of thousands of sites each with their own machines.

This is costing us. I can't remember the numbers but it was something like a thousand pounds in the UK a time for these machines licenses. And I said hey look, we could do this for free. This thing here does all the same things. Now of course, the existing logic within the department all the way up the management chambers, of course this was not okay, right? We can't just take this piece of free software and use it. This was, say in the 90s, the whole Linux revolution hadn't really happened yet but I pushed for it and actually then I found that I had allies and I pushed and I pushed and we piloted things, we tried it, we demonstrated and at that point, when we started to demonstrate that this worked and it was okay and it was reliable, it wasn't going to be a problem at that point Then people started to get interested because I then started to say yeah, this is affecting our boss and mine and know, for me a thousand pounds sounded like a lot for those people, they didn't care.

But when we start saying okay, we scale this up to the whole country and then the whole region and then the whole world had a. Had a profound effect. So I mean again that's. It was controversial in the sense that my managers told me that it was a bad idea and I still pushed to do it anyway it took. Again I say I didn't know better I was young and I think there was a degree of arrogance in pushing for this. But it did teach me that actually sometimes swimming with the flow, doing what everyone else is doing is not the way to get good outcomes. Right. You actually have to stop and think about what you're doing.

And many years later, actually, I read an essay by Paul Graham which is called Beating the Averages, and he talks about his own experiences with technology choices and said he was using something called Common Lisp to build products. And he said, well, people in other companies whose company got bought by Yahoo, they wanted to use C these things. So he said, actually, as a startup, if I look at what I'm doing, I understand the benefits of what I'm doing and I understand that the other people don't see that. And if I see a competitor saying they're hiring C or Java programmers, then I don't worry. But if I see them hiring technologies that are akin to what I'm doing, then I do worry because it means they get something. And if I just do what everybody else is doing, the growth and the returns I can expect from doing that are constrained by the same way. I can't possibly hope to do better than they do, whereas if I find a better way to do it, I should be confident in that and go forward.

And I think that's characterized the decisions that I've tried to make and the attitude that I've tried to bring to companies as I've come forward.

Matt

Speaking of Ben Horowitz and the hard things, I wanted to ask you about the toughest thing in your career. Do you really call the hardest thing that you have ever done in your career and the what lessons did you learn from experience?

Geoffrey Teale

Wow. I mean, honestly, this might be a somewhat obvious answer, but the hardest thing I've ever had to do is to fire people. And actually in the wake of 9 11, I was working then I had to there got a lot of people, the team got downsized and it taught me a lot about the kind of support that you need in that situation. I was still quite young then, I hadn't done anything like that before and actually was quite psychologically difficult for me and I think ultimately left to me leaving the company, even though I wasn't required to do so. So I think that's actually, you know, a really, really important thing to, to think about that this. At the end of the day, hard business decisions result in real human factors and not just for the people who are directly affected, but for everyone around them. And yeah, I think any kind of change in an organization needs careful thought.

And I don't think there's a right way to do do these things, but there certainly are good ways and bad ways.

Matt

Speaking of the hard things, this is my favorite topic. So I have a lot of questions around them as you could notice. But I'm always looking for some kind of insights for the other leaders. Right. If you start to be a CTO and you apply for a job of CTO and you're first in CTO or the principal engineer or the head of engineering, in your case, your experience as a head of engineering, as a principal engineer. But there are some things that are not visible from the outside before you start the job. You don't see the things, you don't see the challenges.

And maybe you could talk about the challenges that are not so widely discussed or not seen from the outside as a newcomer in the role.

Geoffrey Teale

Yeah. And I think that's what's quite interesting is that there are some roles, senior roles, that aren't line management roles. So when you have a line management relationship, it's very easy to fall back on. Dictatorial is not the right word, but telling people what to do and saying, okay, this is how we're going to do something. So you can, I mean you can fall into this trap of micromanagement, but you can also validly set people expectations and say please go and meet that expectation as well. There's a balance there. But there are roles like my current role or being in a platform team or and being a staff engineer where you don't necessarily have these line management relationships, but your job actually fundamentally requires you to make changes in the way that people approach their work and do their work.

So one of the things about that is you have to be really good at making your case. You have to be very practiced and very sure about the way in which you communicate with people and the arguments you make. And of course there can be places where it's clearly your responsibility to make decisions and you have to be comfortable doing that. But actually these conversations, this written content, this however you communicate, this part of saying, okay, I believe that we now need to make this change or we need to do this thing in this way. And here is why to such an extent that people will come with you on that journey and you will achieve your goal is a hard thing. And I think you can't learn lessons for people. So even if you tell people, I don't know, I find a random example, say test driven development, which even today in some companies is controversial.

You can't tell people, oh, by the way, if you do this, there's going to be this future situation where you'll find it invaluable to have this stuff in front of you that helps guide you through the change that you're making. People have to learn that. So you have to create context in which people learn that and build a culture that supports that. And that's a long, hard process that starts with good arguments. I think it can't be overstated how difficult that actually is to achieve, especially in established organizations. When you start from scratch and you can start to influence people from day one, especially people with no experience, then it's quite easy. But when you're coming into an existing situation, with existing culture, existing views on how to solve problems, changing those things and shifting them is a really difficult challenge and not quick.

Matt

It's a set, it's a selling process I really like. You know, we have to show the context and to show the data. Like when I'm doing such changes like the data presentation, you know, some graphs that are showing and supporting what you are saying, give it a try. It's always really helpful to me, like this is how I do it.

Geoffrey Teale

I think, I mean we talk about that a little bit as well, but there's always, I think as well, within companies this aspect of the grass is greener. I mentioned the platform teams before. If people come into a company, they often say, well, I used to have it this way and that was so good, we should do it like that. Which is always valid input, right? You want to take that in anyone to understand it. But there's also this kind of over time familiarity breeds contempt. And when people look out to other companies, they, I don't know, they see a presentation, they see an interview like this online, they take ideas from that, which is great, but they also see this kind of curated view of a company from the outside.

Actually, especially when you're in larger companies, people assume that everyone working at the FAANG companies is a genius doing really interesting work. And actually they have a lot of people who are doing quite mundane work and very few people who are really doing those very interesting things and getting to do those very interesting things and getting that position company is necessarily hard when you have people around you. So this kind of notion that the grass is greener on the other side, everything must be done better somewhere else. So we should just copy what they do that feeds back into that other point by just looking over the wall and saying, oh, every other company is doing this. We should do that too. It's a really dangerous way to shape your business because you can borrow ideas, but you can't borrow situations. You're not them.

You have to actually stop and think and say, how does this apply? What is the right solution in our company?

Matt

The last thing that I wanted to ask you, and I asking all of my guests, are the ask for the recommendations. Can you recommend any books or podcast or resources conferences that maybe have been particularly helpful to you as a leader in tech?

Geoffrey Teale

Yeah, I mean, I think actually one of the most important things, no matter what domain you're in, is actually to try and be a bit of a polymath. I mean, you can be very specialized as an individual contributor and that's fine. But if you're, if you're leading, if you're trying to find your way through this business space as well, you need to look in more than one domain. So I think there are, I mean, for me, actually I talk about devex and things like that. One of the most important books I read, it probably won't be that surprising, but it's a book called the Design of Everyday Things by Douglas A. Norman, which are hugely influential book in the design space. And I sort of learned about this stuff by working with UX designers and starting to think about how some of those ideas would apply to developers.

And actually this, you know, this whole, whole world resolves around the same thing. So just reading in that different space gave me a wealth of ideas for how to deal with things there and how to think about things. I mentioned Paul Graham already. I came across Paul Graham many years ago as a Lisp programmer. I read his books on Lisp, which is for, by modern standards a relatively obscure topic. But then I happen to be following his blog and his career and I mentioned already at least one blog post from him. I think just this last couple of weeks we have this debate about founder mode that he's been writing about as well. And whether you agree with those things or not, I think he's an interesting writer, man with interesting ideas, and I always find that very, very good to follow what he's saying.

The other thing, actually, in the world of economics, I think one of the best books I've ever read is a book called 23 Things They Don't Tell you About Capital by can't pronounce his name, Hajong Chang, who's a Korean economist. It's actually another really well written book that kind of boils down some, some, I think fairly common ideas that people have about economics and challenges those and so if you thought about this what. What's the real situation going on here? And I found that a very interesting book I think I could go on all day I mean conference wise I sadly something's just ended that used to be really wonderful which is a conference in the USA called Strange Loop so I believe they're not doing that anymore but that used to be a wonderful thing because it provided the mix of academic and technical people together in one place and I had a wealth of great ideas from that Here in Germany there's something called Bob Kampf that happens in Berlin which is sort of similar on a much smaller scale um. But yeah, I tend to get to that as well I think that'll do great.

Matt

Thank you very much, Geoffrey for all the recommendation and all the tips and your thoughts. I really appreciate our talk and I think the same with our listeners so thank you for today Good thank you very much.

Geoffrey Teale

Follow Matt and Leshek on.

‍