We’re just four weeks away from Codemanship’s 10th birthday, and this might be a good time to reflect on how and why I started my developer training business, as it may hold clues about where Codemanship might go in the next ten years.
When I started the business, I’d been a professional software developer for 16 years. For the majority of that time I freelanced, working for a wide range of companies on a wide range of business and technical problems. Along the way, I progressed into leadership roles, and found more and more of my time being spent coaching and mentoring teams – with varying degrees of success. I also wrote and delivered training for a number of companies, so Codemanship wasn’t my first rodeo in that respect.
I’d attempted to make the transition to full-time training and coaching several times, but the dice never quite fell where I needed them to. It takes time to build up a business: to build a reputation, to build a client base, to build a livable income. And it’s very difficult to do that while you’re holding down a full-time job at the same time. I would typically try for 6-9 months, and then wimp out and go back to contracting.
The opportunity I needed fell into my lap in 2008. I was finishing up a contract with BBC Worldwide as a – and this was my official title – Software Development Coach. Whereas before, that side of my work happened “between the gaps” as I led dev teams, when time and resources allowed, now it was my full-time job. With the blessing of the management, I was there to help teams do dev better.
Alongside my permanent counterpart, Peter Camfield, we coached teams on what we might now call the “craft” of writing software. And over the course of a year, we saw some quite dramatic changes. It’s easily the most satisfying experience I’d had up to that point.
I get a real kick out of seeing dev teams being empowered to do great work, out of seeing the level of enthusiasm for and pride in their work rise, and out of seeing how so many of those great folk have gone on to inspire a good many developers themselves: people like Matt Wynne, Rob Bowley, Julian Everett and Hibri Marzook, who are today valued contributors and influencers in the developer community.
The experience at BBC Worldwide was, I now realise, very atypical, even though tech there was pretty typical of most organisations of that size. They had the people, they had the talent. It was there all along. All that was needed to set fire to this “kindling” was a suitable catalyst, which – it turned out – was me and Peter. Once we got the fire going, it burned all by itself.
I was fresh off a contract that, on paper, gave me the exact same goal. I had been working as a “Development System Architect” for a large software company, as part of a team that was charged with defining and imposing development processes and practices. This was very much CMMi territory, and I’d been hired for my uncanny skill at drawing boxes connected by arrows and my encyclopedic knowledge of arcane dev processes that no team anywhere has ever actually followed.
We produced reams of documents telling developers how to do their jobs, which, of course, nobody ever read. Sure, we had the full backing of the VP of Engineering. But that made no difference. After one year, nothing had changed. Nothing had improved. And this was by no means the first time I’d seen that happen…
I had decided – after years of watching top-down attempts at software process improvement fail to deliver meaningful, lasting change – to try doing something bottom-up; to water the roots instead of the canopy of the organisational tree. This, it turned out, was far more successful.
Instead of prescribing processes and practices from above, we started with the developers themselves and what sort of things got them fired up. More simply, we ignored the “system” and focused on the culture.
It started small, with regular lunchtime meet-ups where developers were invited to come along and talk about any topic they thought interesting. Eight people out of a department of roughly 100 came to the first one. That might sound like a failure, but I’ve come to realise that if you can find eight people in your IT department who would give up their lunch to share their ideas about software development, that’s something you can really build on: a solid foundation for change.
The audience grew each session, and for many it was their first experience of talking in front of other developers. By the time I moved on, pretty much everyone in the IT department went. And quite a few folk from BBC corporate, too. We had some big talks by some very well-known speakers in some pretty large rooms.
Sure, there was a bit of training, and a lot of coaching and mentoring from myself and Peter for the teams that invited us in. But I firmly believe that wasn’t what made the difference, in the long run. What made the difference was that dev teams found themselves working in a more inspiring, energizing environment. They were thinking about this stuff, and – most importantly – talking about this stuff. They didn’t need to be told to do it. They wanted to do it.
And then, like all families, some of them eventually flew the nest and spread that enthusiasm and inspiration far and wide, to companies like 7Digital, Songkick and the Co-op, to OSS ventures like Cucumber, to meet-ups and conferences like Software Practice Advancement, and the original Software Craftsmanship conference (in fact, the first one was hosted by the BBC). Some of that BBC Worldwide DNA can be found imprinted on businesses and teams and communities all around the world. For example, the list of “good habits” of TDD originated there.
I’ve seen this effect before in other companies, like ThoughtWorks and Google. It’s not their “development system” that makes the difference; it’s their developer culture. If you want talented teams of inspired engineers doing their best work, focus on building a strong developer-led culture in your organisation. You don’t need to make them. Just let them.
My experience at BBC Worldwide in 2007-2008 was so rewarding that I genuinely dreaded going back to the same old same-old on another gig. As it happened, the next contract was one of the least satisfying of my career; trying to deliver working software to a difficult client in difficult circumstances with micro-managers bearing down on us and totally unrealistic expectations. That made up my mind: I was getting too old for that shit.
The relationship I’d built with tech teams across the road in BBC corporate offered an “out”. They wanted training and coaching from the guy who organised all those spiffy lunchtime talks they’d been going to. It was enough work for a few years to allow me to focus exclusively on that, and build the client base Codemanship enjoys today.
Sure, it’s a small business, and in the grand scheme of things I make a small difference. But it’s immensely satisfying. Nobody was going to offer me my dream job, so I invented it. And ten years later, he we are.
And, because it’s my company, we do things on my terms. This isn’t corporate, top-down intervention. Typically, I’m not there because the CTO wants me there. (Quite often I’m there despite the management’s wishes!) My work begins and ends with the developers. They ask for the training – sometimes they have to beg and stamp their feet to get it, of course – and it’s 100% training for developers, written by a developer, and delivered, with a big dollop of developer rabble-rousing and advocacy, by a developer.
And I never forget: when it comes to meaningful, lasting change… It’s the culture, stupid!