Leadership · 2023-2026

Quick Facts

• Industry: OneStream / EPM consulting practice
• Role: Manager — India practice lead
• Timeline: 3 years (2023 → present)
• Team: 1 → 2 → 4 → 7 contributors, in three deliberate waves
• Impact: 1 → 7 contributors with rising delivery quality at each step; single-point-of-failure engagements went from the norm to the exception

---

Overview

The only way to keep delivering well at 7 people is to design for it at 2. That sentence is the whole thesis of this case study. When the practice was a single contributor — me — every engagement was a single-point-of-failure risk and growth was something we talked about in quarterly reviews rather than something the day-to-day was built for. Three years later the practice is 7 people running multiple concurrent engagements, with a hiring playbook, an onboarding playbook, a shared component library, a documentation norm, and a mentorship cadence that turns junior engineers into senior ones on a predictable timeline. It was built deliberately, in three waves, with each wave used as the forcing function to bake in the practice the next wave would inherit.

The Problem

A one-person consulting practice has one shape of risk: you. Two concurrent engagements means each gets half of one person; three means a quality cliff. The pre-team state had five compounding problems:

• Every engagement was a single-point-of-failure. If I was sick or on leave the engagement paused. Repeat engagements were harder to win because the practice looked thin.
• Hiring would compound the risk if new people couldn't ramp. Adding a second person with no onboarding playbook means net delivery capacity goes down before it goes up. We could not afford a dip.
• Mentorship was informal and didn't scale. "Mentorship" was me reading my own commits a week later. That stops working the moment someone else is writing the code.
• No shared component library; every project rebuilt patterns. OneStream / EPM engagements have a lot of shape-similar work — dashboards, imports, validation routines, audit trails, parameterised reports — and without a library, every engagement reinvented them.
• Documentation was scattered. What existed lived in client SharePoints, my laptop, and Confluence pages of varying age. No canonical place a new hire could learn how we did things, because there was no we.

The brief I gave myself: build the practice such that the seventh hire could ramp faster than the second had, against engagements larger and more concurrent than anything we'd taken on before.

Process

Three phases, each gated by a team-size threshold. The phases overlap at the edges — documentation work that started in phase two continued through phase three — but each phase had one dominant focus, and each was sequenced so that the work compounded.

Phase 1 (team size 1 → 2) — Write the playbook before the first hire

The temptation when revenue is growing is to hire fast and figure out the rest later. That's the move that turns hiring into a risk multiplier. Before the first hire I wrote two documents: a hiring criteria document and a 60-day onboarding playbook.

The criteria defined what good looked like at three levels — junior, mid, senior — across four axes: technical fundamentals (SQL, dimensional modelling, OneStream rule structure), problem-solving instinct, communication with non-technical stakeholders, and ownership posture. Each axis had a rubric with concrete signals. "Ownership posture" was things like "candidate volunteers a constraint we hadn't asked about" or "candidate pushes back on a requirement they think is wrong." Two interviewers could compare notes without arguing about taste.

The onboarding playbook covered 60 days: week 1 shadow-only, week 2 paired work on a low-risk piece of a live engagement, weeks 3-4 owning a small deliverable with daily check-ins, weeks 5-8 owning a meaningful chunk with a weekly review. The point wasn't rigidity — it was making the ramp predictable so I didn't have to invent it every time. The first hire ramped on it. So did the seventh.

Phase 2 (team size 2 → 4) — Bake the standards in early

The leverage move at the 2-person mark is to introduce the standards while the team is small enough that adopting them is cheap. At 4 people, retrofitting a code-review standard is a project. At 2, it's a conversation and a one-page document.

In this phase we introduced three standards:

1. Code-review standard. Every change went through review with a <24h turnaround target. The template asked four questions: does this match patterns we've established, is the test coverage adequate for the risk class, is the documentation updated, and would a future engineer understand the why from this PR alone. Not skippable for "small" changes — the cost of a skipped review is paid by the next person who touches that code.
2. Documentation norm. Every engagement got a canonical doc with the same structure: data model, calculation logic, dashboards and owners, gotchas, and a runbook. The doc was updated with the change — a PR that altered behaviour without updating the doc didn't pass review.
3. Definition of done. Reviewed, documented, demoed to the client lead, with a rollback path. Not "works on my machine."

By 4 people the practice already behaved like a team rather than four solo contributors sharing a Slack channel. The cost of the change was low because the team was small; the value compounded as the team grew.

Phase 3 (team size 4 → 7) — Extract the library, structure the mentorship

