Thoughtworks’ Tim Cochran on Developer Effectiveness


Subscribe on:

Introductions [00:05]

Good day folks, this is Shane Hastie for the InfoQ Engineering Culture Podcast. I’m sitting down across the miles with Tim Cochran today. Tim is a technical director at ThoughtWorks and is starting to get known for talking about developer effectiveness, which is going to be the subject of our conversation. Tim, thanks for taking the time to talk to us.

Tim Cochran: Hi, Shane. Thanks for having me.

Shane Hastie: Probably a good place to start. Who’s Tim?

Tim Cochran: I ask myself that every day, but my title is technical director at ThoughtWorks. What I am is a consultant and a developer. I’ve been with ThoughtWorks for over 15 years, and I’ve worked for lots of different types of companies. Right now I’m a technical director, but still very, very hands-on and still very close with technology.

Shane Hastie: What brought you to where you are today, particularly thinking about developer effectiveness?

Why focus on developer effectiveness? [00:53]

Tim Cochran: It’s an interesting journey. Over the around 25 years we’ve seen a lot of changes. So, we used to have to spend a lot of time evangelizing about agile and then DevOps and caring about automated testing, CICD, all those kind of things. Now we have to do less, because industry concepts and everybody wants to do it, and everybody is, everybody’s investing in these concepts and various tools that are popular, cloud and all that kind of things. And I’ve been working at different organizations and the interesting thing about ThoughtWorks is that we don’t just work at slower enterprise companies that want to transform, we also work for cutting edge companies that are about as good as you can get on the DevOps spectrum and on the productivity spectrum. Living in New York, I’ve had the opportunity to work at some of these companies.

And so as I contrast these companies, trying to put my finger on what is actually the difference. When I’ve managed them, managed the accounts or worked on the accounts, I can see that there’s a massive amount of productivity difference. Just like when we analyze or we show, what have we done for the last six months or three months with similar sized teams, just the difference. And of course you can say there’s certain things that of course are going to be true, like legacy technology, you’re not on the cloud and all those kinds of things, but it isn’t necessarily a platform or a tool or a technology. What are some of the investments or the cultural aspects that some of the higher effectiveness companies are working on? That’s where I ended up talking about this concept of developer effectiveness and this concept of feedback loops. And I think what I’m seeing is a lot of the higher effectiveness are really investing and intentionally, almost for a business strategy, definitely technology strategy and a business strategy, to invest in the feedback loops that I call out in the article.

Shane Hastie: Let’s explore that. When you say a feedback loop, what do you mean?

Feedback loops are a key differentiator [02:48]

Tim Cochran: So, as a developer or a product delivery team, most of what you do, is you’re making a change or you’re doing a bit of functionality. And what we see is that what that team wants to do is to validate or to get feedback that what they’ve done is correct and valuable. And that’s a very abstract idea of this feedback loop, but you can apply that to a lot of different things. So you can actually apply that to things that the developer does throughout the day, you can apply that to what a team does, and then you can also apply to more organizational, larger concepts. To give some examples of some of these feedback loops, some small ones are like, as an engineer, I write some code and I want to see that it works, but in a personal situation.

I write a little bit code and how do I know that it works? Well, I run it, essentially. I run my compiler, it compiles, and then I deploy it to my personal environment. That’s probably my laptop or maybe a personal cloud environment and I run it through my application server and I see that it works. I also probably are using a set of unit tests that maybe I wrote, or my colleagues have written, to make sure it works. That’s a very small feedback loop and that can be run, depending on the team, a developer might run that ten times a day or might run it a hundred times a day. I think that the high effective ones are the places where the developers can run that hundreds of times a day. That’s a very small feedback loop, but those other things that I mention is, as an engineer, I change a component and I want to know that I haven’t broken anything that depends upon that component.

Exploring the real value in CI/CD [04:26]

And conversely, I want to know that the things that I depend upon haven’t broken me. So, that’s another example of a validation of a feedback loop. And the reason why I think that some of these are important is sometimes a lot of it gets grouped together into, we talk about a CI or a CD pipeline, which is incredibly important. But sometimes we miss, well, what is the value of developers getting out of that pipeline. Why are we doing that? What happens then is then you end up getting into these discussions about tooling and then we forget, we get very dogmatic about doing something, like test coverage is a good example, we’re very dogmatic about a hundred percent unit tests. But then we forget, okay, well, what are we actually trying to do?

Tim Cochran: We’re trying to speed up, we’re trying to make our code high quality, or we’re trying to speed up product development. And that’s where I think that what I’ve been talking about with those feedback loops, it’s really focusing on the value to the engineer. And if you do that, then you can think about, what are the investments and the tooling and the organizational and process changes that I should be making to improving effectiveness. And thinking about that value going across organizational structures, team boundaries, thinking a little bit outside the box, that’s where I think these things are valuable. So it’s less about, how do I deploy Kubernetes or which CI server should I be using, what is the value I’m providing to my developer and my development teams?

Shane Hastie: How do we measure this? You’ve said, at the macro level you can see this in terms of how much a team produces over a period of time, but that’s quite a lagging indicator. At a team level, at an individual level, how do I start putting this into practice?

Different contexts require different feedback loops  [05:59]

Tim Cochran: What I recommend is thinking about what are the feedback loops that are important for you in your context, and I list out some ones that I see very common. An example, being one, a developer joins a team, I want to become productive. There’s some technical elements to that, but a lot of that is cultural and process related, so that’s one example. And it really depends, so some teams, especially fast moving, agile startups, if you work for one of them, you know that these companies reorg every three months or six months. So most important thing is change, so the ability to very quickly join a new team, work in a new technical or business domain, and become up to speed quickly. It’s important, but not every company is like that. What I recommend is, think about what are some of the feedback loops that you’re really trying to optimize for your company, and then you can measure it.

What I suggest is, you define, I describe it as the trigger and the outcome for those feedback loops, what is the starting point and the end outcome. And then you can measure how long it takes, you can measure how much steps, how much automation, how much manual, how much back and forth. But then you also got to think about the outcome. What we see sometimes is, folks are very focused on automation and speeding things up, but not like, am I actually getting what I want from it? So for example, again, back to the automated testing example, often regression tests, there’s a lot of focus on automating everything, but sometimes the output, the test…


Read More:Thoughtworks’ Tim Cochran on Developer Effectiveness