1.13 Mentoring, coaching, and knowledge sharing

Overview and motivation

The knowledge that runs your systems lives in people’s heads long before it reaches a wiki. Someone knows why the payment retry logic looks strange, someone remembers the migration that must never run twice, someone can smell a bad database index from across the room. When that person leaves, or takes a vacation, or simply gets too busy to answer, the knowledge leaves with them. Mentoring, coaching, and knowledge sharing are the deliberate work of moving that knowledge out of individual heads and into the shared bloodstream of the team, so the organisation gets smarter over time instead of forgetting what it learned.

This chapter is about the practices that grow people and spread expertise: how a senior engineer develops a junior one, how communities form around a craft, how teaching gets built into the daily work rather than bolted on afterward. It sits close to several neighbours. Chapter 1.3 defines the career ladder that these practices help people climb, chapter 1.8 covers the hiring and onboarding that hands you a new colleague to develop, chapter 1.10 measures the effectiveness that healthy knowledge flow protects, and chapter 1.11 covers the management craft that funds and rewards this work. On the technical side, the code review of chapter 2.5 and the documentation of chapter 2.7 are two of the most powerful teaching vehicles you own.

For large teams, knowledge sharing stops being a nicety and becomes structural risk management. A bus factor of one, meaning a system that only one person understands, is a latent outage waiting for a resignation letter. Enterprises feel this across hundreds of services and long-lived platforms. Government organisations feel it most sharply of all, because they run systems for decades, staffed by rotating civil servants and contractors, under an obligation that a citizen-facing service remain understandable and maintainable long after the people who built it have moved on. In these settings, teaching your colleagues is not generosity. It is the machinery of institutional memory and continuity.

Key principles

Distinguish mentoring, coaching, and sponsorship; a person needs all three, and they are not the same act.
Treat knowledge sharing as real work with real time budgeted for it, not as something people do after hours.
Attack bus-factor risk deliberately: no critical system should be understood by only one person.
Make teaching a visible, rewarded expectation in the career ladder, not an invisible tax on the generous.
Prefer practices that transfer knowledge as a side effect of doing the work, such as pairing and review.
Grow senior and staff-plus engineers as force multipliers whose leverage comes from raising others.
Design knowledge sharing to work asynchronously and in writing, so it survives distance and time zones.

Recommendations

Distinguish mentoring, coaching, and sponsorship

These three words get used interchangeably, and the confusion costs people their careers. Mentoring is sharing experience and advice: a more experienced person helps a less experienced one navigate technical and career questions by offering perspective the mentee has not yet earned. Coaching is different. A coach does not hand you answers; a coach asks questions that help you find your own, building your capability to solve the next problem without them. Mentoring says “here is what I did in that situation.” Coaching says “what options do you see, and what would happen if you tried each?”

Sponsorship is the one people neglect, and it matters most for advancement. A sponsor spends their own credibility on your behalf when you are not in the room: recommending you for the stretch project, putting your name forward for promotion, defending your work in a calibration meeting. Mentoring and coaching develop a person; sponsorship advances them. Research on career progression consistently finds that sponsorship, more than advice, is what moves people into senior roles, and that the people who most need sponsors (those from underrepresented groups, discussed in chapter 1.12) are the least likely to get one by default. Name these three acts explicitly on your team, and make sure your senior people are doing all three, not just the comfortable first two.

Build structured onboarding buddies

Chapter 1.8 gets a new engineer through the door; the first weeks decide whether they thrive. Assign every newcomer an onboarding buddy: a peer, not their manager, whose explicit job is to answer the “dumb” questions, explain the unwritten norms, and be a safe first point of contact. Make it a real, named role with time carved out, not a hopeful afterthought. The buddy shows the newcomer where the bodies are buried: which service is fragile, which channel to ask in, how deploys actually happen versus how the doc says they happen.

A good buddy system pays off twice. The newcomer reaches productivity faster and feels they belong sooner, which is the single biggest predictor of whether they stay. The buddy, often a mid-level engineer, gets a low-stakes first experience of developing someone else, which is a rung on their own growth toward senior. Rotate the role so the same few generous people are not always carrying it, and give buddies a lightweight checklist so the experience does not depend entirely on who they drew.

Grow communities of practice and guilds

