What Forward Deployed Design Actually Looks Like

7 May 2026

I appreciated both Roger Wong and David Hoang’s blog posts about Forward Deployed Design.

Reading them, I kept thinking about my time at 18F, where we employed this model without calling it ’forward deployed.” This operating posture is how most civic technology firms work too, though everyone has their own flavor and some models are more decentralized than others.

There are lots of reasons for how/why we operated how we did — some well documented, others not — but I just want to focus on both Roger & David’s takes on what FDD looks like in practice, because I spent 8 years doing it with 4 of those as Director of a 40-person design division.

The real reasons that design roles aren’t being considered for this is the ways orgs constrain how designers show up on cross-functional teams. If your designers are only good for handoffs, you’re not going to invest in the headcount.

The people are the key, but you have to be opinionated about what you’re looking for your designers to do. If you’re looking for pixel-perfect, portfolio polish then you’re doing it wrong. Due to the quirks of federal hiring rules, we weren’t allowed to consider portfolios. It didn’t mean we couldn’t look at them, they just couldn’t be part of the criteria someone got an offer or not. Every practice had their own take-home assignment or some kind of “talk us through a piece of work” segment as part of a technical interview, but when you’re an org that received 1000s of applications for an open role that only could legally stay open for a week; talent was not the problem, it’s about finding the right fit for the sort of work we were doing.

In the forward-deployed context, that means ability to navigate ambiguity, stakeholder management, low ego, bias toward working in the open and collaborating. The other big thing and I’ll bold this: hired designers who can do more than one thing. Some impressive UX researchers would show up on our doorstep often, and if they talked to me, I’d be very direct with them about how we worked and that our designers often had to wear more than one hat out of necessity. The other constraint? Headcount. Design often has to justify itself more than other practices, so we couldn’t afford people who were too “special” to be staffed to a broad array of partner engagements. What this meant in practice? Designers who could code, researchers with content strategy & information architecture chops, service designers who could lead and/or PM projects, and every designer being a strategist on some level.

This usefulness paid dividends in the form of satisfied customers, happy internal stakeholders who wanted more of [insert their favorite designer here] enabling us to trade with practices who weren’t hiring to broaden our bench at different times/skills.

Our three interview phases were standard parts of the 18F process including a ’core values” and “leadership and collaboration” segment, that allowed anyone across the org to be part of interviews for other practices. I know some companies only let designers hire other designers and I get why, but given how cross-discplinary teams have to be inside delivery organizations, it’s too important not to get broader perspectives. (Plus, it’s a great way to bridge internal silos!)

We operated this way out of necessity, on engagements that started with what we called Path Analysis and moved into Experiment & Iterate — short, problem-scoped, cross-functional deployments that shipped working product, procurement packages, or capability handoffs.

Adjacent skills built the practice. 18F stood up the first service design practice in the federal government by hiring UXers who could flex into service design first. The work proved the value, partner demand grew, and then we hired service designers proper. UX engineering went the same direction. The adjacent skill surfaces the demand and the deeper hire follows.

Designers led projects. They PMed when there was a PM shortage. They were stakeholder-facing and leadership-facing in the same week. The role flexed into whatever the engagement needed design to do.

As I explained in Design as Repair at IxDA Oslo last September: we need designers embedded where problems happened, not downstream after it’s been scoped, broken and all the framing has been done and asked to execute.

Having actually been deployed in the Air Force many moons ago, I think the term applied to software engineering is quite funny. In general though, orgs are leaving money on the table by not figuring out how to maximize design as a force multiplier for their downstream partners.

Great teams develop by building it into the culture, having senior leaders and managers who invest in it, provide the air cover for good work to happen. That translates to wins for ICs who “play free” when they have to upskill, burn extra cycles on a taxing sprint, or need additional internal support.

I build design teams the way a sports team player personnel might, it takes investing in people and putting them in the right places to succeed. Even if it’s a wrong fit forward-deployment, you can still maintain morale and good performance by investing in understanding what your direct reports/skip levels need to thrive.

Admittedly, this is harder as your team scales. But the urge to create rigid hierarchy in orgs with unpredictable outcomes, will probably lead to bad results. Lastly, I’m most proud of how many designers in our org were promoted during my 4 year stint as director, we graduated well over a dozen to senior leadership roles outside our unit. Very often, we had designers who could shapeshift into product manager roles or even engineering roles depending on the scope.

The hardest part about my lens on forward-deployed designers is 1) I saw how it worked 2) maintained a POV about the culture 3) was relentless about promoting the practice’s value, wins & the dexterity of the roles.

Without that kind of evangelism, the type that translates into stakeholder and intra-org education about what different design discipline skills could do for the work, and without the openness of colleagues see that value, you don’t get the full value.

n.b. We rotated people often, it depends on what the role was. The designer had a say too, but this was influenced by needs of the project, timeline & what else we had in the pipeline that fit their skillset. We could be creative about the last part, though.