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 expand 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.
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.
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 (take it up the chain) vs the coalition path (win the leads without escalating)
Salma is a staff engineer at a quick-commerce company in Cairo. A year ago she designed a new orders platform. The numbers are not in question: in the two services already migrated, infrastructure cost dropped about 40 percent and on-call pages dropped by half. The RFC was approved six months ago. The CTO called it "our most important platform work this year."
Two squads still have to migrate, and the migration is stuck at 30 percent. Squad A's lead, Tarek, resists openly. In planning he says the same sentence every month: "We ship a business deadline every four weeks. Your platform is not our problem." Squad B's lead is friendlier. He says yes in every meeting and then never schedules the work. Two sprints in a row, the migration tickets were moved to "next sprint" on the last day.
Salma has tried the reasonable things. She gave two demos. She migrated the first service herself to prove the path, and nobody followed. She wrote a step-by-step guide. She reminded both leads in planning, politely, five times. Meanwhile her platform team is paying the real cost: they maintain two systems in parallel, and the old one still pages them at night.
Last week two things happened. The CTO asked her manager, in a leadership meeting, why infrastructure cost is not dropping yet. And the contract for the old system's vendor comes up for renewal in eight weeks. If the migration is not done by then, the company signs for another year, and the business case she promised falls apart in public.
Her manager's advice was short: "Escalate it. You have the mandate. Make the CTO order it." Salma is not sure. An order would get compliance, but she has to work with these two leads for years, and forced work is done badly. The coalition path means winning Tarek and the quiet lead person by person, and she is not sure eight weeks is enough for that.
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 (fix delegation after) vs force the handover now
Youssef was the strongest engineer on his team, so four months ago the company made him the engineering manager. Nobody trained him. His team of seven now owns the biggest release of the year: a bank integration with a fixed go-live date agreed with the bank's compliance team. The date is five weeks away and it does not move.
Youssef is working the way that made him successful as an engineer, but at manager scale. 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 team tells a different story. Two senior engineers, Nour and Khaled, are doing small tickets a mid-level could do. Nour told the director directly: "There is no real work for me on this team. I have started interviewing." Velocity is dropping, not rising, because every decision waits in one queue: Youssef. Last sprint, three tickets sat blocked for two days waiting for his review while he was heads-down on his own component.
The director has tried once already. A month ago they had a calm 1:1 about delegation. Youssef agreed with everything. The next week he handed a component to Khaled, then took it back after Khaled made one design decision Youssef would not have made. Nothing was said. Everyone noticed.
Now it is five weeks to a date that cannot slip, with a lead who is the single point of failure, one senior halfway out the door, and a pattern that gets stronger every week it is allowed to work. Forcing the handover now means short-term chaos in the most dangerous five weeks of the year. Protecting the deadline means telling Nour, in effect, wait until after go-live, and hoping she does.
You are the director. Youssef's 1:1 is tomorrow morning. What do you do?
Case 3: the promotion that could cap the team
Leans: management track · Laws in tension: The Lid, Legacy, Connection · Camps: promote the strongest engineer (keep him, pay the leadership risk) vs promote the multiplier (better lid, risk losing your best coder)
A team lead seat is open, and the head of engineering has two candidates.
Omar is the strongest coder in the department. He built the settlement engine and he is the only person who fully understands it. He wants the title, and he has hinted clearly that if he is passed over, he will take one of the offers recruiters send him every month. But there is a pattern around Omar: juniors avoid asking him questions. One said in a retro, carefully, "he makes you feel slow." Two quarters of coaching on mentoring produced small changes, then faded.
Hana is mid-senior, two years less experience, and technically weaker than Omar. She is also the actual center of the team. She onboards every new hire without being asked. Design reviews go better when she runs them. In the last engagement survey, three people named her, unprompted, as the reason they stayed. When the team is stuck, people walk to her desk, not Omar's.
The head of engineering knows the research both ways. Manager quality caps team output, and promoting the best individual performer is exactly the trap the Peter Principle study measured. But the study does not have to retain Omar, and the settlement engine has a bus factor of 1 with his name on it.
Promote Omar and you may put a lid on a healthy team and lose Hana's ceiling. Promote Hana and you may lose Omar, the settlement engine knowledge, and set the message that technical excellence does not get rewarded here. Announce is Sunday.
You are the head of engineering. What do you announce, and what do you do about the person you did not pick?
Case 4: the engineer who owns everything
Leans: IC track · Laws in tension: Legacy, Empowerment, Priorities · Camps: start the handover now (accept peak-season risk) vs keep him through peak season (risk losing him for good)
Amr is a principal-level engineer at a delivery company. He built the pricing engine five years ago and has owned it ever since. It reprices the whole catalog in real time, it drives a third of the company's margin, and its bus factor is exactly 1: Amr.
Everyone has known this is a risk for years. Twice, engineers were assigned to shadow him and learn the system. Both times they were pulled to feature work within a month, because features have deadlines and risk does not, until it does.
A year ago, Amr was promised a move: the company is starting an ML pricing initiative, and leading it is the technical challenge he has wanted for years. The move keeps getting delayed, always for the same reason: nobody else can hold the pricing engine. Last week Amr put it plainly to his director: "I have an external offer. I would rather stay and build the ML system here. But if the move does not start now, I am done waiting." He is not bluffing, and he is not being unfair. The promise is a year old.
The complication is the calendar. 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 ways only Amr has ever debugged. A real handover needs three months of the new owners running the system while Amr watches, which puts the riskiest part of the learning curve exactly inside the season.
Start the handover now and the company faces its most important season with beginners on its most critical system, and Amr splitting his attention. Delay again and the company probably loses Amr entirely, which means facing every future season with nobody at all.
You are the director. Amr wants an answer this week. What is it?
Case 5: the platform work nobody will fund
Leans: IC track · Laws in tension: Buy-In, Timing, Priorities · Camps: use the skip-level now (go to the top, risk your manager) vs build the evidence for a quarter (pre-wire the leads, accept more pages)
Mariam is a senior infrastructure engineer at a fintech. The core message queue that every payment flows through is failing slowly. Incident count has doubled in six months. On-call is burning people out; two engineers have already rotated off the team because of it. Her honest estimate: fixing it properly needs about a quarter of work from two squads.
The product roadmap is locked for the next two quarters with growth features the CEO announced publicly. Mariam wrote a clear proposal with the incident data. It was heard politely in quarterly planning and answered with one sentence: "Great work, we will look at it next quarter." That was the second quarter in a row it got that 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." A month ago there was a four-hour outage that reached the news. For three days, everyone cared about reliability. Then the attention faded and the roadmap won again.
Now Mariam has an opening. A skip-level with the VP of engineering is on her calendar in two weeks, part of a normal rotation. She could bring the queue. Said directly to the VP, with the outage still in recent memory, it might actually move. It would also go around her manager in a way everyone would see, and if it fails, she has spent her one shot and marked herself as someone who escalates past her boss.
The alternative is slower: spend the quarter turning incidents into money (engineer hours lost, SLA penalties, the outage's real cost), pre-wire the two squad leads one by one, and walk into the next planning with allies instead of a document. The cost of slow is another quarter of 2 AM pages, and maybe another public outage that lands on her team's name.
You are Mariam. The skip-level is in two weeks. Do you bring the queue?
Case 6: two captains, one squad
Leans: both tracks equally · Laws in tension: Influence, Connection, Buy-In · Camps: settle it structurally now (write the decision rights) vs coach the relationship first (connection before structure)
Six months ago, a growth-stage company hired Laila as engineering manager for its most important squad. Seif, a staff engineer, had led that squad informally for two years before she arrived. He interviewed her and voted to hire.
On the org chart, the squad has one leader. In practice it has two. Engineers still 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. Two engineers have separately asked the director the same question: "Who actually decides architecture here?" Standups have developed a careful, cold politeness that everyone can feel.
They tried the obvious fix. The director sat them down for an alignment meeting two months ago. It was calm and professional. Both said the right things. Nothing changed, and Seif skipped their next scheduled 1:1 with a real but convenient excuse.
Last week it escalated. Laila asked the director for a structural decision: "Write it down. Architecture decisions report to me. I cannot manage a team where my calls are optional." The same week, Seif mentioned, casually, that another squad has been asking if he would transfer. Losing him would take two years of system knowledge out the door. Overruling her would tell the whole company that the manager they hired is a manager in name only.
The director can see both truths. A written decision-rights document (a DACI for the squad) would end the ambiguity this week, and might end the relationship with it. Coaching the relationship first respects that no document makes people follow anyone, and risks more weeks of a squad watching its two leaders disagree.
You are the director. Both of them expect an answer at their 1:1s this week. What do you do?
Case 7: the go-to engineer wants the hard project again
Leans: management track (works for IC too) · 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)
The company is rebuilding search, its most visible feature, and the CEO will demo the result to investors in eight weeks. The engineering lead has to decide today who runs it.
Dina is the obvious answer. She has delivered the last three critical projects, each one on time, each one excellent. She is also the reason the on-call runbook has one name in half its entries, and she is already at full capacity. When the project was announced, she messaged the lead within an hour: "This one is mine, right?" For Dina, these projects are the job. Taking this one away will read, to her, as a demotion in public.
Ali and Farah are the other answer. Both mid-level, both ready for a stretch, neither proven at this size. Honest estimate: with them leading and real coaching, the project takes 30 percent longer and the polish is less certain. Ali asked the lead directly last month, in words that stuck: "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?"
The lead knows the multiplication math. 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. The lead also knows the demo does not care about multiplication math. Eight weeks, investors in the room, 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 the engineering lead. The kickoff is tomorrow. 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)
A new product line needs a foundation decision: microservices from day one, or a modular monolith that splits later. Two senior engineers have been fighting about it for three weeks, and the fight has stopped being technical.
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 a point "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 asked the tech lead privately: "Can you just decide? Any answer is better than this."
The tech lead, Hadi, has the authority to call it. 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, and Hadi needs one of these two people to lead the build. Commitment ordered is not commitment.
The other option is the slower tool: 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 was the person paged 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, and it 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 tell them how every future fight here gets resolved. What do you do this week?