“Technology strategy” and “fractional advisory” are two of the vaguest phrases in software services. They can mean anything from a single slide deck to a part-time CTO showing up to standups indefinitely. So rather than describe what advisory work is in the abstract, here’s what it concretely looks like in the first week of an engagement with us.
Day one: we read before we talk
Before the first real working session, we ask for access — not a briefing, access. Repos, architecture docs if they exist, the ticket tracker, deployment configuration, incident history if there is one. We’d rather spend a day reading code and postmortems than a day listening to a summary of them, because summaries are where problems get smoothed over, usually without anyone meaning to.
If there’s nothing to read — no docs, no history — that’s itself a finding, and we say so on day one rather than discovering it’s a surprise in week three.
We ask “what decision are you stuck on,” not “what’s your roadmap”
Most companies that bring in fractional advisory already have a roadmap. What they usually don’t have is confidence in one or two specific decisions sitting on top of it: build vs. buy on a particular capability, whether to take on a migration now or defer it, whether the team structure matches the architecture. We spend the first week finding that decision, not producing a new roadmap to replace the one that already exists.
This matters because a 40-page strategy document nobody acts on is worse than useless — it creates the feeling of progress without any of the substance. A clear recommendation on the one decision that’s actually stuck is worth more than a comprehensive review of everything.
We write down what we’d do with more time, and what we won’t need it for
By the end of week one, we produce two short lists, not one. The first: what we’re not yet confident about, and what we’d need to look at to get there. The second — usually shorter, and just as useful: what we already have enough information to recommend on now, without further investigation. Clients are often surprised by how much falls into the second bucket. Not every technical question needs a discovery phase; some just need someone with the right experience to look at it directly.
We say when we’re not the right people for something
If week one surfaces a problem that’s really an organizational or hiring problem rather than a technical one — no amount of architecture review fixes a team that doesn’t have the headcount to execute the plan — we say that plainly, even though it doesn’t grow the engagement. Technical judgment includes knowing the limits of what technical judgment can fix.
What you should expect to have by the end of week one
A named point of contact who has actually read your system, not just heard about it. One clear recommendation on the decision you brought us in for. An honest list of what still needs investigation. And a sense, one way or the other, of whether continuing the engagement is worth your money — because if it isn’t, we’d rather tell you in week one than in month three.