Two years in and I finally stopped rewriting the org chart every quarter
Constant restructuring is a symptom of unclear ownership, not wrong structure. Org charts stabilize when decision rights are explicit.
Every quarter for the first eighteen months at FinanceOps, I redrew the org chart. I moved people between teams. I renamed squads. I shifted reporting lines. I told myself each change was responding to new information. It was not. It was responding to the same problem I refused to name: nobody knew who owned what.
Most of the leadership posts in this phase are me compressing scar tissue into defaults. It also builds on what I learned earlier in “Eighteen months in: the five things I would tell myself on day one as Head of Engineering at a startup.” I am less interested in performative management language now and more interested in the boring mechanisms that keep teams aligned when nobody is in a heroic mood.
The Restructuring Addiction
Restructuring feels productive. You draw new boxes. You announce the change in an all-hands. People nod. For two weeks, energy is high because the new structure promises to fix the friction that the old structure created. Then the same friction reappears, wearing a different hat.
The pattern was obvious once I stopped to look at it. Every reorg was triggered by a coordination failure. A feature shipped late because two teams each thought the other owned the integration. A bug sat unfixed for a week because no one could identify the responsible engineer. An infrastructure migration stalled because platform work had no explicit owner.
My instinct was to fix the structure. Move the people. Change the topology. But the real problem was never the shape of the org chart. It was the absence of written ownership.
Decision Rights Over Reporting Lines
The fix was embarrassingly simple. I wrote a single document that listed every major system, every cross-cutting concern, and every recurring decision type. Next to each one, I wrote a name. Not a team. A name. One human being who could say yes or no.
- Payment processing pipeline: owned by Sarah, including schema changes, retry policies, and vendor integrations
- CI/CD pipeline and deployment tooling: owned by Marcus, including build times, flaky test policy, and release cadence
- Database schema and migration strategy: owned by me, because the consequences of a bad migration at our scale are existential
- API design standards and breaking change policy: owned by James, who had the best instinct for downstream consumer impact
- Infrastructure cost and capacity planning: owned by Sarah with quarterly review from me
The document was two pages. It took an afternoon to write. It replaced six months of quarterly reorgs.
What Actually Changed
Three things happened immediately. First, decisions got faster. When someone asked who should approve a schema change, the answer was in a document, not in a Slack thread that pinged four people and got zero responses. Second, accountability became real. When a system broke, we did not play the team-boundary blame game. We had a name. That name had context, history, and motivation to fix it permanently.
Third, and most importantly, people stopped waiting for permission. When ownership is ambiguous, senior engineers default to caution. They ask before acting. They schedule meetings to align. They write proposals that sit in review for weeks. When ownership is explicit, the owner just decides. Speed comes from clarity, not from reorganization.
The Org Chart Stabilized on Its Own
Once decision rights were explicit, the reporting structure stopped mattering as much. People still reported to the same managers. Teams still had the same names. But the invisible wiring that actually determines how work flows through an organization was finally documented and defended.
I have not redrawn the org chart in eight months. Not because the organization is perfect but because the problems we face now are real engineering problems, not coordination theater. When someone proposes a reorg, my first question is always the same: what decision is being made badly, and who should own it? If you can answer that question, you rarely need to move anyone.
This is the phase where individual scars finally turned into repeatable operating principles. I cared less about sounding clever and more about leaving behind a system that stayed sane without me in the room. That is how I build lifeos and bisen-apps too.
Org charts describe reporting relationships. Decision rights describe how work actually flows. Fix the second before you touch the first.
The Windsurf acquisition by Cognition for $250M happened around this time, and it mirrored what I was learning internally. Consolidation in AI tooling was happening because unclear boundaries between competing tools created the same coordination failures that unclear ownership creates inside organizations. The pattern scales from four-person teams to entire industries.
Two years in, and the lesson is simple. If you are restructuring your organization more than once a year, you do not have a structure problem. You have an ownership problem. Write down who owns what. Defend those boundaries. Stop redrawing boxes.
The stability that followed the ownership framework surprised everyone, including me. Engineers stopped asking who owns this and started asking how should we improve this. The shift in language reflected a shift in mindset. Clear ownership does not mean rigid boundaries. It means everyone knows where decisions live, who to escalate to, and what success looks like for their piece of the system. That clarity is worth more than any org chart redesign. The team became more autonomous because they understood their scope, not because I drew better boxes on a slide. Every new engineer who joins now reads the ownership document in their first week, and within a month they are making decisions without asking permission. That is the compounding return of getting ownership right.