A community of practice is a group of people who share a craft and meet to develop it: the frontend engineers across every team, the people who care about databases, the accessibility advocates. Some organisations call these guilds or chapters. They cut across the team boundaries of chapter 1.2, so that knowledge flows horizontally even when the org chart only connects people vertically. A guild sets shared standards, reviews hard problems together, curates the best patterns, and gives specialists a professional home beyond their immediate squad.

The failure mode is a community of practice that becomes a standing meeting no one wants to attend. Keep them alive by giving them real work and real authority: let the testing guild own the testing standard, let the frontend guild choose the component library. Rotate facilitation so the group does not depend on one champion. Keep a written charter and a searchable record of decisions, so the guild produces durable artifacts and not just conversation that evaporates when the meeting ends.

Run internal tech talks, brown bags, and lightning talks

A regular internal talk series is one of the cheapest, highest-return knowledge investments you can make. A brown bag session is an informal talk over lunch where someone explains what they learned. A lightning talk is a strictly time-boxed five-minute presentation, which lowers the bar so far that first-time speakers will volunteer. These formats spread specific knowledge (how the new caching layer works) and something subtler: they normalise teaching, they surface hidden experts, and they give people a low-risk stage to build the presentation skills their promotion depends on.

Make the series sustainable rather than heroic. Record talks so distributed and future colleagues can watch them, keep an indexed library of recordings and slides, and rotate the organising duty so it does not die when one enthusiast burns out. Invite external speakers occasionally to import fresh ideas. Celebrate first-time speakers loudly, because the cultural signal that “everyone here teaches” is worth more than any single talk’s content.

Treat documentation as teaching and defend knowledge continuity

Documentation is not a filing task; it is teaching that scales past the moment and past the author. The runbook, the architecture overview, the “why we built it this way” note are how you teach someone you will never meet, including the version of your own team that exists three years from now. Chapter 2.7 covers how to write documentation well; the point here is motivational. Every piece of durable writing lowers your bus factor, because knowledge captured in a good document is knowledge that no single departure can take away.

Attack bus-factor risk on purpose. Identify the systems that only one person understands, and treat each as a risk to retire: have that person write the overview, pair someone else through the code, and rotate who handles the next change to it. Some teams run a deliberate “vacation test,” where a system’s expert goes genuinely unavailable and the team must operate without them, surfacing exactly which knowledge is dangerously concentrated. The goal is that no critical system depends on the memory of one human being who might resign, get sick, or simply forget.

Use pairing and mobbing as knowledge transfer

Pair programming, where two engineers work on one problem at one keyboard, is among the fastest ways to move knowledge between two people, because the transfer happens in real time and in context. Mob programming (also called ensemble programming) extends this to a whole small group working together on one thing. Neither is only about the code produced. Their quiet payoff is that expertise, conventions, and judgement spread from person to person as a natural byproduct of doing the work, without anyone scheduling a separate training session.

Use these deliberately for their teaching value, not as a mandate for all work at all times. Pair a newcomer with a veteran on their first real change. Mob on the gnarly, high-bus-factor subsystem specifically so more than one person leaves understanding it. Pair across team boundaries to seed a new practice. Pairing and mobbing also improve the code review of chapter 2.5, because much of the review has effectively already happened live, and they raise the psychological safety of chapter 1.1 by making it normal to think out loud and be wrong in front of a colleague.

Grow staff-plus engineers as force multipliers

Beyond senior engineer, the ladder of chapter 1.3 continues into staff, principal, and distinguished roles, collectively the staff-plus tier. The defining trait of a great staff-plus engineer is leverage: their impact comes less from the code they personally write and more from how much they raise the effectiveness of everyone around them. They set technical direction, unblock other teams, mentor the next generation of seniors, and turn one good idea into a practice the whole organisation adopts. A force multiplier is someone whose presence makes the team’s total output larger than the sum of its individuals.

Grow these people on purpose, because they do not appear by accident. Give your strongest engineers scope that requires influence rather than heroics: owning a cross-team initiative, shepherding a guild, mentoring several seniors at once. Reward the multiplier behaviour explicitly in performance reviews, or you will accidentally teach your best people that only individual output counts, and they will hoard problems instead of developing others. A staff engineer measured only on personal commits is a force multiplier you have deliberately disarmed.

