When I first started leading engineers, I joined one organisation and spent my first quarter trying to speed delivery up: tighter planning, more structure around sprint commitments, better velocity tracking. From the outside it looked obvious. The business was under pressure, the team was slow, and I'd arrived with tools that could close the gap.
It took me too long to see that the team didn't need speed. They needed confidence. Before I arrived they'd had missed deadlines, shifting priorities and a falling-out with their stakeholders. They needed steadiness and room to rebuild. For the first few months, what I gave them was more process and more pressure.
I'd read the business and ignored the team. And I'd reached for a process before I understood what was going on.
Everyone does it
Since then I've watched three companies, big and small, bring in OKRs to get more done. None of them had stopped to look at how the company actually worked first.
The large ones wanted more throughput. But a lack of goals wasn't what was limiting their throughput. Their existing processes were: approvals, handoffs, and the three meetings it took to change a column. OKRs on top gave everyone one more thing to report on and did nothing about what was slowing them down.
The small one used OKRs to keep everybody pointed the same way. That's fair enough. But a startup's advantage is that it can change its mind on a Tuesday. Objectives written in January were out of date by March, and people either followed them anyway or ignored them.
I've done it myself there too. I once spent three months helping build a set of OKRs I was genuinely proud of. By February nobody was looking at them, and everything we'd agreed was being argued over again in response to whatever had happened that Monday. Looking back, we'd used the OKRs to avoid a harder conversation about what the company actually prioritised when things got difficult.
The "should" problem
Agile gets the same treatment. I hear a lot of "we should be doing it this way". I hear much less of "given the constraints we're working in, let's try this, see how it goes and adjust".
The second one is the actual idea. Sprints, stand-ups and story points were somebody's answer to their own constraints, and yours are different. A two-person data team supporting a sales-led business doesn't need the rhythm of a forty-person product organisation, and pretending it does costs you time every fortnight.
Diagnosis first
So now I spend my first few weeks anywhere new asking questions rather than proposing answers. Where does the money come from? Who makes decisions, and how quickly? What happens when something urgent lands? Who ignores the official process, and why? What's the team tired of, and what's the business frustrated by?
The gap between those answers is usually where the real work is. It also tells you what process you need, which is usually less than you'd expect and different from the textbook. Then I try something small, see whether it helps, and change it if it doesn't.
Before I bring in any process, I ask myself three things. What problem am I actually trying to solve? How will I know if this solved it? And what conversation am I avoiding by introducing it? If the honest answer to the last one is uncomfortable, I have that conversation first.
Most fixes are fairly obvious once the problem is properly understood. That's why I've come to think leadership is mostly diagnosis.