Getting Support for Technical Improvement
The CTO is responsible for making the right technical investments, but this isn't easy. Engaging the right level of support for investment requires skill. Here's a guide.
When I was first a CTO, a crucial part of my role was translating to others the state of our technology, the investments being made, and their impacts. While, as CTO, you were responsible for the overall budget, you still needed to make the case for the various investments in your portfolio. You must also negotiate commitments with your peers when those investments impact their teams.
Early on, it became clear that not every investment, even when it was clear to you that it was necessary, was easy to convey as important to others. This was a skill I needed to develop.
In my coaching, this same question has been a common challenge faced by CTOs I work with. This has been consistent across different-sized organisations, different experience levels of CTOs, and other sectors.
Noah Cantor and I focused our second episode of the CTO Life Line livestream discussion on ‘Getting Support for Technical Investment’. We selected this topic in part in response to this question from an audience member in our first episode:
In my experience, it is common for CTOs to have good instincts for the investments that need to be made. This comes from career experience in technical roles at various levels during their career on the path to becoming a CTO. The struggle for many CTOs is articulating the rationale for the necessary investments in terms others can understand.
For this reason, they may struggle to gain the support required to make the investments. Other investments might get prioritised, or cooperation to maximise the impact may not be forthcoming.
We covered this topic with examples from our career experience and delved into various issues. For a deeper dive I recommend checking it out.
We concluded with a summary of our discussion for areas to consider when planning to seek support for technical improvement:
Understand the need for technical improvement
Reframe the need in terms accessible to your audience
- what are the connections back to customer experience or risks?
Prevent technical debt from occurring
Track technical improvement and adapt based on progress
Be intentional about how you communicate and engage.
Understand the need for technical improvement
Consider where debt is coming from:
Is there pressure from the organisation to cut corners to deliver more quickly?
Are sales commitments being made that are contributing to less sustainable investments, such as inconsistent customer types or customers outside the target customer profile?
Is the leadership moving from whim to whim rather than using a congruent strategy?
Do the engineers not value practices that help reduce the risks or quality concerns?
Whatever the cause, the CTO must determine how decisions contribute to quality concerns or unmitigated risks and how to address this.
Exclusive reader offer:
How to get the board to say "yes" to engineering spend?
11 minutes video showing how to get the board to say "yes" to more budget for engineering
Before and after real example from a CTO client I worked with in a company of 4,000 staff
See what the CTO's message was when it was not approved by the board (continuously for 9 months!)
See what the CTO's message was when it was approved by the board in one meeting
Know how the CTO's presentation changed to get board approval straight away
See how CTO got $5M for a technical redesign.
Exclusive offer for CTOs reading this newsletter:
With the "GREATCTO" discount code you can reduce the BUY (not rent) price from £50 to £5. The discount code is valid until 21 April 2024. All we ask is that you review the video!
https://geekadelina.gumroad.com/l/yes
Reframe the need in terms accessible to your audience
It is typical to frame technical investments in terms of the solutions being considered. This framing might even be the most accessible way to communicate the work to the team likely to undertake the work.
The challenge is that outside of the technology team, it is unlikely to be the best way to be introduced to the investment for those further away from the technical work.
An ‘outside-in’ approach can be more accessible. Universal concepts such as the customer experience or business risks may be better ways to frame technical investments.
Identifying the risks and customer experience concerns or productivity improvements motivating the investments and working backward from these to make the links to the solutions being considered can provide people from other parts of the business to engage with these investments.
With this broader context, you may identify other opportunities to address technical improvement differently. For instance, an expensive technical solution may more effectively be addressed with applicable documentation that helps the users achieve the same ends.
I’ve shared some visual approaches to documenting these relationships in this post:
Prevent technical debt from occurring
‘Technical debt’ is a common framing for a subset of technical improvement. Some technical improvements result from investments that should have been made but weren’t.
For instance, some technical issues may not have been addressed as they were identified, or there may have been complete ignorance of the investments that should be made to ensure the services being developed meet customer expectations or help support business performance.
Addressing these gaps is a better and cheaper investment than correcting for these after the fact.
Track technical improvement and adapt based on progress
Once you have a reasonable frame for the investment that links the solutions being considered to the problems and the logical chain of connections that show the rationale for the investment to the risk being addressed, the customer experience improvement, or the efficiency to be achieved - you can also quickly identify relevant attributes to measure and track progress against.
Measurement can be made at various levels. A customer experience issue might affect a customer satisfaction measure tracked on a product. Such a measure is likely a lagging measure that changes slowly. Other things that can be measured indicate that the solutions being applied are working as expected, which will show change more frequently.
There can also be a range of intermediate measures between those leading and lagging measures that provide visibility on how successfully you validate or invalidate the hypotheses underpinning your rationale.
The sophistication with which this is approached can start and grow as the service's expectations and standards increase. What can help with engaging others is ensuring you lead with measures closer to universal aspects that are broadly understood. Even better is if it uses measures that are well-established indicators of performance.
As an example, measuring the availability of services, that is, ‘are the services responding when users access them’, might be understood to a degree by many in the organisation (although the thinking behind “4x9’s”, 5x9’s” terminology might require some explaining!).
In my experience, even though availability is a technical measure, it's simple enough and close enough to how the issue is experienced to be accessible, i.e., well understood by all audiences.
Regardless, even better than availability might be measuring customer satisfaction. Customer satisfaction ratings may be declining because people are struggling to rely on these systems because of their unreliable nature. This could be the metric that will help people across the organisation sit up and take notice.
The measurement the team uses to detect the potential for availability failure events to occur may be very useful for that purpose but may be less helpful in communicating the issue to a broader audience, at least for understanding its importance and the need for investment.
Once there is a common understanding of the need, visibility of these measures, and the ability to forecast issues, it may be useful to share upon request to build confidence that the issues are in hand.
Be intentional in how you communicate and engage
An ex-colleague of mine neatly summarised a helpful structure for documenting the case for investment Tang Tze Chin here:
As I covered in an earlier post, it can be ineffective to try to make the case for investment reactively:
It is better to proactively engage others, multiple times if necessary, to address the gap in understanding between where you have arrived in terms of seeing the need for investment and the audience just learning about it.
If there is background information that would help them reach the same conclusions you have, then it will be necessary to share this context. Sometimes, this is adequate to share as you make your case. Sometimes, it will help to establish these concepts ahead of time.
What I have found effective to reduce the gap of understanding as much as possible is to:
And also to:
This is a huge topic, but hopefully, this provides a framework for you to think about and start improving how you approach gaining support for technical improvement. Have you had any experiences where you successfully made a case for an important investment? Share your experiences in the comments.