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.
What I inherited needed work on every axis at once. The technology was a large legacy monolith sitting on aging databases that had never been sharded. The processes and the knowledge that kept it running were written down almost nowhere, so the system ran on the few people who happened to remember how it worked. Delivery was effectively waterfall, which meant feedback arrived late and expensively. And the culture matched the tech: siloed teams, no real habit of open communication, and an organization that shipped by heroics rather than by any repeatable system. The engagement survey put numbers to that last part, with low scores on exactly the questions that predict whether a team can take on hard work. You cannot modernize any of the technical mess with a team in that state, so the people and the way they worked are where I started, and that is what the rest of this piece is about. The deep technical work, breaking the monolith and sharding the data, ran as its own track with its own stories. But the two were never truly separable. A monolith on a single shared database is not only a technical fact; it forces the whole organization to coordinate through one choke point, which is precisely what breeds silos and heroics. Conway's Law cuts both ways, so the org and the architecture had to move together, and I come back to how below.
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, built in a deliberate order. It helps to be clear about what kind of model it is. Turning an organization like this around is not one project but three that have to move together, the same three the industry has been modernizing for years: the people and the culture, the process and the ways of working, and the engineering practice underneath. Each has a well-worn playbook. For culture, the target is what Ron Westrum calls a generative organization and what Amy Edmondson calls psychological safety, where information moves toward the people who need it and a failure triggers inquiry rather than blame. For process, it is the familiar move off waterfall and heroics onto iterative delivery, small batches and visible flow, the ground that Lean, Kanban, Team Topologies and the DORA research in Accelerate all map. For engineering, it is the delivery discipline that lets a team ship safely and often, with the deeper work of breaking the monolith and modernizing the data as its own track.
Transparency and continuous improvement are not two more phases bolted on at the end. They run through all of it. A modernization people cannot see does not build trust, and one they cannot correct does not last, so making the work visible and giving the team a standing way to improve it are load-bearing, not decorative. The five phases below are how those three tracks actually landed for me, in sequence. 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.
Those mechanisms got flow moving, but human unblocking has a ceiling. Pairing and runbooks do not scale past a point, and on a legacy monolith the real risk is not who reviews a change, it is whether the system can prove the change is safe. So the durable answer was automation, the continuous delivery discipline that shifts risk left instead of leaning on a person to catch it. Automated test pipelines as the gate rather than a senior engineer's memory. Progressive delivery, canary releases and feature flags, so a risky change on old infrastructure meets a small blast radius first and can be pulled back without a deploy. And policy as code, so security and compliance checks run on every change automatically rather than as a review someone can forget. Human unblocking gets a stuck team moving. Automated guardrails are what let it stay fast without getting reckless, which is the whole point of DevSecOps.
There was also a ceiling on how much work could be in flight at once, and naming it explicitly mattered. A legacy monolith with a lot of coupling is a queueing system, and queueing systems have an unkind property: as utilization climbs past roughly 85 percent, waiting time does not rise gently, it rises steeply. Kingman's formula describes it, and anyone who has watched a busy team seize up has felt it. The fix is boring and it works. Explicit work-in-progress limits at the team level, small batches, and Little's Law as the mental model, that lead time is just work-in-progress divided by throughput, so the way to ship faster is usually to start less at once rather than to push harder. Running the team at 90 percent utilization felt productive and was the reason nothing finished.
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.
Structure follows structure
Removing the single points of failure kept running into a deeper cause, and it is worth naming. Conway's Law says an organization ships systems shaped like its own communication structure. The reverse is just as true and more useful: if you want a different architecture, you often have to change the team structure first, which people call the inverse Conway maneuver. Our monolith and our silos were the same problem wearing two faces. A change that touched three parts of the system needed three teams in a meeting, so the architecture itself manufactured the coordination overhead, and the heroics came with it.
So the team shape had to move in step with the architecture, and Team Topologies, from Matthew Skelton and Manuel Pais, gave the vocabulary for it. We reshaped toward stream-aligned teams that owned a slice of the product end to end, against clear service boundaries as the monolith was carved up. A platform team stood up the paved paths, the CI/CD, the golden runbooks, the self-service infrastructure, so a stream-aligned team could ship without filing a ticket to another group. And enabling teams moved through the organization a quarter at a time to raise one specific capability, testing or observability or on-call practice, and then moved on. Sharding the database and decomposing the monolith was the technical half of this. Giving each new bounded context a team that genuinely owned it was the other half, and doing only one of the two would have quietly undone the other.
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.
The cadence was also where the process modernization actually happened. This was the point where waterfall gave way to short iterative cycles, so feedback arrived in weeks rather than at the end of a plan. And every demo was paired with a blameless retrospective, which is the part that turns a cadence into continuous improvement instead of a recurring meeting: the team names what to change while the memory is fresh, owns the change, and checks it the next cycle. The demos and the shared dashboard were the information radiators that made the work visible, to the team and to the business at once, which is the transparency the old waterfall plan never offered.
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, measured through the year, the engagement score roughly doubled: it started around 30, reached 45 by the middle of the year, and finished near 60. 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.
Not everyone made the trip
I have made this sound smoother than it was. Moving off waterfall and heroics onto a transparent, iterative, high-accountability model is not universally welcome. Some people had built their standing on being the indispensable expert, and a model that spreads knowledge on purpose reads, at first, as a demotion. Others had learned over years that visibility was dangerous, and quietly waited the change out, expecting it to pass like the last three initiatives.
I ran the change with more structure than the story so far suggests, close to Kotter's sequence. Start with a real sense of why now. Build a coalition of the willing rather than trying to convert everyone at once. Win visible short-term results and use them to bring the fence-sitters across. Only then push for the harder structural changes. Most people came along once the wins were real and it was safe to. Some needed a re-skilling path, time and pairing to move from a narrow legacy specialty into the new way of working, and that investment paid back. And a few, a small number, either could not or would not make the shift, and keeping them in place would have taught everyone else that the new standard was optional. Managing those cases honestly, with support first and a clear line second, is the part leaders most want to skip. It also raised the talent density, and the result was not a colder team but a safer one, because psychological safety and a real accountability bar are not opposites. People felt safest when the standard was clear and applied to everyone.
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.
Built to keep improving
The best part of this whole approach is the one I saved for last: it is built to keep improving itself. Continuous improvement was not only something I applied to the delivery process. I apply it to the operating model too. These mechanisms are a living system rather than a fixed program, and treating them that way is what keeps them working as the team and the company grow.
Any mechanism can drift if you leave it alone. A monthly demo can settle into a ritual people know how to perform. A skills map ages the moment it is written. A town hall can turn into a broadcast. That is not a reason to distrust the model. It is the normal upkeep any living system needs, and the fix is the same discipline the team already uses on its own work: look at it honestly, keep what is earning its place, and improve what has gone quiet. A mechanism that gets that attention keeps compounding instead of fading.
So I put my own mechanisms on the same review cycle the team puts its work on. Once a year, for each one: what was this for, is it still doing that, and what does the team need now that it did not a year ago. I keep the ones that still earn their keep, refresh the ones that have drifted, and gracefully retire the ones that have done their job. A team that watches its leader hold their own methods to that standard trusts the next change all the more.
Servant leadership, in the end, is exactly this: tending the system that everyone else's work flows through, and improving it steadily so the team keeps getting better. Do that consistently and the result outlasts any single mechanism, any single quarter, and eventually the leader who started it. What you are left with is a team that owns its own improvement and a culture that compounds, which is the most durable thing an engineering organization can build.
The reading list, and what each is 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.
- Team Topologies, Matthew Skelton and Manuel Pais. Team shapes as a design tool, and why the org chart and the architecture have to be drawn together.
- The Principles of Product Development Flow, Donald Reinertsen. Why queues, batch size and work-in-progress decide your speed more than effort does.
- Leading Change, John Kotter. The eight-step spine for a change that has to survive contact with people who liked things the old way.
- The Innovator's Dilemma, Clayton Christensen. A nudge to keep improving what already works, while it still works.