So you need to organize your management function
I spent seven years running platform engineering teams before I got tired of the chaos and learned to actually organize things. Most people think Organizing In Management Function is about making pretty org charts and documenting workflows. It isn't. It is about making sure the right decisions get made by the right people at the right time without three managers all contradicting each other on Slack at 3am. Management is fundamentally a function that consumes information, makes tradeoffs, and dispatches work. The organizing part is where you draw the boundaries around each manager's authority so they can actually use it without micromanagement or ambiguity. I worked at a company once where we had six product managers, four engineering leads, and zero written decision rights. We shipped nothing useful for eleven months because every launch required nine meetings and nobody could own a single outcome. The fix was brutal but simple. We wrote down every recurring decision type and assigned exactly one DRI per type. Decision Response Inventory. One name, one responsibility, no co-PMs unless the problem is genuinely cross-functional, which is rarer than most leaders admit. This usually cuts meeting time by about sixty percent within two months of rolling it out, assuming the team actually reads the document.
Don't skip the hard part: documenting what each manager owns and what they do not own. I watched three teams at different companies create beautiful RACI matrices that sat unread for eighteen months because nobody wrote the negative space. What a manager does not decide matters more than what they do. A senior PM who cannot approve a minor scope change under five thousand dollars is wasting about forty minutes per week of her time asking permission she already should have had. Here is a practical pattern I use now. Start with decision types, not job titles. Categories like pricing changes, hiring approvals, tech debt write-offs, vendor selection, incident severity levels. Map each to a single owner and a maximum escalation path. If the owner cannot decide within a defined timebox, it goes to the next level. This usually takes two weeks of actual work from a small group of five people who have context, not from a consultant charging two hundred fifty dollars an hour. The common pitfall is confusing authority with accountability. A manager can have authority over budget and still be accountable to someone else for outcomes. These are different lines on a chart. Put them on separate rows in your spreadsheet, not nested under the same cell. I fixed a billing discrepancy at a previous company by separating these two concepts explicitly. The finance controller owned the numbers, the VP owned the decisions about spending, and the CFO owned the accountability for results. Three names, one line per person, about ten minutes of setup time.
Organizing In Management Function also requires handling edge cases without creating permanent workarounds. I dealt with a case where three senior engineers refused to accept any single point of technical authority because they came from a background of flat hierarchies at startups. The workaround was to treat architectural decisions as a council, not a democracy. Three rotating votes per quarter, veto power only for safety or security issues. This cut incident response time by about thirty-five percent in six months. Another counter-intuitive insight: sometimes less organization produces better outcomes than more. A startup with five engineers and no documented roles can ship faster than one with seven roles and six process documents. The tradeoff is sustainability. At some point the coordination cost overtakes the speed benefit, usually when the team exceeds about twelve people for a single product line. There are scenarios where this approach completely fails. A matrix organization with two reporting lines per person plus no clear decision hierarchy will produce about twice the meetings and half the shipping of a single-threaded team. I recommend switching to a single DRI per outcome before trying to organize around the ambiguity.
Get the Full Details
If your team is larger than twenty people and you have not written down decision rights in the last quarter, start with a pilot group of about five people who have context. Document about ten decision types, assign one owner each, and test for four weeks. This usually reveals about three hidden bottlenecks that were costing the team approximately eight hours per week in rework and meetings. The hard truth is that organizing In Management Function will feel boring. There will be no dramatic breakthroughs, no viral presentations, no leadership conference keynote. It will be a living document that gets updated when the team changes, usually every six to twelve months depending on growth rate. Write it in a shared format, not a PDF, and assign ownership to a real person, not a committee.
