Scale Engineering Effectively with Cross-Functional Teams

As companies grow they place ever greater demands on their IT (and/or Engineering) organisations. There are constant requests for assistance, be they from the CMO who is looking to get a better understanding of customers to the customer support team looking to keep costs stable while expanding to 24×7 support. If you’re a VP or Director of Engineering at one of these growing companies this post is for you.

So, how do we approach this problem? What is the best way to grow and scale? To address those questions and more, we need to first determine how to structure our teams. Let’s explore that now.

An IT organisation can adopt one of two approaches when it wants to grow: the functional or the cross-functional team structure. One approach will lead the IT organisation down a path that will enable them to:

  • effectively scale as the company grows,
  • minimise bottlenecks and inefficient exchanges,
  • consistently deliver high quality product to their customers, and
  • maintain a happy and productive workforce

Unfortunately, the other approach will not achieve these goals. Instead you’ll be faced with an IT organisation unable to give an indication of what they will deliver, or when it will be delivered. Your teams will be constantly churning, wasting time and resources. And, they certainly won’t be delivering their best work.

To ensure you’re headed down the right path we’ll explore both approaches and explain why having cross-functional teams is the right approach.

Functional Teams

This is, unfortunately, still a common scenario. Using this approach, the IT organisation builds teams around a particular skillset, be that design, engineering, operations, quality, databases, etc.

Functional Engineering Teams

This is the path most commonly taken as it allows a VP of Engineering or a CIO to find a Director of Design and allow them to build their team. Then that same VP / CIO will find a Director of QA and have them build their team. And so on. Although logical and easier to implement, this approach has many unfortunate downstream consequences.

Fairly soon you’ll find fiefdoms within the IT organisation. Each Director will be building out their team in the way they know best, often in direct opposition to the approach that will enable the whole company to be most successful.

The functional approach leads to barriers being built between groups, often through the use of requirements documents and/or contracts. No doubt you’ll also find significant bottlenecks emerge between groups and people start talking about their people like they are talking about cattle – not fun.

Getting functional teams to operate harmoniously and collectively, while focusing on delivering solutions to meet customer demands is difficult and not at all optimal.

Imagine the value we could unlock with a better approach!

Cross-Functional Teams

In the world of cross-functional teams you may well still have a Director of Design, a Director of QA, and so on. However, the difference is that teams are structured across functional boundaries.

Cross-Functional Engineering Teams

Using this structure, we build a backlog of projects and any team within the IT organisation should be capable of delivering on a given project. Different teams may have a different scope – for instance, imagine a cross-functional hardware team that comprises firmware, capacity planning and hardware engineering people, or a cross-functional web application team that comprises front-end HTML/CSS/JS people and backend Scala people.

In this scenario there is no need for a clear contract between Operations and Engineering as we’ve got a number of teams that can approach any given project, and each of those teams have all the people they need to deliver that project. Furthermore, having stable cross-functional teams allows us to cross-train the team members – thereby making more resilient and higher throughput teams (although that is for another post).

With cross-functional teams we proactively build teams full of people that have a diverse set of skills, and in doing so we alleviate the distrust and blame that can fester within a functional organisation.

On top of that we have eliminated the greatest form of waste in the IT organisation – the bottleneck (see Mitigating Bottlenecks below).

For best results you will want all the people within a cross-functional team to sit together, you can learn more about that approach in Building an Ideal Agile Team Workspace. Another aspect we leverage in the cross-functional model is to build a team of t-shaped people, more on that in Why Agile Teams want T-Shaped People.

Mitigating Bottlenecks

In the functional structure where we have silos for Engineering, Operations, etc work may wait on a particular function. For instance, you’ve got a lot of DBA work on and only so many people capable of doing it – blocker. This may also be due to understaffed roles or different priorities between teams. Aligning the organisation is key, for more on this see Collaborating Across an Enterprise from Atlassian Summit 2013.

With a cross-functional team we’ve immediately cut the cross team communication headache that used to take place, we can better align teams with the company priorities and we deliver more value to our customers.

Now go, grow!

So, with the functional teams you’ve got…

  • Engineering and QA teams pointing their fingers at one another, questioning who’s fault it is for the poor quality of a release,
  • the Operations team pointing their finger at the Engineering and QA teams for delivering a release that can’t be deployed, and
  • no doubt you can think a few examples from your own experience

Cross-functional teams are the best way to scale an IT or Engineering organisation. They enable an IT organisation to:

  • effectively scale as the company grows,
  • minimise bottlenecks and waste,
  • consistently deliver high quality product to their customers, and
  • maintain a happy and healthy workforce

Remember to take a pragmatic look at your organisation before deciding on an approach as you may find areas where a functional team will work best. For example, Legal is one area where I would advocate for a central team looking after all activities.

Ask yourself: can we afford to keep the current functional structure in place? To learn how to change from a functional to a cross-functional structure let us know your top concern via Twitter:

Leave a Reply