I keep an audiobook running on my commute and my runs. It serves as a continuous feed of leadership frameworks that I test against the actual problems in front of me. A few give me language for something I was already trying to solve. This is an account of one stretch where that mattered, when I took over a large engineering organization and had to rebuild the culture from the ground up.
The situation I inherited was not a crisis, but it was a dangerous plateau. The systems survived the daily load, but velocity was capped and innovation was stalled. The organization relied heavily on heroics to ship anything. At the same time, the engagement survey showed low scores on the questions that actually predict whether a team can take on hard work. You cannot build scalable platforms with a burned-out organization. Engineering culture and system architecture are closely linked, and a siloed team produces a brittle system.
The first thing I did was clarify the purpose of our work. Simon Sinek argues in Start with Why that people commit to the reason behind work rather than to the work itself. He notes that people do not buy what you do, they buy why you do it. Our engineers had been executing Jira tickets for years without understanding the downstream revenue impact or customer value. I had to connect their code to the business outcomes before I could implement any structural changes.
A note on the books before any of the rest. I am not going to pretend the sequence below was designed from a reading list. It was mostly reactive, and several pieces only look deliberate in hindsight. What the books gave me was vocabulary, a handful of mechanisms I would not have invented on my own, and the occasional uncomfortable mirror. They are tools, not doctrine. A framework applied to a situation it was not built for does more damage than no framework at all.
Before the first change, the reason for it
The first thing I did was nothing structural. No reorganization, no new process, no plan published in the first month. Simon Sinek's argument in Start with Why is that people commit to the reason behind work rather than to the work itself, and that a leader who opens with the what has already lost the room. Engineers are a sharp test of that claim. Ask a team to build a feature and you get a feature, on time, to spec, and nobody will tell you it was the wrong feature. Tell them which customer problem it exists to solve, what it costs the business every month it is late, and what will be true once it ships, and you get questions, pushback, a better design, and usually a simpler one.
That organization had been receiving tickets for years. The work was well specified and entirely disconnected from any consequence. Nobody could tell me what happened downstream of the thing they had shipped last quarter, and a few people had stopped asking. That is not a motivation problem. It is an information problem that eventually becomes a motivation problem, and it is the leader's to fix.
What follows is the model that came out of the next year, in the order I built it. The order turned out to matter more than any individual piece.
Phase one: ground truth
In the first two weeks I started structured skip-level meetings, going two and three levels down. Scheduled, on a calendar, with a short standing agenda, not an open-door policy. An open door is a passive mechanism and it selects for the people who were already confident enough to walk through it. Those are rarely the people whose view you are missing.
The discipline was to listen and not solve. That is harder than it sounds when the problem being described is one you can see how to fix in thirty seconds, and when fixing things in thirty seconds is roughly how you got the job.
What came back in those rooms was not tidy feedback. It was years of accumulated frustration, some of it aimed at decisions I now owned and some at people still in the building. Difficult Conversations, from Stone, Patton and Heen, was the most useful thing I had read for this. Their framing is that any hard conversation is really three conversations happening at the same time: a factual disagreement about what happened, an unspoken layer about how everyone feels, and a quieter one about identity, about what saying this out loud implies about the person saying it. The complaint I heard about the release process was the factual layer. Underneath it was something closer to: I have raised this three times, nothing changed, and I am starting to wonder whether I am the problem. If you answer only the first layer you have technically responded and actually missed the entire conversation.
The other thing I had to get straight was whose problem the morale number was. It is tempting, and completely available to a new leader, to treat the state you inherit as context rather than responsibility. Jocko Willink and Leif Babin's Extreme Ownership, with the military framing set aside, makes the useful version of the point: a leader does not get to explain their circumstances. The engagement score was mine on day one. Not my fault, and that distinction is worth nothing to the person who has been disengaged for two years.
An open door selects for the people who were already going to tell you. A calendar invitation selects for everyone else, which is where the information you do not have is kept.
The mechanism that made skip levels worth anything was the part after the listening. Skip levels that produce no visible consequence are worse than no skip levels, because you have now asked people to spend social capital and shown them it buys nothing. So I committed to a loop: within two weeks, publish back what I heard as themes rather than attributed quotes, paired with what I was going to do about each one. That list included the items I was not going to fix, and why. Saying plainly that something is not changing this year, and giving the real reason, bought more credibility than any of the things I did change. People can work with a no. They cannot work with silence.
Phase two: flow, and the person holding it all together
Listening produced a map of where work actually stopped, which did not match the process diagram. Almost every long-running delay traced back to a small number of engineers who had to be involved in everything.
Anyone who has read The Phoenix Project knows Brent. He is the engineer who can fix anything, which is precisely why everything gets routed to him, and he becomes the constraint that caps the whole system regardless of how many people you add around him. Every organization at scale has a Brent. Usually several. And they are almost always the people you are most grateful for, which is what makes this genuinely difficult rather than just operationally awkward.
The mechanics were unglamorous. We mapped the queue honestly, asking of every piece of waiting work who it was waiting on, and the answer clustered immediately. Then, for anything only one person could do: a second person paired onto it the next time it came up, no exceptions. Runbooks written in the days after a real incident rather than in a documentation sprint that nobody reads or maintains. Review load distributed by an assignment rule instead of by whoever people trusted most. On-call rotations that included the experts, so the gaps in everyone else's knowledge became visible instead of theoretical.
The part that mattered most was not a process change at all. It was redefining the hero engineer's job. His work stopped being the work and became making the work possible for other people, and that is what went into his objectives and his promotion case. Without that last step you are simply asking someone to give away the thing that makes them valuable, and they will be entirely right to resist you.
Which is how I got it wrong the first time. I introduced it as risk reduction, which is true and was heard, accurately, as a statement that the most capable person in the room had become a liability. That conversation took months to repair. The framing that worked, once I understood what I had done, was about reach: you are currently the ceiling on how much of this the company can do, and I want to spend your time on the constraint rather than on the queue.
For sequencing the changes themselves I borrowed from The Lean Startup, not for the product but for my own management changes. Eric Ries's build, measure, learn loop and his argument for small batches apply cleanly to process. One change at a time, with a stated expectation of what should move, checked four weeks later. Several of my changes did nothing. Two made things worse. Shipping them in small batches is the only reason I could tell which ones.
Phase three: alignment, and the habits I had to drop
This is the part I would describe as the actual pivot, and the part where I personally had the most work to do.
Marshall Goldsmith's What Got You Here Won't Get You There is an unpleasant read if you have been promoted for technical judgment. His thesis is that the behaviors that earned you the role are frequently the ones now capping you, and the habit he names that applied most directly to me is what he calls adding too much value: the reflex to improve every idea brought to you by some small increment. The improvement is usually real. The cost is that the person who walked in with their idea walks out with yours, carrying it without owning it. Do that consistently and you have built an organization that brings you decisions instead of making them.
I was not going to stop being a builder. I read the code, I sit in design reviews, and I go deep on the decisions that are expensive to reverse. The line I had to find was being in the details enough to be useful and out of them enough that the decision stayed with the team. The test I settled on is simple: if I leave the room and the design reverts, I was not collaborating, I was issuing instructions politely.
Mapping skill against interest
The second half of this phase was talent alignment, done explicitly rather than by reading resumes. For every engineer I kept two things: what they are demonstrably good at, and what they actually want to be doing. Those two lists overlap far less than an org chart assumes. People get assigned permanently to the thing they were good at in their second year, and seniority quietly becomes a trap.
What you do with the map matters more than the map. Where skill and interest overlap, assign deliberately and protect it. Where someone wants a skill they do not yet have, pair them onto it with someone who does and accept the short-term cost, because it is a quarter of slower delivery against years of capability. Where someone is excellent at something they are plainly tired of, plan the handoff instead of hoping the preference goes away, because it does not. It turns into a resignation with two weeks of notice.
Aligning what someone is good at with what they care about is the highest-return move available to an engineering leader, and it costs nothing but attention. The engagement effect is immediate. The technical effect shows up a quarter later, in the quality of work from people who are finally interested in the problem.
Changing the vocabulary
David Marquet's Leadership Is Language gave me the most directly usable set of changes of anything on this list. His argument is that the language of industrial work, designed to get compliance from people doing physical tasks, survives in modern organizations where it now suppresses exactly the thinking you are paying for. The specific moves are small and the effect is not.
Two of these are worth more than the others. Replacing a yes or no question with a confidence scale is the single highest-yield change I have made to how I run a review. "Are we on track" has one socially acceptable answer and you will get it every time. "How confident are you, one to five" produces a three, and a three is the beginning of a real conversation. The other is asking for what someone sees that you do not, which explicitly gives them the job of finding the flaw, rather than the job of agreeing with you.
The outage question matters for a different reason. Asking who is responsible teaches an organization to hide information, and an organization that hides information from its own leadership is one bad quarter away from a serious problem.
Phase four: a cadence people could see
By this point the listening was real and the flow was improving, and the remaining problem was that nobody could see anyone else's work. Backend engineers did not talk to frontend engineers. Engineering and product communicated through tickets and a quarterly plan. Each group had a complete mental model of a different part of the system and no model at all of the rest.
The mechanism was demos. Monthly within engineering, quarterly with stakeholders in the room, and a small number of rules that are the entire difference between a demo cadence and a status meeting with a projector.
- Working software only. No slides, no mockups, no recorded walkthrough of a thing that does not run.
- The engineer who built it presents it. Not the manager, not a designated presenter.
- What did not work is in scope and gets the same airtime. This is the rule that decides whether the whole thing is honest.
- A hard timebox, because a demo that runs long becomes a demo that gets skipped.
- Stakeholders ask their questions directly in the room, not afterwards through a manager.
Patrick Lencioni's The Five Dysfunctions of a Team explains why demos do more than distribute information. His model stacks five failures, with absence of trust at the base and avoidance of accountability near the top, and argues you cannot address the upper ones while the lower ones hold. A demo attacks two layers at once. Trust, because people watch each other be competent, which is the only reliable way it forms between groups that do not share work. And accountability, because a public commitment with a visible date does what no amount of management chasing achieves. Nobody wants to stand up in front of the organization two months running with the same half-finished thing.
It also breaks silos in a way status reporting cannot, for a mechanical reason: you cannot demo half a feature. Getting something on screen forces the backend engineer and the frontend engineer to have integrated, and forces product to have decided what it was for. A status report lets everyone stay in their lane and report green.
The stakeholder version needed a different language. Engineering metrics do not land with a business audience, and a dashboard of deployment counts reads as activity rather than progress. Two books got me to something workable. Accelerate, from Nicole Forsgren, Jez Humble and Gene Kim, gave the measurement side: the four metrics of deployment frequency, lead time for change, change failure rate and time to restore service, which have the rare property of being hard to game without actually improving. And Mik Kersten's Project to Product gave me the framing that stakeholders understood immediately, which is to report where capacity went by type of work: features, defects, risks and debt.
That distribution changed the conversation more than any velocity chart ever did. When a business leader sees that roughly forty percent of a quarter went into defects and debt, the question stops being why engineering is slow and becomes a shared question about what to do. They are now participating in a trade-off rather than receiving an excuse. That is the moment the demos stopped being a reporting obligation and became the most useful hour of the quarter.
Phase five: recognition that costs something
Quarterly town halls closed the loop: public recognition, and an honest connection between what the teams built and where the company was going.
Recognition is easy to do badly. The failure mode is generic praise, which is recognition that costs the giver nothing and is therefore worth nothing to the receiver. Being specific is the whole mechanism, and it is expensive in the only currency that matters, which is that you have to actually know what people did. Three rules I would keep:
- Name the work and the decision, not the attitude. Not that someone showed great ownership, but that they found the cache invalidation bug on the Friday before the release and what would have happened if they had not.
- Managers nominate, but I say it, and I have to be able to explain it without notes. If I cannot, I do not know the work well enough to be praising it.
- Reserve a slot for the invisible work. The person who fixed the build everyone complains about, wrote the runbook, or cut the on-call pages in half. Left alone, recognition flows to demos, and the work that keeps a system alive is not demoable.
What moved, and what I trusted
On the same survey instrument a year apart, engagement scores rose between 45 and 60 percent depending on the team. The questions that moved most were the ones about clarity of purpose, confidence in leadership, and whether people felt able to raise a concern, which is roughly the list you would predict from the mechanisms above. The questions about compensation and career progression barely moved, because those are slower, partly outside my control, and not fixable with cadence.
I trusted the flow metrics more than the survey, because they are harder to talk yourself into. Lead time for change came down as the single points of failure were retired, which is the expected result of removing a queue rather than adding capacity. Deployment frequency rose and change failure rate did not, which is the pairing that tells you the speed is real. Review latency fell once review load was assigned instead of volunteered. And the count of systems with exactly one person who understood them, which I tracked deliberately and recommend to anyone, went from uncomfortable to manageable.
A survey tells you how people feel about the organization. The flow metrics tell you whether the organization actually got easier to work in. You want both moving, and if only one does, it is the second one I would bet on.
What this cost
Four things I would warn anyone about, all of which I ran into.
Demos decay into theater. Left unattended, teams start building for the demo, the rough edges get hidden, and the failures quietly stop being mentioned. The countermeasure is to keep presenting failures yourself, at your own level, and to occasionally ask a team to show the thing that did not work instead of the thing that did.
Skip levels can undermine your own managers, and it is easy to do without noticing. If you resolve something in a skip level that belonged to someone's manager, you have just taught an organization to route around its management layer. The rule I hold to is that I take information in a skip level and I take it back to the manager, and the only exceptions are the ones everyone would agree are exceptions.
The cadence is expensive in real hours. Skip levels, monthly demos, quarterly stakeholder sessions and town halls are a meaningful slice of a quarter for a large group. It was worth it, and I would not pretend it was free, and anyone who tells you the overhead is negligible has not added it up.
Aligning interests is not the same as everyone getting what they want. Some work is necessary and nobody is excited about it. The honest version is to name it as such and rotate it fairly rather than quietly giving it to whoever complains least, which is what happens by default and is how you lose good people without ever hearing a complaint.
The part where this stops working
Clayton Christensen's The Innovator's Dilemma is about companies and technologies, not management process, and I am applying it out of context on purpose. His finding is that capable incumbents fail not through incompetence but by continuing to do precisely what made them successful: listening to their best customers, defending their strongest margins, investing in sustaining improvements to an existing model. The competence is the blind spot.
The operating model in this post is now my legacy system. I can already see the decay paths. Skip levels become a ritual people know how to perform, where the answers are pre-cooked and the information content approaches zero. The monthly demo becomes a deadline teams optimize for rather than a window into real work. The skills map goes stale the week after it is written. The town hall becomes a broadcast. None of these mechanisms fail loudly. They keep running, on the calendar, producing less and less, which is the hardest kind of failure to notice because the metric you are watching is attendance.
So I now put my own mechanisms on a review cycle. Once a year, for each one: what was this for, is it still doing that, and what would I replace it with. And I retire one deliberately, even when it still looks fine, because an organization that has seen its leader kill a mechanism he invented will tell you the truth about the next one.
Servant leadership gets described as a posture, which makes it sound like a personality trait you either have or do not. In practice it is maintenance work on the machinery that other people's work passes through, and a willingness to break your own machinery before someone else has to do it for you.
The reading list, and what each was actually good for
- Start with Why, Simon Sinek. Why to lead with purpose rather than plan. Useful in the first month, when you have no credibility and only a direction.
- Difficult Conversations, Stone, Patton and Heen. The most practical book here. How to hear the conversation underneath the complaint.
- Extreme Ownership, Willink and Babin. Own the baseline you inherited. Skip the war stories if they are not for you, the argument survives without them.
- The Phoenix Project, Kim, Behr and Spafford. The clearest illustration of a constraint in an engineering system, and of why adding people next to it changes nothing.
- The Lean Startup, Eric Ries. Small batches and a measured loop, applied to your own process changes rather than to the product.
- What Got You Here Won't Get You There, Marshall Goldsmith. An uncomfortable inventory of the habits that got you promoted and are now in your way.
- Leadership Is Language, David Marquet. The highest density of immediately usable changes. Start with replacing yes-or-no questions with confidence scales.
- The Five Dysfunctions of a Team, Patrick Lencioni. Why trust has to be built before accountability will hold, and why that order cannot be skipped.
- Accelerate, Forsgren, Humble and Kim. What to measure, and the evidence that delivery performance and organizational performance are the same question.
- Project to Product, Mik Kersten. Flow metrics, and the capacity distribution that finally made engineering trade-offs legible to the business.
- The Innovator's Dilemma, Clayton Christensen. Read last, as a warning about whatever you have just finished building.