In the latest episode of ‘Beyond the Code’, Host Kovid Batra engages in a thought-provoking discussion with Alexandre Goedert, Head of Technology at Thoughtworks and a former contributor to SecondFloor and GVT. The heart of their conversation revolves around ‘Building Autonomous Dev Teams’.
The podcast starts with a fireside chat with Alexandre, providing us with a glimpse into his personal journey. As the conversation progresses, he takes a deeper dive into his team collaboration practices and defines what constitutes 'Good software' for engineering teams. Further, he also highlights the pivotal role of large-scale CI/CD, fostering the autonomous mindset and crucial aspect of ensuring a positive developer experience within teams.
Alexandre concludes by offering parting advice to the audience, emphasizing the importance of connecting to business value and fostering a collaborative team environment.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. And today with us, we have an interesting, amazing guest with us who is a curious, passionate technology soul. He has 20+ years of engineering and leadership experience. He’s currently serving as Head of Technology at ThoughtWorks.
Welcome to the show, Alex. Great to have you here.
Alexandre Goedert: Hi. Great to be here. Thank you for the invitation, Kovid.
Kovid Batra: Pleasure. Pleasure. So, Alex, we’ll start with a quick fireside chat where we would love to know more about you outside of work, all right? And here, you have to be, like totally honest and tell us whatever you feel, okay?
Alexandre Goedert: Sure! Let’s do it.
Kovid Batra: All right. All right. So I’ll, I’ll start with a very simple question. How do you start or kickstart your power-packed day? And how do you love to end it?
Alexandre Goedert: Yeah, sure. I’m pretty much a morning person. So I really need to wake up early and try to do some kind of routine. Otherwise, my day is not very productive, right? So, I try to wake up around six, sometimes it’s a bit tricky to not hit the snooze button, but I think I succeed most of the time. And, one thing I like to do at least during weekdays, I do at least 10 minutes of meditation and I try to exercise from 15 minutes to one hour, but depends a lot on how busy my schedule is, right? I try to alternate between yoga, running, and functional exercises. That’s pretty much it. So, I try to do it at least on weekdays.
Kovid Batra: And, let’s say it’s a, like full power-packed day for you and you’re coming back. How do you unwind? How do you love to end the day then?
Alexandre Goedert: Yeah. For me, usually at the end of the day, I’m more tired and I have a son, so I try to keep time with my family. I try to block my agenda. I think in most of the cases, I can do that. And, I think one of the things I enjoy doing nowadays is as I’m living in the Netherlands and I’m studying Dutch, I try to watch news in the local language. I think that’s a way to also do some like a lightweight study at the evening. Yeah.
Kovid Batra: Perfect. Perfect. All right. Let’s move on to something more deep probably, and you can take a minute to think about it and tell us. Those three things that define Alex, like you have three words that define you.
Alexandre Goedert: Yeah, that’s a good question. I think probably the first one I took this StrengthsFinder test some years ago and the first strength that I have is called achiever. And, I would connect that to like I’m a passionate person to try and deliver new things when I’m working. So, I think that’s probably one of the objectives I can think about. I consider myself also a curious person. I think I started on this career because I was just curious to understand how a programming language works. And, what we could do with them back in the day.
So, yeah, problem solving and curiosity, I think it’s also part of who I am. And the last one is, like, I really like to collaborate with other folks to, to achieve solutions together. So that’s, I think me in a nutshell.
Kovid Batra: Perfect. The last one that you’ve said, like you, you love to collaborate with people. I think this is a very good quality to have, right? And, if it comes innately and if you really believe in it, that’s super amazing because that way, you are able to create even more impact than you could do individually, right?
I just want to understand what do you think actually inspires you to be more collaborative? What drives that thing in you that makes you so collaborative with people?
Alexandre Goedert: Yeah. I think it’s since I started developing software. So nowadays, I cannot be in touch with code as I used to be, but I remember when I was starting to code, it was amazing to me that the things that you could do when you started working in your team structure, in your relationships and communication lines.
So for me, the journey was like from a developer, I became a tech lead and I had to balance these activities of writing code, being with clients in meetings, talking about architecture, talking about.. And also, doing some coaching and mentoring of team members. So, I think that’s, for me, a big motivation is okay, how can we develop software in a better way? And, I think part of it, it’s through communication and relationship within your team.
Kovid Batra: Makes sense. All right, moving on to something related to book reading, I’m sure you must be doing that. Just tell us about the latest book that you’re reading and share some learnings from that.
Alexandre Goedert: Sure. The book I’m reading at the moment is called, ‘Find Your Red Thread’ by Tamsen Webster. And, this book actually I gained in a conference that I presented last year. It was sitting in my shelf for quite some time and I picked up recently. So the author is, she used to work as a TEDx idea strategist. So, she was essentially responsible for selecting multiple TED talk ideas, right? And there was a lot of competencies. So, she came up with this structured way to select the best talks. And, I think why it’s relevant to me nowadays is that I’m spending a lot of time trying to build proposals for new clients, and sometimes when I join a client engagement, I have to set up the foundation of this new client account. And, I think it has a lot to do on how you communicate your story in a way that is compelling to the other person. And so, it’s a very interesting book from this angle. So yeah, I’m finding it very interesting.
Kovid Batra: Nice. I think that’s, that’s really interesting. Never thought somebody would be planning what talks to have on TEDx. So, I think that really requires a deep thinking and connecting with the audience. Yeah.
Amazing. All right. I think that was knowing you and it was pretty amazing. I would love to move to the next section, which is talking about your experiences, your success, failures, how you work with your teams. So, are you ready for the main section? Let’s get started?
Alexandre Goedert: Sure. Let’s start.
Kovid Batra: Perfect. My first question is how do you currently work with your teams? Just talk about some of the practices that you follow, and what do you think you are trying to achieve in terms of operating in the most ideal way. So, just talk about something, how you operate right now and how you would want to operate ideally with those teams.
Alexandre Goedert: Yeah. Yeah, it’s a good question. I mean as I mentioned, I like to collaborate with other people. And, also in the StrengthsFinder, I have this “relator” attribute. So I enjoy doing that, but it’s not always easy, right?
So, as a work I’m doing now, the role is called Head of Technology, but in practice, as I work in a new market within ThoughtWorks, I have to do a lot of work with demand that is related to technical sales, but it’s also related to how we implement in the region, the technical, or the technology strategy from ThoughtWorks Global. So, for me, the interesting part is that how we articulate that strategy into action with different people. So, the way I prefer to do it is like, we have a group that we call Tech Council. And, we have representatives of different specialties. And, we try to come up with agreements on what is more important. So, a lot of times what I try to do is like, drive this group to actually prioritize together. I think you need to give up some structure because otherwise it’s just, it takes a lot of time. But, I don’t try to solve everything by myself as well. So, I try to give some structure and let also the thinking flow a little bit. And of course, you need to sometimes take decisions on, okay, we should go to this side, or we should pivot. But, that’s pretty much how I like to work with my teams and of course, we have people with different seniority, so, sometimes you have to support a little bit one person or the other.
Kovid Batra: I have a question here.
Alexandre Goedert: Yeah, sure.
Kovid Batra: So, this team, first of all, I didn’t catch the name of the team. You call it the?
Alexandre Goedert: We call it the Tech Council, Technology Council.
Kovid Batra: Okay, Technology Council. What’s the purpose of having this team in place? Like, for you as a Head of Technology, translating, let’s say, the business strategy into a technical strategy and then execution is something that you want to do, but how does this team actually help you in doing that? I just wanted to understand because I’m just listening to this term for the first time. So..
Alexandre Goedert: Yeah, sure. I think for me, the main benefit is to have people that can challenge my own ideas and perceptions, right? I have a lot of experience in this market. But, I’m not a technical specialist in some areas nowadays. I think technology has changed a lot, and nowadays, it’s very hard if you’re a generalist to actually know some specific things about, let’s say, IoT, data and AI, machine learning, you know? So, I use this group as my source of information and critical thinking about different tech trends. Yeah. So, I cannot do all by myself.
Kovid Batra: Amazing. I think this is a very good thought, and this really helps in making much better decisions that you could be taking individually. So, it makes sense. Perfect.
Alexandre Goedert: Yeah.
Kovid Batra: All right. Yeah, please, please go on. Yeah.
Alexandre Goedert: No, exactly. So, I try to use this thing as much as possible. It’s a lot to do with, like creating the structure for a conversation, having the conversation, taking decisions during the sessions, and then helping to draw a conclusion at the end and next steps, right? So, for us, it’s really important to know what we are investing in terms of technology strategy and how we can meet this sweet spot because we need to sell things that the client wants, that our thoughtworkers want to work with, right? And things that we can actually have the capacity to deliver.
So, I think the work is actually finding the sweet spot and taking decisions every now and then to adjust.
Kovid Batra: Makes sense. Perfect. So while you’re working with your teams and making these decisions and then operating, do you feel that there is something that you could do better? Do you feel anything missing right now which you’re not able to do, or maybe you’re trying to do right now, but some realities, some ground realities stop you from doing that and you’re finding your ways out?
Alexandre Goedert: Yeah, yeah. I think always, right? But in my case specifically, as I work for usually new markets within ThoughtWorks, it’s always a very constant stretch between working with demand and pre-sales pursuits and looking inside ThoughtWorks from an engineering point of view. This is normal because new markets in ThoughtWorks, they’re kind of an internal startup. So, it’s part of the work, but doesn’t mean it’s easy. Right? So, I think a lot of effort is also to try to balance these things. And, it means having to drop a lot of plates sometimes. But, yeah, I think that’s something that’s, it’s always a struggle.
Kovid Batra: Yeah, absolutely. But, I think the balance is the key. Like, you always try to strive for that. Makes sense. Perfect. Perfect.
All right. I remember our last conversation, like when we were talking about having this podcast together, you told me, “Kovid, people just need good software and that’s enough to run something.” And, I was intrigued by this thought, but I could not relate to a situation where this philosophy exactly fits.
So, I just wanted to, like go back to that thought and understand more from you. Like, from what context it is coming, in which situation this philosophy applies, or it is generally applicable in every scale of company, be it like the scale of ThoughtWorks or be it a startup of 20, 30, 50 folks?
Alexandre Goedert: Yeah, sure. I think the point is, like, what good software means, right? And, if you talk to different people, they have different definitions. And usually, it’s the case that technical people, they know better. And, this reasoning doesn’t come out of the team. So, we have this classic misconception of people want to start with a new team and deliver fast into production without investing in good engineering practices and having a solid foundation, right? So, because what you want to achieve at the end, you want to have a software that is easy to evolve. So, to consider nowadays, business is changing faster than ever. So, I think after the pandemic and with all this recession.
Kovid Batra: Definitely.
Alexandre Goedert: Yeah. Together with the fact that technology basis is very accelerated. So, we can only make a good usage of the client’s money, if you build software that is adaptable. So, we need to be very conscious about what good looks like in this scenario, right?
Kovid Batra: Yeah.
Alexandre Goedert: So, for example, we cannot afford accumulating tech debt since the beginning and we need to expose that. So, what’s the shortcuts we’re taking? What is the consequence of taking some bad decisions in code? So, the problem is that you need to invest some more time initially to make able to make easy changes later in the software. And, some people take the shortcut to deliver fast initially and after some time, it just stalls, right? So, I think it’s a lot about that. So, to define that from the start and make the team with proper autonomy to fight for it, to explain what good looks like to the external stakeholders.
Kovid Batra: Yeah. I think now, I think I relate a little bit. In one of my podcasts with Serdar Mustafa, I think he mentioned, “It should not be a Minimum Viable Product, it should be a Minimum Lovable Product.” So, when you have that mindset of building a Minimum Lovable Product, you would definitely consider building the software also to a certain standard that doesn’t.. I mean, of course it has to cater to a customer’s requirement and the person should love it at the very first stage, but also, it should not be a tech burden for the coming months or the coming years when you’re operating on that. So yeah, it makes sense.
The next thing that I would love to know from you is that this topic is quite hot in the DevOps from quite some time now, but still, how important do you think for a company like ThoughtWorks or at that scale, a continuous integration and delivery, deployment is important? And, how do you think it should be done at that scale?
Alexandre Goedert: Yeah, I mean, it’s something that we like pretty much inside ThoughtWorks, right, since we started to work with the agile movement when we used cruise control that was on the first CI servers back in the day. So I think the discipline of keeping your build in a healthy state and your artifacts always ready to be shipped, I think it brings many benefits. So, if you do it right, there is no concept of works in my machine problem. So, you get consistency across environments. There is also no obscure script that you need to execute and then only some senior folks know how to do it, right? So, you deploy, your deploy is automated and it can also be audited.
There’s also a good way to recover from failure. So, or even if you use techniques like Canary Release. So, I think in a way, you can give the autonomy for the team to deliver instant value and even multiple, multiple times per day, right? So, for us, it’s really one of our core practices. And I think one very interesting way that we try to apply it is, like when we start a new team, the first iteration, we call ‘iteration zero’ and it’s really what would a ‘hello world’ for this team context would mean in production. And, we start by building the path to production from a CI perspective, right? So after that, your first story, it’s automatically deployed in production. So, I think it’s a mindset that is very important if you want to be really adaptable as a software team.
Kovid Batra: But, I think what we have usually seen is, I mean, it’s right that you have to build that frame of mind in the teams to actually move on to this process and this kind of ideology. But, there are a lot of challenges like they’re innately, people are not in for it. Why do you think is, is that there, like with developers, with teams? It exists, I’ve seen that. What do you think is the reason? How should one work on that?
Alexandre Goedert: It’s interesting, right? Because what I’ve seen also in, if you talk about DevOps as a culture or a mindset, in many companies you see nowadays that platform engineering is all the rage and the way some people implement is by having these layered teams, in the sense that you have all the expertise about DevOps inside one team. And then, you have the consumers that only know how to consume that, but they don’t have the knowledge of built themselves. So, if any clients that we work with, we try to say, okay, you know, “Platform team, you should build services that should be composable and owned by the external team.”
So, for example, if we’re building a development pipeline, I can maybe build some libraries that I can connect to build stages in my CI, but I never should build the pipeline myself for the other team. The team should own that, and they should know how to build that from scratch. I just build accelerators, right? And try to build some conventions around what’s good. So, for me, that’s something that we see in many clients. And, they see, okay, I have a platform engineering team, but I still need help with DevOps. And usually, that’s the case. So, usually, you don’t have a multidisciplinary team where actually people own the full deployment process, right?
Kovid Batra: Yeah. Perfect. All right. I think moving on to something which you just talked about, like you should allow the teams to do it themselves. You should work as an accelerator there. So, this is more around giving them autonomy. So, how do you think we can bring this autonomy mindset or how do you think we can improve this autonomy in the teams and inspire them to probably deliver more? Because when people are autonomous, I’m sure they move faster. They feel more accountable. There is more value delivered in that scenario.
Alexandre Goedert: Yup.
Kovid Batra: So, how do you do that? Or how do you recommend to do that with different teams?
Alexandre Goedert: Yeah. Yeah, sure. I think CI/CD is actually a mean to an end, right? So, when we talk about autonomy, I think what something that is very important in delivery teams is to connect the software delivery process with the business to start. And, it seems obvious, right? But in many places, you have this multiple layers of teams, people, and processes that are sitting between the software is deployed and the actual value that you have from a business perspective, right?
So, I still remember when I once back in the day, I had to develop a fancy 3D visualizer for market data used for financial instruments.
Kovid Batra: Okay.
Alexandre Goedert: And, we had a BA that tried to capture the requirement from the user. And then, it was our proxy to the business. Past it was, we took one month to develop some beautiful 3D charts. At the end, the client said, “Okay, it looks beautiful, but actually, it’s useless for us from a business perspective.” Right? So, I think that’s the first thing. So, you need to.. Many people have POs nowadays, but I mean, is the PO really a representative of the business? Do you really have autonomy of pivoting your backlog if you’re required to, right? So, I think that’s the first step.
And, I think people should start having observability for business metrics as well. So, what are the KPIs that are lagging or leading that indicate that what you’re developing is making an impact, right? So, if I talk about e-commerce, for example, you might think about a conversion rate for a sales pipeline. So, what is the conversion rate after I do every release of my product? What’s the impact of the conversion rate in the total revenue of the company? There’s a correlation or not? And, the developers should try to explain that. So, I think that’s the starting point. And then, if you have that combined with automation and a good software process.
Kovid Batra: Yeah. Got it.
Alexandre Goedert: You can achieve real, real autonomy. Yeah.
Kovid Batra: I think this is a very, very interesting point. This goes long way actually. If people have clarity on the impact that they’re gonna create, their brain starts working in a very different manner than if you just tell them, “Okay, do this piece.” Like, accountability kicks in, your curiosity starts popping up, right? You tend to think of ideas that could actually get things done, and you become more agile also because you know that you want to achieve this. If something is defined and it’s not working out, you are seeing it in real time, you are quickly adapting to something else, which could really work out according to you. So, I think that’s a very interesting point where autonomy can be built by bringing that visibility of the business metrics.
From the point of business metrics, I think, for sales teams, for support teams, there are always some KPIs defined, people are looking at it. If you go to the juniormost salesperson to the Head of Sales, everyone knows that, okay, they need to work on the revenue or they need to close this client, which would bring so many dollars, right? With engineering teams, I feel, there is a little bit of a gap. I’m not sure how you think about it. So, I would love to know your opinion on how you define success for an engineering team and how you measure it, how you find inefficiencies there and then try to improve on those right?
So, I hope I made my question clear there.
Alexandre Goedert: Yeah. Yeah. Is it clear? Yeah, it’s clear pretty much. So, I think that the problem is that developing software is expensive, right? So, it is even more so if you need to break your system every now and then to add new features and that unfortunately happens very often, right? But, that’s no wonder that many different corporate departments, they just want to know how IT is performing as a whole, right? So, there’s a lot of pressure over CTOs and these kinds of roles. So, sometimes it’s quite a difficult conversation for non-technical people when engineers, they have to constantly excuse themselves for a perceived bad performance, right? So, it’s the perception that IT is always lagging behind. So, I think the problem is that we need to explain these technical reasons in a way that people can actually relate to them.
So, before actually measuring, I prefer to start optimizing the flow and capturing the metric, what a normal metric looks like. So, we always have this problem of business coming up with estimates and people have to say, “Okay, I think it’s nice.” But, no, no one knows at the end, right? So, what we prefer to do, at least at ThoughtWorks with our clients is, let’s start the first iteration. We optimize the flow to a minimum level, and we try to see what our base is, what’s our throughput after a couple of iterations. And then, let’s start to measure those things, right? So, how many cards we have for iteration. Usually, one thing that we also try to cover is DORA’s four key metrics. So, okay, what’s our lead time from idea in the backlog until deployment? What is our time after the commitment to the deployment? What’s the change failure percentage? So these, these things we, we try to measure together with the throughput, and then we try to interpret what is happening after each iteration, right? So, sometimes you have a lot of outliers. So, maybe you have one card that it was too big and was poorly captured. And, this thing is dragging your lead time as an average, right?
So, I think what you need to create is this habit of normalizing what are the metrics for different teams, acknowledge that each team is different, and then try to use that as first signals, but then interpreting what reality looks like after each iteration, right?
Kovid Batra: Yeah.
Alexandre Goedert: So, I think it’s very dangerous sometimes when people try to come up with metrics from outside because in other departments, I mean, if you talk about sales, it’s pretty easy to have a target, like, okay, what amount of leads we have and how much leads are converting, and what’s the revenue that we have projected, right?
Kovid Batra: Yeah.
Alexandre Goedert: In software, it’s a bit harder than that. So, we need to create ways to communicate, a sense of performance, but that’s not all. We need to always interpret them and explain to the outside non-technical audience in an easier way.
Kovid Batra: I think just to add onto this, I feel we measure velocity, the quality, throughput, and then we have these DORA metrics to enable us to measure that. What I feel is that this is very critical. So, it’s like engineering is a function which is always enabling the whole business. Like, depending on the nature of the business, the percentage would vary. But, at the end of the day, if I look at a product team and an engineering team, I mean, they should not be looked at separately. I feel they should be one unit, because at the end of the day, what product is going to deliver cannot be accomplished without having that feature or a release in place, right? So, for an engineering team and for a product team, the metrics they need to actually look at to create that impact should be same, like it could be something as simple as user satisfaction, right? Like, after every release, how the satisfaction of the user is growing, let’s say, if it is aligned with that particular metric. And, let’s say, if that is not working out and you’re not seeing the impact there, then when you deep dive and try to understand what could be the reason behind it, is it the bad user research or is it the bad quality of the software that we are producing here? And then, comes the point where you say, “Okay, quality is bad.” Then you jump into those metrics and then look at it.
Alexandre Goedert: So, I think a combination of these business and technical metrics, as you mentioned, yeah. Yeah.
Kovid Batra: Yeah. I think that makes sense. It was really an interesting point there. And, lastly to conclude on a point here. I mean, I just wanted to understand it from you. When you look at the throughput of the teams or how they’re doing velocity-wise and everything, I’m sure there are certain cultural practices that you are ensuring to have a good developer experience also, where you take care of the developers, where you take care of their well-being. So, just wanted to understand, how you ensure in your teams that a good developer experience is there, and…
Alexandre Goedert: Yeah, yeah. Yeah, I think that is a very good point. I was a bit not skeptical, but I, I didn’t believe, for example, in pair programming as something to use constantly before I joined ThoughtsWorks. And, I was amazed to see that we actually use it quite a lot and so this is 1 of the things, right? So usually inside a team, I mean, staffing for technical teams is very complex, at least inside our company, right? So, you need to find this right combination of people that it’s a benefit if they can work together or not. And then, there are also people, so maybe they don’t get along with each other. There are many variables. So, what I like about pair programming is that it enables you to usually level up the team according to technical expertise, according to the one person that knows best about a particular tech stack, for example. You should do a proper rotation in pairs. It could be after one week, after one iteration, after a couple of days, depends on the team. But in my experience, it helps a lot to create this sense of support. And you know that you are not alone, that you can count with other people, right?
We also like to have these sessions we call ‘Dev Huddles’, usually on a weekly basis. And, I think it’s important for new teams. So, if you need to take an architectural decision, you’re not quite sure, you can have this huddle to actually talk with the team and maybe you capture a decision as an architectural decision record at the end. It also helps to create that sense of, okay, it’s a collective ownership of the code base, right? You should read the code base, you shouldn’t know which person wrote each part. It, it should be a collective like standard. So, I think these practices help a lot to achieve that.
Kovid Batra: A lot, yeah. I think that is a very good example actually. And regarding pair programming, I have been hearing both sides, but, if I have to, like personally, go for this opinion, it really works, I feel so.
Alexandre Goedert: No, and to be honest, I mean, I don’t think it’s something to do all the time. For example, there are certain tasks that are quite mechanical. Maybe some of them you can automate with AI nowadays, but still, if you don’t need to think a lot critically to write the code, maybe you should just do it yourself.
Kovid Batra: Yeah, yeah.
Alexandre Goedert: At the end of the day, as Martin Fowler used to say, right? “Our limits in velocity is not dictated by the speed on which we can type in the keyboard, it’s by the speed of thought.” So usually, if we have two people, they work faster.
Kovid Batra: Yeah. Makes sense. Perfect.
I think to sum up this point, I feel looking at a lot of aspects of an engineering team is very important. So, just to like, put out loud these DORA metrics are important. Developer experience, the processes that are built around having a good developer experience are very important. So, probably product and engineering can have similar goals, but when it comes to the KPIs or on daily or weekly or sprint level, you have to look at how people are doing or efficiency-wise people are doing, maybe product has different metrics and engineering teams can have different metrics.
So ultimately, it is important probably to have that measurement in place, so that things remain on track. But yeah, I think it was really, really interesting to know those aspects from you, hearing those hands-on advice that you have just shared. So, thanks a lot for this, Alex. I really loved talking to you.
Alexandre Goedert: Thank you for the opportunity.
Kovid Batra: Great! All right. So with this, I think we’ll end our episode. Any parting advice for our audience?
Alexandre Goedert: Yeah. I mean, I think one of the things is like, try to get more ownership about what you deliver from a business perspective. Don’t think it’s normal to accept tech debt, try to correlate that with business and money value right? So, as technical people, we need to be able to explain what we do, even though we have to translate it. So yeah, my main advice is like optimize your flow first. Try to connect to business value and try to create a team environment that is good for everyone.
Kovid Batra: Perfect. Thank you so much.
Alexandre Goedert: Thank you.
Kovid Batra: All right. See you. Bye-bye.
Alexandre Goedert: See you. Bye-bye.
Implement DORA metrics, gain dev visibility & drive success in your teams.
Try Live Demo
