Don't come to me with solutions

Let's address our problems with intent

It’s on the list

I think everyone who’s worked in software development has their hate-list of phrases. I’ve taken to writing about some of these as ‘agile swear words.’ I see these as expressions that accidentally limit the horizons of debate. They’re not helpful, but they’re not necessarily debilitating. There are really only two mantras that I hear which are truly damaging.

The first is the all-too-frequent misquote of “if you can’t measure it you can’t manage it.”

The full quote reveals the truth and something of the people who intentionally misuse it.

“It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth” - W. Edwards Deming

As someone who cares passionately about being data-driven, the trap is obvious. If sufficient data’s not easily accessible, there is a temptation to insert process so that more data can be surfaced. But data is only useful when it can lead to action or insight.

Data is for decisions

More data is not a good in itself. Observations do not automatically lead to improvement. Not allowing for unmeasurability fetishises control, and pretends that you can’t improve, when improvement is always possible.

It would be better to say, if you can’t demonstrate correlation between action taken and an improvement, then you don’t know whether you’re likely to have contributed to that improvement, or if it was the result of chance. That’s a bit more of a mouthful, so I can see that it’s not going to be on a mug or a keynote slide any time soon. At least it’s an honest assessment.

A drive to become more data-driven is undoubtedly a good thing. To quote a highly-respected VP of Engineering at one company where I worked “Data beats opinion.”

I wholeheartedly agree.

However, taken too far, a focus on measurement can turn into a demand for continued demonstrated progress. Again, this isn’t a bad thing in itself, but often the appearance of progress on a report can belie a more complicated reality. As a result, people may feel pressure to game metrics, as the leader demands graphs that go up-and-to-the right, regardless of the circumstances.

I was once told about a team in this kind of environment. They inherited a codebase and weren’t given the time to review it fully or address issues properly. They also had a target that meant they had to demonstrate certain levels of test coverage across ‘their’ codebase. They created tests that didn’t actually test anything so that their coverage scores went up. They believed their best course of action was to game the situation while they worked out how best to address learning about the inherited codebase over time, without the added pressure of missed targets.

This example highlights how the measurement/improvement obsession acts in concert with the second damaging phrase:

“Don’t bring me problems, bring me solutions.”

I can see how a leader who thinks they are being empowering might say something like this. It can sound like they are telling people to crack on and solve problems for themselves.

But that’s not what people hear. Like the graphs that go up and to the right, they hear that their leaders want to be made comfortable and only want to know things are getting done, and that results are good. This attitude encourages people to either hide problems or to create sub-optimal solutions and lie to their leaders about them.

To put it another way, if people can solve all their problems without their leader, why is that leadership needed? Like the full Deming quote on measurement, we can see how what might seem sensible on the surface can quickly become a poor leadership practice.

Trust and intent

Trust is the best predictor of high-performing teams. Neither an obsession with data or a completely hands-off management style build trust. Trust is developed by co-creating solutions, demonstrating care and consistency, and by being of service.

I don’t want the people who work for me to come to me with solutions. In his book Turn the Ship Around!, former submarine captain L. David Marquet describes how he implemented a policy whereby his crew would always inform him of their intended actions, giving the required context, before taking an action. Instead of him giving orders, crew members would say “I intend to…” when speaking to him about an action. At first, he found himself having to ask a bunch of questions, but then he and the crew learned to give him the context he needed to validate that decision.

That is a good checkpoint for discussion. Nothing has happened yet. No irreversible decisions have been made. You have a great chance to validate the logic driving a decision.

When someone knows what they want to do and why, if it’s potentially a big impact decision, this is great. But we don’t need it all the time. We’re not all running nuclear submarines. While I want the people I work with to come to me with their intent, I also spend time helping them understand where my assistance is likely to be most valuable, and where they are empowered to take decisions on their own.

Come to me with problems

But when all is said and done, I want problems. I want big, hairy, audacious problems. I want to forge my relationships with my teams by showing them I’m with them, I understand, and I can help.

Let’s talk about hard things. Let’s discuss options. Let’s co-create the future. We can build an environment where we can all be honest about the problems that we’re facing. We need to develop the knowledge that we’re going to succeed and fail together. Trust evolves. We don’t get it by hammering on metrics that don’t matter or by hiding complexity. We forge it by addressing our problems with intent.