Leadership Garden
A team of mine shipped clean for four months. Every sprint closed, nothing slipped, on-call stayed quiet. I wrote the update to my SVP with real pride.
Then somebody outside the domain asked what had changed for the business, and I did not have an answer worth saying out loud.
That team worked hard. They worked hard on something any competent team at any competent company could have worked hard on.
The test
Justin Jackson published a post in June called Do the hardest thing. His phrase for the mistake is a hard job attached to an easy idea. He opened a snowboard shop in 2003, worked harder than he has at almost any time since, and closed it in debt by 2006. Inventory, theft, scheduling, stock turnover. All of the difficulty lived in the operating, and anyone could have had the idea. Plenty did.
He is writing for founders. The distinction transfers to anyone running an engineering org, and I think it bites harder here, because we have built an operating culture that can only see the job.
The test I use now: if I disappeared for six months, would the difficulty go away?
Hard-job difficulty is made of my effort and my team’s. Pull us out and it evaporates, because a replacement drops in and grinds the same grind. Hard-problem difficulty belongs to the problem. It survives reorgs and roadmap changes and both the managers who owned it leaving, and it is still sitting there when you get back.
We measure the job
Sprint commitments, cycle time, DORA, the weekly delivery update. All of it answers one question: are these people working, and are they working in an orderly way?
Nothing in that stack asks whether the work was worth choosing.
(I have written a performance review praising someone for a heroic quarter on a project I now think should have been killed in week two. The review was accurate. That is the part that bothers me.)
Will Larson’s Work on what matters is the standard reference here, and it is good, but it aims at your calendar. Hunter Walk’s snacking, the easy low-impact work that feels productive when you are busy, describes how you spend your own hours. At forty-five people my hours are a rounding error. The portfolio that counts is what forty-five people are pointed at, and an org can run a well-instrumented grind at high morale on a problem nobody ever chose on purpose.
Your hardest problem is not technical
Ask an engineering leader at a scale-up to name the hardest problem in their org and most will reach for something technical. The monolith. The vendor migration. The test suite that fails twice a week.
Those are hard jobs. Well understood, well documented, and a few hundred teams have already done them. You can hire someone who has done it before, which is close to a definition of a job.
The problems that actually resist look more like this:
- A team that made sense two reorgs ago and now exists because dissolving it would embarrass the person who built it.
- The senior engineer everyone routes around, whose net output has been negative for a year, who is well liked.
- Two domains with a dependency that both leaders have agreed not to raise, because raising it means somebody loses headcount.
- A product surface nobody owns that generates a third of your support load.
Notice you did not have to go looking. You knew which one was yours before you finished the list.
Jesse Hanley, quoted in Justin’s post, says hard things attract little competition because most people do not want to do them. Inside a company that holds even more strongly, for a specific reason.
The cost of touching an org’s hard problem lands on whoever touches it, and the benefit spreads across everyone. So it sits there, year after year, getting more valuable to whoever finally picks it up.
You do not get to just pick it
This is where founder advice stops being portable, and where most attempts to translate it fall over.
Justin can decide to build podcast hosting. Nobody has to approve it. I cannot decide that my domain spends two quarters unwinding a team that reports to a peer.
So the real work sits one level above the problem. You have to buy the right to own it, and I have never seen anyone name that as work, which is strange, because for most Heads/Directors of Engineering it is the work.
Say it out loud, early, in a room with the person who could kill it. These problems survive on being discussed in pairs, in kitchens, after the meeting ends. Naming it in front of leadership costs you something and permanently changes its status. It becomes a thing that was said.
Turn it into a bet with a date and a number. “Operator onboarding is bad” gets nodded at and forgotten. “We take time to first value from eleven days to three by the end of Q3” gets argued with, which is what you want. The argument is how you find out who is actually opposed, and it is rarely who you expected.
Give something up in public. Nobody believes you are serious until they watch you stop doing something else to make room. It is also the fastest way to learn whether your leadership agrees with you or was just being polite.
Get one executive on the hook for the downside. Approval is not the same thing. I mean somebody senior whose name is attached to the failure case, because on your own you are a person with an opinion who might not be here next year, and everyone in the room knows it.
Where this gets people hurt
Hanley spent seven years on Bento before it paid off. He could afford to, because he owned it.
You have a performance cycle. Maybe eighteen months of runway with your current VP, less if they leave. Commit your org to a hard problem that does not resolve inside that window and you carry the cost while your successor collects the return. That asymmetry is real, and I am not going to pretend otherwise for the sake of a cleaner argument.
So pick hard problems that pay out in visible pieces. A bet that returns nothing until month twenty belongs to a founder. And accept that some hard problems are not worth your career. (I have walked past one I still think about. I would walk past it again.)
Walking past one is still a choice. What I am arguing against is the drift: falling into a hard job by default and then reading the exhaustion as evidence that you picked the right thing.
Ask who else could do it
Look at what your org is grinding on this quarter and ask who else could grind on it. If the answer is any competent team anywhere, you are running a hard job. It will still be difficult, and it will still tire everyone out. It just will not be worth much.
You already know what the hard problem is. Everyone does. The question is whether you will be the one who says it in a room where saying it costs you something.