Most founders who bring in a fractional engineering leader are looking for the same thing: engineering momentum. Not activity — engineers are almost always busy — but directed motion. Work that compounds toward something, where effort today makes tomorrow's effort easier rather than harder.
When that's missing, the symptoms are familiar. Delivery has slowed. Cross-team communication feels like friction rather than collaboration. Something that should take a week takes a month, and nobody can quite explain why. The team seems capable, but the output doesn't reflect it.
What's usually underneath that isn't a talent problem. It's a system problem. And untangling it — in a way that actually sticks — takes more than a fresh set of eyes. It takes experience reading the specific signals that tell you what's actually happening versus what the visible problems are pointing at.
Here's what that process looks like in practice.
Week 1: Build the map
Before anything changes, I need to understand the system — and a software team is a system, not just a collection of people writing code. That means looking at the technical layer and the human layer simultaneously, because they almost always reflect each other.
I meet every engineer individually in the first week. One at a time, without an agenda beyond understanding their experience. What are they working on? What's making it harder than it should be? If they could change one thing, what would it be?
What surfaces in these conversations is irreplaceable. Engineers know where the complexity lives and why it got there. They know which decisions created the most downstream pain. They know who carries the most implicit knowledge and who is quietly stretched thin. They also know — and this comes up more than founders expect — when their team has drifted into operating in isolation. Processes that were never documented. Tooling built internally that solves problems nobody else in the organization knows they solved. Decisions made locally that have never been communicated upward or across to other teams.
That last pattern is one of the most common and most costly things I encounter. Teams develop their own ways of working — their own rhythms, their own standards, their own internal language — and those ways of working never make it out of the team. What starts as autonomy quietly becomes a silo. And silos make organizational communication slow, expensive, and fragile.
I also spend time in the code this week — reading commit history, tracing the architecture, understanding where complexity has clustered and why. A codebase reflects the culture that built it. The shape of the technical debt tells you something about how decisions were made and whether they were ever revisited. Undocumented patterns tell you what was understood but never written down. If you know how to read it, the codebase is one of the most honest documents in the organization.
By the end of week one I have a working map — of the people, the technical landscape, and the relationship between the two.
Week 2: Find the real constraints
Most teams that are underperforming aren't lacking talent. They're operating inside a set of structural constraints that create friction across nearly everything they do — and because the friction is everywhere, it feels like the natural cost of building software rather than something that can be addressed.
This week is about finding what those constraints actually are, specifically, for this team and this organization. I start showing up more visibly — in code reviews, architecture discussions, planning sessions — not to direct them yet, but to see how the work actually flows in practice.
The separation between symptoms and causes is where real diagnostic experience matters. Slow delivery, unclear priorities, duplicated effort, decisions that have to be relitigated every sprint — these are real, but they're downstream of something more specific. The skill isn't just knowing what patterns to look for. It's knowing which ones are causing the others, and in what sequence addressing them will create the most leverage.
One of the patterns I look for explicitly is what engineers sometimes call "not invented here" syndrome — the tendency for teams to build or develop their own version of something rather than adopt what already exists, either within the organization or in the broader ecosystem. It comes from a good instinct: engineers want to understand and own what they're building. But left unchecked, it compounds into a much larger problem. Each team's internal tooling, processes, and conventions become a private language. Cross-team collaboration requires translation. Organizational knowledge stays trapped inside individual teams rather than flowing across them. What should be a shared foundation becomes a collection of parallel, incompatible approaches — and the cost shows up as exactly the kind of slow, grinding friction that makes it feel like the whole organization is moving through water.
Addressing this isn't about standardizing everything into uniformity. It's about identifying what needs to be shared and building the bridges that let it be. That's a technical problem, an organizational problem, and a communication problem all at once — and untangling it requires understanding all three.
Team structure becomes concrete this week as well. Not headcount, but organization. Does ownership match accountability? Are there engineers operating above or below their actual level? Are there gaps a new hire would fill, or gaps that restructuring existing roles would address just as well? Scaling a team doesn't always mean growing it. Sometimes the leverage is in removing the structural friction that's preventing the people already there from doing their best work.
Week 3: Begin moving
The trust built in the first two weeks has to translate into visible change, or it dissipates. By week three the team is watching — not skeptically, but expectantly. They shared things with you. They want to see what you do with it.
I pick the highest-leverage change available and make it. Most often this is a process or communication change rather than a technical one — not because the technical work isn't important, but because process changes produce immediate, felt results. A clear definition of done eliminates the ongoing ambiguity about what "finished" means. A code review standard cuts the time spent waiting on feedback. A shared architecture decision record means that the decision made this week doesn't have to be made again in six months when the context has evaporated.
On the organizational communication side, this is often when I start building the connective tissue that was missing — shared documentation standards, cross-team visibility into technical decisions, communication patterns that let teams stay loosely coupled rather than accidentally isolated. None of this is glamorous. All of it matters.
The people conversations deepen this week as well. Role misalignments, skill gaps, or team dynamics that are creating drag get addressed directly — with honesty, with care, and with a clear picture of what a better outcome looks like. Engineers want to know where they stand. Most of the difficult conversations I've had with people on teams were hard because they'd been deferred, not because they were inherently bad news.
If there are hiring needs, I start building the case now — not as a headcount request, but as a specific capability tied to a specific outcome. What can this team not do today that it needs to do next quarter, and is there someone already here who could grow into it, or does that capability need to come from outside?
Week 4: Establish the next horizon
By week four the team should feel different — not because the fundamental work has changed, but because the structural friction around it has started to lift. Velocity isn't a metric. It's a quality of motion. A shared sense of direction and the confidence that comes from knowing what you're optimizing for.
I bring a clear picture to the founder or leadership team: the team's actual strengths, what was creating the most drag and what has been done about it, where the remaining gaps are, and what the people and organizational plan looks like going forward. Not a deck of observations — a grounded account of the current state, built from real understanding of the codebase, the team, and the business context they're operating in.
Then I define the next 60 days in terms the whole team can commit to. Real targets tied to actual capacity. Technical priorities sequenced against the team's current constraints rather than set against an idealized version of them. Organizational changes that are still in motion but have a clear destination.
The goal of the first month isn't transformation. It's foundation — the kind that makes transformation possible. A team that understands what it's building and why, with the communication patterns and shared standards to move as a unit rather than a collection of individuals, is a team that can build what actually moves the business forward.
That's engineering momentum. And it's what every decision in the first 30 days is aimed at.
What this looks like from where you're sitting
If you're a founder watching this unfold, the first week will feel deliberate rather than urgent. That's intentional. The quality of everything that comes after depends on the quality of the understanding built first — and rushing that understanding is where most well-intentioned interventions go wrong.
By the end of week two you should have more clarity about what's actually happening in your engineering organization than you had before — not because I've handed you a summary, but because the right questions have a way of making things that were always true finally visible.
By the end of week four you should see motion. Not a finished transformation, but a team moving with clearer direction, fewer structural obstacles, and a shared sense of what the next quarter is actually going to require of them.
That's the foundation. Everything built on top of it is faster, sturdier, and more aligned with where the business is actually trying to go.
If your team is carrying more friction than it should — or you're not sure what's causing the slowdown — let's talk about it. Engineering momentum is buildable. You just need to know where to start.
Originally published at m2s2.io
Top comments (0)