People: Bus Factor, Expectations and Day One

Part of the "How to bring order to a project" series - the people track. It comes after infrastructure and architecture not because it matters less, but the opposite: it's the most important and the slowest track. A config can be moved into git in a day; trust, habits and the understanding of "who owns what" take months to rebuild. Let me repeat the track's thesis from the hub, because it's the main one: code with a bus factor of 1 is not an asset, it's a hostage. And the other way around: a team where knowledge flows freely can fix any code. Step 1. Bus factor: find the hostages The source material is the "who knows what" map from the state snapshot. If the "who knows it" column shows the same name for five services, you have five hostages and one irreplaceable person - who, by the way, isn't enjoying it either: they can't take a vacation or move to new work. The treatment is three moves, in order of rising cost: - Documentation on touch - the cheapest: figured out a piece - leave a passport or a note (this is already built into the architecture track) - Pairing on tasks - a second person on tasks in a "solo" zone; slower, but the knowledge transfers live - Ownership rotation - the most expensive, for critical zones: a service officially gets a second owner Don't try to push the bus factor to two everywhere - life is too short. Prioritize by the risk map: first what is both critical and lives in one head. Step 2. Ownership: assemble from facts, don't draw it The classic mistake is to sit down and draw a beautiful responsibility matrix the way it "should be." A matrix like that dies within a week, because it doesn't match reality. The working recipe is to assemble it from facts: pull half a year of closed tracker tasks and the git history of the repositories, and see who actually does the work and who actually decides. That's how our RACI matrix across all services was born: for each one - who executes (R), who's accountable for the result (A), who's consulted (C), who's informed (I). Not "as designed" but "as is" - with all the uncomfortable discoveries, like a service whose executor sits in one team while accountability sits nowhere in particular. From there the matrix works both ways: - a mismatch of "one does it, another answers for it" becomes a conversation and a decision instead of a silent conflict; - every service gets a name next to it - and that name comes from reality. Updates happen on touch, like everything in this series: the owner changed - the row changes in the same merge request as the passport. Step 3. Delegate - and spell out expectations The most personal part of the track. When you're bringing order to a project, it's easy to fall into a trap: you know how to do it right, so you do everything important yourself. The outcome is predictable - you become the very bus factor of 1 you're fighting. You have to delegate. But delegation has an entry price that often goes unpaid: spelled-out expectations. A familiar scenario: you hand over a task, the person works for a month, brings the result - and you expected something else. Nobody's guilty: you didn't say, they didn't ask, both filled the gaps with assumptions. A month burned, trust dented on both sides. What to spell out at handover - four things, literally as a list: - The result: what "done" looks like - not the process, the end state. Better in writing, two sentences. - The deadline and checkpoints: not "show me in a month," but "in a week we look at the direction." An early checkpoint is cheap insurance against "I expected something else": turning the work around after a week costs days; after a month it costs a month. - The boundaries of freedom: what the person decides on their own, and what they bring to you. Without this they either ping you about everything, or silently make decisions at your level. - The why: the task's context. A person who knows "why" makes the right micro-decisions where the instructions are silent. And the symmetric rule: expectations are spelled out in both directions. Ask what the person needs for the task to move - access, context, uninterrupted time. Half of the "didn't get it done" cases turn out, on review, to be "waited three weeks for access and was too shy to nag." Step 4. Onboarding and one-on-ones Onboarding is not "handed over a laptop and added to the chats." Two metrics worth measuring it by: - environment in a day - by the end of day one the person runs the project locally; - a production task in a week - within the first week they ship something real, however tiny. For that to work, the onboarding documents must exist before the hire, and there are exactly three levels - no more needed: - company - what the product is, which teams exist, who leads them, where to look; - engineering - how we work: a task's lifecycle from discussion to deploy, the standards, the decision process; - glossary - the domain dictionary: internal terms and abbreviations "everybody just knows." And separately - one-on-ones for the early period. Regular short private meetings: weekly for the first month or two, less often later. Not a status update (the tracker exists for that), but "how is it going for you": what's confusing, what's in the way, what surprised you. In their first weeks a fresh person sees your oddities better than any veteran - then they get used to it and that vision is gone. One-on-ones are how you collect it in time. They're also the natural place to re-sync the expectations from step 3 - while a mismatch costs days, not months. Step 5. Hiring: an honest footnote Hiring gets one step in this plan, and a short one - not because the topic is small, but because it's a separate big one. The market is full of people; picking the one who will strengthen your particular team is a discipline of its own that doesn't fit into a section. What does fit is one rule that costs little and gives a lot: write the job post from the project's real tasks, not from a list of technologies. Not "Python, Docker, K8s, 5 years of experience," but "here are three tasks you'll work on in your first quarter." A text like that filters by itself: the people who respond are the ones interested in the tasks, not the ones who matched the keywords. And the interview gets a ready-made script - you talk about those three tasks. The rest - the funnel, evaluation, probation - deserves its own article; it's in the backlog. What came out of it - The irreplaceable stopped being irreplaceable - and breathed easier themselves - Every service has a name from reality, not from the org chart - Delegated tasks arrive at the intended result - because the intended result was spelled out up front - A new person is useful in their first week, and their fresh perspective is collected, not lost - Job posts answer "what will I actually do here," and that's who applies The track's checklist ⬜ Bus factor from the snapshot map; treatment by cost: docs → pairing → rotation ⬜ Responsibility matrix assembled from facts (tracker + git), not drawn ⬜ Every service has a name; "does vs. answers" mismatches resolved ⬜ Delegation = result + checkpoints + boundaries of freedom + the "why" ⬜ Expectations spelled out both ways, in writing ⬜ Onboarding: environment in a day, a production task in a week ⬜ Three documents: company / engineering / glossary - existing before the hire ⬜ One-on-ones early on: weekly for the first months, not status but "how is it going" ⬜ Job posts - from real tasks, not from a list of technologies The other tracks of the series are on the map. Originally published at mind.mansur.expert. Top comments (0)