# 🙌 Squads @ Attest

# Squads and engineers

There are many different ways to organise teams and engineers, at Attest we want to set ourselves up in the best possible way for the future. Getting it right, for us, is crucial not only for the growth and scalability of our teams but also for the success of the company.

As Engineering Managers we want to give focus to excellent growth and development for engineers, to be an enabler for engineers to work in the best possible way, and to nurture the incredible culture we have here.

This is as important as the effectiveness and autonomy of our teams and we're organised in a way that allows both to be achieved, where you can choose between three different tracks or roles to progress in.

Tech Leads own the technical direction of the squad and coordinate team efforts. They are responsible for helping set up squad goals, future milestones, and ensuring high standards of quality.

Engineer. This is the default track that most Engineers will feel at home in. Those who progress along the Engineering track will typically be expert coders, they understand deeply the business context and problem space they're working in and may have a seat across more than one squad. They make significant contributions directly to our goals or drive chapter work that improves our ability to deliver. They possess and build on a deep level of technical capability and domain knowledge, whilst being accountable for upskilling others and distributing knowledge across the whole engineering team and wider company.

Engineering Managers focus on their team's growth, progression, performance, and wellbeing. Ideally managing no more than 6-8 people, they optimise for cross-functional collaboration and the skills needed to continually improve individuals and team performance.

Engineering Managers may also contribute technically to a squad, balancing this appropriately with their other responsibilities. By not restricting the code/management ratio we create a diverse group of people in the engineering management chapter. When contributing technically to a squad, there should be consensus with the squad around expectations and time given.

squads model

Engineers keep the same manager when they move squads, this creates focus on growing and developing engineers throughout their career at Attest, knowing the context of their journey so far and career aspirations for the future. Relationships work better when they last.

Engineering Managers will form a chapter, to ensure a consistent approach and to learn from each other.

Engineering Managers manage a diverse group of people, from a range of levels, specialisms, and aspirations, matched with engineers where they can make the most impact.

The Benefits of having this set up include

  • Engineers have two people to turn to for very different kinds of advice. Tech leads for advice on the most impactful thing to work on next, technical advice, and feedback on their work. Managers for personal development, growth, and wellbeing.
  • Relationships can last for a long time. Your manager should know you really well, understand your journey so far, where you want it to go, and help you to do it.
  • We can work efficiently and adapt to new company priorities, challenges, and customer demands. To facilitate this engineers may need to move teams. Because managers stay the same throughout, we can react quicker to change.

# Squads


"If you can't feed a team with two pizzas, it's too large" - Jeff Bezos

We work in small, cross-functional squads and move quickly as a company.

Product Managers, Designers, Frontend & Backend Engineers and Data Scientists work together in small squads. Focussed on a mission each squad operates with full autonomy to define and work towards it's own goals.

Each squad will look slightly different, due to the nature of their mission, but as a rough format to follow our squads will look like this:

  • Product Manager
  • Designer
  • Data Scientist
  • 3-5 Engineers
  • Business Ambassadors

Squad members will be balanced so there is an effective mix of different experience levels, and are not overweight on either end of the scale. Squads work the best when they're set up to provide excellent mentoring, coaching, and support to all levels.

# Chapters

chapters in squad model

As we move into truly cross-functional squads it's important that we don't lose the level of communication and collaboration that we've had previously, especially within your discipline or those you share a codebase with for example.

Chapters are a group of team members working within a special area, for example within Backend Engineering, Frontend Engineering, or Engineering Management, a way to promote team collaboration and innovation.

These groups get together on a regular basis to exchange ideas, get help on challenges, and discuss new technologies/methodologies.

# Pillars

Some of our squads have a common mission and share goals. We call these groupings of squads Pillars. All squads within a pillar share a common Strategic Track.

pillars in squad model

# Taskforces

Not all problems we need to solve fit neatly within the strategic direction of our squads or pillars. Nor is it always obvious or easy to work out what the solutions are to these problems. Where do critical security improvements fit? How do we work out and resolve our most impactful tech debt artifacts?

This isn't as hard when your whole team can fit within a single room, where you can collaboratively whiteboard a solution and decide on what to work on next week. This becomes exponentially harder with scale and this is why we introduced the concept of taskforces.

A taskforce is a temporary grouping of engineers, who may be from multiple different squads, with a common goal of solving a specific and impactful piece of work. This work probably doesn't fit within an existing squad's goals, is often timeboxed, and usually isn't worked on by more than 4 engineers. Taskforce members do not leave their existing squads but will manage expectations with them regarding the temporary commitment to the workforce.