software solutions / project leadership / agile coaching and training

Team-based organizations vs. role-based organizations

Posted on April 7, 2018

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:
role-based org chart

Team-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.

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.

3 Comments »

  1. Agree re standardisation, but I think having a default “here’s how we do things unless you have a reason not to” method is good. This stops people needlessly reinventing and spinning wheels (and moving projects/teams easier), but gives the freedom to innovate when the standard language/framework/tooling doesn’t work.

    Darrell Mozingo — April 9, 2018 @ 7:02 am

  2. [...] Team-Based Organizations vs. Role-Based Organizations [...]

    Professional Development 4/09/2018 – 4/15/2018 – The Software Mentor — April 16, 2018 @ 9:22 am

  3. [...] Team-based Organizations vs. Role-based Organizations (via The Software Mentor) [...]

    Professional Development – 2018 – Week 16 – Geoff Mazeroff — April 23, 2018 @ 12:12 am

Leave a comment





SERVICES
SOFTWARE SOLUTIONS
I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
PROJECT LEADERSHIP
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
PROCESS COACHING
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
PRESENTATIONS
Ditching the Office - How an everyday corporate development team turned into a remote working team
From Stir Trek 2018
From Stir Trek 2017, cbus.js 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010