We live in a society that inherently teaches us very early in our lives that we have to become specialists. Most of us are familiar with this logic because it starts when we’re young. The way to job security and a rewarding career is to get very, very good at one very specific thing.
While there’s nothing wrong with specialty, in most modern software development environments, an overly strict focus on specialization can stifle innovation and experimentation. Becoming innovators and building excellent products can often mean changing how you structure teams, especially in how you define roles.
IT role matrices exist because they were a holdover from the days of physical manufacturing. While some specialization is still called for in the physical world, the more diversity of experience and perspectives you have on a team typically means that you solve problems, and build products, a whole lot faster.
When IT was still porting methodology over from manufacturing, management had a tendency to treat people as “resource pools.” Leadership assessed all the resources they needed for the thing the company built and pulled in those resources based on where they determined they were light on capacity.
As your product scaled, you’d hire more resources. This resourcing methodology went hand in hand with the “project” style of workflow (especially waterfall), which identified start and end dates, as well as what resources you needed to get that project completed. The entire process relied heavily on estimates and domain experts (usually a project manager), who would of course identify which resources (and how much money) were needed to fund and build the project within that timeframe.
However, in more modern workplaces, we no longer use the term “resources” to refer to people, or at least we shouldn’t. In reality, in the knowledge work world, this staffing and funding model instantiates—and all but guarantees—bottlenecks into your process.
Let’s say you have a pool of analysts you need for this work. They’re going to be serving a number of projects simultaneously, constantly context-switching throughout all of them. From there, the project jumps onto the next pool (like the developer team) and so on.
When something goes wrong, the project doesn’t go forward to completion. It goes backward to the last resource pool. They’re usually already on to something else, and there’s a good chance they’ve completely forgotten the original context for the work they did on this project to begin with.
The cycle becomes one of constant context-switching, and projects get further and further away from deadlines based on the initial scope.
The answer to the problem of context switching was to adopt different agile-like frameworks, including Scrum. Shorter sprints made it tougher for projects to drift further away from the original scope. The logic went: How much can you get off track in two weeks?
However, another understandable trend developed. A number of concurrent Scrum teams also focused on a single project, which furthered siloes and component-based project mentalities. The most common source of that bottleneck? The handoff between development and testing. Development could take a couple of days, whereas testing could take weeks.
The testing backlog would get bigger and bigger, especially if testing is over-utilized. But the developers keep throwing more stuff over the wall. The development team has no idea why their work isn’t making it to prod, or even what’s wrong with it, but work still isn’t getting done on time.
The backlog, and frustration, grows and the entire organization blames the system instead of looking at the right problem. Sprints aren’t the issue. The separation of people from delivery could be.
When you take a look at all the skills (and not humans) you need to get work finished and put those skills on one team, you at least start to move away from this foundational issue.
Let’s say, for example, that you group an analyst, a tester, and a developer on one team and they get to work side by side. The obvious advantage is they know what the other ones are doing. The challenge is that you’re still structuring handoffs that can become bottlenecks within the same team.
What if, instead, a developer finishes their work and then asks the question: “What can I do now?” Maybe that developer can help QA work that still needs to be tested. If that person is a front-end developer, they (reasonably) assume that they can shift some of their time to learn what the back-end developers are doing.
Both Scrum and Kanban incentivize people to pull work across the finish line because the team is encouraged to finish the work already committed to or in progress before pulling new work. In organizations that allow it, this T-shaped approach has a history of saving time and money, and giving people more control and say over how they spend their time.
Role-based siloes include a lot of skills. Let’s go back to our developer example. Traditionally, middle-layer and front-end developers are specialized. Earlier in the century, if you were a talented UI developer, that became your specialty. On the software side of things, the trend (over the course of the past couple of years) is moving away from that.
About 90% of the time, knowledge work doesn’t require skill specialists. Cultures that empower generalist specialists (craftspeople who are very good at a couple of things, but mostly good at a lot of things), are seeing better results at sustainably delivering sprint over sprint.
If you have very deep knowledge of one subject (maybe far better than anyone else in the company or at least on the team), even if the team doesn’t always need that specific expertise, the team always has work that needs to get done. Deep-knowledge people may like their jobs a whole lot more if they can look around and answer the question. “What’s the most valuable thing I could be doing for the team right now?”
A good java developer could pick up some other work if java development isn’t needed in the current story. If an analyst is overloaded (or the team doesn’t have a dedicated analyst), there’s an opportunity for our java developer to roll up their sleeves and dig into something completely new.
Then the slider moves from groups of individual contributors on temporary teams to groups of problem-solvers who want to help the team succeed. At that point, roles start to fall away. We still have things in the process of delivering that need to get done, stories need to get refined, developed, and tested.
But you no longer have dedicated people who are only going to do those things.
This can be tough in organizations that are staffed with specialists. With dozens (or even hundreds) of bottlenecks, and work still going to individuals, those people can often be protective of their specialty.
Career paths take decades to build. If leadership says, “I just want people to learn other things and see what else interests you,” career specialists often hear that their job is in jeopardy. Not everyone looks forward to becoming a novice again.
People new to the career don’t have the same set of expectations and may in fact anticipate flexible skills as a part of any modern engineering career. How do you convert the rest of the folks who are concerned that they’re being set up to fail?
Failure needs to be permitted, as well as expected. We often say at Sketch that leadership has to prioritize safety. So the organization basically has to say, “Oh you’re definitely going to screw this new thing up. And it’s fine. In fact, go right ahead.”
It’s up to leadership to grow a culture of psychological safety where people are safe to fail.
Traditionally, a firewall resides in either networking or security, and they don’t give away permissions due to the risk that comes along with it. Role-based permissions are there for a reason: No one wants to see the company come crashing down, let alone be the reason it did.
For the T-shaped skills model to move forward, you need to start giving access to the people who need it, not just those who are used to having it.
This is a give and take, defined by bigger and smaller battles. Getting access to production is the mother of all hills to die on. Who gets access to the lower environments (development or testing) could be a smaller step and an excellent way to build success.
Companies moving toward a DevOps approach often transition this way. They could start out with a single DevOps team, and that team can build an infrastructure that everyone else can use. Quick-release pipelines or high-availability failover create enough boundaries to enable safe and non-impactful learning.
The number of companies that are hiring “specialists” is diminishing rapidly. Transitioning to a T-shaped skill model is going to take time. Remember, the goal is to deliver high-value products better and do so by eliminating bottlenecks. One way to get there is to take baby steps. Maybe a front-end developer starts learning more about testing. Testers and analysts trading skills back and forth is an excellent place to start.
A bigger extreme is to take away all roles and titles, and just call everyone team members. This is extremely disruptive, and it can be a bit extreme for some folks, especially the people more advanced in their careers. However, others could flourish. I once saw an analyst who had never written a line of code evolve into a full-stack developer in a similar situation. That started with another developer turning to her and saying, “Want to see what I’m doing?” Before long, she was one of our most engaged and passionate rock stars.
Professionals who prefer rigid boundaries, or who have worked at companies with subpar (or misnamed) agile and Scrum transformations, may bring some baggage with them. It’s best to honor those experiences and invite them to discuss them openly. You never want to discount people’s needs or experiences.
This is where context is everything.
Even if someone has had a bad experience with Scrum, agile, or Kanban, becoming a T-shaped person is more about answering the question, “Do I want to learn anything else in my career, or am I done learning?” Very, very few people of working age ever give up the desire to pick up new skills. Once you frame the conversation as an opportunity to learn again, the discussion becomes about having an adventurous, exciting, dynamic career.
Leaders need to give people the environment to succeed. Build the sandbox for your teams to play in that allows them to be successful.
If you’re on a function-based team, you’re only going to be able to grow within the bounds of that team. Regardless of your role or expertise, if you are given that sandbox: Explore it. Take up that mantle yourself and become an explorer.