Greenbox delivers weekly produce boxes to 3,500 subscribers across Perth and Melbourne. The team of fifteen is stretched thin. Maya needs developers. When Jordan Chen’s application lands, it looks like the answer to every problem they have.
Jordan Chen’s CV arrives on a Monday. Tom reads it twice.
Twelve years of experience. Three languages. Senior developer at a fintech company in Sydney for four years, then lead developer at a logistics startup. Open source contributions. A conference talk on event-driven architecture. Two years of remote work for a US company whose name Tom recognises.
“This person is better than me on paper,” Tom tells Maya. He means it as a compliment to Jordan, but there’s something else in the sentence, relief. The Melbourne expansion has Tom stretched across two squads, reviewing code at 10pm, answering architecture questions from developers who should be able to answer them on their own. He needs someone who can carry weight without supervision.
The technical interview is on a Wednesday afternoon. Charlotte sits in. Jordan is articulate, precise, and fast. When Tom poses the system design question, “How would you build a real-time inventory system for perishable goods?”. Jordan produces a clean architecture in twelve minutes, complete with event sourcing, CQRS, and a supply buffer calculation that accounts for seasonal variance.
Tom and Charlotte debrief afterward.
“Technically, the strongest candidate we’ve seen,” Tom says.
Charlotte nods slowly. “I noticed something. When I asked about working with a team on a shared codebase, Jordan said ‘I prefer to own my domain and deliver independently.’ Did you catch that?”
Tom caught it. He filed it under “senior developer confidence.” People at Jordan’s level often prefer autonomy. That’s not a red flag. That’s a feature.
“We need someone who can ship independently,” Tom says. “We’re drowning.”
Charlotte doesn’t push. She notes it, and they make the offer. The salary is higher than anyone else on the team except Tom. Maya approves it without hesitation. Good developers are expensive and bad hires are more expensive.
Jordan accepts within twenty-four hours. No negotiation.
Week one
Jordan starts on a Monday morning in September. Maya gives the welcome talk she’s been refining since Ravi joined, company history, the Event Storming origin story, the bounded contexts, the farm relationships. Jordan listens politely, takes no notes, and asks one question: “Where’s the repo?”
By Wednesday, Jordan has shipped a complete refactor of the delivery scheduling module. Three days. The module had been on the backlog for six weeks. Nobody else had picked it up because it touched three bounded contexts and nobody wanted to deal with the coordination.
Tom reviews the PR. The code is clean. The test coverage is thorough. The architecture is elegant. Jordan has introduced a pattern Tom hasn’t seen before, a kind of pipeline composition that reduces the scheduling logic from 400 lines to 180.
“This is really good,” Tom says in the PR comment. He means it. He approves and merges.
Priya looks at the merged PR that evening. She doesn’t comment. She reads the code three times and understands about 60% of it. The pipeline composition pattern is unfamiliar. She’s been at Greenbox since week one. She’s never felt lost in her own codebase before.
She closes her laptop and feeds Refactor. The cat head-butts her ankle. Priya tells herself it’s fine. Jordan is senior, she’ll learn the pattern. Everyone learns new things.
Week two
Jordan’s second week follows the same pattern. Heads down, headphones on, shipping fast. Jordan opens PRs that are large and self-contained, entire features, not incremental slices. The code is invariably clever, well-tested, and difficult to follow.
On Thursday, Priya reviews Jordan’s PR for the supplier notification system. She spends forty-five minutes reading it. The logic is correct, she’s fairly sure, but the abstraction layers are deep. She leaves a comment: “Could you walk me through the notification chain? I’m not sure I follow the callback delegation.”
Jordan replies within minutes: “It’s pretty straightforward if you understand the decorator pattern. Each handler wraps the next. The chain resolves at runtime based on the supplier’s notification preferences.”
The words are technically accurate. The tone is technically fine. Priya reads the reply twice and feels something tighten in her chest, not anger, exactly, but a quiet closing-off. She doesn’t ask a follow-up question. She approves the PR.
Ravi, who’s been at Greenbox for three months now and is building deep knowledge of the subscription system, messages Priya privately: “Did you understand the notification PR?”
“Not fully. You?”
“No. But I didn’t want to ask. Jordan made it sound like I should already know.”
Neither of them says anything to Tom. They don’t say anything to each other about it again, either. The silence is the beginning of the damage.
Week three
The team has a pair programming slot on Tuesdays. Charlotte introduced it as part of the collaborative culture she’s been building since the bounded context work, two people working together for a couple of hours on the week’s trickiest story. It’s voluntary but nearly everyone participates.
Jordan doesn’t.
Tom asks, casually, during a one-on-one: “You’re welcome to join the pairing sessions. Might be a good way to get familiar with the team’s conventions.”
“I’ve looked at the conventions,” Jordan says. “They’re fine. I don’t think pairing is a good use of my time. I can cover more ground solo.”
Tom doesn’t push. He tells himself this is what senior developers are like. Some people are solitary workers. The important thing is output, and Jordan’s output is exceptional.
But there’s something Tom doesn’t notice because he’s not looking for it. Kai, who joined six months ago and has been pairing regularly with Priya, stops signing up for the Tuesday slot. When Charlotte asks why, Kai shrugs. “If Jordan can ship without pairing, maybe I should too. I don’t want to look like I need help.”
One person’s refusal has given everyone else permission to withdraw.
The standups
Jordan’s standup updates follow a pattern.
“I’m fine. Nothing blocked.”
Every day. Five words. No context about what they’re working on, no mention of dependencies, no request for input. The rest of the team gives updates that include questions, concerns, mentions of what they’re stuck on. Jordan’s updates are a closed door.
Jas notices it first. She’s quiet by nature, but she’s perceptive. She’s been in every standup since Greenbox was five people, and she knows the rhythms. The standups used to have a texture. Tom asking Priya about an edge case, Ravi checking whether his subscription change would affect the farm portal, Sam mentioning a courier issue that might affect Thursday’s delivery. Conversations that crossed boundaries. Problems shared before they became crises.
Now the standups are shorter. Not because they’re more efficient. Because people have stopped volunteering information. Jordan’s presence has changed the dynamic, not through anything Jordan says, but through what Jordan doesn’t say. When one person treats the standup as a status report rather than a collaboration, the rest of the team adjusts downward. Nobody wants to be the person asking for help when someone else is “fine, nothing blocked.”
Jas mentions it to Lee over coffee on a Thursday. Lee is in Perth for a farm partner onboarding, and Jas catches him in the kitchen.
“The standups feel different,” she says. “I dread them now.”
Lee looks at her. “Different how?”
“Quieter. Like everyone’s performing instead of talking.”
Lee doesn’t say anything right away. He stirs his coffee. “Have you told Maya?”
“It’s not a complaint. It’s a feeling.”
“Feelings are data,” Lee says.
The ownership problem
By week four, a pattern has emerged that nobody has named yet. Jordan has touched four major areas of the codebase: delivery scheduling, supplier notifications, the farm reconciliation pipeline, and the subscription pause feature that Ravi built. In each area, Jordan has refactored, improved, and shipped.
In each area, nobody else on the team is willing to make changes any more.
It’s not that Jordan has told anyone to stay away. It’s that the code is now written in Jordan’s idiom, abstractions and patterns that Jordan understands fluently and everyone else understands partially. Making a change means understanding Jordan’s architecture first, and understanding Jordan’s architecture means asking Jordan, and asking Jordan means hearing “it’s pretty straightforward if you understand the pattern.”
So people route around it. Priya picks up stories that don’t touch Jordan’s code. Ravi, who built the subscription pause feature from scratch, stops making changes to it after Jordan’s refactor. When a bug appears in the pause logic, Ravi spends twenty minutes trying to understand the new structure, gives up, and assigns the bug to Jordan.
Jordan fixes it in ten minutes and doesn’t mention it at standup. Ravi sees the fix in the commit history. The approach is different from what he would have done, not wrong, but not what he recognises. It’s his feature, the one he built from scratch during his first month at Greenbox, and he doesn’t recognise it any more.
He messages Tom: “Should I still own the subscription pause feature, or has Jordan taken it?”
Tom doesn’t know how to answer. In theory, features aren’t owned by individuals. In practice, Jordan has ownership of everything Jordan touches, and everyone knows it.
“You still own it,” Tom replies. But they both know that’s not true any more.
Tom sees the throughput numbers and thinks things are going well. Jordan is shipping more story points than any other developer. Tom’s review queue is shorter because Jordan’s code doesn’t need much feedback. The metrics say the hire is working.
The metrics are wrong.
Charlotte sees it
Charlotte runs a team health check during a Thursday afternoon session. She uses a format borrowed from the Spotify model, the team rates themselves on eight dimensions, anonymously, on a scale of 1 to 5. Mission, speed, quality, fun, learning, support, teamwork, codebase health.
The results come back.
Speed: 4/5. Quality: 4/5. Mission: 3/5. Codebase health: 3/5. Learning: 2/5. Support: 2/5. Fun: 1/5. Teamwork: 2/5.
Charlotte looks at the numbers for a long time. The team is fast and the code is good. The team is also not learning, not supporting each other, not having fun, and not working together.
“This is the profile of a team with a star performer and no collaboration,” Charlotte tells Maya privately. “High output, low cohesion. It looks productive until someone leaves, or until the star gets sick, and then nobody can maintain what they’ve built.”
Maya pushes back. “Jordan’s shipping more than anyone. The delivery scheduling module was a six-week backlog item and Jordan did it in three days.”
“And how many people can maintain it now?”
Maya doesn’t answer, because she doesn’t know. She asks Tom.
Tom asks Priya.
Priya says: “I can read it. I can’t change it confidently.”
Tom asks Ravi.
Ravi says: “I stopped working on the subscription pause feature. Jordan’s version is better, but I don’t understand the abstraction layer well enough to fix bugs in it.”
Tom sits with this. He’s been so relieved to have someone shipping fast that he hasn’t noticed what’s happening underneath.
The conversation Maya doesn’t want to have
Maya procrastinates for a week. She rewrites the talking points three times. She asks Charlotte for advice, then asks Lee, then asks Ren on a Saturday morning over tea in Fremantle.
Ren’s advice is the simplest: “Be honest. Be kind. Be clear.”
On a Tuesday afternoon, Maya asks Jordan into the small meeting room. The Event Storm photos are still on the wall. The sticky notes from the original session are fading behind their lamination.
Maya starts with the data, the health check results, the code ownership patterns, the team’s reluctance to work in areas Jordan has touched. She’s careful to frame it as a system problem, not a character flaw.
Jordan listens. Then Jordan says something that catches Maya off guard.
“I’ve been shipping more than anyone on the team. The delivery scheduler was stuck for six weeks. I fixed the notification system. I refactored the pause feature. My code has zero production bugs. What exactly is the problem?”
Maya has rehearsed this, but hearing it said plainly is harder than she expected. Because Jordan is right. By every individual metric, Jordan is the best developer on the team.
“The problem,” Maya says, “is that the team is worse with you on it than it was without you.”
The sentence lands heavily. Jordan’s expression changes, not to anger, but to genuine confusion.
“I don’t understand that. I’ve done everything you asked. I’ve shipped more than anyone. I haven’t complained, haven’t caused drama, haven’t missed a deadline.”
“You haven’t collaborated,” Maya says. “You haven’t paired with anyone. You haven’t shared what you know. You haven’t asked for input. You write code that only you can maintain. That’s not sustainable.”
“Pair programming is for juniors,” Jordan says. Not dismissively. Factually, as if describing a natural law.
Maya remembers the Event Storm, the session where seven people stood in front of a wall and built shared understanding in three hours. She remembers what happened when Tom tried to build alone in the first weeks: the wrong assumptions, the wasted sprints. Collaboration isn’t a nice-to-have at Greenbox. It’s the thing that makes the product possible.
“Not here,” Maya says. “Here, it’s how we work.”
Jordan is quiet for a long time. Maya watches the expression shift, confusion to something harder, something defended. Jordan isn’t angry. Jordan is processing the realisation that the thing they’ve been rewarded for their entire career, individual excellence, solo delivery, technical brilliance, is the thing that’s causing problems here.
“I don’t know if I can be what you’re asking me to be,” Jordan says finally.
It’s the most honest thing Jordan has said since arriving. Maya respects it.
“I know,” Maya says. “Let’s figure out what that means.”
The outcome
Jordan leaves Greenbox three weeks later. It’s not a firing, it’s a mutual acknowledgement that the fit is wrong. Jordan is a talented developer who works best in environments that value individual ownership and autonomous delivery. Greenbox values shared ownership and collaborative practice. Neither approach is inherently wrong. They’re incompatible.
Jordan negotiates a clean exit. No drama. Two weeks’ notice, a professional handover of the four areas they touched, and a quiet last day where Jordan shakes hands with Tom and nods to Priya on the way out.
The handover takes the full two weeks, and it’s revealing. Every session surfaces another piece of knowledge that lived only in Jordan’s head, a configuration choice, a performance optimisation, a design decision that makes sense only when Jordan explains the reasoning. By the end, Priya has filled half a notebook with context that should have been shared from the start.
“This is what ADRs are for,” Charlotte says, watching one of the handover sessions. “Every one of these decisions should have been written down when it was made.”
What Maya changes
The Monday after Jordan leaves, Maya rewrites the hiring criteria. She does it with Charlotte and Tom, in the small meeting room, over three hours that feel like a retro for a hire that didn’t work.
They add three questions to every technical interview:
“Tell me about a time you helped a teammate understand your code.” Not “tell me about a time you wrote great code.” Not “tell me about your biggest technical achievement.” The question that reveals whether someone sees knowledge-sharing as part of the job.
“How do you handle disagreement about technical approaches?” Jordan would have answered this with something about being willing to explain their reasoning. The answer Maya is looking for is closer to “I’ve changed my approach because someone else had a better idea.”
“What does a good code review look like to you?” Jordan’s answer would have been about correctness and coverage. The answer Maya wants is about learning, communication, and shared understanding.
Tom adds a practical component: a pair programming exercise during the interview. Thirty minutes, a small problem, the candidate working alongside a Greenbox developer. Not to test skill, to test collaboration. Can this person think out loud? Do they ask questions? Do they listen?
Priya, who sat through Jordan’s handover sessions filling her notebook, suggests one more thing: a probation review at four weeks, not twelve. “We knew at week two,” she says. “We just didn’t say anything.”
Nobody argues.
The lesson that’s hard to learn
The cost of Jordan wasn’t the salary or the three months of disruption. The cost was what happened to the team while Jordan was there.
Priya stopped asking questions in code reviews. Ravi abandoned a feature he’d built. Jas dreaded the standups. The team’s support and fun scores dropped to levels that take months to recover. One person’s working style, applied without adaptation to an existing culture, degraded the entire system.
Jordan wasn’t a bad person. Jordan was a good developer in the wrong environment. The failure wasn’t Jordan’s, it was the hiring process that optimised for technical skill and didn’t test for values alignment.
Charlotte puts it in terms the team understands: “You can teach someone a new framework in a week. You can’t teach them to value collaboration if they don’t already.”
The team rebuilds. The standup texture returns, slowly, then all at once, like a conversation resuming after an awkward silence. Priya starts asking questions in code reviews again. Ravi takes back the subscription pause feature, reads Jordan’s code carefully, and rewrites the parts he doesn’t understand. He keeps the parts he does. Some of Jordan’s patterns were genuinely good. The team absorbs what works and lets go of what doesn’t.
It takes about six weeks for the health check scores to recover. Fun goes from 1/5 to 3/5. Support goes from 2/5 to 4/5. Teamwork climbs back to where it was before Jordan arrived.
Tom, loading the dishwasher that evening while Leo draws at the kitchen table, tells Sarah about it.
“We lost three months,” he says. “Not because Jordan was bad. Because Jordan was good at the wrong things.”
Sarah hands him a plate. “Did you learn something?”
“Yeah. Hire for the team, not the CV.”
“You say that like it’s simple.”
“It’s not. That’s why I needed three months to learn it.”
Ava looks up from the couch. “What are you talking about?”
“Work stuff,” Tom says.
“Sounds boring,” Ava says, and goes back to her book.
It’s the most boring lesson in management, and the most expensive one to learn the hard way.