Context

January 2023 was a six-month mark into my new role in the same company. This was a lateral move, Head of Engineering in the Platform team. While the team was smaller in scale, it was more specialised, with higher expertise tech leaders and a more comprehensive range of scope.

One of the key takeaways for me was to stay lean and keep our leadership team leaner. In our team, we managed to keep 80% of our people (including our tech leads) hands-on who publish some sort of artefact to the production environment on regular (but varying) frequencies (aka doing what they love and delivering value to their customers).

Observations

This approach resulted in few observations highlightes below.

Optimised for Observability of Signals

Having a leaner team and specifically reducing the number of middle-management team members made signals more visible to the leadership team. It took little effort to understand the impact of a change in our ways of working, as there is no translation layer between the leadership and engineering teams.

Less Noise and Low Collaboration Effort

Smaller leadership team means less noise (vs. signals). You hear things and observe changes first-hand. More importantly, compared to a job-sharing set-up, where more than one person does the same leadership job (e.g. People Leadership), collaboration costs are reduced heavily, and accountability is clear. This is a reminder that collaboration is expensive, and you should reduce the lines of communication as much as possible.

Higher Bar for Being a Leader

This set-up, with clear accountability for leaders, makes the bar higher for being a leader. This does not necessarily mean a higher bar from a competency perspective but from the passion for being a leader and the hunger to deliver results. There is no bystander and little opportunity to do work around work. (There is no one responsbile for our LinkedIn inspirational quotes, either. Sorry, could not resist). Furthermore, one of my favourite observations is that with a smaller leadership team, our leaders have to work together to solve problems rather than operating in their functional silos.

Reducing the Need for Big Planning Sessions

We used to use Big Room Planning sessions that took a month from the beginning to the end. Every quarter. In that one month, teams were identifying cross-team and cross-business dependencies, directions for the next quarter, OKR setting, breakdown of stories, and asking guidance from tech leadership on where to focus and what to prioritise.

With a smaller leadership team, setting direction and priorities for the next feedback loop (usually quarter) is the responsibility of a small group of senior tech leaders (CTO, Head of Architecture, and Head of Engineering). They work with tech leaders during the quarter in their 1:1s or skip 1:1s to ensure the direction is set and equip them with their vantage points. Dependencies are identified by technical product owners during the quarter for the majority of the dependencies.

For this frequent engagement to work, we had to normalise that it is okay for senior tech leaders to be more hands-on and that most of our input is recommendation and feedback rather than decision and mandate. Equally, this keeps us - as senior tech leaders - on our toes to learn frequently, stay authentic when we don’t know something, and seek feedback from tech leads who are SMEs in certain areas.

While we still have the quarterly ritual of planning, we use it for building alignment, celebration, and pivots rather than complete prioritisation and dependency mapping.

Decoupled and Reduced Dependencies

As a central platform team, creating dependencies on ourselves can be inherently natural. About a year ago, it was a sense of pride and accomplishment to accept all the dependencies from stream-aligned teams and work hard to unblock them. The side effect was that platform teams were left with little time to focus on future impactful platform developments. Putting an artificial limit on the size of the team, clear guidelines around self-service capabilities, upfront communication with the teams around the intent, and equipping them with traditional and novel ways to reduce dependencies can be effective in unblocking teams.

Artificial Limit on the Team Size

In order to advocate for prioritising the most valuable and impactful piece of work, it is a common practice to limit the size of the teams. Numerous studies and real-life evidence show that large teams are less efficient and effective, which needs no further explanation. Equally, we reduced our dependencies on contractors as a default go-to approach for tackling capacity problems, and now we mainly using them where we have a capability gap in our teams. We have noticed that contractors - rightfully - are not partaking in team rituals, and celebrations, that leads to a spiral effect of disengaged teams.

Conclusion

An immediate question that comes to mind when reading pieces like this about keeping teams lean is: “How do you scale as your organisation gets bigger and bigger?”

There are a few ways to answer this question:

• Some organisations scale out instead of up. As soon as one team gets to a certain size, they restructure them into two independent teams, ideally based on their sub-domains.
• Some other organisations actively reduce their toil to free up space for new domains. This may also be killing products that are less profitable or valuable.
• And of course, some companies don’t get bigger intentionally, as they are happy with what they are doing and they care more about doing one thing and one thing very well.

Any conversation around team structure and culture has heavy roots into the culture of the team, company, and country. This post is essentially what I found out after years of trialing and error in my organisation and subject to revisions. One area that I can heavily attest to that, is the positive impact of reducing team sizes, and lines of communications.