ingridleiria Chief of Staff at Series A
The money arrived, headcount doubled inside a year, and everything that worked at twenty people is failing quietly. The weekly meeting that used to settle everything now has fourteen people in it and settles nothing. Two teams are solving the same problem and a third is blocked on something nobody owns. The founder finds out a week late and has not yet admitted they no longer have full context.
At the same time the first functional leaders are arriving, hired to own exactly the work the Chief of Staff built and still holds. This is where the role most often fails, in a specific way: by keeping things. The person is competent, the systems are theirs, handing them over is slower than doing them, and eighteen months later they own a shadow version of four functions, the leaders around them are resentful, and nobody can say what the role is for.
This stage is not about building. It is about giving away most of what the role owned at seed, and rebuilding the few things that have to be rebuilt, in an order the company can absorb.
When to use this, and when not to
Use it in the twelve to eighteen months after a Series A, between roughly thirty and a hundred people, when the first functional leaders are in place or arriving, when the cadence from seed has stopped holding, or when the diagnosis in chief-of-staff-by-stage returned the rebuilder archetype. Use it when the complaint is that things keep falling between teams, which at this size is nearly always an unowned dependency rather than a disagreement.
Do not use it while the founder is still the only decision-maker and there are no leaders to transfer to; that is cos-at-seed, and attempting a handover with nowhere to hand to produces an unowned mess. Do not use it once a real leadership team owns its numbers and the work has become synthesis across functions rather than repair inside them; that is cos-at-series-b.
The adjacent case worth naming: where the actual problem is that the newly hired leaders have titles but no authority, this method stalls, because there is nothing to transfer into. Fix the decision rights first, as the second scenario below describes.
What you need before starting
A written inventory of everything the role currently owns. Every recurring meeting attended, every system maintained, every approval sitting in the path, every thing people ask you about. Missing: reconstruct it from your calendar and your last month of messages. It will be longer than you expect, which is the point.
The organisation chart with start dates and scope for every leader. A leader hired two weeks ago cannot absorb a handover; one hired eight months ago should already have it. Missing: get the start dates, because they set the handover sequence more than anything else.
Where work dies between teams. Three questions asked of six to ten people: what are you waiting on, who is waiting on you, and what did you have to chase twice. Where a connected project or ticket tool is available, sample the items that sat unassigned for more than a week and take the questions to those teams first. Missing: this is a week's work and cannot be skipped, because the answers are the dependency ledger.
The last two planning attempts. Most companies at this size tried planning once, informally, and abandoned it. Missing: ask what last quarter's targets were and who set them. If nobody answers consistently, that is the finding.
The hiring plan against capacity. Who is being hired, when, and what output they produce in which quarter. Missing: build the sequencing question into the planning cycle rather than fixing it separately, and see annual-planning-and-headcount.
One definition per metric that appears in two places. Active customer, qualified lead, delivered feature. Missing: collect the definitions in use before any reconciliation, because two functions reporting the same word with different meanings will invalidate the whole plan.
The method
Inventory what the role owns, in writing, before changing anything. Every item, with the hours a week it takes and who else could hold it. Do this in week one of the stage, not when it becomes painful.
Sort every item with one rule, not a feeling. Transfer if a function exists that will own this within six months. Keep only if the work is genuinely cross-functional and has no natural home. Stop if the item exists because it always has. When in doubt between keep and transfer, transfer: the cost of handing something over slightly too early is a rough quarter for one leader, and the cost of holding it too long is the role's credibility.
Sequence handovers by the leader's start date plus ninety days. Do not transfer into someone's first month, and do not wait past their sixth. Where a function has no leader yet, put the item in a holding list with the hire it is waiting on, so the handover is scheduled rather than remembered.
Hand over properly: a document, a date, two shadowed cycles, then stop attending. The handover document says what the thing is for, what breaks if it stops, who depends on it, and what a good month looks like. Two cycles shadowed together, then you leave the meeting. Attendance after handover is the most common way a transfer silently fails, because everyone including you keeps treating you as the owner.
Build the dependency ledger. Every commitment one team is relying on from another: what, from whom, to whom, by when, and what happens if it slips. Most cross-functional failure at this size is an unowed dependency rather than a disagreement, and a ledger converts an argument about intentions into a date.
Rebuild the cadence, one layer at a time, no more than two rebuilds a quarter. Weekly leadership meeting, monthly business review, quarterly planning, each with a stated purpose and a rule about what belongs in it;
operating-cadence-designcarries the method. The limit is the discipline that matters: rewriting processes as fast as the company grows means nothing is stable long enough to be adopted, which is the characteristic failure of an energetic Chief of Staff here.Run one planning cycle properly, including the reconciliation. Top-down target and bottom-up build, both produced, then reconciled in a room with the leaders present rather than by spreadsheet. The gap between them is the actual content of the meeting. Most companies at this size plan by extrapolating and discover the gap in the third quarter, when it is expensive.
Settle metric definitions before the first reconciliation, not after. One definition per term, written where people can see it, agreed by the two functions that use it differently. This is unglamorous and it is the difference between a plan that adds up and a quarter of arguments.
Install written internal communication before you need it. Between fifty and seventy people the room stops holding the company. Written weekly updates, a predictable all-hands, one place where decisions live. When people stop knowing what is happening they invent an explanation, and it is worse than the truth.
Name the first-time manager gap out loud. Individual contributors promoted for being good at the work now have reports and no training. This is the largest single source of attrition at this size and it is nobody's job until someone makes it theirs. Naming it to the chief executive is inside the role even when fixing it is not.
The handover register
The register makes this stage's work visible, because handover is invisible by nature: done well, it looks like nothing happened.
Every item carries a receiving owner, a date and a state. Three states only: shadowing, transferred, or blocked with the reason. Items sitting in shadowing for a quarter are telling you the transfer is not real.
Review it monthly with the chief executive and read out the keep list. That list should shrink for two quarters and then stabilise at three or four genuinely cross-functional things. A keep list that grows is the early signal of the accumulation failure.
Decide alone, or escalate
Decide alone: the shape of the cadence, planning mechanics, how information moves, tooling, metric definitions once agreed, and anything procedural.
Escalate: role and organisation design, anything about an individual's performance, resource trade-offs between functions, and anything where two leaders disagree.
The rule that matters most at this stage: do not adjudicate between functional leaders. It is tempting, because you can see the answer and they are both busy, and it costs you the neutrality the role depends on. Put the disagreement in front of the chief executive with both positions stated fairly, including the one you disagree with, and let it be decided by someone with the authority to make it stick. decision-memo is the format.
Worked example
Situation. Halloway, a data quality platform sold to mid-sized banks. Sixty-eight people, nine months after a 16 million Series A, with a plan to reach 105 by year end. Recurring revenue 4.2 million against a target of 7 million. Four functional leaders had been hired in the previous seven months: engineering, sales, customer success, and finance. The Chief of Staff had been there since the company was fourteen people and still owned recruiting coordination, the numbers workbook, vendor and tooling decisions, the office, the investor update, and a standing seat in every escalation.
Two symptoms had reached the founder in the same week. Two engineering teams had built overlapping data ingestion for four months. And a bank in onboarding for eleven weeks had been passed between sales and customer success three times, with no owner at any point.
Task. Within one quarter: get the accumulated ownership out of the role, stop work dying between teams, and run a planning cycle for the following year that the leadership team would actually use. Good meant the founder not being the escalation route for anything cross-functional.
Action. The inventory listed nineteen items and 31 hours a week. Sorted by the rule: eleven to transfer, three to keep, five to stop. Sequenced by leader start date, which put the numbers workbook first, the finance lead being six months in, and recruiting last, on the holding list against a people hire that did not yet exist.
The wrong turn came in week two. The overlapping-ingestion problem was read as a communication failure and answered with a weekly cross-functional sync of fourteen people. It ran five weeks, cost roughly fourteen hours of company time a week, and surfaced one duplication, late. It was abandoned when the founder asked what had been decided in it and the honest answer was nothing. The problem was not visibility but ownership: nobody had written down who owed what to whom, so the meeting was a place to notice failures rather than prevent them.
The dependency ledger replaced it. Twenty-three live dependencies were collected in nine conversations, each with a giver, a receiver, a date and a consequence. Nine were news to at least one party. Three had no owner at all, including the onboarding handoff that had lost the bank for eleven weeks, assigned to customer success with a written trigger at contract signature. Metric definitions were settled next and found two problems: sales and finance counted a customer at moments roughly 15 percent apart, and customer success measured onboarding by a checklist nobody else had seen.
The planning cycle ran in the last five weeks of the quarter. Top-down target 7 million; bottom-up build from the four functions 5.4 million with the hiring plan as written. The reconciliation took three hours in a room. The gap was mostly hiring sequencing: nine of fourteen planned sales hires started in the second half and none would produce revenue inside the year. Six moved earlier, three were cut, and the target was reset to 6.3 million with the leadership team's agreement rather than the founder's insistence.
Result. By the end of the quarter the keep list was three items: the cadence, the dependency ledger, and the investor update. The role's hours on transferred work went from 31 a week to about 7, which was the shadowing overhead of the two most recent handovers.
The reconciled plan is the part that mattered most. The company hit 6.1 million against the revised 6.3, and the leaders described the number afterwards as theirs, which had not been true of any previous target. The recruiting handover stayed blocked for two more quarters because the people lead was hired late, and it sat on the register visibly blocked rather than quietly held, which is the small distinction that keeps a keep list honest.
A second scenario, where it goes differently
A forty-five person company, seven months after a Series A, with a newly hired head of sales and head of engineering. The same inventory was produced and the same sort applied, and the handovers stalled immediately. Both leaders accepted items and then routed decisions back, because the founder was still approving hiring, pricing and roadmap changes personally, and everyone had learned that a decision was not final until the founder had touched it.
The method inverted. Transferring work into a leader with no authority creates a slower version of the same bottleneck, so the handover was suspended after two items and the work became a written decision rights table: for each of eleven recurring decision types, who decides, who is consulted, and what threshold sends it up. It took three weeks, most of it spent getting the founder to be specific about discount and hiring thresholds, and it was reviewed line by line with both leaders present so nobody could later claim a different reading.
Only then did the handovers resume, and they took half the time expected, because the receiving leaders could actually decide.
What changed the sequence was not size or funding. It was that authority had not moved with the titles, and no amount of handover discipline fixes that. Where the second or third transfer bounces back for reasons that have nothing to do with the receiving leader's competence, stop transferring and go fix the decision rights.
Output
OWNERSHIP INVENTORY AND HANDOVER REGISTER
| Item | Hours a week | Verdict | Receiving owner | Handover date | State |
| | | transfer / keep / stop | | | shadowing / transferred / blocked, why |
KEEP LIST (should stabilise at 3 or 4 cross-functional items)
1. [item, and why it has no natural home]
DEPENDENCY LEDGER
| What | From | To | By when | If it slips | Status |
PLANNING RECONCILIATION
Top-down target: [number]
Bottom-up build: [number]
Gap: [number], attributed to: [causes, largest first]
Resolved by: [what changed: sequencing, scope, target, headcount]
Agreed target: [number] Agreed by: [names, in a room, on a date]
Failure modes
Keeping things because handing them over is slower. It is slower, for one quarter. Recognise it by a keep list that grows or a transfer that has been shadowing for three months. Fix by setting the date first and working backwards.
Handing over and still attending. Recognise it when people still ask you and the new owner defers to you in the meeting. Fix by leaving the meeting entirely on the agreed date, even when the first month is worse without you.
Adding a meeting to fix a cross-functional failure. Recognise it when the new meeting has more than eight people and no decision rights. Fix by writing the dependency down with a giver, a receiver and a date, which is what the meeting was trying to substitute for.
Rebuilding everything at once. Recognise it when three processes changed this quarter and none is being followed. Fix by capping at two rebuilds a quarter and finishing them.
Adjudicating between leaders. Recognise it when two leaders each lobby you privately. It feels like influence and it is the fastest way to lose the neutrality the role runs on. Escalate with both positions stated fairly.
Ignoring the metric definitions. Recognise it when two functions report the same word with different numbers and everyone has learned to live with it. Fix before the reconciliation, because afterwards the plan cannot be defended.
Edge cases
No leader exists for something that must be transferred. Put it on the holding list against the hire, name the hire, and report it monthly as blocked. Blocked and visible is a legitimate state; quietly held is not.
A leader is failing and the role is compensating. Recognise it as a handover that keeps coming back. This is not a process problem and cannot be fixed by better documentation. It goes to the chief executive as an observation about the role, never as a judgement about the person, and it goes early, because the compensating is what hides it.
The founder will not let go of a decision. Where a decision type keeps returning to them despite a written rule, treat the rule as unagreed rather than broken and go back to the conversation. One area, small, for a month, is the test that usually settles it.
A reorganisation lands mid-handover. Freeze the register, re-sort against the new structure, and restart the sequence. Transfers made into a structure that is about to change fail twice.
The company is shrinking after the round. The handover reverses, and the role absorbs work rather than shedding it. Say so explicitly and put an end date on each absorbed item, otherwise a temporary absorption becomes permanent ownership.
Quality bar
- An ownership inventory exists in writing, with hours a week against every item.
- Every item is marked transfer, keep or stop, with a date and a receiving owner where it transfers.
- The keep list is three or four genuinely cross-functional items, and it is shrinking or stable rather than growing.
- No meeting is attended after the item it belongs to was transferred.
- The dependency ledger names a giver, a receiver, a date and a consequence for every live dependency.
- One planning cycle has been reconciled in a room, with the gap and its causes written down.
- Metric definitions are settled and written before any reconciliation.
- Disagreements between leaders were escalated with both positions stated, never adjudicated by this role.
Adapting this to your context
The defaults come from venture-funded companies of thirty to a hundred people in the year after a round. The round name is a proxy for something far more portable.
- "Series A" as a label. It means one layer of functional leads has arrived, headcount sits roughly between thirty and a hundred, the cadence built at twenty has stopped holding, and there is finally somewhere to hand work to. An agency appointing its first department heads, a family business bringing in a general manager, a charity with its first senior team and a bootstrapped firm at that size are all here, whatever they raised.
- The ninety-day handover rule. It assumes a full-time commercial onboarding. Extend it where the receiving leader is part-time, seasonal or inherited from a merger, and shorten it where they have done the same job here before.
- Two rebuilds a quarter. Set for a company absorbing change while growing fast. A team already carrying a system migration, an inspection or a regulatory deadline absorbs one.
- The metric definitions. Active customer and qualified lead assume a sales pipeline. Substitute the two terms your functions count differently: beneficiaries served, billable hours, cases closed, places filled.
- What not to change. Sort every item by the rule rather than by feeling, and never adjudicate between functional leaders.
Related skills
cos-at-seed built what this stage hands over; its transfer register is the starting inventory here. cos-at-series-b is where this leads, once the leadership team owns its numbers and the work becomes synthesis rather than repair.
operating-cadence-design carries the cadence rebuild. annual-planning-and-headcount carries the planning cycle and the hiring sequencing that usually explains the gap. okr-planning sets the objectives the cadence tracks. decision-memo is the format for every escalation, particularly disagreements between leaders. onboarding-plan is what the receiving leaders need if they arrived without one. chief-of-staff-by-stage confirms this is the right playbook and rediagnoses when headcount passes a hundred and fifty.