Chairing a Cross-Team UI Guild

Context

In a large telecoms engineering department at Sky, most teams were organised around backend use cases. Each scrum team had mostly backend and network engineers and perhaps one UI engineer. Across the department there were a good number of UI specialists, and almost none of them worked together.

Problem

I wrote down what that structure was doing to UI work:

• Stand-ups had little value for UI engineers. Nobody depended on their updates, and backend updates weren’t abstracted enough to follow.
• No shared view of UI work. Engineers were asked to review code for use cases they had no context on.
• Nothing to pair on in mixed-role teams, and little knowledge sharing between UI developers.
• UI work was small and repetitive per use case, so engineers were under-used, while cross-cutting work (logging, performance monitoring, test automation, tech debt) never got prioritised.
• Low awareness: people didn’t know what UI work existed elsewhere, even when they’d seen the code.
• UI work wasn’t planned like other areas (no demos, no improvement time), so it was treated as lower priority.

What I did

• Made the case in writing, with the pain points above and a proposal: a UI-focused team around the newest platform, and a restarted UI guild as a community of practice across teams.
• Was asked to chair the guild for UI/UX across the department, and ran it on a regular cadence with UI developers from several teams.
• Used a simple, repeatable format. A shared whiteboard each session: responsibilities this week, work in progress, who you need to reach, current issues, codebase issues; then what went well, what’s in review, and any regressions found.
• Set shared agenda items: aligning on technologies, sharing tech wins, demos, and team health checks (capacity and upcoming work) so specialists could support each other across team lines.
• Worked towards consistency: a recommended set of front-end technologies, so products across departments could share a consistent look, feel and tooling.

Outcome

UI engineers who had never spoken started reviewing each other’s work, reusing each other’s components and documentation, and asking each other for help. Testing practices, Playwright for one, spread through the guild rather than by mandate. The department had a recognised forum for UI decisions, which the CV sums up as chairing UI/UX across the department.

What I’d do again

• Write the problem down first. A clear list of pain points persuaded people far more than “we should have a guild”.
• Keep the format boring and the cadence regular. Communities die from irregular meetings, not from boring ones.
• Include health checks. Asking about capacity made the guild useful to managers, not just to engineers.

What I’d do differently

Give the guild a small, visible backlog of cross-team improvements from the start. Discussion builds trust; shipped shared work builds momentum.

Related notes

Pair Programming · Communicating with Stakeholders · A Testing Strategy Teams Actually Adopted · Headless Component Libraries