How I work with teams
Two things shape every engagement: how close I sit to the work, and what kind of project it is. Below are the three levels of involvement, and the project types they usually cover.
Direction
You need to know where the opportunity is and what to do about it, before committing budget or headcount to the wrong thing.
- Operations audit across growth, efficiency and cost
- Opportunities ranked by value and cost to capture
- Architecture and tooling recommendations: build, buy, or leave alone
- Written report and a working session with your team
Guidance
You know roughly what needs to happen. What's missing is the design, and someone who has done it before reviewing the work as it goes in.
- Implementation blueprints: architecture, data models, and the decisions behind them
- Recorded training for the people doing the build
- Templates, worked examples and reference code
- Design review and async support throughout
Embedded
Sometimes the fastest way to move a capability into a team is to sit inside it for a while and build the first one together.
- Hands-on implementation alongside your team
- Standards and patterns set by example, not by document
- Structured handover so it doesn't leave when I do
Project types, and what they have delivered
These are the kinds of projects I take on. Where I have done one before, the result is listed with it. Clients are anonymised.
Three things worth knowing up front
Start with a conversation
Tell me what you are trying to move. If there is a fit, the first step is an audit that establishes what is actually happening and what is worth fixing.