Make it explicit in ladders, time budgets, and metrics

Knowledge sharing that lives only on goodwill gets crushed by the next deadline. Make it structural. Write mentoring, teaching, and knowledge sharing into the career ladder as explicit expectations that grow with level, so that reaching senior genuinely requires developing others, and so the people who do this work can point to it at promotion time. Budget real time for it: a standing share of the week for guilds, talks, documentation, and mentoring, protected the way you protect on-call. If teaching is only ever done in stolen hours, only the people with spare hours will do it, and that is neither fair nor sustainable.

Measure the health of the flow, carefully. Track leading indicators such as bus factor per critical system, documentation coverage and freshness, onboarding time to first meaningful contribution, and participation breadth in talks and guilds. Chapter 1.10 warns against reducing people to a single gameable number, and that warning applies here in full: these signals are a conversation starter about where knowledge is dangerously concentrated, not a leaderboard. The question they should provoke is “which system would hurt us most if its one expert left,” and then what you will do about it.

Design for remote and distributed knowledge sharing

When your team spans time zones, as chapter 1.9 assumes it increasingly does, the hallway conversation where knowledge used to pass simply disappears. You have to replace it deliberately. Default to writing and to asynchronous formats, because a recorded talk, a searchable decision record, and a well-tended wiki reach a colleague who is asleep when you are awake, while a synchronous whiteboard session excludes them. Written knowledge is inclusive knowledge; it does not privilege whoever happens to share your working hours or your office.

Invest in discoverability, because knowledge no one can find is knowledge you do not have. A powerful search over your docs, recordings, and decisions is worth more than another meeting. Record and index every talk. Pair remotely over screen share and treat it as normal. Create explicit virtual spaces for communities of practice so specialists find each other across locations. The organisations that do distributed knowledge sharing well are the ones that stopped treating the office as the real source of knowledge and made the written record the source of truth.

Trade-offs: pros and cons

Investing in mentoring and knowledge sharing costs time that could go to features, and that tension is real. The table lays out the main choices honestly.

Practice	Pros	Cons
Pair and mob programming	Fast, contextual knowledge transfer; fewer defects	Two or more people on one task; feels slower short-term
Communities of practice / guilds	Horizontal knowledge flow; shared standards	Can decay into meetings; needs real authority to stay alive
Internal talks and brown bags	Cheap, surfaces experts, builds speakers	Organising burns out champions; attendance can sag
Documentation as teaching	Scales past the author; lowers bus factor	Goes stale without ownership; writing takes real time
Structured onboarding buddies	Faster ramp, stronger belonging, buddy grows too	Buddy’s own work slows; quality varies by person
Explicit ladder and time budget	Makes teaching fair and rewarded	Adds process; can become box-ticking if measured crudely

The central trade-off is short-term throughput against long-term resilience and capability. Pairing two engineers on one task looks like halved output today, and it buys you a second person who understands the system, fewer defects, and faster future work. Budgeting a day a week for knowledge sharing looks like lost velocity, and it buys you an organisation that does not forget, does not stall when someone leaves, and grows its people instead of burning through them. Resolve the tension by being deliberate: spend the investment where bus factor is highest and where a person is ready to grow, rather than mandating every practice everywhere. The cost is always visible and immediate; the return is real but deferred, which is exactly why it needs explicit protection.

Questions to discuss with your team

