Team-based organizations vs. role-based organizations

I had a conversation with a friend of mine this week about how to structure teams in an IT department, the main question being do you align reporting structure by roles or do you have everyone on a team report to the same person regardless of role. It was a good conversation, but I kept thinking about it more for a couple days, so here I am writing about it.

Just to illustrate, here are pictures showing the two approaches:

Role-based org chart:

Team-based org chart:

(We were discussing IT departments with 80-100 people, with teams generally around 5-10 people. Things are a little more complicated in larger IT departments, but some of the arguments I lay out here likely still apply.)

Here is the question – if you have a team-based structure where inevitably several team members will be reporting to a manager who doesn’t come from a background in their discipline (e.g. BAs reporting a manager with a development background), how do you accurately evaluate, train, and mentor those team members?

I was say that those can be valid concerns, but I would also say that there are more important considerations.

One goal

The problem with the role-based structure is that now team members are forced to choose between two masters – their team leader and their boss. Many times everyone is aligned and this isn’t an issue. But happens when people have to choose? For example:

• QA is behind, so the team lead asks if a developer can pitch in and help test. QA lead on the project is nervous because they feel like as a QA person they are responsible for quality, and they’re worried about getting in trouble with their boss if things get out the door with bugs because the developers that were helping with testing missed something.
• Developers want to start writing more unit tests and the team collectively agrees, but the dev manager thinks unit testing is a waste of time.
• Developers offer to automate some of the testing for QA so that QA can skip some really difficult, time-consuming manual tests. QA people are skeptical because they are sure that they’re boss will be OK with it.
• The team feels like they can solve a certain problem faster by just coming together to solve the problem with less (or no) written requirements from BAs. BAs are worried that their boss will see the requirements and think they aren’t doing their job correctly.
• Team members can’t agree on the best way to do something, and while a team leader would like to break the tie, team members won’t change because they choose to align with their boss instead.

Regardless of discipline, everyone on the team should have the same goal – delivering great software that solves the right problems. In a team-based structure, it’s much easier to put the goal over your role.

Communities of practice

The concern about people reporting to managers in a different discipline is a valid one. That being said, I’ve reported to several non-technical project manager types and it never bothered me. If you ask a team leader how well people on their team are producing, they’ll know who is good regardless of role. Also, if you manage people but you’re not a member of their team, how well do you know what they’re doing? (I have some people like this that report to me, and the answer is I honestly don’t really know that much other than things I hear second-hand.)

Also, when you think about the people who taught you the most in your career, how many of them were your direct manager? I’ve learned a lot from some of my managers, but probably more from other team members and other people at the company that I worked with. In many cases, employees are often better at their discipline than their manager (who doesn’t do it all day and has different kinds of job responsibilities as a manager).

One thing you can do is set up “communities of practice”, which are groups of people in the same discipline that get together to share ideas. This is a good idea anyway — it gives people an opportunity to learn how other teams are doing things so that they can learn from each other and collectively get better. I’ve seen this done for everything from QA, Scrum masters, architecture, automated testing, and various JavaScript frameworks.

Encourage learning

In my opinion, we shouldn’t just encourage learning, we should require it. Technology changes so fast, and it’s a challenge to keep up. I’m surprised how many companies don’t have any training programs for their employees.

If you want people to value learning, help people find learning opportunities, pay for them to attend conferences (and don’t make them use PTO), and even require people to spend a certain amount of time in training/learning as a part of their job (during work hours). Not only does this keep people up to date, good employees will appreciate the investment in their career.

Train people well enough so they can leave, treat them well enough so they don't want to http://t.co/QHONOZYXEy

— Richard Branson (@richardbranson) March 27, 2014

Continuous learning is a good thing, and it has nothing to do with who someone reports to. So even if someone is reporting to a person who doesn’t share their discipline, they’re still honing their craft.

Standardization is the enemy of innovation

There is an idea out there that once we find out the “right” way to do something (whether it’s a certain tool, home-grown framework, template, etc.), we should roll it out to everyone so that everything will be done in a standard way that follows “best practices”. This reduces the chances of failure, and allows employees to be moved around to different teams and not face a large learning curve because things will be done in the same way. Most IT departments will “standardize” at some level (e.g. “we’re a .NET shop”), and things like that are good for consistency’s sake, but that’s not the level of standardization I’m referring to here.

The pace of technology is changing faster than ever, and the only way companies can keep up and survive is innovation. Striving for standard methods is the opposite of innovation — it tells people that they’re not allowed to find new, innovative ways to solve problems, because it’s more important to follow the standards, even if the standards are outdated or don’t work in their situation.

Often times the standardization comes from role-based managers who roll out their standards for how their people do their job. Not that there isn’t good information that comes from these managers, because often times the information is good. But every team is different, and every project is different. The way you test a high traffic public website is way different from how you would test a mobile app on multiple platforms, an internal app doing back-end transaction processing, or reporting solutions. Good teams will come up with innovative ways to solve problems, and will figure out what makes the most sense for their situation.

Putting teams first

One of my favorite principles from agile is the idea that you try to keep teams together, and then bring projects to teams (rather than assembling teams for projects). If your organizational structure mirrors your team structure, this gets a lot easier. If you shuffle your teams around, you inevitably have that one guy that is too important to take off support for a system, so he has to split time. You end up with systems that were developed by teams that no longer exist, so the support structure is missing. You lose all of the cohesion and camaraderie that a team builds up over time.

I’ve been on teams where the core of the team had been together for a long time (years), and those teams ran so smoothly. We all understood our process, we knew how each other worked, and we got really good at working together to solve problems with just the right amount of process. The team didn’t need a lot of oversight because we all knew the agreed upon way to work. But the best part was that these people became really close friends of mine, and I’ll still keep up with them even though I’ve moved on.

More of what works

There’s no one right way to do anything, and there will be situations where my arguments don’t apply. But no matter what your environment is, I always strive to do more of what works and less of what doesn’t, and we all need to keep innovating.