Fresh Eyes on a Cucumbered Team
Posted on
I once did some subcontracting for Test Double (wonderful consultancy btw, really good people there). While there I picked up a term for what happens when you’ve been inside an organization so long you stop noticing its quirks: you’ve been “cucumbered.” Left in the brine long enough, you become indistinguishable from the brine itself.
It’s a good metaphor because it isn’t unkind. A cucumber doesn’t do anything wrong by becoming a pickle. It just sits in the brine, and the brine does what brine does. The same is true on a team. Nobody decides one day to stop questioning the workaround that’s been “temporary” for two years. It happens gradually, as a side effect of being close to the work.
Why it happens to good teams
Cucumbering isn’t a sign of a bad team or a lazy engineer. If anything, it tends to happen to the most embedded, most trusted people on a team – the ones who’ve been there long enough to know where all the bodies are buried, which also means they’re the ones least likely to ask why there are bodies there at all.
Proximity is what makes someone effective day to day. You learn the shortcuts, the unwritten rules, the “oh yeah, just ignore that error, it’s always been like that.” That knowledge is valuable. But it’s also exactly what makes the weird parts of a system invisible. You stop seeing the thing because you’ve stopped looking at it – you’ve just started working around it, the same way everyone else already does.
What a consultant actually brings in week one
This, I think, is one of the real values of bringing in outside help. Hiring a consultant is usually framed in terms of technical skills: bring in a senior person to solve a specific problem or boost team velocity. Sometimes that’s true. But more often, the most useful thing I do in the first week or two on a project has nothing to do with technical chops. It’s that I haven’t been pickled yet. I get to ask “why do we do it this way?” about things that everyone else on the team has long since stopped seeing as a question at all. And because I’m new, that question doesn’t carry any history or political weight – I’m not implying anyone made a bad call, I’m just genuinely asking.
That question, asked plainly and without an agenda, is sometimes the most valuable thing a consultant can offer.
The guardrail
Here’s the part that matters most, though: there’s a fine line between asking why and trying to remake a team in your own image, and you should be careful not to cross it.
The practice of asking why isn’t an opportunity to slide in your own preferred workflow because it’s what you’re used to. It’s about creating space for the existing team to have their own introspection. If that leads somewhere – great. But what that somewhere should be needs to come out of team review and discussion, not the whims of a single person, even if that person is me (and I’m pretty great).
So, what’s gone unquestioned on your team?
You don’t need a consultant to ask “why do we do it this way?” Anyone can ask it – it’s just easier for someone who hasn’t been in the brine as long.
So: what’s something on your team that’s survived purely on “that’s how we’ve always done it,” that nobody’s actually re-examined in years? It might be worth asking the question out loud, even if the answer turns out to be a perfectly good one.
About the Author. Mike Zornek is a developer and teacher focusing on product design and development with a heavy focus on Elixir and LiveView. In between his projects, Mike helps other teams through consulting. During off hours, he enjoyed watching Phillies baseball and playing relaxing video games.
Hopefully, you found interest in my scribbles. If you have commentary or a response, I'd love to hear it.