Manage Engineering Risk, not the Team
Today’s issue of Crafting Tech Teams addresses the aspect of certainty, risk and estimation. Who’s responsibility is it to manage it—understand it—and re-plan when things don’t go according to plan. If you’re an engineer or tech lead and would like to have more influence in your outcomes, this is for you!
This is an introduction to this topic. The Lean-specific math on calculating risk pertaining to percentiles of cycle and lead time will be covered in a future post.
Stock Broker Analogy—The Death of asking for permission
The recurring theme in this issue will be the collaboration of two roles. A business client and a chief engineer. To better understand these two roles I have prepared an example in a domain you likely know very well: stock trading.
This analogy came up in a recent coaching call with one of my super star clients. It was very easy to produce the A-ha moment necessary to absorb this concept more easily. If you have a tech lead or team members who struggle with this—I suggest you forward them this post. I love to hear your success stories.
It displays the core concepts of responsibility vs. accountability when it comes to a joint-responsibility of outcome between a business and engineering representative.
You are the client in this exercise. The stock broker is the chief engineer.
The business client’s role: Set expectations and milestones for financial success. Investment, time, ROI, and comfortable level of risk.
The chief engineer’s role: Set a clear, unemotional strategy to deliver a requested level of certainty for returns on investment at the requested level of risk. Lower risk=lower gains and longer timeline.
The A-ha! Scenario
You set an ROI goal. A willing level of risk and a timeline. And empower the engineer (the stock broker) to manage your assets. They charge you a fee for this.
Here is the anti-pattern: Imagine that in this scenario the broker constantly messages you with following patterns…
“Hey, is it okay if I invest more into X?”
“Hey boss, do you mind if I sell this now?”
“Not going well, need to sell. Please confirm. RESPOND ASAP.“
… rather than outlining their strategy, adapting it and following their process.
It’s crazy right? Imagine they have something important to sell and don’t do it because you didn’t respond in time. The window of opportunity is missed.
Now take a deep breath. You know where this is going. Is the exchange above familiar to you?
.
.
.
I thought so.
Most tech leads and engineers I speak with shy away from the idea that managing the scope of features, the quality and the investment allocation is their responsibility, not that of product, business or—god forbid—an externally facing agency or client.
Yet it seems that that responsibility of managing the engineering risks is exactly what they are being paid for. This is hard on an emotional level as the lowest, simplest form of relationship between engineering and the business is compartmentalising responsibilities and divorcing engineering from product.
Such a team is always a cost-centre with very little room for financial freedom, growth or—in some cases—even basic job satisfaction. Once job satisfaction is out the window, so is employee retention.
The Three Pillars of Tech Teams
Niels Malotaux who joined me on the technologist podcast (video below) was the first person to spark the idea of letting go of the iron triangle. You know—the one where it says good, on time, cheap, pick two.
His counter-argument and lifelong mission is that business leaders shouldn’t be focusing on maximising two out of the three. Instead, the focus should be on balancing them to figure out how to deliver the right thing at the right time at the right level of quality.
Inspired by a recent discussion on LinkedIn, I tried to codify the various growth-pains teams I worked with and on faced and try to compare where they are and how much potential is still untapped.
This is an empirical attempt to oversimplify a team’s reasoning and they are subject to my own interpretation and fancy. Your milage might vary.
Level 1 - The team is struggling to deliver anything on time. This can be due to various reasons, such as poor planning, lack of resources, or unexpected challenges.
Level 2 - The team can deliver on time, but struggles to deliver expected quality. The team may be cutting corners or not prioritising quality in order to meet deadlines.
Level 3 - The team struggles to deliver expected quality on time. This is a more balanced level where the team recognises the importance of both time and quality, but may still face some challenges in achieving both.
Level 4 - The team can deliver on time, but struggles to deliver the right thing. This can happen when there are unclear requirements or misaligned expectations between the team and stakeholders.
Level 5 - The team can deliver the right thing on time, but may not yet be consistently delivering expected quality. At this level, the team has a good grasp of requirements and expectations, but may still face some challenges in quality assurance.
Level 6 - The team is fully playing the game. They are delivering the right thing, with the expected quality, on time. At this level, the team is continuously questioning and improving their processes, and actively seeking to create knowledge and improve their craft. They have learned how to negotiate with stakeholders who stigmatise questioning the roadmap and scope.
Unmanaged Risk & Unproven Confidence
An experienced (L6) team is 100% confident at the beginning of the project. Not only that they will deliver on time. But also 100% confident that the plan is WRONG. An experienced team has full certainty that they will deliver the WRONG thing at the end of the project based on their current level of knowledge.
Their object isn’t only to be on time. But also to question what the right thing is—especially given outside stakeholders assurances without proof that this is really really what we want and need.
I’m sure you’ve been in a situation like that. Think back on one such project now. Were post-delivery changes requested? Shocked dismay upon realising what they got isn’t what they expected. Blank stares as the product didn’t deliver on revenue goals?
In contrast, an inexperienced (L1) team is not fully confident they can deliver on time, but they are falsely confident that they are delivering the RIGHT THING.
That's where the Crux of Agile is.
It's not about estimates.
Or quality.
It's about questioning what the right thing is constantly.
MVP’s are especially difficult as they put high pressure on minimising the scope of the thing and the quality at the same time with very limited knowledge.
Ideally, an MVP should be built in days or weeks using low-code solutions. Not to work. But to create knowledge.
Knowledge that can be used to increase the level of confidence that the right thing is being deliver to the expected level of quality on time.
The Way Out
The software development process can be simplified into a very simple formula.
Invest time to create knowledge by building things.
Act upon the knowledge to increase your confidence.
Continue building if your confidence is high
Continue learning if your confidence is low
At the beginning of each project, the team’s project/business/engineering knowledge is at its lowest point. Confidence is low. So low in fact that the team will be in their right to question any estimated promises of delivery.
But they are professionals, so they will create knowledge by pursuing activities that increase confidence in delivery. This is the philosophy behind scrum.
We will look into the math of estimation, cycle time and story delivery percentiles in a follow-up issue.
For now I leave you with this question:
What amount of the product and feature risks that you are empowered to deliver is being managed by your engineering team?
This post definitely resonates with me - throughout my career I've noticed my outlook shift from 'We'll definitely deliver what this customer wants in 6 months!', through 'The problem is always lack of planning at the outset - that's why we're late or we don't meet expectations', and finally to 'Don't think too many steps ahead, nobody really knows where this is going to end up'. Admittedly, different projects require different strategies for planning, risk assessment etc - but on the whole I feel that regularly re-assessing where you and where you're going is the best way to deliver something everyone is happy with.
I've found that letting go of 'needing to know everything up front' was probably the most liberating development - but it definitely required unlearning a lot of advice I'd received early in my career. Planning ahead is obviously beneficial, but you need to know where to draw the line, commit to building something, and then standing back and seeing how it fits. Rinse, repeat!