Which of our critical systems would hurt us most if its one expert resigned tomorrow, and what are we doing about it? Most teams have never mapped this honestly, which means the answer is discovered during an actual resignation, at the worst possible time. Bring your list of important services and, for each, name every person who could confidently make a nontrivial change to it. Where that list has one name, or zero, you have found a concrete, addressable risk rather than a vague worry. The action that follows is specific: have that expert write the overview, pair a second person through the next change, and rotate ownership so understanding spreads. A team that can name its single-expert systems and show a plan to de-risk each one has turned bus factor from an anxiety into a managed portfolio.
Are mentoring, teaching, and knowledge sharing actually rewarded here, or only praised? There is a wide gap between an organisation that says it values developing others and one that promotes people for it, and your best engineers can read that gap precisely. Bring your last cycle of promotions and performance reviews and ask what fraction of the recognition went to multiplier behaviour versus individual output. If the honest answer is that the person who quietly mentored three juniors and wrote the docs everyone relies on advanced more slowly than the person who shipped a flashy feature alone, you are training your people to stop teaching. The evidence you want is teaching written into the ladder as a real expectation, time budgeted to do it, and at least one recent promotion where developing others was the headline reason.
How does knowledge actually move on this team, and does it reach the people who are remote, new, or quiet? Every team has real knowledge-transfer paths, and often they are invisible and exclusionary: the decisions made in a hallway, the context that lives in one senior’s direct messages, the norms you only learn by having lunch with the right person. Bring a recent nontrivial thing a newcomer needed to learn and trace how they actually learned it, then ask whether a remote colleague or a shy one would have learned it the same way. If your knowledge flows mostly through synchronous, in-person, informal channels, you are systematically disadvantaging exactly the people chapter 1.9 and chapter 1.12 tell you to include. The goal is a shift toward written, searchable, asynchronous knowledge that reaches everyone regardless of location, tenure, or how loudly they ask.
Who on this team gets sponsored, not just mentored, and does that pattern quietly track who already looks like our leadership? Sponsorship, spending your own credibility to advance someone when they are not in the room, is the act that actually moves people into senior roles, and it is the one most often given by default to people who resemble the existing seniors. For a large team, this compounds into a leadership pipeline that narrows year over year while everyone insists the process is fair. Bring the last two cycles of stretch-project assignments, promotion nominations, and calibration defences, and name who advocated for whom; the pattern is usually visible once you look. The competing consideration is that sponsors pick people they have seen do great work, which feels meritocratic while structurally favouring whoever got the visible work first. In enterprise and government settings, where promotion decisions must withstand equity review and, for public bodies, public accountability, an undocumented sponsorship pattern that always flows to the same profile is both a fairness failure and an audit exposure. The outcome you want is deliberate sponsorship of capable people your seniors would not have picked by instinct, tracked well enough to show the flow is widening.
When the next hard deadline arrives, what is the first thing we cut, and is it the knowledge-sharing time we swore was protected? Teaching, documentation, guilds, and pairing all cost time that is visible today against a return that arrives later, which makes them the reflexive first casualty of any crunch. For a large organisation, if every team quietly defunds knowledge sharing under pressure, the aggregate effect is an institution that stops learning precisely when it is under the most strain. Bring the last two delivery crunches and trace honestly what happened to the mentoring hours, the talk series, and the documentation during them. The competing consideration is real: sometimes a deadline genuinely must win, and pretending otherwise burns credibility. What you are testing is whether the time is protected like on-call (defended by default, sacrificed only by explicit, accountable decision) or protected only in the slide deck. In enterprise and government contexts where systems run for years, cutting knowledge continuity to hit a quarterly date trades a durable liability for a short-term win, and someone should have to sign their name to that trade rather than let it happen by drift.
Do our communities of practice actually own anything, or are they meetings we hold to feel like we invest in craft? A guild with real authority (owning the testing standard, choosing the component library, curating approved patterns) spreads knowledge horizontally across teams the org chart never connects; a guild with none decays into a calendar event people decline. For a large team, this is the main mechanism by which a solution found once reaches everyone instead of being reinvented badly a dozen times, so its health is a direct efficiency question. Bring each community’s charter, its last three decisions, and its attendance trend, and ask what would actually break if it stopped meeting tomorrow; if the honest answer is nothing, you have a zombie. The competing consideration is that real authority means real accountability and slower, more contested decisions, which some leaders resist ceding to a cross-cutting group. In enterprise and government settings with many teams, vendors, and long-lived platforms, a chartered community with a searchable decision record is also how you keep standards consistent and auditable across organizational and contractual boundaries, which ad hoc coordination cannot do.

Sector lens

Startup. With a handful of engineers and little runway, the risk is not process, it is a bus factor of one on the system that keeps the lights on. Skip guilds and formal ladders; instead make the founding engineers pair whenever they touch a critical subsystem, and run a five-minute lightning talk at lunch so teaching becomes a cheap habit rather than a programme. Your one durable investment is a short runbook and architecture note for anything only one person understands, written before that person takes leave, not after.

