We were four engineers shipping once a week. Not by choice — that was the pace our habits could support. Merges piled up. Thursday was "deploy day." Friday was "fix what Thursday broke" day.
Nobody called it a problem. It felt normal. The way a room with a slow gas leak smells normal after an hour.
Then we hired a fifth engineer — someone whose previous career had nothing to do with our stack.
She came from operations. Not software operations — warehouse logistics. Her engineering skills were solid but unremarkable on paper. What got our attention was how she talked about workflow.
She kept asking: "What happens between when you finish writing the code and when a user sees it?" We gave vague answers. She pressed. We gave vaguer ones.
We hired her to fill a gap. What we thought the gap was: someone to own a new product surface. What the gap actually was: someone who would refuse to treat deployment as a ceremony.
On her third day she asked why a finished feature had been sitting in review for two days. The author said he was waiting for Thursday. She asked why Thursday. He said that's when we deploy. She asked what would break if we deployed on Tuesday.
Nobody had a good answer.
By Friday she had merged and shipped a small change on a Wednesday. Nothing broke. The sky held.
Over the next six weeks, three things shifted:
Review turnaround dropped. She treated a pending review the way a warehouse treats a pallet blocking an aisle — something to move now, not later. Her urgency was social, not managerial. She just asked people to look at things. Average pull request wait time went from about two days to about four hours.
Deploys became frequent and small. Faster reviews shrank the batch size of each deploy. Smaller batches meant less risk. Less risk meant less anxiety. Less anxiety meant people stopped saving things for Thursday.
Testing shifted left. When you know your change ships the same day you write it, you check your own work differently. The team started writing more focused tests before asking for review, because there was no two-day buffer to catch mistakes by accident.
None of this happened because she introduced a tool or wrote a policy document. It happened because her instincts about flow were different from ours, and she acted on them immediately.
Here is the point most founders miss about engineering teams: you don't get a new process by adopting a new process. You get a new process by changing who is in the room.
Tools are inert. A deployment pipeline does what you tell it. If the humans using it have a weekly-batch habit, the pipeline will execute weekly batches. If someone on the team has a visceral discomfort with work sitting idle, the pipeline will run more often.
We had tried to "move faster" before. We wrote it in retrospective action items. We agreed on it in planning meetings. Nothing changed, because agreements don't override habits. People override habits.
When you write a job description, you list skills. Languages, frameworks, years of experience. Maybe you add something vague like "strong communicator." That list optimizes for the skill gap — what your team cannot build today.
The more interesting question: what does your team not do well as a process? Where does work stall? Where do people wait without realizing they're waiting?
That's the workflow gap. The best way to close it is to find someone whose prior experience makes the current dysfunction feel strange. Not someone who will politely adapt. Someone who will question it on day three.
You can't interview for this by asking "describe your ideal deployment process." You interview for it by describing your current workflow honestly and watching whether the candidate's face changes.
This kind of hire introduces friction. Not the bad kind — the productive kind. But it still costs social energy. Our team spent two weeks feeling mildly defensive about habits we had never examined. Some of those conversations were uncomfortable.
The discomfort was the mechanism. If she had quietly conformed to Thursday deploys, nothing would have improved.
A team of five people with the same instincts will produce the same process, no matter what tools you hand them. A team of five with one different instinct will produce a different process — often a better one.
Hire for the workflow gap. The skill gap fills itself with documentation and time. The workflow gap only closes when someone walks in and asks the question nobody thought to ask.
Be the first to comment.
0 comments
Loading comments...