Apr 2023
As a technically complex project matures, team processes must change to keep up with the times.
Such project's earlier phases tend to focus on bootstrapping -- making critical technical choices and building an MVP that the team can evolve and extend. The later phases involve increasing adoption and capturing more of the market by building on this MVP and the prior technical decisions.
I've observed two significant differences between these phases:
1/ Centralized Decision Making → Decentralized Decision Making
Alignment is critical in the early phases. I visualize a project's early stages as two teams digging a tunnel from both sides of a mountain -- we won't meet in the middle unless we're fully aligned on the direction. This means decision-making needs to be centralized, with frequent sync points.
On the other hand, this kind of strict alignment can become a bottleneck in the latter phases as the team grows. Since many cornerstone design decisions have been made by then, it is OK to decentralize decision-making, and frequent cross-team check-ins aren't as necessary. Furthermore, backtracking on suboptimal technical choices is no longer as disruptive since, by this time, you have a baseline working system.
2/ Looking Inward → Looking Outward
In the early phases, the team must align on a vision and focus inwards. Excessive outward focus on customers can dim the manic obsession necessary to build the initial momentum. Senior leadership also needs to buy into this and sequester the teams to a certain extent.
In the latter phase, the team becomes has to become more reactive. Reactive tactical work, like responding to users, implementing features based on customer feedback, is usually necessary to foster adoption and build confidence in the user base. The quarterly/yearly plans need to reflect this. Having said that, if the technical choices are sound, this reactive engineering time should scale sub-linearly with adoption.