Small business. With no dedicated learning-and-development function and a tight budget, treat knowledge sharing as lightweight structure you buy or borrow rather than build. Lean on a simple onboarding-buddy checklist, a shared wiki, and recorded walkthroughs rather than a staffed mentoring programme, and prefer tools you already own over a new platform. The build-versus-buy call here is usually to buy a searchable documentation tool and spend your scarce time keeping it current, because a stale wiki is worse than none.

Enterprise. Across many teams and long-lived platforms, the problem is horizontal knowledge flow and governance: communities of practice with real authority over standards, mentoring and multiplier impact written into the career ladder, protected time budgeted like on-call, and bus factor tracked per critical system as a managed risk portfolio. Standardise onboarding buddies, an indexed talk library, and documentation-as-deliverable so a solution found by one team reaches all of them, and audit knowledge health the way you audit other operational risks.

Government. Systems run for decades under rotating civil servants and contractors, so knowledge continuity is a legal and accountability obligation, not a nicety. Procurement should treat documentation, decision records, and runbooks as contracted deliverables of equal weight to code, and transitions should pair departing staff with incoming ones so understanding transfers before access is revoked. Communities of practice keep standards consistent across departments and vendors, and the searchable, written record is what lets a citizen-facing service stay understandable and maintainable long after its original builders have gone.

Examples

Startup. A twelve-person startup notices that only one engineer understands the billing system, and she is about to take a month of parental leave. They treat it as a fire drill: she spends two days writing an architecture overview and a runbook, then pairs a colleague through the next three billing changes. They start a weekly lightning-talk lunch where anyone can spend five minutes on something they learned, which quickly surfaces that a quiet junior deeply understands their observability stack. Within a quarter, no critical system has a bus factor of one, and the habit of teaching each other has become part of how the team works rather than a policy anyone had to enforce.

Enterprise. A global bank with thousands of engineers runs formal communities of practice for each major discipline: backend, frontend, data, security. Each guild owns its standards, curates approved patterns, and maintains a searchable knowledge base, so a solution found by one team spreads to all of them instead of being reinvented badly. Staff and principal engineers are evaluated explicitly on their multiplier impact, mentoring is a named expectation at senior levels of the career ladder, and every engineer has protected time for knowledge sharing. Internal tech talks are recorded and indexed so an engineer in any time zone can learn from an expert in another. The result is that expertise moves horizontally across a huge organisation, and no single team’s departure can strand a critical capability.

Government. A national tax agency maintains systems that must run for decades, staffed by civil servants and contractors who rotate through over the years. Knowledge continuity is a legal and operational necessity, so the agency mandates thorough documentation, decision records, and runbooks as deliverables of equal weight to code, and it pairs incoming staff with departing ones during transitions so understanding transfers before the person leaves. Communities of practice keep standards consistent across departments and vendors, and structured mentoring helps career civil servants grow into the senior technical roles that hold institutional memory. When a contract ends or an official retires, the systems remain understandable and maintainable, because the agency treated teaching the next steward as part of building the system in the first place.

Business case: motivations, ROI, and TCO

The return on knowledge sharing shows up as reduced risk, faster ramp-up, and retention of both people and expertise. The clearest line is bus-factor risk: a single-expert system is an unpriced liability, and the cost of that person leaving (an outage no one can fix, a rewrite of code no one understands, months of rediscovery) dwarfs the modest cost of spreading the knowledge in advance. Faster onboarding is directly measurable too. Every week you shave off time-to-productivity for a new hire is a week of salary that produces value instead of confusion, multiplied across every person you hire.

Retention is where the numbers get large. Replacing an engineer costs a substantial fraction of their annual salary in recruiting, onboarding, and lost productivity, and people leave organisations where they stop growing. Mentoring, coaching, and sponsorship are among the strongest retention levers you have, because they make people feel invested in and give them a visible path forward. The cost to adopt is mostly protected time plus light structure: budgeted hours, a talk series, guild charters, a buddy checklist. The cost of neglect compounds quietly as knowledge concentrates, documentation rots, and your best potential mentors leave for organisations that will grow them. To make the case to leadership, connect knowledge sharing to the metrics they already watch: onboarding time, retention, incident recovery when an expert is unavailable, and the effectiveness measures of chapter 1.10.

Anti-patterns and pitfalls

