Focus not on the task, but on the problem behind the task

Consider the following situation: A team is asked by their Product Manager to implement features X, Y, and Z into an existing system.

The team then organizes itself and executes the project. After a certain amount of time, they delivered exactly what was asked of them. But then, one of these things happens (choose at least one):

• The features work only for the happy path, failing miserably at any sort of edge-case
• The features work as expected, but were designed so badly they are immediately considered tech debt
• The features work as expected, but are considered useless by the users of the system and end up completely unused (they do not solve those users’ problems)

What do you think happened here? Is this the Product Manager’s fault for giving wrong requests, or the engineering team’s fault for not understanding what was asked of them?

Some people will say this is the PM’s fault, and in some cases it might be true. But the situation I want to cover here is the scenario where this is the engineers’ fault, because it’s something I’ve seen countless times throughout my career.

The reason the scenario above happened (when the PM is not the one at fault) is because the engineers focused too much on the immediate task they were given, when what they should’ve done is focus on the problem behind the task, by asking themselves questions such as:

• What’s the context behind this ask? Is this a larger project that includes other features and tasks?
• Who exactly is asking for this? (Does anyone actually need this?)
• What problem are these users facing that led to this ask?
• Did someone attempt to solve this problem before? What did they try to do?
• Who is going to benefit from this ask being executed? How would they use the solution?

It’s only after understanding this context that you can consider yourself ready to come up with a technical solution to it. But what happens a lot is that some engineers tend to immediately jump into problem-solving as soon as they are presented with a task, leading to solutions that despite being “accurate” when evaluating the task in isolation, completely miss the mark when looking at the bigger picture. In short, the issue was that the engineers in that situation had too much tunnel vision.

Understanding the context behind tasks allows you to come up with a solution that fits the bigger picture, making it possible not only to solve your users’ problems, but also to do so in a way that is clean, scalable, easy to maintain, and that benefits everyone (as opposed to being beneficial to you and your team, but a pain in the ass for everyone else in the company).

In The Staff Engineer’s Path, Tanya Reilly describes this as the Local vs Global Maxima problem, where the Local maxima means focusing on what’s good for you or your team in an individual sense (the tunnel vision situation above), and the Global maxima means focusing on what’s good for the company as a whole, regardless of whether or not it would be ideal for you as an individual (the big picture situation). In the book, she presents this idea to argue that this focus and ability to gather context about the bigger picture is a core ability of Staff+ level engineers and a minimum requirement for those aspiring to reach that level.

Although I agree with her that only Staff+ engineers should be expected to be masters at this, I do also believe that this is something everyone should attempt to do, regardless of level. Doing so not only improves your knowledge of how your company works and is structured, but also teaches you how to better determine what does and doesn’t matter when trying to solve a particular problem, enabling you to be more effective both at coding and at providing value for your company.