Week 5 case bank
Eight candidate cases for the case clinic. Pick two before the session: one leaning IC track, one leaning management track. Cases 1 and 2 match the seeds in the course blueprint; the week 5 guide, deck, and board currently name those two. If you pick different cases, update the case titles on the slides and the board frames.
Every case puts the room in the seat of an early-stage leader: a first-year tech lead, or a senior engineer leading without a title. Nobody in these cases can simply give an order. That is on purpose: it matches where the cohort is, and it is what makes both camps defensible.
These drafts are written to sound real, but they are fiction shaped around common situations. Before the session, edit your two picks toward real events you have seen, and change any detail that feels close to a real person. Read time out loud: about 4 to 5 minutes each.
Each case has a matching kit in `case-kits/` with a ready slide block, board frame labels, and facilitator notes, so swapping a case into the session is mechanical.
Every case ends at the decision point on purpose. There is no answer key. Both camps must be defensible, or the case is broken.
Case 1: the migration two teams refuse to adopt
Leans: IC track · Laws in tension: Influence, Buy-In, Timing · Camps: the escalation path (ask the managers to order it) vs the coalition path (win the engineers without escalating) · Kit: slides, board labels, facilitator notes
Salma is a senior engineer with six years of experience, on a four-person platform team at a quick-commerce company. She has no title over anyone. Last year she built a shared payments client to replace the three slightly different copies that live inside the feature squads. The copies are the source of a long line of painful bugs: every time the payment provider changes something, three teams patch three codebases, and one of them always misses.
The engineering guild approved her plan six months ago. Everyone agreed in the meeting. Her own team migrated first, and their payment bugs went to zero. Two feature squads remain, and the migration is stuck.
Squad A's lead, Tarek, refuses openly. He says the same sentence in every planning: "We ship a business deadline every four weeks. Your library is not our problem." Squad B's lead is friendlier. He says yes every time and schedules nothing. Twice, the migration tickets moved to "next sprint" on the last day of the sprint.
Salma has done the reasonable things. She gave a demo. She wrote a step-by-step migration guide. She migrated the first service for Squad B herself, hoping momentum would carry it, and nobody followed. She has reminded both leads, politely, five times.
Now there is a clock. The old copies depend on a payment SDK whose security updates end in eight weeks. After that date, every unmigrated service is a compliance problem with her company's name on it.
Her manager offered help last week: "Say the word and I will raise it with their managers. They will be ordered to do it." Salma is not sure she wants that. An order would get compliance, but she has to work with these squads for years, and she knows how ordered work gets done. The other path is slower: win Tarek's most trusted senior first, then the quiet lead, person by person, and she does not know if eight weeks is enough.
Put yourself in Salma's seat. It is Sunday morning. What is your move?
Case 2: the lead who will not delegate during the crunch
Leans: management track · Laws in tension: Empowerment, Priorities, Sacrifice · Camps: protect the deadline (hold on, fix delegation after go-live) vs force the handover now (confront the lead and make the work move) · Kit: slides, board labels, facilitator notes
Four months ago, Youssef was the strongest engineer on the team, so he was made the team lead. Nobody trained him. The team of seven now owns the biggest release of the year: a bank integration with a fixed go-live date agreed with the bank. The date is five weeks away and it does not move.
Heba is the most senior engineer left on the team, and until four months ago she and Youssef were peers. She is watching him lead the way he used to code: alone. He reviews every pull request himself. He took the two hardest components and is building them personally. He answers Slack at 1 AM. He looks dedicated, and in some ways he is.
The costs are piling up where he does not look. Heba is doing tickets a mid-level could do. Nour, the other senior, told Heba privately that she has started interviewing: "There is no real work for me here." Last sprint, three tickets sat blocked for two days each, waiting for Youssef's review while he was heads-down on his own component. The team is slowing down five weeks before a date that cannot slip.
Heba has tried the gentle version. A month ago she told Youssef directly, as a friend, that he needs to hand things over. He agreed with everything. The next week he gave Khaled a component, then took it back after Khaled made one design decision Youssef would not have made. Nothing was said. Everyone noticed.
Yesterday the director stopped Heba in the corridor and asked, casually, "How is the team doing with the deadline?" She said "we are pushing" and walked away, and has regretted it since.
Forcing the issue now means a hard conversation with Youssef, maybe an honest answer to the director, and short-term chaos in the most dangerous five weeks of the year. Protecting the deadline means five more weeks of the pattern getting stronger, and hoping Nour is still here after go-live.
You are Heba. Youssef asked you to grab coffee tomorrow. What do you do?
Case 3: the name you give your manager
Leans: management track · Laws in tension: The Lid, Legacy, Connection · Camps: name the strongest engineer (keep him, pay the leadership risk) vs name the multiplier (better lid, risk losing your best coder) · Kit: slides, board labels, facilitator notes
Hadi has been a team lead for eight months. His team is splitting in two next quarter, and yesterday his manager gave him the question he has been dreading: "You know them best. Who should lead the new half? Give me your recommendation Monday."
There are two real candidates, and Hadi has worked next to both for three years.
Omar is the strongest coder on the team, maybe in the department. He built the settlement flow and he is the only one who fully understands it. He wants the role badly, and he has said, half joking, that recruiters message him every month. But there is a pattern around Omar: juniors stopped asking him questions. One of them said in a retro, carefully, "he makes you feel slow." Hadi has coached him on it for two quarters. It gets better for a few weeks, then fades.
Hana is mid-senior, technically weaker than Omar, and the quiet center of the team. She onboards every new hire without being asked. Design reviews go better when she runs them. When people are stuck, they walk to her desk, not Omar's. In the last engagement survey, three people named her as a reason they stayed.
Hadi knows what the course data says. Manager quality caps a team, and promoting the best individual performer is exactly the trap the Peter Principle study measured. He also knows the data does not have to sit in a room with Omar afterward. Whoever he does not name will guess, correctly, whose recommendation it was. Name Omar and he may put a lid on the new team and watch Hana's ceiling go unused. Name Hana and he may lose Omar, the settlement flow knowledge, and a friend.
You are Hadi. It is Sunday night and the recommendation is due in the morning. Whose name do you give, and what do you say to the other one?
Case 4: the component only you understand
Leans: IC track · Laws in tension: Legacy, Empowerment, Priorities · Camps: take the new role and start the handover now (accept peak-season risk) vs stay on the engine through peak season (risk the role going to someone else) · Kit: slides, board labels, facilitator notes
Amr is a senior engineer at a delivery company, five years in. He built the pricing rules engine and has owned it ever since. It reprices the catalog in real time, it drives a big share of the company's margin, and its bus factor is exactly 1: Amr. Everyone has known this is a risk for years. Twice, a junior was assigned to learn the system, and both times the junior was pulled back to feature work within a month, because features have deadlines and risk does not, until it does.
Last week, Amr got the offer he has wanted for two years: tech lead of the new ML pricing project, starting next month. It is his first lead role, the technical direction is his dream problem, and it is the visible step his career has been waiting for. There is one complication, and it is a big one.
Ramadan season starts in ten weeks. It is the highest-load, highest-margin period of the year, and the period when the pricing engine breaks in the ways only Amr has ever debugged. A real handover needs about three months of someone else running the system while Amr watches over their shoulder, which puts the riskiest part of the learning curve exactly inside the season. The two mid-level engineers who could take it are willing, but they are starting from almost zero, again.
And the offer will not wait. His manager was honest: "If you cannot start next month, I have to give the lead seat to the external candidate we are interviewing. I cannot hold the project."
Take the role and start the handover now, and Amr walks into his first leadership job while his old system faces its hardest season with beginners at the wheel, and his name still on every incident. Stay through the peak, and the role he has earned goes to someone else, with a polite promise about next time that he has heard before.
You are Amr. Your manager wants an answer this week. What is it?
Case 5: the pipeline nobody will fund
Leans: IC track · Laws in tension: Buy-In, Timing, Priorities · Camps: bring it to the skip-level now (go over the roadmap, risk your manager) vs build the evidence for a quarter (pre-wire the leads, accept more pain) · Kit: slides, board labels, facilitator notes
Mariam is a senior engineer at a fintech. Her team's problem is not glamorous: the CI and deployment pipeline is slowly failing. Test runs are flaky, releases take three days of babysitting, and one deploy in four gets rolled back. She did the math: her honest estimate is three sprints of focused team work to fix the core of it. She also did the other math: the team loses more than that every quarter to the babysitting.
The roadmap has no room. It is locked for two quarters with features that were promised to the sales team. Mariam wrote a clear one-page proposal with the numbers. In quarterly planning it was praised and moved to "next quarter." That was the second quarter in a row it got that exact sentence.
Her manager agrees with her privately and will not fight for it publicly. "I raised it. The answer was the roadmap. My hands are tied." Last month a bad deploy caused a six-hour checkout outage that reached the CEO. For three days, everyone cared about the pipeline. Then the attention faded and the roadmap won again.
Now Mariam has an opening. As part of a normal rotation, she has a skip-level meeting with the head of engineering in two weeks. She could bring the pipeline. Said directly, with the outage still in recent memory and her numbers on one page, it might actually move. It would also go around her manager in a way everyone would notice, and if it fails she has spent her one shot and earned a reputation as someone who escalates past her boss.
The alternative is slower: spend the quarter turning pain into money (engineer days lost per release, the outage's real cost, the rollback rate trend), win the two squad leads one conversation at a time, and walk into the next planning with allies instead of a document. The cost of slow is another quarter of three-day releases, and maybe another outage with her team's name on it.
You are Mariam. The skip-level is in two weeks. Do you bring the pipeline?
Case 6: the team that still asks the old lead
Leans: both tracks equally · Laws in tension: Influence, Connection, Buy-In · Camps: take the structural fix (make the decision rights official) vs decline it and win the person first (connection before structure) · Kit: slides, board labels, facilitator notes
Three months ago, Laila got her first lead role: tech lead of a squad she did not come from. She earned it on a neighboring team, interviewed well, and moved across. Seif, the squad's most senior engineer, had led the team informally for two years before she arrived. He was on her interview panel. He voted yes.
On paper, the squad has one lead. In practice it still has the old one. Engineers bring decisions to Seif, because for two years that is what worked. Laila sets priorities in planning; more than once, Seif has quietly reordered them in code review, not from malice, from habit and conviction. Last week a junior asked her, honestly confused: "So for the API design, do we go with what you said or what Seif said?" Standups have developed a careful politeness that everyone can feel.
Laila has tried the human route once. A month ago she took Seif for coffee and named the problem gently. He was polite, agreed things should be clearer, and nothing changed. Then he skipped their last 1:1 with a real but convenient excuse.
Yesterday her manager asked how things were going, and she answered honestly. The manager offered a clean fix: "Say the word and I will make it official in writing: architecture calls go through you. Done by Friday."
She wants to say yes. She is also afraid of what yes does. A written rule ends the ambiguity this week, and might end any chance of Seif genuinely following her, because a rule can force compliance but it cannot create followership. Declining the fix means more weeks of leading a team that is watching two captains, while she tries to win a person who may not want to be won.
You are Laila. Your manager is waiting for the word. Do you take the structural fix?
Case 7: the go-to engineer wants the hard feature again
Leans: management track · Laws in tension: Explosive Growth, Empowerment, Priorities · Camps: optimize the delivery (the proven person leads) vs multiply the team (the mid-levels lead, the star consults) · Kit: slides, board labels, facilitator notes
Omar leads a team of five, one year into his first lead role. The company just landed its biggest client, and the client demo is in eight weeks: a rebuild of the search experience, the most visible work the team has ever had. Omar has to decide today who runs it.
Dina is the obvious answer. She has delivered the last three critical features, each on time, each excellent. She is also the reason half the on-call runbook has one name in it, and she is already at full capacity. When the project was announced, she messaged Omar within the hour: "This one is mine, right?" For Dina, these projects are the job. Taking this one away will read, to her, as a public demotion.
Ali and Farah are the other answer. Both mid-level, both hungry, neither proven at this size. Omar's honest estimate: with them leading and him coaching, the project takes 30 percent longer and the polish is less certain. Ali asked him something last month that has not left his head: "How do I ever become the person who gets the hard projects, if the hard projects always go to the person who already had them?"
Omar knows the multiplication math from his own career. Every time the critical work goes to Dina, the team adds her output and loses a growth cycle for two people, and the gap between her and everyone else widens, which makes the next decision even more automatic. He also knows the demo does not care about multiplication math. Eight weeks, the biggest client in company history, one shot.
There is a middle option, and it might be the worst one: Dina leads, Ali and Farah "assist," and everyone gets the costume of growth without the authority that makes it real.
You are Omar. The kickoff is tomorrow morning. Who runs the project, and what exactly do you tell Dina?
Case 8: the architecture fight that stopped the team
Leans: IC track · Laws in tension: Connection, Buy-In, plus disagree and commit as the tool · Camps: call the decision now (enforce disagree and commit) vs negotiate interests first (one more week of digging) · Kit: slides, board labels, facilitator notes
Hadi is three months into his first tech lead role, and the two most senior engineers on his team, both older and more experienced than him, have been at war for three weeks.
The fight is about the foundation of a new service: microservices from day one, or a modular monolith that splits later. Rana wrote the microservices RFC. Adham wrote the monolith counter-RFC. Between them: 140 comments, four meetings, and two documents that keep growing appendixes aimed at each other. Both are right about different things and both know it. Last week the argument moved to the public team channel and the tone slipped; Adham called one of Rana's points "junior thinking" and apologized a day later, but the team read every word. Four engineers are now waiting to write code that depends on the decision. One of them asked Hadi privately: "Can you just decide? Any answer is better than this."
Hadi has the authority to call it, at least formally. That is the clean option: pick one, invoke disagree and commit, and start building. The risk is not technical. Whoever loses will feel run over after three weeks of public investment, both of them were interviewed for the lead role Hadi got, and he needs one of these two people to lead the build. Commitment ordered is not commitment.
The other option is the slower tool from week 2: sit with each of them alone and negotiate interests, not positions. What does each of them actually need? There are hints the fight is not about services at all. Rana is up for promotion and needs a visible architecture win. Adham carried the pager for two years on the last distributed system that was split too early, and he is not doing that again. Neither of those needs appears in either RFC. Digging there might dissolve the fight. It also costs at least another week, while four engineers wait and the deadline does not.
You are Hadi. The team is watching how this gets resolved, because it will teach them how every future fight on this team gets resolved. What do you do this week?