What I learned separating people management from delivery accountability
14 min read
A couple of weeks ago, I saw a Head of Engineering job post that required leadership experience working in a flat organization. Then, last week, a post by Dr. Milan Milanovic appeared in my LinkedIn feed, asking whether teams should be hierarchical or flat. His framing stayed with me because it pointed to the real leadership question: not which structure is universally better, but whether teams know which mode the moment requires.
That distinction matters.
Flattening an organization is not only about removing layers from an org chart. At its best, it is about reducing decision latency, shifting autonomy closer to the work, and giving the people with the most context more authority to act responsibly. It is a design choice about how decisions move, how quickly learning reaches action, and whether the organization trusts teams to use judgment without waiting for permission at every step.
Leaders often use the word flat very differently. For some, flat means fewer layers. For others, it means less bureaucracy, faster decisions, fewer managers, or more empowerment. In some organizations, it changes how authority works. In others, it mostly changes the language leaders use to describe the same hierarchy.
I spent much of my career working and leading in traditional hierarchical organizations. Managers managed teams. Decisions moved up and down the chain. Authority was easier to see because it usually followed the org chart.
Later in my career, I helped scale a flatter engineering model built around small, self-managed, cross-functional teams. Engineering Managers still had direct reports, but they did not manage the delivery teams their direct reports served on.
Teams owned the work. Managers developed the people.
That model created stronger ownership, better delivery conversations, healthier team dynamics, and clearer accountability close to the work. It also confused some leaders who joined later.
More than once, I heard some version of the same question:
“What do you mean the teams are not led by managers?”
That question reveals the real tension.
Many leaders are comfortable removing layers from an org chart. Fewer are comfortable when authority actually moves closer to the work.
I have written before about the mindsets that shape software delivery team structures and the friction that appears when team structure, role alignment, architecture, and career paths are not designed together. This article builds on those ideas but focuses on a more practical leadership question: what actually happens when people management and delivery accountability are intentionally separated?
A lot of leaders say they want flat organizations until the first time a team makes an important decision without a manager visibly in charge.
That is where the flat organization conversation gets interesting.
Flat still needs structure
From the outside, our model looked flat. Inside the division, structure still existed.
People still had managers. Leaders still had accountability. Career development, performance, compensation, hiring, coaching, and organizational decisions still had clear ownership.
What changed was who had the floor inside the work.
The best teams do not operate in one mode all the time. They know when authority needs to become clearer, when the room needs to flatten, and when the person closest to the problem needs space to be heard.
When production is down, the team does not need a long consensus exercise. Someone needs to coordinate the response, make decisions, communicate clearly, and help the team move.
Use that same leadership mode in a design review, retrospective, discovery conversation, or root-cause discussion, and the team may lose the insight it needs most. The best idea may come from the junior engineer, the QA engineer, the designer, the Agile Leader, or the person who has quietly been seeing the pattern for weeks.
That was one of the biggest lessons from running this model.
The structure stayed stable. The leadership mode changed depending on the work in front of the team.
Two models, different choices
This is where the conversation can get too binary.
An Engineering Manager-led delivery team is not wrong. A self-managed cross-functional team without an Engineering Manager in the daily delivery authority structure is not automatically right. They are different operating choices.
The better question is whether the model matches the organization’s goals, architecture, dependency landscape, leadership capability, and team maturity. Architecture matters because it shapes how teams coordinate, where decisions need to happen, and how much cross-team conversation is required. Conway’s Law still applies: the way teams communicate and make decisions eventually shows up in the systems they build.
Team design should not be treated as a leadership preference detached from the technical system. Different architectures and operating models create different coordination needs. A monolithic system, a tightly coupled platform, a distributed architecture, a mature DevOps environment, or a domain-aligned product model can each require a different structure. Leaders create risk when they copy the visible model without understanding the system underneath it: the architecture, dependencies, maturity, leadership capability, and operating context that determine whether the model can actually work.
The model we ran
In our model, Engineering Managers still had meaningful management responsibilities. They hired people, coached people, supported career growth, handled performance management, contributed to compensation decisions, developed talent, and helped their direct reports navigate the human side of organizational life.
Their role mattered deeply. They were simply outside the team’s daily delivery authority structure. The delivery team managed the work. The Engineering Manager supported and developed the people.
There was also an important nuance: front-line Engineering Managers contributed technically. Many Engineering Managers were individual contributors on delivery teams. They contributed as senior engineers, stayed close to the technology, and remained engaged in building software.
The distinction was that they were not acting as the delivery authority for their own direct reports. Whenever possible, managers contributed to teams without directly managing the people doing the work around them.
That mattered.
It allowed managers to remain technical without turning every delivery conversation into a management conversation. When an Engineering Manager contributed code, design input, or technical judgment, they were participating as an experienced engineer. When they were coaching, developing, reviewing performance, or supporting career growth, they were acting as managers.
The 50/50 balance was never a perfect daily equation. Some weeks leaned more toward management. Some weeks leaned more toward engineering contribution. It was a design principle that kept managers close to the technology while still giving them enough capacity to lead, coach, develop, and support their people well.
That also shaped our management ratios. We kept the direct-report ratio intentionally small. The target was around 5 direct reports, and even experienced managers generally stayed at 7 or fewer. That gave managers enough room to coach, develop, support, and evaluate people well while still contributing as senior engineers.
Teams scaled around the work. Management capacity scaled around the people.
Self-managed did not mean unsupported
Self-management is easy to misunderstand.
We did not take a group of developers, remove the manager, and call it empowerment. The team had the capabilities, roles, and support required to own delivery together.
A typical team included the skills needed to deliver enterprise software responsibly: product ownership, agile leadership, technical leadership, software engineering, quality assurance, and enabling support from production engineering, architecture, data, or security.
The Engineering Manager remained part of the system, but with a different responsibility.
The team built the habit of managing trade-offs, inspecting progress, improving flow, responding to feedback, and learning from outcomes together. The manager focused on people development, coaching, performance, hiring, retention, and career growth.
That did not mean teams were expected to solve every issue on their own.
If a team needed decision support from a senior manager or me, they reached out. If they had a concern with a team member they could not resolve directly, they reached out to that individual’s manager. The system still provided clear escalation paths, active management support, and visible accountability when teams needed help.
The difference was that escalation did not replace team ownership.
That distinction is important. Autonomy without support becomes abandonment. Support without ownership becomes dependency. The goal was responsible autonomy.
Why leaders struggle with this model
The hardest part of this structure was often explaining it to new leaders who had only known manager-led delivery teams.
Their reaction was understandable.
In many organizations, the Engineering Manager is the team leader, delivery owner, people manager, escalation point, agile translator, technical decision filter, and strategy interpreter. When leaders grow up in that model, every form of leadership appears to sit in one role.
So when they hear that teams are not led by managers, it can sound like accountability has been removed.
In truth, accountability moved closer to the work.
People leadership stayed with the Engineering Manager. Technical leadership lived with the Technical Lead. Flow and team health were supported by the Agile Leader. Product direction came through Product. Quality and risk thinking came through QA and the full team. Senior leadership still set direction, clarified priorities, and handled decisions that belonged above the team level.
The model only looks strange if you expect every form of leadership to sit in one chair.
That expectation can become a leadership blind spot.
A senior leader may say they want empowerment, autonomy, and faster decision-making. Then they see a team operating without a manager overseeing the work, and they become uncomfortable because authority is less apparent.
The instinctive question is, “Who is in charge?”
The better question is, “Is authority sitting with the person closest to the work, or only with the person easiest to find on the org chart?”
That difference is important because accountability did not disappear in our model. If a team struggled, if delivery went sideways, if quality dropped, or if a people issue created risk, I was still accountable as the senior leader. My managers were still accountable for the people they supported. The team was accountable for owning the work, surfacing issues, making responsible decisions, and asking for help when needed.
The model kept accountability clear while shifting day-to-day authority closer to the people with the most context.
Why we separated people management from delivery
We made this choice because we wanted teams to build stronger ownership.
The goal was to have engineers, QA, product, design, technical leadership, and agile leadership working as peers around the problem. Decisions needed to sit closer to the work, and teams needed shared understanding of customer needs, technical constraints, risks, flow, quality, and outcomes.
That dynamic changes when the person responsible for performance reviews is also the person directing the daily delivery conversation.
A thoughtful Engineering Manager can create a healthy team environment. Many organizations run manager-led teams well. I have worked with strong leaders who make that model successful.
The challenge is that the dual role changes the dynamics of the room.
When your manager is also the delivery authority inside the team, people may become more careful. They may challenge less directly. They may frame uncertainty differently. They may hesitate in a retrospective. They may wait for the manager to decide, even when the best answer is already inside the team.
This does not always look like dysfunction.
Sometimes it looks like politeness. Sometimes it looks like alignment. Sometimes it looks like silence.
Psychological safety had to show up in how teams worked, debated, learned, and improved. The Technical Lead could guide technical direction without also owning someone’s performance review. The Agile Leader could protect flow and team health without becoming a status reporter. Product and Engineering could debate trade-offs honestly. QA could raise risk without being treated as a blocker. Managers could coach people without needing to sit at the center of every delivery decision.
The design gave teams more room to operate honestly.
Leadership became more distributed
One of the biggest misunderstandings about self-managed teams is that leadership disappears.
In my experience, leadership becomes more distributed.
Product brought customer context, business priorities, discovery, and outcome clarity.
Technical leadership brought architecture judgment, technical direction, maintainability, and engineering trade-off thinking.
Agile leadership supported flow, facilitation, team health, impediment removal, and continuous improvement.
QA strengthened test strategy, risk thinking, release confidence, and quality advocacy.
Developers brought implementation, design input, operational awareness, and technical ownership.
The Engineering Manager brought people leadership.
That separation helped us avoid turning every Engineering Manager into a unicorn. Even when managers contributed technically, they did not need to be the architect, delivery lead, agile coach, career coach, performance manager, and organizational translator all at once.
Technical excellence still lived close to the work. Management excellence still lived close to the person. In some cases, the same individual contributed to both, but the responsibilities remained distinct.
That gave people more room to grow in the direction where they could create the most value. Strong engineers could become technical leads, domain experts, staff-level contributors, or architectural leaders without being pushed into people management. Strong people leaders could develop management craft without pretending they had to be the technical north star for every system their direct reports touched.
The model respected both paths.
Authority moved with the moment
The word flat becomes limiting because the organization was never flat in every situation.
During an incident, authority became clearer. Someone needed to coordinate the response. The team needed speed, communication discipline, and operational focus.
During a design conversation, the Technical Lead might guide the discussion. Strong Technical Leads still made room for challenge because the goal was to improve the design, not win the conversation.
During discovery, anticipated outcomes, and prioritization, Product might lead. The team still needed to challenge assumptions, surface feasibility concerns, and connect the work to customer and business outcomes.
During retrospectives, the room needed to be flatter because the point was learning. If hierarchy dominated the conversation, the team would only discuss the safe problems.
During career conversations, the Engineering Manager stepped fully into the manager role. Coaching, performance, development plans, feedback, growth, and support belonged there.
Authority moved depending on the work in front of the team.
That was the real operating model.
What made the model work
Self-managed teams need more than permission to be autonomous. They need the conditions that make autonomy responsible.
Responsible autonomy required clear ownership, stable team boundaries, product and technical context, and the skills needed to deliver the work. It also required delivery practices that supported small batches, feedback, and learning; architecture that did not force every decision through a dozen other teams; and platform, security, and operational guardrails that allowed teams to move with confidence.
Role clarity was essential.
Without it, flatness becomes confusion. Autonomy becomes abandonment when teams lack the support they need. Distributed leadership starts to drift when feedback loops are weak.
That is why this model depended on the surrounding system: Agile practices, DevOps, continuous delivery, Value Stream Management, flow metrics, product alignment, Team Topologies thinking, and strong Engineering Managers.
Good management still mattered.
Managers held one-on-ones, gathered feedback, understood the work their people were doing, and partnered with Technical Leads, Agile Leaders, Product Managers, and peers to understand contribution, growth, collaboration, strengths, and development areas. They coached people through challenges, addressed performance concerns, helped people navigate career paths, and developed talent.
They did not need to attend every team ceremony as the delivery authority to do it well.
Being outside the team often gave managers a healthier coaching position. They could focus on the person, not only the sprint. They could talk about growth, confidence, influence, communication, technical development, collaboration, and career direction without every conversation being filtered through this week’s delivery pressure.
The model protected team ownership, psychological safety, management craft, and technical leadership as its own path.
Those benefits showed up in the culture. Teams learned faster. People built domain expertise. Managers developed as coaches. Technical leaders had room to lead. Decisions moved closer to the work.
The model had challenges, as every model does. But the biggest challenge was rarely whether the teams could work this way. The bigger challenge was whether leaders could understand it without trying to force it back into the model they already knew.
That is where experience can become dangerous.
A leader’s past success can become a universal playbook. What worked in one architecture, culture, product, or stage of growth may struggle in another.
Context matters. Structure should fit the system.
Why this matters now
This conversation matters even more as organizations become leaner, more AI-enabled, and more willing to rethink team design.
AI will change how work is done. Teams may shrink. Roles may blend. Some responsibilities may shift. Some tasks may require fewer people than they did before.
I am not against that. Change and adaptation are part of the work.
The caution is that reducing task effort does not automatically reduce responsibility. The jobs to be done still exist somewhere. Product judgment, technical direction, quality strategy, delivery flow, security awareness, production readiness, people development, and outcome learning still need ownership.
That was true when we separated Engineering Managers from delivery teams, and it remains true as AI reshapes and redefines teams.
A flatter structure can be more demanding because it requires clearer roles, stronger trust, better feedback loops, and more mature leadership behavior. People have to know when to step forward, when to step back, when to challenge, when to decide, and when to escalate.
Organizations struggle when they pretend hierarchy has disappeared. They also struggle when hierarchy silences the intelligence distributed across the team.
The stronger operating model is honest about both.
The leadership lesson
The years we spent running this model taught me that team structure is never just an org chart decision.
It shapes culture, ownership, psychological safety, and how people speak up. It influences whether teams wait for direction or act with judgment, and whether managers become bottlenecks or multipliers.
Flat, manager-led, and hybrid models can all work. They can also all fail when leaders copy the structure without understanding the conditions that made it succeed.
There are no universally right or wrong models. There are choices, trade-offs, and consequences.
Team design depends on the system around it: current and future technical architecture, product boundaries, value streams, dependencies, leadership styles, team maturity, operational risk, and the organization’s ability to support distributed ownership.
Our transformation worked because the structure evolved with the system. We did not move from larger functional groups to self-managed, cross-functional, stream-aligned teams overnight. We earned that model over time by changing the surrounding conditions: team ownership, technical practices, delivery discipline, product alignment, platform support, and leadership expectations.
For us, the model worked because it was intentional.
Teams owned delivery. Engineering Managers owned people development. Technical leadership lived close to the work. Agile leadership protected flow and learning. Product brought context and prioritization. QA protected quality and risk thinking. Enabling teams helped with architecture, security, data, and operations.
The hierarchy remained, but it became more purposeful.
That is the lesson I take from the flat-versus-hierarchical debate. Leaders need to understand how authority, responsibility, and accountability should move through the system.
The next time a leader says they want a flat organization, I would ask a more direct question:
Are you comfortable with authority moving to the person closest to the work, even when that person is not the manager?
If the answer is no, the organization may simply have fewer layers.
That is not the same as being flat.
A strong engineering organization does not need one mode. It needs the maturity to know which mode the moment requires.
What are you seeing in your organization? Are team structures being designed around the work, the architecture, and the value streams, or around the leadership models people are already comfortable with? Let’s talk: phil.clark@rethinkyourunderstanding.com
Stay curious. Learn to unlearn. Rethink your understanding.
Coming Soon
This article connects to a larger theme in my upcoming book, Profitable Engineering: technology organizations create more business value when leaders design the system around the work. Team structure is part of that system because how authority moves, who owns responsibilities, and how teams connect Flow to Realization all shape whether technology becomes a true strategic business partner.
References
- Dr. Milan Milanovic, “Should teams be hierarchical or flat?,” LinkedIn post, May 31, 2026.
- Clark, Phil. “Mindsets That Shape Software Delivery Team Structures.” Rethink Your Understanding. https://rethinkyourunderstanding.com/mindsets-that-shape-software-delivery-team-structures/
- Clark, Phil. “When Team Structure Collides with Role Alignment,” Rethink Your Understanding, https://rethinkyourunderstanding.com/when-team-structure-collides-with-role-alignment/