Managing a product development organisation made up of multiple teams tasked with delivering functioning software means that you need to be constantly thinking about productivity. As your organisation changes, you need to be readjusting.
This post attempts to provide an outline for beginning to think about the challenge of improving productivity in a product development organisation.
I’ve written it because, although there is a significant amount of content out there, I needed my own model to consider the volumes of research, books, case studies and individual opinions. In particular, I wanted something that supported my somewhat unique lens having worked in executive teams, as a software engineer, in sales and in product. Much of the best information I found was “IT” driven so this is an attempt to bring multiple perspectives together and, ideally, transform it into something that IT and non-IT folks alike see value in.
I’m also sharing my early thinking to be challenged and gain a better understanding.
So, to start with, I want to give you (and me) a mental model for thinking about productivity from first principles, by considering the variables of product development productivity within an organisation.
Why measuring development productivity is hard
Ultimately, what matters is that you and your organisation get a return on your investment. If you spend $X, you want a return of two times $X or whatever internal target rate you have.
On the surface this seems straightforward to apply but in practice it is hard to be certain of returns at the outset, it is often hard to link one feature or bug fix directly with revenue, it’s often hard to measure actual cost and it’s often hard to attribute revenue, is the success a result of a strong sales and marketing team or because the feature was designed/implemented well?.
These challenges often get used as an excuse not to measure. But it can’t be. Measurement is essential. It’s essential for improvement and essential for management.
But if we can’t measure it using simple financial measures of return then how can we think about productivity?
Another place to start with unpacking product development productivity is with the smallest unit possible which is usually a single engineer or a single engineering team.
The Smallest Production Unit: A Single Engineer or Single Team
The smallest unit of production1 in a product development organisation is an individual software engineer or a small software engineering team (would only eat two pizzas between them kind of small).
I realise it might be an issue to conflate the two but for the sake of allowing large scale and smaller scale organisations to think about productivity let’s just roll with it for now.
By starting with the smallest unit we can more easily understand the factors that drive production. For the purposes of building up a theoretical model we will assume, for now, that the team exists in complete isolation and not as part of a larger organisation. Then later in this article we’ll add the factors that being part of an organisation introduces.
With an individual software engineer or team the factors relating to output are:
- Working on the right thing (prioritisation) – the features or functionality that is delivered needs to create value for the customer. The more value created, the higher the quality of the output. Therefore, selecting the right things and then working on those is an essential factor for high quality output.
- Time to market – this factor is about the speed at which a feature moves from being selected as the right thing to do to it being done and then the customer realising value from it. There are a few subfactors at play here:
- Once you gained some insight or data (e.g. customer feedback, analytics data) how long until something was selected to work on
- Once selected as the right thing to work on, how long until work starts?
- Once work starts, how long until development is complete?
- Once development is complete, how long until it is being used by the customer?
- Once it is being used by the customer, how long until they are getting value?
- Cost to benefit ratio (partly a function of prioritisation) – this is about how profitable the outcome is.
- Disruptions – disruptions interrupt cycle time, working on the right thing can increase costs or reduce the benefits delivered. The disruptions most relevant to this small unit are:
- Defects (Bugs) – Defects are issues with functionality that was delivered that prevents a customer from gaining value, such as performance issues or functionality not working as expected. Defects can interrupt output and represent problems with the quality of the output itself.
- Downtime – products not being available for access interrupt the output that the development team could be creating.
Some of the factors that haven’t been included but warrant a mention:
- Estimates v actuals – need to think about what they provide in terms of understanding productivity
- Points and velocity – On the surface this seems to be internally focused, product development teams need to focus on customer value. See also Story Points v Days.
Extrapolating to a Group
Now if we take an individual engineer or small team and then have it work within a wider group some additional factors begin to impact outcomes:
- Dependencies – waiting on or aligning with other teams will impact time-to-market.
- Collaboration – working with others necessarily introduces communication overheads.
- Standard practices – the need to work in consistent ways across the organisation.
Just the beginning…
The plan is that this is just the beginning of an exploration of product development productivity. Keep an eye on the blog or sign up for Terem news for future thoughts on this, reply in the comments or email me with suggestions or to start a robust debate.
Footnotes
I somewhat leverage the concept of a production centre or factory throughout this article. I realise that some may disagree with this association but it is used more for intellectual ease and because the executives I speak with also drift between thinking of their product development organisations as factories and R&D centres. This is mostly a topic for another day except to say that this article tries to focus more on the parts of the organisation geared towards delivering more so than discovering.