The Keyboard Is a Poor Measure of Progress

A developer typing looks productive. A designer moving things around a screen looks productive. Scrum master insulating the building with sticking up post-it notes all over the shop. A team spending time on a whiteboard looks like someone should intervene.

We’re comfortable with work we can see. Code appears. Mockups take shape. Tickets move. There’s evidence that salaries are being converted into something. Thinking is less reassuring. It has an unfortunate habit of looking like sitting down.

Starting before understanding

When a small group has already researched a problem and prepared a solution, the next step seems obvious: get the developers coding. Inviting the whole team into discovery can feel like reopening decisions that were conveniently considered closed. Customer conversations introduce questions. A visit to see how people actually work reveals awkward details. The whiteboard becomes crowded with conflicting interpretations. It can look slow because the team is encountering uncertainty together, but those conversations often uncover assumptions that would otherwise become expensive code. They help teams understand the need, designers understand constraints, and everyone questions whether the proposed solution deserves to exist.

Skipping that work doesn’t remove the uncertainty. It increasing the chance that we’ll just discover it later, once it has a release plan.

Learning is part of developing

Developers listening to a customer might be making a valuable contribution before writing a line of code. The same can be true of reading, sketching, discussing or taking time to think through a difficult problem. That doesn’t mean every conversation is useful or every meeting deserves defending. Discovery needs a purpose: a question to investigate, an assumption to test, a decision to inform.

It does mean that visible output is an incomplete measure of progress. Sometimes the useful result is a clearer understanding. Sometimes it’s ruling out an approach. Sometimes it’s deciding that the feature nobody has built is also the feature nobody needs. A difficult achievement to demonstrate at a showcase. An excellent one for the budget.

Code can be a question

Even when the team starts coding, it may make sense to build something disposable. A small prototype can test feasibility or reveal how someone responds to an idea. Its purpose is to help the team learn. It might not even belong in the finished product. Demanding prod-ready software from the first experiment can make learning unnecessarily expensive. We start maintaining the answer before we’ve finished asking the question.

Things I’d listen out for

• “We can’t have developers not developing.”
• “How can we have engineers not typing?”
• “We need to start building the real thing.”

I’d want to check what we need to understand, and which activity will help us make the next useful decision. Typing may be exactly what’s needed, but a team can produce a great deal of code while becoming increasingly committed to a misunderstanding.