Many engineering teams struggle to produce.

We at Convex are frequently called in when the engineering team is nearly at a standstill and has lost the confidence of the organization. The culprit, in nearly all cases we encounter, is speed.

In this case I’m not referring to speed as an effect, but as the cause. Most engineering teams try to speed up by going faster, and as you might guess, it has the opposite effect.

The majority of software engineers with whom I have worked over the last 30 years believe that the best way to figure out how to write software, is to write software. You may have previously encountered this in a scenario that goes something like this:

“Hey team, Operations needs to be able to schedule appointments with end users.”

The team enthusiastically replies, “No sweat, we can get that done!” and immediately jumps into coding.

The team starts building and before you know it they’ve delivered…something. However, it turns out the “something” doesn’t solve the problem, or it’s buggy, or often both. The team tries to fix it, and this time they try to move a little faster because other projects have begun to back up. Before you know it the team is trying to deliver yet another fix for the feature that Operations still says doesn’t fit their process, and other departments are clamoring for their own projects which were supposed to be delivered months ago but are nowhere to be found.

Some version of this repeats itself every day in countless businesses, and it’s deadly.

Being stuck sucks. It’s costly and demoralizing. We’ve been called in to work with teams in this situation many, many times. Getting out of such a jam is beyond the scope of this post, but let’s talk about how to avoid getting into it in the first place.

Our focus? Speed.

Speed in the above scenario is, as I mentioned earlier, a cause. The team tries to generate outputs more quickly by working faster. This is extremely difficult to do when building software, and it’s only successful if the team has the necessary experience and the right framework in place.

Instead of trying to move quickly, the team must recognize that the right software cannot be built until they:

– Understand the problem
– Have sufficient grasp of the requirements
– Explore multiple solutions

Your team should be able to understand the problem that is being solved, and they must do so decoupled from a solution. It’s human nature to want to immediately solve a problem, so this will be a little awkward for early-career developers and even to those who have been at it for a while.

Discuss the problem with your team and encourage them to ask questions, but don’t let them talk about solutions. This is going to be like holding back wild horses with reins made of wet shoelaces, but do it anyway. Jumping to solutions before thoroughly understanding the problem can result in teams anchoring on a solution too early and ignoring other, potentially better ways of solving the problem. Worse, teams might instead build the wrong thing, as in our example above, and waste resources and time.

When the team understands the problem and can discuss it in depth with stakeholders, then it’s time to talk requirements. Requirements are the conditions or demands that must be satisfied by any solution in order to adequately solve the problem.

It is possible go overboard with requirements, but in my experience most teams spend far too little time gathering, enumerating, and understanding them. In most cases they only uncover requirements on their short hop to a solution, and this is what gets many teams into trouble. Spending a few weeks working on something only to find you missed a critical requirement can be a killer for a startup that has a short runway.

In an Agile process it’s not necessary to enumerate and thoroughly document every single requirement before identifying a solution and beginning to build, but it is critical to identify those requirements that are most important to the next phase of the solution.

Finally, once the team has a firm grasp on the most important requirements, they can begin to whiteboard potential solutions. No code should be written at this stage unless some particularly tricky concept requires proving out, in which case a tightly scoped proof of concept can be quickly and cheaply coded. Resist your team’s urges to write code right away. Have them whiteboard at least two or three different solutions and walk you through the tradeoffs of each.

Once multiple solutions have been considered and the team has settled on one that best fits the requirements of the business, then and only then should the team begin coding.

Two notes on this process:

1) Depending on the complexity of the problem, the entire above process can take either 15 minutes or many weeks. Even the apparently simplest of problems can lead to waste if a team jumps right to a solution and starts coding, so slow them down by requiring that they talk through the above process even for the smallest of problems. Eventually it will become second nature.

2) I’ve described the process as sequential (AKA “Waterfall”) but it works best if it’s cyclical. Work on understanding the problem, flesh out some requirements, go back to the problem, add more requirements, examine potential solutions, add a few more requirements, etc.

If your teams instinctively jump to solutions, slowly guiding them through the above steps is one way to embed in them the habits of thinking carefully through a problem and its requirements. It’s an investment, but it’s well worth it to maintain momentum and avoid getting stuck.