How to solve hard problems

I’ve been thinking about how people solve problems in a “senior” role. While it’s ultimately just a title, success generally requires more than technical skills and feats. In a more junior role, you’d do well to just deliver a solution to a problem you’re given. But success beyond your constrained tasks is important in progressing to a more senior role. Defining a problem and building a solution is often just the beginning of the journey.

But this isn’t a post about what to expect based on seniority. It’s fundamentally about people who get things done (beyond personal goals) vs. people who don’t. I’ve made a non-exhaustive list of the traits I’ve noticed in people that solve complex problems. A lot of these principles have been personally valuable to everything I’ve achieved, and this is an attempt to make them plain so I can teach others to do the same.

When solving problems beyond your immediate self, it makes sense to:

1. Get people onboard.

When a team has existed long enough and has a broad scope of services, it tends to drift towards SMEs (Subject Matter Experts) for each piece. This is what I often see with initiatives that don’t succeed – An SME defines a problem and a solution that holds true within their scope, but the problem doesn’t only sit within that scope. They then invest time in building out the solution, but it never gets used or fully adopted. If they invested more time in aligning with the needs of other team members, they’d have come up with a better solution.

This can be a two-edged sword however. It’s difficult to please everyone. So,

2. Don’t wait for full consensus.

In diverse teams with different backgrounds and experiences, there’ll always be some disagreement about the nature of problems and their solutions. As someone solving any problem, your task is to get the majority to agree, and the minority to compromise, while forming an understanding of how and why they came to their stance. I’ve seen several useful initiatives that never got off the ground because a single team member did not agree. Meanwhile, the entire team continues to suffer the consequences of the problem. But getting consensus is easier if you:

3. Build lots of allies.

The more experience you have, the more it becomes clear that very little is achieved to solve cross-cutting problems without allies. The Staff Engineer’s Path describes “sponsors” who support your work from above, but I’m more particular about lateral allies here. These are the people that will speak up for your initiatives in different rooms and give you feedback that improves your solutions. You don’t need to have a ton in common with every ally. You just need to find common ground with each of them. This is particularly important if you tend to solve widely-varying problems. A more heterogeneous crop of allies means you’ll have at least one of them to discuss it with.

4. With enough eyes, a big problem becomes a small one.

This is one of my favourite lessons from The Cathedral and the Bazaar. When solving problems, it’s easy to enter a silo and get stuck. There is great power in getting multiple different eyes and lenses on a problem. One great example of this is in incident response (IR). The reason IR processes are designed that way is to get the right eyes on the problem, but also to get as many contextual eyes on the problem, either from the same team or multiple teams. It’s also much easier to get more eyes on your problems if you:

5. Treat your users and stakeholders as first-class citizens.

When building solutions to problems (tooling or frameworks, for example) that people will use, it’s important to treat those stakeholders like royalty. When someone reports a bug, fix it fast and have them retry. If this is not possible, respond in a reasonable time and give them a ticket to track. When you do treat people well, they become champions of the solution, and of you. They help you spot more novel bugs and advocate for the solution.

One possible drawback though is some people tend to give up on tools immediately they spot a bug, and don’t report said bug. So it’s also your duty to:

6. Test more than your users.

Never consider a task complete until you can reproduce and test in production. Even on a deadline, it’s better to delay than to push new code and wait for someone to use it. Your users should only discover novel bugs that you weren’t able to find. And whether you have bugs or not, you should always:

7. Communicate often, clearly, and early.

Let the relevant stakeholders know what problems you are thinking about and why you think they’re important. When describing problems, make sure you speak in the language of the target audience. ICs often care more about execution, and execs care more about broader impact. The reason you may not be getting traction on your initiatives could be a mismatch in the way you communicate their importance. By communicating early, you also learn that:

8. Not every idea is a good idea, but it’s better than having no ideas.

You will eventually learn that it’s possible to have tremendous ideas, but it’s also possible not to. I’ve had several ideas that seemed fantastic in hindsight, but I either overestimated or underestimated the problem, or was just focused on the wrong problem at the wrong time. Speaking to people about ideas and problems gives you perspective, do it often.

9. Don’t be afraid to put things in the hands of users.

Quite often, you’ll think about edge cases when building and wonder if they’ll actually hold true in production. Instead of deliberating or trying to cover every edge case in logic, it’s better to put the solution into the hands of the actual users and see what happens. You can’t expect to have all the answers in one straight swoop, so a strong feedback cycle helps you build better solutions.

10. Learn to “manage”.

Do the boring glue work for initiatives you care about. Regular meetings work wonders for progress. You’d be surprised by how much you can get done with a group of people working towards a solution if you bring them together regularly with clear agendas. It’s also important to know when to stop them, though. Meetings should always be optional, and if they do not bring value anymore, don’t be afraid to stop them.

There is a lot more to be said about solving the right problems, and solving them well. But I’ll stop here and continue to reflect.

Until next time.