02 / Organizational context / When to involve me
When to involve me
Organizations need different kinds of technical leadership as their web development capability develops.
Sometimes the stage is clear: you are moving into web development, strengthening an early foundation or scaling across teams. At other times, the need first shows itself through slower delivery, recurring quality problems or increasing dependence on a few people.
The stages below describe where your organization may be; the triggers describe what you may be noticing. You do not need to know the underlying cause before starting a conversation with me.
Where your organization is
01
Moving into web development
Your organization has just started or is moving from desktop, native or another established platform into web applications. The first decisions about architecture, tooling and ways of working will shape what the team can build later. I help establish a foundation the team understands and can continue to develop.
02
Strengthening the foundation after the first releases
You have built one or more versions of a web product, but further development is becoming harder than expected. Decisions that helped you get started are beginning to affect maintainability and development speed. I help identify what needs to change and build a more deliberate foundation with the team.
03
Creating coherence across growing teams
Web development has spread across products or teams, and each team has developed its own solutions and ways of working. I help establish a shared technical direction, improve reusable foundations and make knowledge flow across the organization, while leaving room for the needs of individual teams.
04
Embedding technical leadership
Your organization recognizes the need for technical leadership across front-end engineering, but the function is not yet established or an internal candidate is still growing into it. I can take on the role temporarily, provide direction across teams and help that candidate prepare for the role.
What you may be noticing
01
Development slows as the product grows
Adding developers or delivering more features no longer produces the expected increase in speed. Changes require more coordination, pull requests become larger and dependencies between teams increase. If this continues, additional capacity creates more overhead instead of more progress.
02
Autonomy is turning into fragmentation
Teams make reasonable decisions for their own products, but architecture, tooling and ways of working begin to diverge. The same problems are solved repeatedly, shared code accumulates exceptions and no one provides direction across front-end engineering as a whole. Over time, changes that cross team boundaries become increasingly difficult.
03
Quality problems keep returning
Bugs, regressions or production issues are resolved, but similar problems continue to appear. This can point to gaps in testing knowledge, quality tooling, monitoring, ownership or delivery processes rather than one isolated defect. More development time gradually shifts from building the product to recovery and rework.
04
Knowledge and ownership depend on a few people
The same developers are needed for important decisions, difficult incidents, releases or onboarding. Work starts waiting for their availability, while knowledge leaves with them when they change roles or leave the organization. Knowledge, responsibilities and decision-making need to become more broadly supported.
05
Improvements keep losing to feature work
The organization knows which architectural, tooling or process improvements would help, but they repeatedly lose priority to product delivery. Temporary workarounds become permanent, the improvement backlog grows and every new feature inherits the same friction. Without technical direction and clear ownership, improvement remains incidental.
