Why I Never Start with the Developer Process

Someone asked me recently: "How would you design the developer process?"

My answer surprised them. I wouldn't start with the developer process at all.

Most CTOs go straight to tooling, branching strategies, sprint ceremonies, and deployment pipelines. All valid. All necessary. But none of it matters if the team doesn't share the same vision of where they're going.

Before any process, I ask: how well does information actually travel through this team? How much gets lost between a decision and its execution? How fast do people's mental models drift apart after a meeting ends?

Because they always drift. That's not a failure. That's just how communication works.

The real problem most tech teams ignore

Communication has one job: to transfer the vision of the person who holds it into everyone who needs to act on it. That sounds simple. It isn't.

Every message passes through filters. Language is the obvious one. A native German speaker talking to another native German speaker will be closer than a B2 German speaker from Portugal talking to a B2 German speaker from Russia. Same words, different signal. Now imagine that conversation in English, where both speakers learned it as a second language, with different accents, idioms, and cultural references. The gap between what was meant and what was understood can be enormous, and nobody notices until something goes wrong.

But language is just the surface. There are deeper filters running underneath every conversation. Previous experience shapes how people hear things. Someone who has been burned by top-down decisions without context will hear the same instruction differently than someone who has always worked in flat, transparent teams. Mindset, seniority, domain background, even mood on a given day, all of these distort the signal.

Then there's the shared vocabulary problem. A product manager, a backend developer, and an investor can sit in the same room and talk about "performance" for an hour. Each one means something entirely different. Nobody asks for clarification. Everyone leaves thinking they're aligned.

Alignment is not a state, it's a constant effort

Even when communication goes well, alignment decays. This is the part most teams don't build for.

Think of it this way: every conversation aligns two vectors. At the end of a good discussion, both people are pointing roughly in the same direction. Roughly. Never exactly. The vision can never be transferred with 100% fidelity, there's always some delta between the sender's intent and the receiver's understanding.

And then time passes.

Memory fades. Priorities shift. New information comes in and gets interpreted through each person's individual lens. The vectors start to drift. Slowly at first, then faster. Two weeks after that alignment conversation, you might be surprised how far apart the mental models have moved, even between people who genuinely want to be on the same page.

This is not a dysfunction. This is physics.

The mistake most teams make is treating communication as an event. "We talked about it" becomes "it's handled." But communication is not an event, it's a continuous process of recalibration. The intervals between recalibration matter enormously. Short, frequent syncs outperform long, infrequent ones, not because of the duration, but because they catch the drift before it compounds.

What I actually do about it

A few principles I've arrived at after working with teams across very different contexts:

First, optimize for frequency over depth. My default is a ten-minute alignment conversation every day, especially during critical phases like project kick-offs, onboarding, and release periods. That's when the vectors drift fastest, and that's when you can least afford it. The goal is not to fill the time. The goal is to catch drift before it compounds.

Second, every conversation gets recorded, transcribed, and summarized. AI handles the summary and extracts action points. The result is a single, written, central source of truth that everyone can refer back to. If it isn't documented, the conversation happened in five different versions, one per person in the room.

Third, repeat deliberately. Good communication is redundant by design. Say it, write it, say it again. Asking someone to restate what they understood in their own words can also help close the gap, though it's not a guarantee. It's a check, not a fix.

Why this comes before the developer process

All of this, the language gaps, the filters, the drifting vectors, lives underneath every technical process you could ever design. Sprint planning only works if the team shares an understanding of what they're building and why. Code review only works if there's a shared definition of quality. Architecture decisions only stick if the reasoning travels correctly through the team and survives over time.

The developer process sits on top of something that most teams never build deliberately: a communication foundation that keeps everyone pointing in the same direction, again and again, over time.

That's where I start.