2 November 2023

When I wrote about the importance of a technology vision, strategy, and roadmap, I said engineering time is always a scarce resource. It’s important to understand that I’m talking about time from all the people involved in building and assembling (“engineering”) software: designers, researchers, architects, engineers, product marketers, and their leaders! A small team might not have specialists in all of those roles, but somewhere along the way someone usually does the work expected of each of those roles.

A technology vision, strategy, and roadmap is one tool that helps product and technology people with one of the most important parts of their jobs: telling a story that makes it possible for the whole business to participate in prioritising their work. When a business lacks alignment on balancing the competing demands for engineering time, fingers are pointed, blame is laid, and ultimately the health of the products and the happiness of the customers suffer.

Beyond a vision, strategy, and roadmap, I’ve found that establishing a “taxonomy of demand” and a model to visualise trade-offs are two more tools that product and engineering teams can use to bring alignment with other parts of the business and avoid the perils of “lazy rhetoric”.

Lazy rhetoric: taking control of the narrative

I learned a lot about working with stakeholders from an executive I reported to. She would identify “lazy rhetoric” that circulated in the business we worked in. Lazy rhetoric is something that once heard is easy to repeat: but doing so doesn’t add any value. It can also amplify and extend the life of unhelpful company myths. I find it turns up a lot in prioritisation conversations when engineering capacity is being fought over. Some examples:

Engineering:

• “We have too much tech debt”
• “The company keeps changing its mind”
• “No one will work on that codebase: it’s too messy”
• “We do sales-driven development”

Sales:

• “Development is too slow”
• “Product don’t really understand the customer”
• “We don’t innovate”

The same leader talked about the importance of taking control of the narrative. Teams building software can choose to be victims of lazy rhetoric - or they can elevate the conversation so constructive debate can be had and decisions can be made!

Making sure everyone understands where demand for time comes from and has a common language to describe it is a solid first step: a taxonomy of demand…

A taxonomy of demand

When I worked at Xero, our technology team put a lot of effort into establishing a “taxonomy of demand” (ToD). The team analysed the reasons behind work that had been delivered over many months and classified it. The classifications reflected both the kinds of work that any software as a service business has, and also categories more important to Xero.

It’s also useful to put a discretionary vs non-discretionary lens over the demand:

• Discretionary work: work that we can defer (e.g. new features, re-architecting for scale ahead of the actual demand, backlogs of bugs that are not impacting customers)
• Non-discretionary: work that just has to be done (e.g. fixing bugs impacting customers, keeping systems running)

Whether the work is discretionary or not and whether it originates from the technology or the product roadmap, it’s all a source of demand for engineering time.

At Xero, the top level categories were:

• Run the business (non-discretionary): everything necessary to keeping the business operating, customers up and working, and to stay compliant
• Scale the business (discretionary): remove bottlenecks to growth, e.g. for Xero this was mainly modernising applications and creating an integrated data platform
• Grow the business (discretionary): creating value for new or existing customers and driving adoption and engagement with better product-market-fit

Another example comes from when I was the founding CTO at Ambit: an AI-enabled conversational user experience platform startup. Ambit was an early stage business with more capacity for discretionary work. I broke the product strategy into three simple demand areas based on what was important at the time:

• Build: fleshing out features that existing customers were asking for and incrementally evolving the architecture
• Innovate: creating points of difference with novel technology and approaches
• Channel: expanding capabilities that opened new routes to market

Here’s a visualisation of the Ambit ToD:

Non-discretionary work includes what I prefer to call “necessary engineering”. As an example of necessary engineering, consider third-party dependencies. Modern software is heavily dependent on third-party frameworks and libraries, and these will have a steady (or not so steady) stream of new releases. Falling behind on upgrades means incurring a debt that will have to be repaid later: increasing the likelihood that known vulnerabilities in security will be exploited or defects will cause problems for customers. Getting alignment on and acceptance of what non-discretionary work is avoids relitigation every time cross-functional planning rolls around.

Over time, and as it becomes more refined, a ToD becomes a common language between people doing the work and their stakeholders. By capturing the effort going into product and engineering work and classifying it against the ToD, a picture emerges.

Having a realistic view of where the team’s effort will be applied means cross-functional planning can start from a realistic footing. If the tech team knows that 10% of team time for the last two quarters went into supporting incidents and 5% was spent keeping up with third-party upgrades, then it is clear to stakeholders what the team is “doing the rest of the time” (when they are not delivering features). This helps establish how much capacity is truly available when debating how to invest it across the discretionary categories. A realistic view of capacity also makes it easier to have conversations about growing or reducing the size of teams.

To communicate choices about how time is or will be divided between the classifications, I find a visual trade-off model is also useful…

A trade-off model

At Ambit, each quarter, I used a dot on a triangle as a simple way to convey how our planned investment in the upcoming quarter was a tradeoff between these dimensions. The investment is represented as a rough percentage of overall team capacity for the quarter. Here’s an example from back in 2019 where we made an intentional choice to increase discretionary spending in “build” and “innovate” between two quarters, sacrificing new routes to market to better resource the non-discretionary work in “build” and push harder on novel differentiators:

Simple visual models make the reality of planning choices stark. That might lead to uncomfortable conversations, but it’s worth it to ensure understanding is shared.

Wrapping up and next steps

Once a technology vision, strategy, and roadmap are in place, a taxonomy of demand and a trade-off model are two more tools that product and tech teams can use to enable the business to align on sharing precious engineering time around.

Rich Mironov has an excellent article on what he calls “The Chocolate Cake problem” which includes “visible C-level scorekeeping for sales-led specials” - definitely worth a read.

All this alignment is great – but it won’t necessarily show a picture that every stakeholder wants to see. It’s not unusual at that point for someone to say “what if we give you more money - surely you can go faster?”. In the next article I’m going to tackle why that is unfortunately not always possible.

If you want to find a way to share previous engineering time around: I can help! Read more at cronin.nz or drop me a line at gareth@cronin.nz.