Development leadership / Shared systems
From separate projects
to a shared way of working.
A common Unity foundation, reusable tools and a delivery process the whole team can use.
Read the case study
The starting point
Each application began with an empty Unity project. Player rigs, movement, interactions and design decisions were recreated independently, with little carrying forward into the next project.
My contribution
I built, tested and documented a common template around the Meta SDK, standardising the player rig, movement, teleportation, grabbing, buttons and interactions. It became the agreed starting point for new projects.
Reusable quizzes, review mechanics and assessment systems followed. Course-building wizards allowed non-developers to set up content, while developers concentrated on more technical work. Useful new capabilities were added back into the shared foundation.
Making it work for people
I explained why we were choosing a common system, including its limitations. Familiar constraints helped the team become more proficient and gave the business clearer choices: use an established capability, or allow time to build something new. Written guides, videos and demonstrations supported different ways of learning.
What changed
The team spent less time discussing the basics, prototyped more quickly and delivered more consistent courses. Project teams shared a clear process for setup, testing, deployment, bug reports and progress tracking. Routine course delivery became largely independent, while I continued to focus on prototypes and new technical challenges.
For one anonymous utilities client, a familiar interaction model let planners and developers recommend a solution confidently within the available budget. It became one of our cleanest and quickest projects, substantially reducing development time compared with similar early work.