By the 4-person mark we'd accumulated enough shape-similar work to see the patterns clearly. Phase 3 extracted them into a reusable component library and put mentorship on a cadence.

The library was built engagement-down, not top-down. Each engagement was asked at close-out, "what did we build here that the next engagement will also need," and the answer went into the library with a thin wrapper to make it engagement-agnostic. By the end of phase 3 it covered dashboards, data-import scaffolding, validation routines, audit-trail helpers, and parameterised report templates — the spine of any OneStream / EPM engagement we typically ran.

The mentorship cadence was the other half: a weekly architecture-review forum where any engineer could bring a design and get pressure-tested, monthly career-development one-on-ones ("what do you want to be doing 18 months from now and what's the next concrete step"), and a staffing rotation where the most-senior engineer on each engagement was not the most-senior in the practice — forcing knowledge transfer down the seniority gradient. Uncomfortable in the short term, load-bearing in the long term.

Solution

The practice has four named components, each reusable by anyone running a similar consulting build-out.

1. Hiring + onboarding playbook

A rubric-based hiring criteria document covering technical fundamentals, problem-solving, communication, and ownership at three seniority levels, plus a 60-day onboarding playbook that takes a new hire from shadow-only in week 1 to owning a meaningful chunk of a live engagement by week 8. Made the ramp predictable and let the team grow without quality dipping during ramp-up.

2. Code-review + documentation standards

Mandatory review on every change with a <24h turnaround, a four-question review template, a canonical per-engagement documentation structure, and a definition-of-done that includes review, documentation, demo, and rollback. Introduced at the 2-person mark precisely because adopting them at 4 or 7 would have been a project, not a conversation.

3. Reusable component library

OneStream / EPM building blocks — dashboards, data-import scaffolding, validation routines, audit-trail helpers, parameterised report templates — extracted engagement-by-engagement as patterns crystallised. Not a framework; engagement-agnostic pieces that a new engagement composes against rather than rebuilds from scratch.

4. Mentorship cadence + ownership culture

A weekly architecture-review forum, monthly career-development one-on-ones, and a staffing pattern that puts the most-senior practice engineer off the most-senior engagement seat. Together these make the senior bench grow rather than concentrate — the only sustainable answer to single-point-of-failure risk.

Results

| Metric | Before (year 1) | After (year 3) | Change | |---|---|---|---| | Team size | 1 contributor | 7 contributors | 7× | | Single-point-of-failure engagements | Most | Few | error class largely retired | | Ramp time for a new hire to first independent delivery | Long, ad-hoc | Short, predictable | playbook-driven | | Reuse coverage across engagements | None — every engagement rebuilt | Meaningful — library covers the spine | library-driven | | Concurrent engagements the practice could run | 1-2 with quality risk | Multiple, comfortably | capacity unlocked |

Soft outcomes:

• Delivery quality got more consistent across engineers. The review standard and the shared library meant two different engineers on two different engagements were writing recognisably similar code. Clients noticed on repeat engagements.
• Junior engineers became senior on a predictable timeline. The mentorship cadence plus the deliberate staffing pattern meant the gap between joining as a junior and owning a meaningful piece of a senior-level engagement shrunk with each wave. The seventh hire is on a faster trajectory than the second was.
• The practice can take on larger, more concurrent engagements. Work we would have declined as a 1- or 2-person practice — multi-cube, multi-stream, multi-quarter — is now well within the team's running shape, because the failure mode of any single engagement is no longer "the one person who knows it is out."

Learnings

What worked. Sequencing was the whole game. Writing the hiring and onboarding playbooks before the first new hire, introducing the code-review and documentation standards at the 2-person mark before the team was big enough to make adoption hard, and extracting the component library engagement-by-engagement — each was a decision to do something earlier than felt comfortable, and each is the reason the next phase was tractable. The transferable mental model: design the practice for the team size you want to be at, not the size you are at, and use each hiring wave as the forcing function for the next piece of the design.

What I'd do differently. Start the component library at team size 2, not 4. By the time we extracted it at 4 people we were re-extracting patterns written three or four times in slightly different shapes, and reconciling those was real work a year-earlier library would have avoided. Same lesson as the engineering one: write the abstraction once you've seen the pattern twice, not once you've suffered through it five times.

Skill developed. Building hiring rubrics two people can agree on. Hiring is the highest-leverage thing a practice leader does, and the failure mode is taste-driven decisions that don't survive contact with a second interviewer. Defining "ownership posture" as a set of observable signals rather than a feeling made hiring a team sport rather than a solo judgement call — the skill I now reach for any time I'm scaling a decision that used to live in one person's head.