I hit something of a milestone this year, I started managing developers. This didn't seem like a big thing at the time - simply a sensible internal restructure to establish clearer leadership responsibilities in my company and allow me to really focus a new team on trying to get a brand new product off the ground. It was only through later recollections and reading that that it occurred to me that leading developers as a non-programmer was perhaps a more significant change than I appreciated.
One recollection was Paul Gerrard introducing Rob Lambert for his keynote at EuroSTAR 2014 - out of the wealth of positive things that Paul could have highlighted, one he picked out was that Rob was a rare example of a tester who had transitioned to leading developers. It did strike me as rather a sad reflection on the state of testing that such a step should be considered unusual for a person of Rob's talents.
A second event was that I recently meet a former boss of mine for a drink as he was staying in the area. Having just returned to the UK after a period heading up development for a product company overseas, he was now looking for a new role but had encountered some frustrations. Coming back to the UK he was finding it harder than he expected to get similar roles because he didn't have hands on development experience. It seems that despite the fact that he had successfully run two product development teams in his previous two roles, his background in product management rather than programming precluded him from being a suitable applicant to an equivalent job, as for many development leadership roles the employer insisted that the applicant be a programmer.
A third trigger was when I saw this quote from this summary of a Mind the Product Leadership forum
"At the most innovative organisations, Product and Engineering report into the same leaders."
If I was to choose one word to characterise how I want the Product Development at Team River to behave it would be innovative, so naturally my confirmation bias went into overdrive on reading this. I'm aware that this statement says nothing about whether those leaders come from development or not. The fact remains that such an arrangement was unusual enough to be highlighted as trait of particularly innovative organisations.
I can't say I really understand why this is apparently such a novel arrangement. If it is the case that the most innovative companies align product and development to the same leaders, why do so many organisations insist on their development leaders being programmers when people from other roles could be just as capable, if not more so?
Doing the right thing ...
The two best leaders of development departments that I worked for in my earlier career both came from product roles. I've personally found product leaders to be more inclined to focus on the value and outcome rather than process and standards of a product development operation. To me the former is a healthier focus for a development group. The product leaders I've worked with tended to worry less about rigidly sticking to methodology than being flexible around delivering value in their own product context. This provides a strong motivational benefit for the teams they lead. It's far more engaging to collectively work to address risks to customer value than striving to deliver the perfect process.
There is naturally a risk that a focus on features over process can be just as damaging, however the most effective leaders I've seen have respected the team and delegated responsibility effectively to ensure that process decisions are made within the teams rather than being dictated. In short the strongest collective innovation and collaboration around effective processes that I've been involved in has been from teams headed by folks coming from product roles rather than coding.
... or not doing the thing right
By contrast I've seen some very poorly run development teams when the leaders have come directly from development roles.
I've found that some strong developers can have a very fixed idea of how things are done, which can stifle and suppress ideas from other members in the teams they are leading. I've seen more than one development team whose regular meetings descended into a process of repeating the same arguments about coding standards and methods between the development leads.
This doesn't just apply to coding. Methodology and process is another area where imposing certain methods or architectures on teams can result in resentment and frustration from those members who felt they could input more creatively into how the team work. Developers in leadership that I've encountered were more inclined to arbitrarily apply and insist on doctrine from books or development gurus, without questioning the contextual value of such practices, than more business oriented leaders. In one extreme example an extremely talented and capable developer friend of mine described to me working in a new role where he was reprimanded for delivering too many story points, as the development lead placed a high value on consistent sprint velocity and wanted to minimise deviation.
I have, of course, encountered some really good leaders who were developers. I also strongly believe that technical leadership is essential to help coalesce teams and drive progress - I actually recommended the introduction of more technical leadership to address some of the productivity challenges we were facing when I started working on the River agency programmes. What don't agree with is the argument that development skills are a pre-requisite to effectiveness in a role with overall responsibility for a software development operation. Strong leadership skills cut across disciplines and are more important than any technical ability when it comes to running software development.
What do I wish for?
Leading a development team on an entirely new product has been as challenging as it is exciting so far. As I wrote in this post my approach aligns with the principles of servant leadership, with all the challenges that entails. As a team we've had heated debates about the shape of the product; the value of certain features ; how visually 'shiny' an early stage product needed to be; whether to remove certain features; whether to automate tests before we're confident in our early features and all manner of other topics.
Through these discussions I've found myself wishing I'd had lots of things
- More time to work problems through before presenting to the team
- More access to users
- More experience of user research
- More design skills
- More real world examples of our target market
- More persuasive communication skills
- and more sleep
New Product, New Story
As Team River and I progress in this journey of getting a brand new product off the ground I'll be writing more around the themes of building a start-up product. It's a process that involves a wealth of mistakes, a huge amount of learning and a whole lot of testing across the whole process. I'm looking forward to sharing some of the successes and failures that we encounter as we go.
Photo by Ilya Pavlov on Unsplash
Post a Comment