Don't be the leader that wants a pony

It is November, which means somewhere in your company the following document is being written. Where we are, where we want to be, what engineering will be known for a year from now. My own role shifted this year away from the tactics and toward defining the long shots, so along with shipping I have also been writing a lot more at work, and most of that writing has been some version of that document.

There is a pull at this point to reach for the biggest rock you can lift. This is the year we finally get to X. We are no longer in a position to wait while Y happens to us. The plan becomes a manifesto, the nexus that will carry the organization into the horizon. I have written that document. It reads well.

Before you send it, go back to when one of these landed on you. The average employee went through ten planned enterprise changes in 2022, up from two in 2016.¹ At that rate a bold new world is not an invitation, it is the eleventh thing this year. So you did what I did when I was on the receiving end as a tech lead. You read the alignment doc, you went to the kickoff, and then you quietly went into mitigation mode. What is the smallest thing I can do to make this leader feel heard without putting risk on the way things actually work here.

A pony is what you ask for when you are not the one who has to feed it. The ask is not unreasonable on its face, and that is the trap. It is a perfectly nice thing to want, it is adjacent to things you already have, and the cost of it lands entirely on someone who was not in the room.

The research does not say vision is a waste, and I want to be careful not to claim that it does. Vision is one of the five dimensions DORA measures in transformational leadership, alongside inspirational communication and intellectual stimulation. What its data showed is that leaders in the top ten percent on those dimensions still varied widely in how their teams performed. Having a leader with vision was not enough. What moved delivery was whether that leader’s behavior went into adopting specific technical and product practices.² The vision is not the problem. The vision floating free of any practice is.

The bolder case has a boundary of its own. The work on stretch goals concluded that they are, paradoxically, most seductive to the organizations least able to absorb their risk, and most useful to the ones with recent wins and real slack to spend.³

That gives you two conditions to check before you commit to the bold version. The first is whether your team has recently finished something that worked. The second is whether you are holding slack you have not already spent. This is the one people overcount. A team whose next two quarters are committed to a migration is not slack, even when the migration is going well. An engineer who is nominally twenty percent free is not slack either, because that twenty percent is already absorbing the interrupts nobody wrote down. Slack is the capacity you could hand to this vision on Monday without anyone arriving on Tuesday to ask you what now slips.

When both of those conditions hold, the ambitious vision is the one that pays and you should go write it. If either is missing, the reach for the biggest rock is usually the tell that you already know it is missing.

Be the adversary to your own vision first. Draw out the strategies that already exist, in the words the people running them would use, and then find the lowest common change that gets any of them moving. I did not publish my vision on day one. I published it on day 120, as an extrapolation of a set of bets that were already grounded in local changes, which is a less impressive document and a much harder one to argue with.

So here is the exercise, if you are the one writing this now. Sit with your engineering thought leaders and ask each of them for the three most important conversations or write-ups they have had in the last six months. Tell them plainly that what they send will change where you steer, because if this reads like an archive request you will get their tidiest work rather than their most important. Then read across instead of down. One from each person, then the next from each. Reading all three from one person gives you that person’s narrative. Reading across gives you the lateral observations, the thing three people noticed separately and none of them escalated.

Then say out loud what you found significant and what you are optimistic about changing. Ask the same people whether that change can be realized in the next four months. That is your pony check. Push on specifics and give ground until something fits, and let the thing that survives be smaller than what you walked in with. Take it and put it into the conversation and the design documentation streams, where it has to live alongside real work rather than above it. After four months, publish your true north.

If you are an engineering leader and you are reading this, I want to hear how you graduate opinion into vision for your org. If you are not, I want the other version. The pony you were handed, and what you did to keep the expectation and the ground truth in the same room.

Footnotes

1. Cian O Morain and Peter Aykens, Gartner, Employees Are Losing Patience with Change Initiatives, Harvard Business Review, May 2023. ↩

2. DORA, Transformational leadership, Google Cloud. ↩

3. Sim B. Sitkin, Kelly E. See, C. Chet Miller, Michael W. Lawless and Andrew M. Carton, The Paradox of Stretch Goals: Organizations in Pursuit of the Seemingly Impossible, Academy of Management Review 36(3), 2011. Written for a general audience as The Stretch Goal Paradox, Harvard Business Review, January 2017. ↩