8 The Bones of Growth
This chapter is currently in draft form.
Every time an engineer says “the business,” I stop the conversation. Not as punishment. As a reset.
“What do you mean, the business?”
They usually mean product, or marketing, or leadership—some external force that makes demands on engineering. The people who tell them what to build. The source of requirements. The origin of deadlines. The thing they serve.
That framing is the problem. The replacement is simple: “we.” Not “the business wants this feature,” but “we need this feature.” Not “the business decided,” but “we decided.” The word shift sounds small. The identity shift underneath it isn’t.
As long as engineers see themselves as serving “the business,” they’re built for subservience, not growth. And an organization built for subservience can’t grow beyond its managers’ capacity to give direction.
The bones of growth are the identity underneath everything else in this book. Without them: political capital is harder to earn because you look like a cost center. Leverage stays low because you’re waiting for direction. Momentum collapses because you’re reactive. Strategy never shows up in your work because you don’t see yourself as owning it.
The bones aren’t rules to follow. They’re an orientation to internalize. And internalizing them takes years, because you’re undoing the learned helplessness most engineering organizations install from day one.
I’m not inventing that phrase. Psychologists have studied this pattern for decades: when people repeatedly experience that their initiative doesn’t change outcomes, they stop initiating (Seligman and Maier, 1967). Martinko and Gardner later mapped the same mechanism to workplaces (Martinko and Gardner, 1982). The dynamic is the same in an engineering org: if trying doesn’t matter long enough, people learn to wait.
Organizations without bones are invertebrates—they can move, but they can’t stand up, can’t support weight, can’t grow beyond a certain size. Growing a spine is the work of years.
8.1 You Are the Business
The distinction between “engineering” and “the business” is a fiction. Sometimes it’s a convenient fiction. It’s still dangerous.
In a technology company, engineering is the capability that turns intent into value. Product brings customer needs. Marketing brings market signal and positioning. Sales brings deal reality. But engineering makes all of it real. Without engineering there is no product to sell, no service to market, no capability to compete on.
This isn’t arrogance. It’s responsibility. When you understand that you are the business—not serving it, not supporting it, but constituting it—the frame shifts. You stop asking “what does the business want?” and start asking “what does the business need?” You stop waiting for requirements and start anticipating them. You stop executing tickets and start solving problems.
Engineers who think like owners make different decisions than engineers who think like a service function. Cagan draws a similar distinction in Empowered (Cagan, 2020), contrasting “empowered product teams” with “feature teams.” His framing focuses on product teams; mine focuses on engineering identity. But the dysfunction we’re both pointing at is the same: people who are handed tasks behave differently than people who own outcomes. Engineers operating as a service function invest in infrastructure only if someone else approves it. Engineers who think like owners invest because they expect to be around to benefit. They push back on bad requirements because they own outcomes, not just outputs. They learn the domain because understanding the business isn’t optional when you are the business.
Product, marketing, and leadership absolutely inform engineering decisions. Customer insight, market context, demand signals, competitive intelligence, strategic direction—those inputs matter. None of them make engineering a service function.
When a good product person says, “This feature needs to ship first,” engineering with the right bones listens—not because product has formal authority, but because engineering has judgment. The feature goes first because engineering agrees with the tradeoff, not because engineering complied with an order. Externally, the outcome looks identical. Internally, it’s the difference between alignment and subservience.
Engineering can’t be a pure service function because engineering holds context nobody else has. Engineers see the feature work and the maintenance that prevents outages, the automation that compounds, the technical debt that quietly slows everything down. Product sees customer needs. Marketing sees market dynamics. Engineering sees all of that plus what the system can actually sustain.
That’s why engineering has to own prioritization where technical reality is binding. If engineering doesn’t hold the call, it ends up begging permission for work the decision-makers aren’t equipped to evaluate.
Ownership doesn’t mean engineering always wins. Sometimes the feature genuinely matters more than the maintenance. Sometimes you defer infrastructure because the business needs the release. The difference is whether engineering understands the value and says, “Yes, this is the right tradeoff right now,” or whether engineering is overruled by someone who can’t evaluate the tradeoff. One is judgment. The other is compliance.
And sometimes you do the thing you disagree with entirely. I’ve prioritized work I thought was wrong because the political cost of refusing was too high. I once had a CEO who would fixate. When that happened, whatever he fixated on became the most important work in the company. If you weren’t doing it, you were “hurting the business.” So we did it. That’s not alignment. That’s not even compliance. That’s reading the room and choosing your battles. Ownership means you get to make that calculation yourself, not that you always get your way.
This also depends on political capital. If you haven’t built the standing to make these calls, you might not have room to exercise the ownership you technically have. You might have to take some losses, defer some maintenance you shouldn’t defer, let some features jump the queue—all to build the trust that eventually lets you operate as a real partner. The bones don’t give you authority by themselves. They give you the orientation to build authority over time. See The Economy of Political Capital for how that accumulation works.
This doesn’t mean engineering ignores other functions. I’ve worked with marketing teams that drove conversion rate optimization brilliantly—they understood the funnel, they knew what to test, they were great at tuning the system. They were also collaborative. When they wanted something prioritized, I was predisposed to do it because they’d earned the trust. When we had competing priorities, we had a real conversation and found the right balance. That’s what collaboration looks like when engineering owns the decision but genuinely values the input.
Engineering drives. Everyone else informs. Driving still means listening to the navigation.
And no: there is no such thing as shared ownership. Shared ownership is how organizations avoid making decisions while pretending they’ve made them. Ownership is singular or it isn’t ownership at all.
Collaboration is shared. Input is shared. Context is shared. Accountability never is. Someone has to make the call and live with the consequences. In a technology company, when the consequences are technical, that someone is engineering.
8.2 The Symptoms of Wrong Bones
An organization with the wrong bones can’t stand up straight. It can’t support its own weight. It can’t move with purpose. You see the symptoms before you diagnose the structure.
When engineering sees itself as separate from the business, predictable pathologies emerge.
They become subservient. Engineers wait for direction instead of providing it. They ask “what should I build?” instead of “here’s what I think we should build, based on what I’m seeing.” They treat product managers as bosses rather than partners. Every decision flows upward because nobody at the working level feels authorized to make decisions.
They become task-doers rather than problem-solvers. The ticket becomes the unit of work. Engineers complete tickets, but nobody owns the problem the tickets were supposed to solve. When the tickets are done and the problem persists, that’s someone else’s concern—someone in “the business.”
They wait. For requirements. For prioritization. For approval. For direction. They wait because taking initiative feels like overstepping. They wait because they’ve been trained to wait. They wait because every time they tried to drive, someone told them to stay in their lane.
The pattern is exhausting to watch. An engineer needs to change two characters of copy. Instead of making the change and shipping it, they ask product to prioritize it. Product says they need to see a ticket. The ticket needs a design review. Design wants to loop in marketing for brand consistency. A two-minute fix becomes a two-week odyssey through the organization’s permission structure. Multiply this by every decision, every day, across every team. That’s what learned helplessness looks like at scale—the same dynamic The Conservation of Momentum describes from the physics side, where repeated momentum destruction teaches teams to stop trying to build velocity. It’s also why the organization can’t grow past its managers’ capacity to give direction. Make the decision. Push it out the door. You can always fix it later.
They stop investing in tomorrow. When you’re a service function, you don’t own the future. You respond to today’s requests. Investing in infrastructure, automation, or capability building feels like stealing time from “the business.” So the organization never compounds. It just executes, day after day, with no accumulated leverage.
They disengage. When someone else owns the outcomes and you just execute the inputs, there’s no ownership to anchor your motivation. You do the work because it’s your job, not because you’re building something that matters. The best engineers leave. The rest stay and slowly stop caring.
These symptoms feed each other. Subservience creates waiting. Waiting creates task-doing. Task-doing creates disengagement. Disengagement makes the best people leave. And every departure confirms the remaining engineers’ belief that they’re just a cost center, not the engine of the business.
If engineering feels like a cost center—always asking for more headcount, always explaining why everything takes so long, always responding to requests instead of shaping strategy—the problem may not be talent. It may be identity.
Ask yourself: Do I treat engineering as a partner in building the business, or as a service that executes what others decide? Do I bring engineering leadership into strategy before decisions harden, or only after? When engineering pushes back, do I engage the reasoning, or do I override it?
Organizations live inside the identities leaders assign. Treat engineers as order-takers and they’ll take orders. Treat them as owners and they’ll own.
8.3 How Belief Takes Root
You can say “engineers are the business” a hundred times. You can say it in all-hands meetings, in one-on-ones, in Slack threads and hallway conversations. You can correct people in the moment—every “the business wants” becomes “we need.” You can be relentless.
Engineers will get somewhat better. They’ll take more ownership. They’ll push back occasionally. But nothing will transform. Under pressure, the old patterns will snap back. They’ll wait for direction. They’ll treat product as the boss. They’ll behave like a service function that happens to write code.
The problem isn’t communication. Organizations don’t learn from what leaders say. They learn from what leaders encode into systems.
Every system in an organization teaches something. Promotion criteria teach what gets rewarded. Compensation teaches what matters. Growth matrices teach what advancement actually looks like. What gets tolerated teaches what’s acceptable. Where leaders spend attention teaches priority. Strategy teaches where you’re going. Structure teaches how decisions get made. All of these systems are broadcasting, all the time. The organization is reading them constantly, drawing conclusions about what’s actually true here, regardless of what anyone says in meetings.
When a leader says one thing and the systems say another, the systems win. Every time.
Belief propagates through encoding surfaces—the systems where organizational reality gets defined.
Promotion is the loudest. If you say you want business judgment but promote people based on technical output alone, the organization will optimize for technical output. This surface is almost impossible to override with words. When belief isn’t propagating, ask first: who advanced recently, and what did they do to get there?
Structure teaches who has authority and how decisions flow. If you say engineers own outcomes but organize them as order-takers reporting to product managers who control priorities, you’ve taught the opposite lesson. The diagnostic is whether the org chart actually gives people the authority the belief implies they should have.
Capital allocation teaches what you’re actually willing to invest in. If you say technical debt matters but never allocate time to address it, you’ve answered your own question. Money and time are truth-tellers. Look at where they’re actually going.
Tolerance is the shadow curriculum. What you allow to continue is what you endorse. If you say you value ownership but tolerate people who wait for direction, you’re training the organization to wait. The question to ask: who is operating the old way without consequence?
Language is the surface most leaders underrate—and the one mid-level leaders can fully control without permission. Every time you correct “the business wants” to “we need,” you’re reshaping mental models. Language doesn’t just describe reality; it limits what people can think is possible. It’s cheap, constant, and compounding.
Organizations average across signals. If nine surfaces contradict one, the one loses. This is why culture initiatives fail: leaders announce a new value, change one system to match, and wonder why nothing changes. The organization has ten teachers and only one changed the lesson.
The failure mode isn’t total incoherence—that’s obvious chaos. The failure mode is a single contradiction. You can align nine surfaces and still lose if one high-signal system—usually promotion—rewards the old behavior. People notice what gets rewarded. They conclude everything else is talk.
8.4 Why It Takes Years
The hardest part of establishing these bones isn’t understanding them. It’s installing them in an organization that’s been trained to operate without them.
Most engineers have spent their careers in organizations where engineering was a service function. They learned to wait for requirements. They learned that driving was overstepping. They learned that “the business” was somewhere else, making decisions that they merely executed. These lessons calcified over years into an identity: I am a person who builds what others decide.
You can’t undo that identity with a speech. You can’t announce “you are the business now” and expect people to believe it. They’ll nod, then go back to waiting for requirements, because that’s what their bones know how to do.
The undoing happens through relentless consistency. Every time someone says “the business,” you stop and redirect. Not once. Every time. Every time someone waits for direction they could generate themselves, you ask why. Every time someone completes a task without considering the outcome, you push them to think bigger. Every time someone does manual work that could be automated, you ask when they’re going to automate it.
This is exhausting. For the first year, you’ll feel like you’re saying the same things over and over to people who aren’t listening. You are. They’re not ignoring you—they’re just not ready to believe you yet. The old identity is too strong. They’ve been burned too many times by leaders who said the right words but operated the old way.
What changes their belief isn’t your words. It’s the accumulating evidence that you mean it. When they take initiative and you back them instead of correcting them. When they push back on a bad requirement and you support them instead of overriding them. When they propose an investment in automation and you fund it instead of demanding the manual workaround. When they make a mistake while driving and you treat it as learning instead of proof that they should have waited for direction.
After enough evidence, some people start to believe. They start driving instead of waiting. They start investing instead of just executing. They start thinking of themselves as the business. And their transformation becomes evidence for the next wave.
But not everyone makes it.
Through all of this, there will be people who resist. Not consciously, not maliciously—they just can’t operate this way. They need to be told what to do. They’re uncomfortable with ambiguity. They don’t want to understand the business; they want to write code and go home. They’ve built their entire career on being excellent order-takers, and you’re asking them to become something else.
Some of them will grow. Given time, support, and consistent modeling, they’ll eventually shift. But some won’t. And the ones who won’t become anchors on the organization. Their resistance to driving infects the people around them. Their insistence on waiting creates bottlenecks. Their refusal to own outcomes means someone else has to own their outcomes for them.
This is where The Hierarchy of Leverage comes in. You’re going to have to work some people out. Not because they’re bad engineers—many of them are technically excellent—but because they can’t operate the way this organization needs to operate. The gardening metaphor applies: you grow what you can, you prune what you can’t. Keeping someone who fundamentally resists the identity shift costs more than the pain of letting them go.
It takes about two years. Not for everyone—some people shift in months, some people never shift. But for the organization’s center of gravity to move from service-function to business-driver, plan on two years of relentless consistency.
There’s a reason it takes that long. Culture lives at the level of assumptions—beliefs so automatic people don’t experience them as beliefs (Schein and Schein, 2017). Schein’s point is that you don’t change assumptions with announcements; you change them with sustained disconfirming evidence. And Kotter’s warning is the matching failure mode: leaders declare victory after early wins, pressure hits, and the organization snaps back to the old identity (Kotter, 1996).
That’s the timeline for bones to set. Like actual bones, they need time to calcify, to harden, to become the structure that supports everything else. Rush it and you get fractures. Skip the weight-bearing exercises and you get brittleness. The bones have to grow strong enough to hold the organization up when pressure comes.
But here’s the part most culture advice skips: sometimes the problem isn’t insight or effort—it’s access.
At one organization, I understood all of this and still couldn’t make it work. The growth matrix wasn’t mine to change. Promotion criteria were set above me. Compensation went through a process I could influence but not determine. I had verbal repetition and some tolerance within my teams—three surfaces out of nine. The belief propagated partially. Engineers got somewhat better, but it never became load-bearing. When I wasn’t in the room, the other systems reasserted themselves.
At another organization, I had it all. The growth matrix required business judgment. Promotion criteria measured scope of decision-making. Structure put engineers in position to drive. Every surface, same lesson. It still took years. But eventually the belief became load-bearing—it didn’t require my presence to operate. I never announced a cultural change. I just made it structurally expensive to believe the old thing.
The pragmatic reality: you use the levers you have. Full encoding produces full results. Partial inscription produces partial results. That’s not failure. That’s physics.
Step lightly. This isn’t a transformation initiative you announce. It’s not a reorganization you roll out. It’s the underlying work of your entire tenure at the company. You do it quietly, consistently, through a thousand small moments. You’re changing identity and power structures. That’s sensitive work. The less fanfare, the less resistance. The more it looks like just how things work here, the faster it takes root.
How do you know if your engineering organization has the right bones?
Listen to how they talk. “The business wants X” means service function. “We need X because of Y” means ownership.
Watch how they act. Do they wait for requirements or propose solutions? Do they invest in automation or accept manual work as inevitable?
Ask about the future. Engineers with the right bones have opinions about where the organization should go. Engineers with the wrong bones shrug. That’s someone else’s job.
When your CTO proposes to change it, ask which encoding surfaces they’ll touch. If it’s just communication, it will fail. If it includes structure, promotion, and capital allocation, it has a chance. Your role: hold the line when exceptions get requested. Every exception you allow teaches something.
8.5 Closing
The shift from service function to business driver isn’t a process change or a reorganization. It’s an identity change, and identity changes take years. You install the bones through systems, not speeches. Every surface that touches engineers should teach the same lesson.
When culture isn’t what you want, stop blaming communication. Audit the surfaces. Something is teaching the opposite. Find it.
That’s the orientation. That’s the marrow. And once the bones set, the organization can finally stand up straight and grow.