Most engineers focus on HOW to do something – not whether they SHOULD.
Engineers tend to be very intellectual – curious about how to solve problems, because that’s fun. But asking whether a problem should be solved is something everyone should be doing, at every level of an organization.
Dan recently started working for a great mid-sized startup (a departure from many years of ideating & building MVPs. During his interview, he was given a coding task – and part of the ask just didn’t make sense from a product perspective. He didn’t see how adding this feature would benefit the customer & the business, so he didn’t do it.
When Dan explained this to his interviewers, they were surprised – apparently no one had ever done this before. But they loved it. Because all organizations need contributors who can improve the bottom line of the business, not just execute a development task.
The Cost of HOW
The challenge here is that most organizations aren’t structured to empower engineers to make product decisions. And a result, it’s a skill that many engineers never cultivate.
And this makes sense – there’s a lot of value in splitting out functions and teams as businesses start to grow. But when your engineers are disconnected from the customer, the market, and why the product exists to serve them, there’s a cost, from…
- Wasted development dollars, to
- Lower employee morale (and potential burnout), to
- A “kitchen sink” product – rather than a lean machine focused on customer needs
Don’t get me wrong – having engineers who understand how to do something is critical. But HOW is only valuable after you’ve decided the SHOULD.
In fact, sometimes the best solution is one where you have to write no code at all – and that saves time and money.
But this runs counter to a lot of today’s work culture. We equate seeming “busy” with contributing value – and as a result, we’ve trained our engineers to do those tasks in JIRA, simply because checking them off shows their managers that they’re productive.
And when those tasks include features that aren’t really impactful? This has huge implications for employee morale because no one wants to work on something that no one will ever use.
Creating a SHOULD Culture
In a perfect environment, everyone is comfortable saying NO. The default is, we don’t work on something unless a customer really needs it. Because too often, the impulse is “this is exciting, let’s build it”.
Now, let’s say you do have an engineer (or you are an engineer) who IS thinking about whether something should be done. If that engineer isn’t involved with the product process until the development stage, saying NO threatens egos upstream – because people have spent a lot of time and energy up until that point.
In order to make this a part of your culture, you have to involve engineers at the beginning of the product ideation process. This has 2 key benefits:
- Engineers are deeply connected to the customer, their needs, and WHY a product is being built – so they CAN say no later on, with good reasons for doing so.
- Product / business stakeholders get early technical feedback, which can totally change how they approach requirements.
In practice, you’d have at least 1 engineer who will be working on features involved in product discussions from day 1 – from inception, to execution. So in theory, by the time a product brief is delivered to your developers, SHOULD has already been addressed from their perspective.
So that’s a perfect world. But in the real world, where most organizations silo product decisions from development tasks…
How can engineers develop a SHOULD mindset?
Think critically about whether or not this thing you’ve been told to work on makes sense to you.
If it doesn’t make sense to you, then either it’s not being communicated well enough, or the inherent value isn’t obvious. And if the value isn’t obvious to YOU (who know your company and your product), it isn’t going to be obvious to someone who is a customer.
Now, if you don’t feel like you understand your customers’ needs, go find out. Product marketers can be a great place to start. Talking to customers can be even better.
Because if you don’t understand what pain points you’re trying to solve, and who you’re solving them for, a task will only ever be a task. Key into the why and the SHOULD, and suddenly your code feels like real, tangible impact.