How to set up a team structure in an Organisation

“How does products gets successfully delivered?”

“By the team members who worked on it, of course!”

You may think, what a stupid, trivial and impertinent question it was

The truth is, teams aren’t a set of people randomly grouped based on skillsets. To build a product, you would need multiple teams coming together, aligning on API contracts, building independently and then integrating and releasing together or separately based on the software architecture

Now if you are tasked as the CXO to start with a clean slate and set up a team structure in an organisation of 200 engineers, how would you go about it?

Sit back and think deeply, we often take the organisation structure for granted. Most people have got into an organisation which has an established structure and you work along the existing guard rails

So coming back to the 200 headstrong engineers, how many teams would you have?

Just one team of 200 engineers? Surely no! How would you differentiate responsibilities on who builds which part of the system

Shall we just split into 20 teams of 10 members, because somewhere you’ve read about the magic Dunbar number? Huh, but we still have the same problem that we faced with the 200 engineers in one team. So this too doesn’t solve the problem

Let’s take a step back and consider, what principles should we consider while defining the team structure?

Principles for Team Structure

Lets take a leaf from good software architecture and apply them to team structure

• The teams that we form should have high cohesion. That’s a fancy way of saying, group related things together
• The teams should also have loose coupling. This means, we need a structure where everyone needn’t have to talk to everyone else. There should be clear boundaries and as little communication as necessary, for each team to produce their work
• The cognitive load on the team should not be high. Cognitive load is the amount of working memory a team needs, consider it similar to a RAM

Fine, so what framework can you apply to decide on the team structure?

“Wait a minute, are there multiple frameworks?”

Team Structures suggested in PMP

If you have done your PMP, you would be familiar with these team structures

• Functional
• Projectized
• Matrix
  • Strong
  • Weak
  • Balanced

Lets quickly understand them before looking into software specific structures

Functional Structure

This is commonly found in traditional as well as many new age organisations. Here you group based on areas of specialisation i.e. Finance, Sales & Marketing, Development, QA, etc. Most communication happens within each function

Projectized Structure

In this structure, you organise the whole company based on projects. Once a project is over, people are assigned to another project. The communications in this structure is primarily within each project

Matrix Structure

The matrix is a combination of the functional and the projectized structure. In this type of structure, the team members report to the functional manager as well as the project manager. The communication happens at both levels. Based on who has more control i.e. the Functional Manager or the Project Manager, Matrix is divided into the following

• Strong Matrix: control remains with the project manager
• Weak Matrix: control remains with the functional manager
• Balanced Matrix: control is balanced between project & functional manager

Conway’s law

Does organisation structure influence teams? Conways law throws in light on this

What this means is, the software architecture will mimic the organisation structure. You would find software boundaries around the teams that you have formed. So rather than the most optimal architecture, you would find teams defining architecture to suit their team structure

Conway advises us that we need to understand what software architecture is needed before we organise our teams

How should a software team look like?

As per the authors of Team Topology, they suggest four types of team structures considering the cognitive load for a team as well as reducing the load on communication

Stream aligned teams

A stream aligned team is a focussed team which is working on delivering a product or a service or a feature. Their main focus is in building something meaningful and releasing it quickly to the market

The other three types of teams, work towards reducing the load on the stream aligned teams

Platform teams

A platform team is focussed on building capabilities which the stream aligned teams can use and re-use

Therefore any common capability that maybe needed as part of your product or products would be a good candidate. Identifying & building the right set of services for a platform will help the organisation save cost in the long run as well as speed up deliveries of stream aligned teams

Complicated subsystem teams

Complicated subsystem teams are those teams which require specialised knowledge

The goal for a complicated subsystem team is to reduce the cognitive load on the stream aligned teams when their services need to be used

Enabling teams

Enabling teams are specialists in an area who help in bridging the capability gap. The goal of this team is to guide the stream aligned teams and eventually make the stream aligned teams self sufficient

Summary

After reading this article, you should be in a fair position on understanding what aspects needs to be considered when defining an organisation structure as well as some of the frameworks that are available

I will separately discuss the different team interaction modes in a separate post

If you would like to dive in deeper, you ought to read Team Topologies. You can also read my other posts on teams such as 5 traits to get the best from your Agile team, How to ensure team commitments are honoured by Agile teams

If you liked this post, do comment & share and signup to my newsletter