Architecture decision
For a design your team has already worked out. A working session with your team, then I check the design against your code, build a benchmark where the argument needs numbers, and write up a recommendation with the reasoning behind each decision. Then a session to walk through it and take questions. Typically two to three weeks, and faster when the decision can't wait.
For when
Your team has worked out a design that other teams are about to build on, and you want it checked by someone who isn't on any of the teams.
Why someone from outside
This fits a decision that is hard to change later because a lot gets built on it in the meantime: where the line falls between a shared core and the language-specific code around it, or which of two stacks your on-call engineers can still support in three years.
The team that worked out the design shaped it around its own needs, and sometimes its own preferences. I’m not on any of your teams, so I can tell you which parts every team needs and which ones only that team wants. I write it down with the reasons, so everyone can read them.
When the answer depends on numbers, I measure them. At Band, choosing between two ways to call the Rust core from TypeScript came down to a benchmark I built for it.
How it works
- A written proposal: the scope, the deliverable, the date and the fixed fee.
- A working session with your team to go through the design, the code and the constraints.
- I read the code, and build a benchmark or a small prototype where the answer depends on numbers.
- A few questions to your team along the way. They keep shipping throughout.
- The written recommendation, within two to three weeks.
- A session to walk through it and take questions.
- Questions for two months after delivery.
What you get
- The answer first, in half a page
- The reasoning behind each decision, and what it was weighed against
- What the code shows today, with measurements where they were needed
- Who maintains what afterwards
- A migration plan in phases, each of which ships on its own
- What to avoid
- What is decided, and what is still open
Your other options
Leave it open, and let each team build its own way
It costs nothing now. By the time anyone looks, there are two or three implementations.
The team doing the work decides
That's fast and close to the code, but its constraints win by default.
You decide it as CTO or VP R&D
You have the authority, but maybe not the time to go into the code, and the teams may not accept the ruling.
Questions
How many hours is that?
I don't scope this in hours. It's a fixed fee for a defined deliverable, so the price doesn't depend on how long it takes me. That's deliberate: if it turns out to be more work than I expect, that's my problem, not yours.
Can it be faster?
Yes, it can come down to one week, when your team has everything I need ready from the start and depending on my availability.
Can an outsider understand our system in a few weeks?
Yes. I've done this many times before, so learning a new system goes quickly for me. Your engineers will still know their own parts better than I do. My job is how the parts fit together.
What if you tell us we've been building the wrong thing?
Better to hear it now than after more is built on it, and the plan in phases keeps you shipping while it changes.
Will you sign our NDA?
Sure, signing a mutual NDA is part of the package.
What I learned
Want to talk it through?
