Key Takeaways
- Engineering-driven work (such as tech debt, addressing technical risks, or enhancing the system to open up new opportunities) often gets deprioritized because leadership and product management don't see the value in this work.
- In order to make sure engineering-driven work gets the attention it needs, as engineers we need to learn to communicate in business terms.
- Stories engage people and help you put yourself in someone else's shoes. Structure your message as a story where your business partner is the hero and you are the guide.
- Your story becomes more compelling, both for yourself and your business partner, when you back it up with business-oriented metrics and data, such as productivity, turnaround time, performance and quality.
- When you learn how to talk like a suit, your company, your team, and your career benefit. Your company benefits because they avoid the failures that can come from engineering work piling up. Your team benefits because they know they are improving the technology and working on things that make a difference. Your career benefits because companies value someone who can speak both the language of engineering and the language of the business.
One of the most common complaints I hear when I talk with engineers is that they feel they have to continually work on features, while the software and tools they work with become more brittle, inconsistent, frustrating and it becomes harder and harder for them to get their job done.
As engineers we shake our heads, wondering why our business partners (product owners, senior leadership, sales and so on) don't see the problems that are glaringly obvious to us, and are frustrated how they constantly deprioritize engineering-driven work (for example tech debt, addressing technical risks, or enhancing the system to open up new opportunities) over yet more feature work.
Meanwhile, our business partners (someone you work with who is focused on the business, such as a product owner, senior manager, or even a customer) may feel like engineers are always complaining about the quality of their software and their work environment, and are always wanting to work on making the technology better. Like any craftsperson, they want their stuff to be beautiful and shiny. But from their perspective, business constraints don't allow us to spend hours waxing and polishing the car so it gleams; sometimes we just need to get where we're going.
We could try and get our business partners to think like an engineer, but it's important to remember how much time we spent learning our craft. It is very specialized and complex. And, in general, you really don't have a sense for what works and what doesn't until you actually build software for a while.
So perhaps a better approach is for us engineers to work on "talking like a suit" - to communicate the importance of engineering work in business terms.
In this article I will offer ideas on how you can do this. I'll show how you can construct this as a story, including clearly presenting a problem, offering a solution, and showing them a path to success that solves their problem and avoids failure. By presenting your case in this way, you significantly increase your chances of getting these engineering problems addressed, while also becoming a better partner for the business.
Making your business partner the hero of the story
We need to understand what matters to our business partner . What problems are they facing, and what would success look like to them? They probably don't care much about things like "this API is really complex" or "this system is a web of interdependencies."
Throughout human history, stories have been used to engage and teach. When you tell a story, it draws someone in and they are taken on a journey. The structure of a story is a powerful and effective way to get your message across to your business partners. In particular, think of telling a story where your audience is the hero of the story. A great book that helps you construct a story from the perspective of your stakeholder (in this case your business partner) is called Building a Story Brand by Donald Miller. In this book, Miller provides a framework to help you construct a story by thinking about who the hero is (your business partner), what their problem is, and how you as a guide will help them navigate this problem, avoid failure and lead them to success.
A big step in this process is figuring out what the problem should be. You need to put your business partner in the center of the story as the hero, and place yourself as the guide. If you are not sure what problems they are facing, set up a meeting and ask them. Even taking this step will improve your relationship with them and help them feel heard and understood.
It's good to think about the problem at three levels: the external problem, the internal (or personal) problem, and the moral problem.
The external problem they are trying to solve is almost always related to delivering value for the organization: bringing in more revenue, reducing cost, avoiding customer churn, increasing opportunities.
The internal problem they often are facing is usually around them wanting to avoid looking bad to their peers and leaders; they want to be seen as someone who reliably delivers excellent results and can successfully navigate challenging situations.
The moral problem is an interesting one. This looks at how it just isn't right that things are the way they are. For example "Jeez, it shouldn't be so hard just to ship a single feature!" or "Setting up a new customer should be quick and easy; why is it this difficult?" It taps into an underlying frustration about things just not being right.
How does this all relate to technical work? Well, once we are clear on what our business partner struggles with, we can reword our problem statements away from an engineer's perspective towards the perspective of your product owner or business leader. Here are some examples:
-
Rather than saying "This code base makes it really difficult for me to get anything done," you can say "Any time a feature requires changes to this code, it takes twice as long to deliver and tends to have a lot more quality issues."
-
Rather than saying "Every time I want to make a change I have to get approval from an architectural board and quality engineer," you can say something like "Three fourths of the total time it takes to deliver a feature is spent waiting for approvals. If we can streamline these processes, we can significantly reduce the overall time it takes to build a feature."
Communicating risk
One thing that can be particularly challenging is often the problem that engineering-driven work is addressing isn't much of a problem now, but will likely be in the future. This is where you as an engineer have a particular obligation to try to communicate the risk in business terms so that the work gets prioritized.
For example, perhaps you are working with a monolithic system where all engineers work in the same code base and in particular have direct access to all the underlying database tables. This has been working ok so far, but the organization just got a bunch of funding and the plan is to double the number of teams in six months. You're already seeing challenges with teams trying to coordinate changes and the failures that occur when someone makes a change to the database schema that breaks someone else unexpectedly. How do you help them understand the risks they are incurring with the current system, and the importance of investing now to fix it?
Think back to what's important to your business partner. In this case it might be a senior product manager or a senior manager. They are going to be expected to double their productivity when they double the number of teams, but with the current architecture that's just not going to happen.
So you might set up a meeting with them where you walk them through the process of making a change and show them what that will look like with twice as many teams. If you have had experience of how this plays out in the past, tell stories from your experiences. Help them understand the likely outcome if you don't invest in refactoring now. If you can access it, you can even refer to some of the research on this subject.
But keep it focused on the impact to the business - we won't be able to meet our goals for the year because the rate of feature delivery will only grow incrementally even though you've doubled team size.
Say it with data
Whenever you can, bring data to the discussion. This data should be metrics related to business outcomes. Measure things like bug rates, average time it takes to deliver a feature, employee satisfaction, and customer satisfaction.
A great set of metrics to pull out are the ones that come from Accelerate. You may need to show how metrics such as lead time, deploy frequency, mean time to recovery, and change failure rate directly predict improved business outcomes.
But as much as possible, use metrics that speak to the problems and concerns that are top of mind for your partner. For example, let's say you are seeing that engineers are really struggling to understand a particular component - it is complex, poorly tested and poorly documented. What's the business impact of this? Likely, it takes longer to ship a feature because of a long cycle of testing and debugging, and even when it is shipped, it's probably going to have more bugs. So maybe look at the time to build a feature that touches this component versus ones that don't, and see if you can show a significant difference. Or look at the number of support issues and bug reports against that component versus others and see if you can see a difference.
By the way, if you can not see a difference, then that may actually indicate it is not as big of a problem as you think it is. It is always good to be open to that possibility. If you can't convince yourself that this actually impacts the business, then you're not going to have much luck convincing your business partner.
You can also use these same metrics as a way to measure progress and predict success for the project you will propose. For example: "We are currently shipping on average two features a month, with each feature taking 4-6 weeks to complete from start to finish. Most of that time is spent repeatedly testing and debugging. We also see a significantly higher number of bugs and support cases against this component. Once we refactor this component, we estimate that we'll be able to cut in half the time it takes to ship a feature, and we expect to see the bug and support cases go down by at least half as well."
Be their guide and give them a plan
It's not enough to help your business partner understand the problem. You need to play the role of a guide and show them the plan you have in mind for how to address this problem, avoid failure and achieve great success.
Usually this involves a combination of a high-level set of incremental deliverables, a request for time and people, and a way to measure success (for example using the data metrics I described above).
An example might be a phased approach: "Let's do a pilot with a few engineers working on refactoring out a particular workflow from this old code base. Then we can evaluate how that affects these key metrics and we can decide if we want to invest more time."
It's really important to deliver value early and often. That allows your stakeholder to gain confidence this is going in the right direction, and be more willing to continue investing. Don't ask for an entire team for three months before anything will be delivered.
Maybe it's actually not worth it
One great thing that can come about from working on telling the story from the perspective of your business partner is you may realize that the effort required to fix something isn't really worth it - the business value isn't really there. We have to admit that there are times when engineers do like to gold-plate things; doing this analysis helps us either gain confidence that the work is necessary, or allow us to accept that we should probably just accept the slight ickiness and move on.
For example, maybe there's a component that was written a long time ago using a style and approach that makes it hard to read and maybe hard to modify. But it only gets changed once or twice a year, and the feature that depends on it isn't really a key feature for the business. When that's the case, maybe it's not worth putting in a bunch of time to upgrade and refactor it. If it really bugs you, you could maybe put in a little time on the weekend cleaning it up. But it's probably not worth dedicating time or effort to it when there's probably other higher priority work to be done.
Get it in the same backlog
I have worked in organizations where engineering-driven work is handled using capacity owned by engineering. That may be useful for ongoing bookkeeping work such as upgrading libraries, but for one-off projects I have found that if you don't make the effort to get it prioritized in the same backlog as features a few things happen:
- Engineers don't apply the right level of discipline to make sure they are working on what delivers the most value to the business
- Our business partners have no visibility into what we're doing, and if push comes to shove those resources will be pulled on to other things
- Because it's not part of the visible backlog, when your business partners are asked what those engineers are working on, they're not really able to answer
I have therefore found it very useful to make sure there is only one backlog that everyone is working off, and that the same discipline is followed to justify and prioritize engineering work as is used to justify and prioritize feature work.
Practice makes perfect
The first few times you may attempt this, it may be rough going, and you may feel that you haven't clearly communicated the importance of engineering work. But keep at it - listen to the objections and concerns of your business partners, try to understand better what their goals and needs are, and think deeply about how engineering work impacts those goals.
My experience has been I keep getting better at it, and as I do so as a few things happen:
- I become a more trusted partner with my business stakeholders
- I am actually able to better communicate the value of our engineering work to the engineering team
- It increases my value as an employee, because I am more able to bridge the gap between engineering and the business
Suit up
I will always love doing the engineering work - coming up with designs, getting it to work, working with a team to get it to production, and seeing customers use it.
But I have also found that I am even more satisfied when it is clear to me and to my stakeholders that what I do is valuable, even if it's fixing our build tools, migrating a database to a new model, or writing a bunch of automated tests. There is nothing like seeing key business metrics improve and receiving a big thank you from the business, and think this was because you were able to show them something was important enough to invest in, that they would never have seen otherwise.