Hero culture: rewarding the lone expert who saves the day, which quietly incentivises hoarding knowledge instead of spreading it.
Mentoring as unpaid overtime: expecting teaching to happen in stolen hours, so only those with spare time do it and the generous burn out.
Sponsorship gap: offering advice freely but spending real credibility only on people who look like the existing leadership.
Zombie guilds: communities of practice that became a standing meeting with no authority, no artifacts, and dwindling attendance.
Documentation theatre: writing docs once for a checkbox, then letting them rot until they mislead more than they help.
Bus factor of one, ignored: knowing a system has a single expert and doing nothing until that person actually leaves.
Measuring teaching by a gameable number: turning mentoring into a metrics contest that produces activity without real knowledge transfer.
Office-centric knowledge: letting the important context live in hallways and direct messages, excluding remote, new, and quiet colleagues.
Multiplier work unrewarded: promoting only on individual output, teaching your strongest people that developing others is a career mistake.

Maturity model

Level 1, Initiate: Knowledge sharing is accidental and personal. Critical systems often have a bus factor of one, onboarding is sink-or-swim, mentoring depends entirely on individual goodwill, and expertise leaves the building whenever a person does.
Level 2, Develop: Some practices exist but are inconsistent across teams. One squad runs an onboarding buddy, another an occasional tech talk, documentation quality varies widely, and mentoring reaches those who seek it out, but nothing is budgeted, expected, or measured, and it all survives on the effort of a few champions.
Level 3, Standardise: Knowledge sharing is documented and enforced org-wide. Mentoring and teaching are explicit ladder expectations with protected time, communities of practice own standards, onboarding buddies and a talk series are the norm everywhere rather than in pockets, documentation is a maintained deliverable, and every team follows the same expectations rather than inventing its own.
Level 4, Manage: Knowledge health is measured and controlled with data against baselines. Bus factor per critical system, documentation coverage and freshness, onboarding time to first meaningful contribution, and participation breadth in talks and guilds are tracked over time; single-expert systems are treated as a managed risk portfolio with de-risking plans and due dates; sponsorship and multiplier impact are reviewed for equity rather than assumed; and knowledge-sharing time is defended against deadlines by explicit, accountable decision rather than quietly cut. Metrics start conversations about where knowledge is dangerously concentrated, not leaderboards.
Level 5, Orchestrate: Teaching is continuously improved and integrated across the whole organisation, and adapts as conditions change. Pairing, mobbing, sponsorship, and multiplier growth are normal and rewarded; knowledge flows freely across teams, vendors, and time zones in writing; the measures from level 4 feed a regular improvement loop that reshapes practices, rebalances where teaching effort goes, and retires what no longer works; and no critical system depends on a single person’s memory.

Ideas for discussion

What is one system on your team with a bus factor of one, and what is the smallest concrete step to make it two this month?
Does your career ladder actually require developing others to reach senior, or does it merely mention it in passing?
Who on your team is doing invisible multiplier work that your last review cycle failed to recognise or reward?
When did a remote or newly joined colleague last miss knowledge that in-office tenured people absorbed by osmosis?
Do your senior engineers sponsor people (spend real credibility on them), or do they stop at giving advice?
If your best mentor left tomorrow, would the practice of teaching survive, or does it live entirely in that one person?

Key takeaways

Mentoring, coaching, and sponsorship are three distinct acts; a person needs all three, and sponsorship is the one most often withheld from those who need it most.
Attack bus-factor risk on purpose: name your single-expert systems and de-risk each through documentation, pairing, and rotation.
Prefer practices that transfer knowledge as a byproduct of the work, such as pairing, mobbing, code review, and documentation-as-teaching.
Make teaching structural: write it into the career ladder, budget real time for it, reward multiplier behaviour, and measure knowledge health without gaming it.
Design knowledge sharing to be written, asynchronous, and discoverable, so it survives distance, time zones, and the departure of any one person.

References and further reading

Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity
Will Larson, Staff Engineer: Leadership Beyond the Management Track
Tanya Reilly, The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change
Camille Fournier, The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change
Sylvia Ann Hewlett, Forget a Mentor, Find a Sponsor: The New Way to Fast-Track Your Career
Andrew Hunt and David Thomas, The Pragmatic Programmer: Your Journey to Mastery
Kenneth S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process
Woody Zuill and Kevin Meadows, Mob Programming: A Whole Team Approach