August 16, 2023
As a product manager at Jellyfish, I have the honor of discussing how to effectively make and communicate trade-off decisions when it comes to managing the delivery of projects with engineering, product, and program management leaders.
So how do we mitigate delivery risk when communicating engineering trade-offs to the business? Let’s discuss the trade-off decisions in the context of software delivery management, why making trade-off decisions can be challenging, and how to improve the decision-making process to mitigate those challenges. How should we think about the decision-making process depending on where you are in the deliverables lifecycle? And how do we communicate engineering trade-offs to set better expectations with stakeholders, which we know is a big piece of this.
Trade-off decisions in delivery management
First, what do I mean by trade-off decisions related to delivery management? If I had to summarize this in one sentence, it’s the approach technical leaders take to navigating the following questions:
- How can we accelerate the delivery of this project?
- If we had two engineers, will the project be delivered on time?
- What if we had four, five or six?
In short, it’s shifting engineers, their time, energy, and focus around in an effort to get top-priority deliverables across the finish line on time.
These trade-off decisions come up in many contexts, such as prioritizing new work against other deliverables already in flight. Or maybe leadership agreed to a new client commitment to close a deal, and so they need it to be delivered by a specific date. Alternatively, sometimes leaders ask to accelerate the delivery of deliverables already in flight, or priorities will shift and create a new top-priority deliverable to address right now.
There are a variety of reasons why trade-offs are required, but the reasons don’t make it easier to navigate the trade-off decision-making process.
The challenge with trade-off decisions
Why is making trade-off decisions so challenging? As an engineering leader, whether a lead, manager, director, or VP, how often have you heard, “We need to shift priorities now,” from your business counterparts? When this decision-making process happens in times of chaos or crisis, decisions need to be made quickly. As leaders, you want to do right by your teams, but you may be operating off of limited data, potentially a messy spreadsheet process where you’re trying to extrapolate insights. You’re also operating from your gut and using your best judgment in these rushed moments. You move forward communicating these changes and plans to teams, trying to minimize disruption in team productivity and happiness.
What often doesn’t happen is discussing the follow-up question, “But if we do this, what are we giving up? What’s getting the boot? How will other projects be impacted? Is this a trade-off we’re actually willing to make? Let’s just take a beat here.”
As a result of not acknowledging these trade-offs, unfortunately, we end up over-committing. It’s all in good intentions. We’re humans! We’re trying to do a really good job, but when we over-commit and therefore don’t deliver as planned, it doesn’t really instill confidence in leadership. And honestly, teams just feel the weight of unfair expectations due to poor expectation setting.
So how to make the trade-off decision process better? We’re not promising to have all the answers, but I wanted to discuss some pro tips and frameworks I’ve learned so that we can turn these moments of chaos into moments of clear expectation setting and build trust in our teams.
The levers we can pull to accelerate delivery
Engineering managers are empowered with three “levers” that can be pulled at any time in order to accelerate delivery and plan resources accordingly at different parts of the deliverables lifecycle.
First, there’s the project scope: the size and complexity of a given deliverable. If you’re farther into the development on a project, this usually manifests in issues and story points on those issues. If you’re early in the planning process, this might manifest as your best guess, basing your assumptions on work your team has delivered in the past. It could be work in the same part of the code base or something you recognize has a lot of unknowns in it. Maybe it’s just a similar type of work, another chunk of database migration, that sort of thing.
There’s also the number of developers on a project, meaning the engineers actively working on the deliverable, and making code changes to build out the feature.
Lastly, there’s the percentage of the developer’s attention, meaning how much of the development effort they spend on this deliverable compared to everything else on their plate. Out of all the time a developer is spending building out features, what percentage of their time is spent on this one in particular?
The secret to effective forecasting and managing delivery risks come from knowing when to pull these levers, and adjust each of these parameters. In my next blog, we dive deeper into some examples based on real-life scenarios that demonstrate when to adjust each vector based on where you are in the project delivery timeline.
