In the team of the future, roles are verbs, not nouns

If someone asked me to set up a team in charge of software documentation, I would not hire for specific roles or cookie-cut job descriptions. Professions tied to knowledge buckets are bound to shrink or disappear. Instead, I would hire people that could move freely between four quadrants, each defined by the proximity to a focus pole and its skills. The poles in this team setup would be the following: Product Vision, Knowledge Design, Engineering Depth, and Delivery Strategy.

Going from hyper-specialization to generalization

Product Vision would be about owning the design and direction of docs as a product; it’s the house of product management. Knowledge Design is where tech writers, content designers, and content strategists meet. Engineering Depth is the starting point of software engineers and architects. Delivery Strategy is the DocOps and DevOps den, the land of automation, continuous deployment, and quality assurance. Folks would roam between areas, as pictured in this image:

People who move within this framework would be T- or, better yet, underscore-shaped, equal parts humanists and technologists with strong systems thinking. Having a vast map and knowing how to use it would matter more than having deep knowledge of any of the areas, although that could happen naturally and temporarily. Specialization would be fluid and AI-assisted. “I’ll be a dev in the next sprint”, one could say. Nobody would object to it.

Picture a sprint planning session in this team. The Knowledge Designer who spent last month digging into the Kubernetes operator reads the next epic and says, “I can write the controller logic for that. I’ve been living in that codebase.” The engineer who’s been reviewing tutorials volunteers to redesign the onboarding flow. Nobody blinks. The conversation would revolve around what needs to happen. Roles would be verbs, not nouns.

Most people in such a team would have a home quadrant, a pole they’re closest to, where their experience runs deepest. Growth would mean expanding range from that base, becoming increasingly comfortable operating in adjacent quadrants. Eventually, a few would reach the center, to become someone fluent with the four areas, a true generalist with a broad vision of the goal and the ability to juggle all tasks.

In this setting, what would matter the most would be reaching the goal: roles would be pragmatic aspects one would adopt depending on the circumstances. It wouldn’t matter whether things must happen fast or take their time, the view would still be general. The team’s strength would come from overlapping ranges, people whose comfort zones bleed into each other’s territory. Cross-pollination, if you will. Or just pure, unbridled curiosity.

Hire for curiosity, system thinking, and versatility

How would you hire for such a setup? Certainly not by using existing job descriptions, unless you use them as trojan horses. You would, at the very least, bend them to the skills you identified along the dimensions tied to the goal. For example, instead of a software developer, you would end up hiring a docs engineer, or a content designer. You would also make sure to hire against skills.

What you’d look for in an interview is the ability to zoom out. Give candidates a docs problem that spans two quadrants and watch what they do. Do they immediately start writing, or do they ask about the system first? Do they want to know how the build pipeline works before committing to an information architecture? The people you want are the ones who treat the problem space as navigable terrain and don’t say “not my turf”.

In a world where LLMs already have answers, the best differentiator and the most valuable skill is to be able to seek the best unknowns. We need more people who can create the best questions. In the past, we would have called them “philosophers”. Today we could call them “system thinkers”. They’re not unicorns; some probably work with you, waiting for an opportunity to break free.

Documentation is an emergent property of a healthy system

Documentation is best created when one stops fencing crafts and starts letting them roam freely in the same problem space, engaging in fertile discourse. AI here must help team members see the system better, to deepen the knowledge of each part, not to bypass it. Folks must explore, question, and connect instead of supervising and operating LLMs in isolation.

AI augmentation only works when we allow people to cross boundaries and break silos. If we don’t create the teams that allow this to happen, crafts and minds will slowly suffocate while budget cuts provide the merciful blow. Open teams up before it’s too late.