I have a confession. For years, I thought the problem with job titles was that they were too narrow. "Developer." "Architect." "Security engineer." Too specific, too constraining, too much like putting a label on someone and expecting them to stay inside it.
I was wrong. The problem isn't that job titles are too narrow. The problem is that organisations use job titles as a substitute for understanding their own landscape. They don't know which capabilities they need, at what evolution stage, with what dependencies - so they buy a label instead. "We need a developer" is like saying "we need a plan" when what you actually mean is "we have no idea what's going on." It sounds purposeful. It's actually a confession of ignorance.
Meredith Brooks sang "I'm a bitch, I'm a lover, I'm a child, I'm a mother" in 1997 because the world kept telling women to pick a lane. The Ting Tings shouted "That's not my name!" in 2008 because the industry kept mislabelling them - Katie White said the song was about feeling transparent, invisible. And here we are, decades later, doing the same thing to engineers. "You're a developer." But they're also doing security reviews, talking to users, and debugging production at 2am. The label doesn't fit because it was never designed to.
This isn't a complaint about HR taxonomy. This is a strategic problem. And like most strategic problems, it starts with a failure of situational awareness.
The landscape we've built
The history of computing roles follows an evolution curve - things moving from novel and uncertain to standardised and well-understood, the way electricity went from Faraday's experiments to a wall socket.
In the beginning - genuine genesis, where everything is new and nobody knows the rules - there were no job titles because there was nothing to title. Margaret Hamilton didn't call herself a "software engineer" as a pre-existing category. She coined the term because the work demanded a name. Hopper, Turing, the lot - they were mathematicians, engineers, operators, and programmers simultaneously because computing was too uncertain for specialisation.
Then came the NATO Software Engineering Conference in 1968, which recommended engineering discipline. Reasonable enough. But the industry heard "assembly line" and built role silos. Royce's 1970 paper was arguing against sequential phases - his famous waterfall diagram was a cautionary example, not a recommendation. But organisations took the diagram and ignored the argument. They wanted neat boxes. They got neat boxes.
As work evolves from genesis through custom-built to product to commodity - becoming progressively more standardised, better understood, more repeatable - the roles specialise. Testing becomes a separate function. Operations splits off. Security gets its own department. Architecture becomes a title rather than an activity. This is natural evolution. It's not wrong. But here's what most organisations miss: not everything is at the same evolution stage simultaneously.
Some of your work is still in genesis. Your AI experiments, your prototype integrations - these need people who contain multitudes, who think like Hamilton. Other work has commoditised - well-understood, repeatable, utility. Your deployment pipeline, your monitoring, your standard infrastructure - these benefit from specialisation, from people who drive efficiency.
The problem is that the org chart treats everything as if it's at the same stage. One set of job titles. One career ladder. You're a "developer" whether you're exploring a genesis-stage AI prototype or maintaining a commodity deployment pipeline. That's like having one military strategy for both the reconnaissance mission and the supply depot. It's bonkers.
The T-shaped trap
Now, someone clever will immediately say: "But Chris, that's why we have the T-shaped model! Deep expertise in one area, broad knowledge across others." And it's a reasonable point. The concept dates to 1978, was popularised by IDEO's Tim Brown, and has been in management vocabulary ever since.
The problem is that T-shaped is a static metaphor applied to a dynamic reality.
A T-shape freezes you. One vertical stroke of depth. One horizontal bar of breadth. But people aren't typographic characters. They evolve. Adam Smith's pin factory showed that specialisation multiplies productivity - ten workers making 48,000 pins a day instead of ten pins each. But Smith himself warned that extreme division of labour renders a worker "as stupid and ignorant as it is possible for a human creature to become." The father of specialisation was terrified of what specialisation does to the people inside it. The T-shaped model inherits exactly that problem: it optimises the shape of the person for the convenience of the organisation, not for the reality of the work.
Kent Beck's "paint drip" model is closer: depth happens where the work takes you, not where HR predetermined it. Martin Fowler's piece on "expert generalists" argues for something more fluid still - people who cultivate "a rough, perceptive sense of what works in a new environment."
Here's the mapping insight that neither the T-shaped advocates nor their critics seem to notice - what I'd call shape-stage fit: the shape of the person should match the evolution stage of the work. At genesis - novel, uncertain, no established rules - you need people who can do everything. Pioneers who thrive in ambiguity, who can research users in the morning and write code in the afternoon and argue about security models over lunch. At commodity - standardised, well-understood, utility - you need deep specialisation that drives efficiency. The decision rule is simple: broad for genesis, deep for commodity. Arguing about T-shaped versus comb-shaped versus paint-drip without this context is like arguing about build versus buy without knowing the evolution stage of the component. It's context-free prattle.
I know an engineer - Priya - who spent three years as a "senior developer" at a mid-size fintech. On paper, one role. In practice, she was the person the team called when the AI recommendation prototype needed someone who could talk to the data scientists AND rewrite the front-end AND present the trade-offs to the product lead. Genesis-stage work, boundary-crossing in every direction. She was brilliant at it. Then a restructure moved her into a newly created "Platform Engineering" team - commodity-stage infrastructure, clear boundaries, deep specialism expected. Her performance reviews cratered. Not because she'd got worse. Because the org chart had mapped her into an evolution stage that didn't match her shape. Neither "developer" nor "platform engineer" described what she actually did. The map would have.
Conway's Law is eating your people
There's a deeper structural problem, and it's got a name: Conway's Law. "Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure." Melvin Conway wrote that in 1968. It's still true. It's doctrine - a universal principle that works regardless of your specific situation.
What this means for job titles is devastating. Your org chart doesn't just describe your people - it constrains your architecture, and your architecture constrains what your people can do. If you have separate "frontend," "backend," and "infrastructure" teams, you will build systems with those exact seams.
I've watched this mismatch break good engineers. Not in dramatic, visible ways - more the slow erosion of someone who knows they're capable of more but whose environment keeps telling them to stay in their box. You don't always see the damage on the map. Sometimes you see it in someone's eyes during a one-to-one.
The inverse Conway manoeuvre - deliberately designing your org structure to produce the architecture you want - is gameplay, not doctrine. Gameplay means the deliberate moves you make based on your specific landscape; what works for you may be rubbish for someone else. Team Topologies suggests stream-aligned teams that own broadly within bounded domains, with platform teams absorbing complexity. Good gameplay for many contexts. But Valve tried removing job titles entirely and got invisible hierarchies and Lord of the Flies dynamics. Amazon's "you build it, you run it" worked because they paired broad ownership with single-threaded accountability. The Spotify model doesn't even work at Spotify.
Context is everything. The same organisational design produces different outcomes in different landscapes. This is why copying what Google does is usually rubbish advice. You are not Google. Your landscape is not Google's landscape. Their gameplay is theirs.
The privilege that nobody maps
And here's something I don't see mapped nearly enough: the landscape of who gets to cross boundaries - and how that maps onto evolution stages.
The data is clear: sixty-one per cent of women engineers report needing to repeatedly prove their competence. Seventy-one per cent of women of colour experience "prove it again" bias. When someone says "just cosplay other roles, learn broadly, contain multitudes" - that advice assumes you have the social capital to cross boundaries without being questioned. For many engineers, stepping outside their job title isn't exploratory - it's risky. They're not just learning new skills; they're fighting for the right to use skills they already have.
Here's where evolution makes this worse. At commodity-stage work - well-defined roles, clear boundaries, legible success criteria - the cost of crossing a boundary is lower because everyone can see what competence looks like. But at genesis - where the work is ambiguous, the roles are undefined, and "containing multitudes" is the job - the social capital required to cross boundaries is highest. The evaluation criteria are subjective. The gatekeeping is invisible. The people who most need to operate as Pioneers are the people most likely to be pushed back into their lane. The "boundaryless career" is, as the research shows, a privilege that maps onto exactly the evolution stages where it matters most.
Google's Project Aristotle found that psychological safety - not team composition, not individual talent - was the strongest predictor of team effectiveness. You can't broaden roles without safety. You can't create safety without awareness. You can't have awareness without mapping the actual landscape, including the uncomfortable bits.
Stop redesigning the labels
I'll tell you what you don't do: hire a consultant to redesign your job titles. That's a context-free solution to a context-dependent problem. The job titles aren't the disease. They're a symptom.
I might be completely wrong about your situation because I don't have your map. But start here:
Map your work by how well-understood it is - shape-stage fit in practice. Take your team's backlog. The items where you know the answer and you're just executing - that's commodity-stage work. The items where nobody's sure what the right approach even is - that's genesis. You'll disagree about where things sit. That argument is itself the point - the map is the conversation, not the artefact. Now look at who's assigned to what. If your most creative, boundary-crossing engineer is maintaining your CI/CD pipeline while your most process-oriented specialist is being asked to prototype an AI feature, you've got a mismatch that the job titles are hiding. Do this exercise with your team leads next week. It takes an afternoon. The mismatches will be obvious.
Reorganise for architecture, not fashion. Don't restructure because you read about Team Topologies on an aeroplane. Restructure because the system you need to build requires a different communication structure - that's the inverse Conway manoeuvre, and it's gameplay, not doctrine. Before you move anyone, map the architecture you want, then ask: does our current org structure make that architecture possible or impossible? If you can't answer, you don't know your landscape well enough to reorganise.
Audit who actually gets to cross boundaries. Not who theoretically can - who actually does, and who gets questioned for trying. If the answer correlates with demographic factors, you have a situational awareness problem masquerading as a job title problem. Yes, switching costs are real - eighty-three per cent of developers report burnout. But the answer isn't to lock people in silos. It's to match the breadth of the role to the evolution stage of the work, and make sure the opportunity to operate broadly isn't gated by who you are.
Start with one team. FIST: Fast, Inexpensive, Simple, Tiny. Pick one team. Map their work across the evolution axis. See where people's capabilities don't match the evolution stage they've been assigned to. If the mismatches surprise no one, either the team already has situational awareness or the mapping was too shallow - go again. Cross the river by feeling the stones.
The Stack Overflow 2024 survey shows that developers already identify with seven or more roles beyond their primary title. The people contain multitudes. They already know it. The question is whether your organisation has the situational awareness to use what they know - or whether you're still playing chess without a board, moving pieces labelled "developer" and "architect" around an invisible landscape and wondering why nothing ends up where you expected.
Walt Whitman wrote it in 1855: "Do I contradict myself? Very well then I contradict myself, (I am large, I contain multitudes.)" Your engineers contain multitudes too. The question isn't whether they do. The question is whether you can see it. And you can't see it without a map.
At least with a map, when you get it wrong, you can see WHERE you got it wrong. Without one, you're just relabelling the boxes and calling it transformation.
Where's your map?
(Views in this article are my own.)