The case for hiring as a pair
Something I've noticed in almost every team I've worked in: most companies still hire developers and designers as if they were two completely separate species. Different job descriptions, different interview loops, different goals to chase by the end of the quarter. The result is what you'd expect — two opinions on every screen, a Figma file that no-one ever quite implements accurately, and a weekly meeting about whose responsibility the empty state actually is.
I've not actually worked anywhere that does it differently, but here's what I think might work: treat the designer and the developer who'll own a given feature as a single hiring decision. Find the pair, then trust that the pair knows what they're doing. The hard part, I suspect, wouldn't be finding the pair. It would be letting go of the assumption that they'll match what your job descriptions said you wanted in the first place. They probably won't, and you should be quietly pleased about that.
The closest I've come to it
I've not had the chance to be hired as part of a duo, but I have had the next best thing. For five years straight, one of my best friends was the designer I worked alongside. We weren't hired as a pair — we just happened to land in the same team, and from there things clicked.
The shorthand we developed was the kind of thing that's almost impossible to write into a job description. He'd send me a Figma frame and I'd already know which transitions he wanted, even when he hadn't drawn them in. I'd push back on something in his spec and he'd already know whether I was raising it because of a technical constraint or because I thought a different solution would feel better. We argued constantly, and almost none of those arguments needed to escalate to anyone else, because we were both arguing toward the same outcome from different angles.
We were, in our own quiet way, a force to be reckoned with. Features we owned together went out cleaner and faster than anything I'd worked on before or since. The handoff that other teams treat as a process didn't really exist for us — there was no handoff, just two people working on the same thing from two angles, in sync.
What it suggests about hiring
The reason I think hiring as a duo would work is that what made that five-year stretch good wasn't the tools we used, or the framework we built in, or any organisational pattern. It was the relationship. We trusted each other's judgement. We had different specialities but a shared sense of what good looked like. And we both got to a point, fairly early on, where we'd stopped having to translate.
If that's the thing that makes a pair productive, and from where I'm sitting it really is, then the most expensive thing a company can do is hope it happens by accident. Putting two random people in the same standup and crossing your fingers is not a strategy. The relationship is the asset, and you can't manufacture it after the fact. You can only hire for it.
Which means the interview loop has to change. The candidate isn't an individual you assess against a job description. It's a pair you assess against the work you'd actually give them. You'd want to see them disagree about something small in front of you. You'd want to know how they resolve it — whether by power, by precedent, or by genuinely changing each other's minds. The latter is rare, and worth a lot.
The hard part
I'm not going to pretend this would be easy. Most companies don't even have the headcount flexibility to hire two people for one role, let alone the institutional patience to wait for the right pair. HR systems aren't built for it. Career frameworks assume individual progression, not joint contributions. And if the pair falls apart for any reason — one person leaves, they fall out, life happens — you're left with half a duo and the other half wondering what their role was supposed to be.
These aren't reasons not to try. They're reasons the companies that figure this out first will probably do it quietly, and probably do it for senior hires first, where the cost of a mismatched pair is high and the value of a working pair is highest.
If you've tried this
If you've actually tried hiring this way — at any scale, with any seniority — I'd genuinely like to hear how it went. Whether it worked, whether it didn't, what you'd do differently. I'm proposing this as the next thing I'd want to try if I were running a team, but I'm not under any illusion that I've thought through all the corners. If you've thought through more of them than I have, the contact form is right there.