HomeArticlesHow to Find Solutions After You've Identified a Problem

How to Find Solutions After You've Identified a Problem

Want to receive these updates in your inbox? Sign up for my mailing list using the form on the right. (or below if you're reading this on your phone)

So you're giving your team space to innovate, and together you've identified an area in your process that could be improved.

But no one has any idea how to fix it.

For instance, let's say you've clearly identified that the number of bugs and regressions getting into production has risen sharply in the last few weeks.

The naive way to deal with a problem like this is to say "Hey everyone, there have been a lot of regressions lately. We need to be on our toes and more careful about our code." A slightly more effective thing to do is to then start measuring the number of regressions over time and checking in periodically to see if it's improving.

The more solution-oriented approach is to start asking why, and not stop until you get to a root cause with a concrete behavior that can be addressed at an organizational level. For instance:

Problem: Lots of bugs and regressions getting into production lately

Q: Why are bugs getting into production lately?

A: Because some PRs don't include unit tests

We could stop here and say "Everyone write unit tests". Instead, we ask again:

Q: Why do some PRs not include unit tests?

A: Your newest developer speaks up and says he didn't know he was supposed to be writing them (gasp!).

We could stop here and say "Well now you know. Please write unit tests." Instead, we ask again:

Q: Why did he not know he was supposed to be writing unit tests?

A: Because it's not written down anywhere, and everyone assumed he knew.

We could stop here and say: "Someone write that down somewhere." Instead, we ask again:

Q: Why is it not written down anywhere?

A: Because we have no system or precedent for documenting our operating procedures, or for peer code review.

That one feels good and actionable. Now you can figure out the places in your process to start introducing some low-maintenance documentation of operating procedures. Along the way we've also clarified for our newest developer that he should be writing unit tests. Much more importantly, we've improved a foundational way that we operate as a team, which will pay off on other fronts.

Treat your processes like you treat your software. When you find a bug in the system, don't stop investigating until you find the root cause. You'll create a positive feedback loop that strengthens your team, establishes a strong culture of ownership and improvement, and most importantly, prepares you to you grow.

Ben Wilhelm
Hi. I'm Ben.

I help small software teams stay productive as they add more developers.

I send a few emails per week with tips and ideas to help your team ship reliable code consistently.
"What we got from Ben was more than just expertise: it was expertise plus organized thinking, clear communication, good humor, and an obviously habitual willingness to listen before advising. We recommend him without reservation, and look forward to the next time we work with him ourselves."