Your best engineer just asked: “Why are we building this?”
You could dodge it. Say “because the CEO wants it” or “it’s on the roadmap.”
But that’s how you lose your best engineers.
As human beings, we all want to do work that matters.
Even your most curmudgeonly and grizzled software engineer wants to work on the impactful stuff.
But oftentimes, the impact of a software engineer’s work on the larger business is obfuscated in layers of management and relies on other departments to illustrate or quantify that impact.
It takes a customer success manager or support staff passing along a customer’s glee with a problem being fixed or their success with some new feature, or it needs to come from some salesperson fresh off a deal closed by the new thing you just worked on.
Code is useless unless it gets used.
It’s one of the reasons engineering organizations struggle with goal setting in systems with OKRs and EOS – an engineer’s impact on the overall business is often indirect or difficult to directly tie to things like revenue through customer retention or new sales.
An engineering organization disconnected from customers or the users of their work not only struggles to get buy-in from individual engineers, but also tends toward navel-gazing work and gold plating that doesn’t serve those customers but instead makes engineers feel better about their work.
Polishing a turd of a product still makes something shiny to look at eventually.
When you’re managing engineers, part of your responsibility and a tremendous opportunity is to help build that context – to bridge that divide between the code your team is producing and the impact it has on the users and the overall business. This might be new thinking and a new muscle for you – especially if you’ve been promoted from engineering at a company that hasn’t yet done a good job of this.
Or maybe you landed in the job because you were always good at figuring this out for yourself.
In any case, since you have to communicate this connection to your team, you first need to discover and build it for yourself.
Over time, you can build up your own sense of this – of how some task you need to ask of your team connects to the problems the business or product is trying to solve – but if this is new to you, it’s best to be curious and unafraid to ask what might feel like dumb questions – but actually aren’t.
Some of those questions:
“Why are we doing this?” I’ve learned over time to let folks who manage me know that I’m a lot like a precocious five-year-old – I’ll ask “Why?” a lot. In fact, I’d often coach them that it’s easier if they start with the why so I don’t have to ask for it – or make a bad guess.
“What problem are we solving?” or “What’s the business opportunity here?” As much as I like starting with the problem, sometimes folks without an engineering background or one long buried bristle at thinking in problems rather than opportunities, but these serve as a slightly less direct way of asking “Why?”
“Who will be using this?” This one you hopefully don’t need to ask because you’re working in an organization with a clear user archetype or you’re working with a product organization and structure that starts with “Who’s using this thing?” … but if it’s ever unclear who the user for your work is – even if it’s an internal team – ask.
“How will we measure the success of this?” This is my favorite and perhaps the sneakiest way of getting to “Why?” because one measures what matters, so figuring out what you’re measuring can tell you a lot about what matters as a consequence. It also leads into various paths of curiosity that can lead you to dig further without raising as many defenses as the first few can sometimes engender.
Once you think you have the context down, repeat it back to the person or persons you’re asking these questions of – or check your understanding if you’ve made the leaps yourself. This helps set the context before you spread it to your team, helping to eliminate game-of-telephone style communication corruption.
Because once you’ve figured out and confirmed the context of the task or project, you now need to empower your team with that context.
You can also ask your team to ensure that you do this. The way I put it to the people I manage is to explicitly ask them to stop me if their context is unclear.
“If you’re working on something, and don’t know why you’re being asked to do it, or how it impacts the business, then I goofed up, and you should stop and ask for that info.”
Tickets should include this information – who it’s for, how we’ll measure success, what the expected impact is. Project kickoffs should start with this context, and it is handy to reiterate it when it feels like the discussion becomes unmoored from said context.
This context not only increases engineering job satisfaction – through knowing the impact of their work even as they start said work – but it also applies constraints to the problem solving process.
There are many ways to solve problems, and knowing the context that problem solving is happening within helps constrain the field of possible solutions.
If the business problem we’re solving is this quarter’s new sales, or a customer who is up for renewal next month, the solution can look very different than when the impact is new sales next year, or having something to announce at some far off corporate keynote.
Similarly, the appropriate solution can swing wildly if it is a tool that is intended for an internal team with no planned or possible customer-facing impact.
This context being shared and communicated widely can also help hone those solutions when engineers start shaving yaks or arguing about bike sheds. Reminding the audience about the context and problem can help prevent scope from ballooning in engineering – there’s enough scope to come from outside engineering without adding unnecessary scope ourselves.
If your project is long-running, you run the risk of this context shifting beneath you, making some solution that fits well before becoming inadequate to the task.
If you have regular check ins with your business or product partners, it’s always worth checking on your working context to see if things have shifted to a degree that it can change the shape of the solution your team is working on – and then communicating that change in context to your team.
This is part of my Editorial framework, a set of modular tactics and strategies that help software companies ship with speed, alignment, and safety at the same time.