December 23, 2018
by David Morgantini
The Tes engineering team could be seen as a managerless engineering team. It’s better described as an engineering team where the management responsibilities are shared across the team. If you’re wondering how this works, sit down and I’ll paint a picture.
The heart of the Tes engineering model is the autonomous product team. The product team is a group of 3 - 5 engineers, 1 product manager and 1 - 2 UX designers. The product manager is responsible for liaising with the wider business and trying to understand how to match customer needs with business priorities. The engineers are responsible for shipping high quality products (note - not code, we only write code that solves a clear user need via a product) into live on a regular basis. The designers are responsible for working with the other two functions to create iterative designs that are technically achievable and match the user need. The entire team is responsible for delivering value, owning the live service, creating appropriate technical solutions and essentially, delighting our customers. In this model, each of the individuals within an autonomous product team are enabled to take on aspects of leadership. This leadership comes in the form of technical decision making, leading on feature or epic development, improving team working practices and collaborating on the technical roadmap.
We do recognize that, while the leadership described above will naturally occur within most teams, there is a missing part to the equation. This piece is somebody who is responsible for the welfare of the team. In order to not remove leadership responsibility from the rest of the team, this role is called Project Parent and shifts depending on the desires of each team member. The Parent analogy is quite apt in that the responsibility is to ensure that the team is working well together and to address any issues that arise and escalate as necessary to ensure the team can deliver as effectively as possible. It also fits in with the idea that when a family has young children (junior engineers) the parent will need to be more involved in the guidance of the family, while when the team is more experienced the guidance is less necessary.
The next challenge in a ‘managerless’ organization is how to ensure people feel their voices are heard and somebody addresses their concerns. In a world where there is one ‘line manager’ for 50+ people it is impossible for that person to have 1:1s with each and every individual on a regular basis. To address this situation we built a peer-to-peer mentoring network. Each engineer is assigned or chooses a mentor (normally a more experienced engineer) with whom they will build a trust relationship. That relationship is where the individual should feel safe to express their challenges and get advice on how to proceed. The mentor relationship doesn’t stop between the two of them though.
There will be things that a mentor is not able to address and these concerns should be raised directly to the VP of engineering or another trusted engineer who might be able to address the issue.
With this structure in place we’ve handle many of the traditional responsibilities of a manager except for the responsibilities that fit outside the team itself. These include (but are not limited to) coordination between multiple product teams, career growth, overall technical strategy and architecture, hire/fire, performance management, and the defining and protection of the engineering culture.
Coordination between product teams was solved by introducing a Principal Engineer. The Principal Engineer at Tes is responsible for looking after 1 - 3 teams and ensuring that there are clear communication channels with other Principal Engineers (and thus the teams they were responsible for). Once we introduced these Principal Engineers we also realized there was a reasonable solution for career growth. Each Principal Engineer hence became responsible for the career growth for each of the members of the teams they looked after. This is enabled by a very structured approach and tool built by SkillsMap.io. The intention behind the tool is to make it easier to have meaningful career growth conversations.
Crucially, the PE is usually embedded in a team, but NOT the Project Parent. This is an enablement role, not a direct leadership role and, if a PE is also a project parent they will be too much in the weeds to effectively do the PE role.
A PE will have more than one team within their remit and can move teams as needed.
There are currently 8 PEs at Tes taking care of 12 teams.
Overall technical strategy and architecture is handled by a combination of the VP of Engineering and the principal engineering team. They meet once every week to discuss issues that range from the highly technical/architectural to cultural issues. This team is responsible for the overall health of the engineering team and comes together to solve the most challenging problems faced by the engineering team. The VP of Engineering is the leader of this team and helps to coordinate their actions.
The VP of Engineering is the glue that holds everything together. They are responsible for hire/fire across the engineering team, dealing with performance issues (when a team raises the issue), coordinating the Principal Engineering team and helping to define and protect the engineering culture. The VP of Engineering at Tes uses a variety of different mechanisms (champions, bands, etc) to enable the team to own some of these key responsibilities in a way that ties back into the original goal of enabling a team of adults to be responsible for themselves and for the team as a whole.
So, is Tes a managerless engineering team? One could argue that we don’t have anybody with the title ‘manager’ within the organization and thus it must be managerless. The reality, however, is that management is critical in all organizations. Currently, the VP of Engineering has delegated most of the traditional management responsibilities across the engineering team but there are still aspects that need to have a human face to face connection with a single ‘boss’. Because of this, this model has worked up to about 50 engineers reporting to a single VP of Engineering. As this is not the model that Tes had 2 years ago, thus it will also not be the model Tes will be using in 2 years. The heart of the concept is the delegation of leadership and responsibility and enabling the teams to take true ownership of their work. With this in mind, the model is secondary as long as it supports those goals.
The principal engineers at Tes are the closest that we get to a line manager role. They each look after 1 - 3 teams with a total of 3 - 10 engineers. There are two aspects to their role; the leadership aspect where they are meant to provide guidance across the teams they are working on; and the people care aspect where they are meant to provide growth and career support to the engineers on their teams.
As an engineer, you can expect the following from your Principal Engineer:
A Principal Engineer recognises that leadership at Tes is focused on supporting those that are working on the teams. Depending on the strength of the team, the Principal Engineer may need to be hands on with regards to
A Project Parent is a team role focused on building collective responsibility and ownership for a product. This is a leadership role but it differs from both Tech Lead and Scrum Master in that it is focused entirely on ensuring that the team is able to execute effectively. This will include holding others accountable for the responsibilities that traditionally have been handled by a Tech Lead or Scrum Master. Like many technical leadership roles, the role of a Project Parent will differ depending on the relative strengths of the team. At a high level, a Project Parent is responsible for ensure that they are working on a team with:
A Champion at Tes is an engineer who is given the responsibility to solve one clearly defined challenge within the Tes engineering team. These challenges can range from ensuring that hackdays occur each month, knowledge sharing occurs each week, social events occur at all, folks understand what conferences are available, etc. The engineer is given 1 - 2 hours per week where they can take time out from their daily job to focus on addressing these challenges in whichever way they want. The Champion role rotates every three months in order to allow fresh eyes to address the challenge on a regular basis.
A band is a newer concept at Tes where a group of individuals get together to solve problems that are too big for individuals to solve. A current example of this is Frontend. With 300+ microservices and no unified frontend team we need to address the problem a different way. The Frontend band is a roughly organized group of engineers who, in a systematic way, address frontend challenges that don’t fit nicely within a single team.