Building and Levelling Up a UI Team

Context

At Sky I was UI Lead on a low-code network automation platform (Building a Low-Code BPMN Workflow Platform). UI practice across the department was young and uneven: each team built screens its own way, and UI engineers were spread thinly across teams shaped around backend work.

Problem

An inconsistent UI is the visible symptom; the cause is usually a team without shared standards. Reviews varied from person to person, new joiners learned by osmosis, and there was no regular place to agree how things should be done. Building the new platform needed a team that could move quickly and consistently, and that team didn’t exist yet.

What I did

• Put the team together. I interviewed and hired engineers for the platform, looking for people who cared about the craft and could grow, not just people who knew the current stack.
• Onboarded and upskilled them deliberately. A clear path through the codebase, pairing on real work early, and a written record of how things are done (First Week in a New Codebase, Pair Programming).
• Drove a consistent UI. Shared components and patterns, so screens across use cases looked and behaved alike and nobody had to reinvent a table or a form (Headless Component Libraries).
• Structured pull requests. A predictable shape for every pull request (what changed, why, how to test it, screenshots) and smaller, focused changes, so reviews became faster and more useful (Slicing Pull Requests).
• Ran regular syncs. A short, regular team sync plus a wider UI guild across departments, so decisions were made in the open and problems surfaced early (Chairing a Cross-Team UI Guild).
• Mentored one to one. As line manager I ran regular one-to-ones focused on each person’s growth, not just status.

Outcome

The team responded well. The UI became consistent across the platform, process improvements were small and actionable rather than big-bang, and communication within the team and with neighbouring teams improved. When I later moved on, that shared way of working made the handover far easier (Knowledge Transfer Before Moving On).

What I’d do again

• Hire for growth, then invest in it. Onboarding is where a new hire’s habits are set.
• Standardise the boring parts. A pull-request template and shared components remove whole categories of debate.
• Keep the cadence regular. Syncs only work if people can rely on them happening.

What I’d do differently

Write the team’s working agreements down in the first month rather than letting them emerge. Explicit standards are easier to teach, easier to challenge and easier to hand over.

Related notes

Communicating with Stakeholders · A Testing Strategy Teams Actually Adopted · Design Review Readiness Checklist