How Entersekt Designed Their Team Around Their Product Architecture

When communication structures and organisation design happen by accident — ie. they are not set up in parallel to each other — it tends to result in greater cognitive loads on developers, slower development speeds, and suboptimal workflows and productivity. This is why Richard Bailey, Executive VP of Engineering at Entersekt, used intentional organisation design to construct a new team structure around Entersekt’s product architecture so that his teams’ communication could mirror their architecture’s communication structures, and reduce cognitive load on developers. Here’s how he did that.

When Richard joined Entersekt, he noticed that as the teams and architecture had grown, there was opportunity to improve the way teams collaborate and communicate.. Specifically, the developers in his teams had a lot of cognitive overhead: In order to complete any given task, engineers needed to have a lot of contextual information in their heads, and know about all the different dependencies involved in the process. This constrained their flow of work and productivity.

Richard decided to tackle this problem by taking an intentional organisation design (IOD) approach, and design a new team structure around the architecture structure:

“Organising around architecture means organising teams so that the way they communicate with one another reflects the way that the underlying software communicates. On the other hand, organising around a hierarchy normally means that the architecture starts to follow the communication channels of the organisation structure, and that may not be optimal for your business objectives.”

Designing the architecture first and building one’s development team around that does take more time, but it enables Richard’s developers to communicate better with each other, and work faster:

“It’s not always easy… but if you can mirror the way the architecture communicates in your team communication paths, and in the organisation structure, that dramatically reduces the cognitive load and improves the quality of communication between those teams.”

It also ensures his development teams can be more productive in the long-term. Richard says: “If we can think about optimised architecture, allowing us to build software faster, and organise ourselves in that way, then we’re set up to benefit from the longevity of the architecture, as well as the maintainability of the software. It sets up an enduring architecture; and that’s the advantage.”

In order to make sure he got this approach right, and avoid as many risks as possible, he followed a step-by-step approach:

1. Define the blueprint of your ideal architecture
2. Overlay your current architecture
3. Build a high-level team structure
4. Feedback, feedback, feedback!

Here, Richard explains each step a little more, detailing how that helped reduce the overall cognitive load for his developers so that they could communicate more efficiently.

Step 1: Define the blueprint of your ideal architecture

First, Richard’s team laid out the high-level blueprint for their ideal architecture. They looked at examples that they might like to follow and defined what their overarching product architecture should look like, with all its connections.

The goal at this step was to highlight the primary moving parts of the architecture, and get a “big picture” overview of the whole system, as opposed to getting too attached to the details that didn’t impact how the system operated.

As a leader, he saw his role as providing his team with a solid vision, so that they were enabled to work out the details that were relevant to them. Following the blueprint approach prevented him from dictating the details, and rather helped him focus on defining the broader vision of the architecture:

“It’s not my job to come up with the details — those are up to the engineers who work with them every day. And staying at a high level enabled me to give them that vision.”

By having a clearly defined blueprint, Richard could then start to compare what the team’s ideal setup looked like compared to their current one.

Step 2: Overlay your current architecture

With a blueprint for what their ideal architecture could look like, Richard’s team overlaid their current architecture onto their ideal structure, and identified all the current blockers, weaknesses, and inefficiencies that they needed to address most urgently.

“This worked, because it gave quite an insightful heat map as to where our current product had inefficiencies around the cognitive load. It was very revealing. We could see more clearly how much our engineers had to know in order to build a few more lines of code.”

The goal here was to identify where the old architecture is the most incompatible with the new, ideal one. This enabled Richard’s team to prioritise which problems needed solving first, and set up the teams that would be best suited to figure those out accordingly. “Our objective was to break that model up, and decide how we might ease our tech and product leaders into designing a team around that, and ensure that we weren’t breaking anything with this new architecture structure.”

Pro-tip: In Richard’s experience, the best way to overlay your existing structure onto your blueprint is to have a lot of open discussions and communicate with the leads of the various teams in your organisation. This helped him design his team more proactively, and less reactively. Richard says, “It was really useful, just from a people perspective, to match the right people with the right technology, and sort of ‘socialise’ it with the stakeholders.” This helped him get a sense of where the biggest challenges would be in designing a new team structure around the new architecture structure.

Step 3: Build a high-level team structure

With a better idea of where the biggest team structure challenges would be, it was time to design a high-level team structure. To do this, Richard used the Team Topologies framework, which uses very simple shapes, colours, and shading to indicate the broad brushstrokes of how various teams interact with each other.

The main goal at this step was to have an easy-to-understand visual map of the team structure, so that Richard could figure out whether the cognitive load he was reducing would negatively impact the communication structures. Even though less communication means that the cognitive load is reduced, Richard says that too much autonomy can sometimes lead to teams not communicating enough, or at all:

“It’s critically important to think about how teams will communicate once you’ve made the change: How will these teams communicate in a normal course of work? How can we ensure that they don’t just work in a vacuum?

Building out a high-level team structure based off the new architecture structure set him up to start getting feedback from the people in his team.

Step 4: Feedback, feedback, feedback!

For Richard, the most important part of the entire process was to get feedback from the people in his team: “If you are going to sell change, you can’t work with people who don’t believe it.” Richard spent around 25% of the time it took to build out this process getting feedback from the Entersekt CTO, the tech leads, software engineers, and the Entersekt People Team.

Once Richard had the blueprints of their ideal architecture, the places where their current architecture and team structure would need work, and the high-level view of the new team structure, he opened everything up to criticism and discussion. This let him practise a quality he relies on a lot as a leader: Listening.

“Invest the time. Provide an opportunity for everyone to be part of the outcome. In an exceptional organisation, for every two ideas there is going to be another two ideas. The nuance for a leader is to listen more than is our natural tendency.”

In his experience, the biggest risk with not doing this is that you make big changes too quickly, and teams don’t have time to adjust or feel like they were involved in the process. He explains: “If people have worked with the same team, on the same technology for two or three years, they don’t always know that there’s a way of improving what they do. Introducing change too fast… is a big risk.”

By following this step-by-step process, and slowly starting to make changes, Richard says that it’s become much easier to anticipate the “big things” that might break, and opened up communication lines within the team to share feedback on whether or not these changes would make a difference to their ways of working.

IOD is something Richard has thought about a lot in his career, and if it’s something you’d like to ask him more about, feel free to reach out to him on LinkedIn.