From service team
to AI-first guild

When Graham joined Mimecast in 2020, design was a peripheral function. The organisation was engineering and product-led, delivery mattered more than design quality, and designers were frequently either left out of user experience decisions entirely or brought in for low-value work after the important calls had been made.

Over two years that changed. The team built credibility through evidence and outcome, and demand grew. But the organisation had a structural problem that compounded the bottleneck: many teams were operating in a heavily Jira-driven waterfall model. Everything had to be well described, well ticketed, and well understood before work could begin. That discipline had its place, but it made the organisation slow to make decisions and resistant to more flexible, exploratory ways of working. Design sat outside those processes, so even when designers were available and engaged, the sequential hand-offs meant things moved slowly or stalled entirely. AI would later force the organisation's hand on this, demonstrating in practice that faster, more adaptive ways of working were not only possible but necessary. The guild became one of the places where that shift was modelled.

The solution was not to hire more designers. It was to change how the whole system worked.

The decision to restructure was Graham's. His view, grounded in the empowered product model associated with Marty Cagan's work, has always been that good user experience only happens in cross-functional teams where designers, engineers, and product managers work as genuine partners. A centralised service model, however well managed, prevents that kind of collaboration from taking root.

Graham spoke to every product leader individually, agreed the line management changes, and then met with each designer to explain what was shifting. They were not being handed off. They were being recognised as design leaders for their product areas, with the authority and proximity to engineering and product that genuine collaboration requires.

The principal designer took on coordination of Mimecast Elements, the shared design system, giving the system dedicated leadership and a clear home within the new structure.

The guild was the answer to that second question. With designers embedded in squads, the risk was fragmentation: five designers working in isolation, drifting from shared standards, losing the cross-team perspective that makes a design function more than the sum of its parts. The guild provided the connective tissue, and critically, it was open to anyone in the organisation who had an interest in improving the customer experience. Product managers, engineers, customer-facing teams, researchers from pricing and marketing: membership was deliberately broad.

How it started

Mimecast was moving to an AI-first operating model. You.com was the first tool adopted across the business, chosen because it aggregates multiple large language models and selects the most appropriate one for each prompt. It came with structured training courses that built genuine understanding of what AI could offer each person in their role. This seeded awareness across the workforce before the design team had worked out how to use AI well in practice.

The guild created the space to move from awareness to experiment. The approach was deliberately exploratory: new technology, new capability, and a need to learn the real lessons about what worked and what did not. Graham encouraged the team and the wider guild to try things, report back, and share what they found. That learning would shape how the guild evolved.

The Cursor training that became a landmark moment for the team started with a lunch conversation between Graham and a lead engineer about AI tooling. A week later the engineer came back with a proposal to run Cursor training for designers. Graham opened the guild Slack channel to the engineering team and encouraged designers to attend. The session demystified the path from design to working code, and gave designers a practical understanding of what code generation could do in their hands.

Legal and procurement were real constraints throughout. Graham navigated these by framing most early tools as temporary trials, which reduced the approval threshold and gave the team time to build genuine evidence of value. He managed vendor relationships actively, passing feedback from the team back to vendors directly and using those conversations to help improve their tools while securing early access and responsiveness in return.

Tools and how they were used

The research Slack channel

Alongside the main guild channel, Graham set up a dedicated Slack channel for user research and opened it to the wider organisation. It surfaced researchers in pricing, marketing, and other functions who had been working in isolation. Pooling those people and their experience gave everyone better context on real customer problems, helped the group share approaches to AI-assisted research, and created shared understanding of where data was stored and how it should be handled.

Conferences and vendor demos

Graham encouraged guild members to attend conferences and events run by companies demonstrating their latest AI developments. The purpose was twofold: to build genuine excitement about the possibilities across the business, and to give Graham better intelligence about what the team saw as having real potential versus what looked impressive but would not deliver. It also helped test new tools and approaches against the specific culture and working context of Mimecast, which not every tool survived.

For vendor demos, Graham made a point of bringing people together across functions. He would typically invite someone from product management, someone from design, and someone from engineering to attend together. This was deliberate: shared exposure to new capability created shared context, and it meant that conversations about whether to trial a tool happened between the people who would actually use it, rather than being filtered through a single function's perspective.

During this period Graham was invited to join the AWS AI Trailblazers programme, a peer leadership forum for senior practitioners working through the real challenges of AI adoption. Conversations ranged across design, engineering, and product leadership, and included CEOs working through the same questions at an organisational level. The discussions around data sovereignty, regional data privacy regulation, and how to scale AI responsibly across international operations were directly relevant to the work Graham was leading at Mimecast, and fed back into how the guild approached tool trials and data handling questions. It was a useful reminder that the human and organisational challenges of AI were not unique to one company or one function.

The guild was not a structure imposed from above. It grew from a shared enthusiasm for new technology and a genuine collective desire to improve things for customers. Designers, product managers, engineers, and customer-facing colleagues all wanted to try new ideas and sample new ways of working. The guild gave that energy a home and a direction without trying to prescribe what the outcomes should be. It was deliberately open, exploratory, and willing to abandon what did not work.

One of the clearest practical results was a shift in how designers and product managers worked together. When PMs could prototype their intentions quickly in Figma Make, designers could understand the thinking behind a brief far more clearly. PMs were conscious that they did not want to determine the final solution, but the visual exercise helped them work through their own thinking and helped designers engage with the intent rather than interpreting a written specification. That kind of shared exploration removed a layer of friction that had existed since the start.