Embedded vs centralised: design, data, QA, security

Every specialist function in an engineering org gets asked the same structural question, and it gets answered by whichever failure the company most recently experienced.

Centralise them and you get coherence and a queue. One design team, one QA team, one security team, consistent standards, and a waiting list. Product teams learn to plan around the delay, which mostly means asking later and accepting whatever comes back.

Embed them and you get speed and drift. The designer sits with the team, sees the problem as it forms, ships. And after a year you have four design languages, three testing philosophies, and two answers to how authentication should work, plus four specialists who are each professionally alone.

Neither failure is acceptable. So the model I run is a guild: embedded day to day, with a centralised community that owns the standard.

What the guild actually is

The specialist reports into the function or into the team, depending on your size (below fifty, into the team is usually simpler), and works with one product team full time. That team is their home. They're in the standups, they see the problem being framed, and their loyalty in the day to day is to shipping that team's work.

The guild is the horizontal layer, and it's a real thing with real ownership rather than a monthly coffee. It owns the standard: the design system, the testing approach, the security baseline, the definitions in the data model. It reviews work across teams for coherence. It sets the bar for hiring into the function and does the hiring loops. And it's where somebody goes when they're the only person in the building who does their job and they're stuck.

The key mechanic: the guild has authority over the standard and no authority over the schedule. Nobody waits on the guild to ship. The guild says what "good" is here, and enforces it through review and through the shared assets it maintains, not through a gate.

That split is what keeps both failure modes at bay. Drift is prevented because the standard has an owner. The queue never forms because the standard's owner isn't in the delivery path.

Function by function, because they aren't the same

The general model needs adjusting per function, and the differences matter more than the framework does.

Design. Embed hard, and early. Design's leverage is upstream, in framing the problem, which means the designer has to be present when the problem is being defined rather than receiving it afterwards. Centralised design ends up as a service desk producing screens for decisions that were already made. The guild half matters a lot too, because a shared design system is the single biggest engineering accelerant design produces, and it only exists if somebody owns it across teams.

Data. Split by kind of work. Analytics and instrumentation want to be embedded, because the questions are product questions and the person needs to know the domain. The data platform (pipelines, warehouse, definitions) wants to be central, because a metric that means two different things in two teams is worse than no metric. The most valuable central artefact is the definition of what a "user" is, agreed once.

QA. This is the one where the standard model has changed most, and I'd be careful. A central QA team that tests other people's work at the end is the version I'd never build: it separates the writing of a bug from the finding of it by two weeks and a department, and it lets engineers stop feeling responsible for quality. The useful model is embedded quality engineering, where the specialist builds the testing capability the team uses, and a guild that owns the overall strategy and the tooling. Testing is covered properly in its own lesson.

Security. Almost the opposite of QA. The standard has to be central and non-negotiable because the failure isn't contained to one team, and there's real specialist depth that can't be distributed across five people at ten percent each. Embed for consultation and threat modelling, centralise the controls and the review, and make the paved road carry as much of the compliance as possible so that teams get security by using the platform rather than by remembering to.

The pattern underneath: embed where the value comes from proximity to the problem, centralise where the failure crosses team boundaries.

Hub and spoke, and what it costs

Hub and spoke is the common compromise: specialists sit in teams, report to a functional lead, and the lead holds the standard. It's usually right, and it has two costs worth naming in advance.

Dual loyalty is real. The embedded person has a team that needs them today and a function that wants them to hold a line that slows today's work down. Without air cover from their functional lead, they'll fold toward the team every time, because the team is the group they eat lunch with.

And functional leads become coordinators. Someone managing six embedded people across six teams spends their week on context switching and has no direct output of their own. Some people thrive on it. Many good specialists take that job, discover it isn't the job they wanted, and leave.

The meetings that die first

Every guild starts with a weekly meeting and most of them are dead within four months.

They die because they become status: everyone reports what they're doing, nobody needs the information, and it's the first thing to be cancelled during a busy quarter. Once it's been cancelled twice it never comes back.

The guilds that survive have artefacts rather than meetings. A design system with a real owner and a changelog. A shared testing library. A security baseline document that gets updated when something changes. A definitions repo. The artefact is what does the coherence work, and the meeting exists to make decisions about the artefact.

The other survival trait: a standing review slot where cross-team work actually gets looked at. That's a working session with an output, which people show up to, unlike a session whose output is having attended.

Switching models without whiplash

If you're changing this, change it once and be explicit about which failure you're accepting.

Announce what's moving, when, and why, with the specific problem you're solving. "Design is embedding into teams because we keep receiving screens for decisions that were already made" is a reason people can evaluate. "We're moving to a more agile model" is a reason people will assume is really about something else.

Move the reporting line and the seating and the rituals together. A half-move (embedded in practice, still reporting centrally, still attending all the central meetings) gives you both sets of costs and neither benefit, and it's the state most companies are actually in.

And don't do it twice in eighteen months. The specialists are the ones who absorb the whiplash, they're the smallest population, they're the hardest to hire, and they'll conclude the company doesn't know what it wants from them. They'll be right.