Why most org charts are wrong

Assuming that your tech department has an org chart, it probably goes like this: you report to your team lead, who in turn reports to a middle-manager, and so on up to your CEO / MD.

Let’s draw that up:

A more traditional org chart

So each development team has a lead, who holds overall responsibility for the work of the team. It’s his/her job to make sure that stuff gets done. He/she does ‘performance management’ for the whole team. Upper management know (s)he’s the person to have words with if something goes wrong.

It’s simple enough. It’s the way it’s always been. It kind-of works.

Now imagine having two org charts

Two org charts focusing on distinct aspects of an organisation:

  • a first chart focused on management: who’s managing who, from non-managers all the way up to the CEO / MD

  • a second chart focused on teams: which dev teams currently exist, who their team members are and their roles

Again, let’s draw that up:

Management chart

Team chart

And the point is…

Keeping the management and team charts separate implies a structure where people are not managed by their team lead. This key point, and the two-chart approach in general, has many benefits:

  1. Developers (generally, ‘knowledge workers’) don’t just need a line manager. They want a mentor who can guide them and that they can learn from. That mentor needs to have the right technical knowledge and experience. A team lead cannot have this for his whole team. Is a backend engineering lead best suited to mentor a UX designer?

  2. A developer taking on management is a career change, not a promotion. Developers shouldn’t need to do this to be seen as more senior. Tying up technical leadership with line-management is wrong

  3. At the same time, any developer who is willing to and has the right mindset (broadly: is people-oriented) should be given the chance to try and manage one or two people, and more if it works out. And all managers should have the option to scale back if they need or want to. None of this is possible with an inflexible ‘team lead as manager’ structure

  4. Without a manager-lead, teams become more even forums where everyone is empowered to openly contribute. From these contributions, one or two members may emerge as more knowledgeable or experienced, thus providing creative leadership but without the burden of managerial authority

  5. Having two distinct charts make an organisation much more agile. Teams can be created or disbanded, people can move between teams - all without affecting management lines. Conversely, people can change mentor / manager when needed, without having to move to another team

  6. Focus should stay on what matters most: the teams. Teams are where work happens, where ‘value’ is created - getting teams right is key, much more so than tweaking management lines

Finally, teams should not be limited to a single line manager, or even to a single department. By taking management out of the team chart, you can create genuinely cross-functional teams which span several department (Sales, Operations, Engineering) and turn your (passive, disengaged?) stakeholders into genuine team members who are really listened to and contribute to the team’s efforts.

 

Need advice for your technology business? I can help