Guilds and teams for a better engineering
Why I believe you should switch to 2D when thinking about engineering organization
As THRON co-founder I have been waiting for this day for the longest time, so I’m especially proud of opening this tech blog, the place where THRON will share its technology-related experience and the lessons we learned, the hard way, over time.
I would like to begin our journey by explaining how we evolved our team structure and organization up to current state and why we came up with the current unusual solution.
As any other company, we’ve faced several different organization challenges during our growth, we still have a small and agile engineering team, we mainly operate in Italy, outside popular tech hubs and managing a very broad-scope product with global scale; we believe some of the choices we made are not very common and are worth sharing to prove once again that there’s no “right way in itself”, only the “right way for your company” makes sense.
Where we are coming from
As the team grew we started focusing more and more on roles, usually based on personal characteristics and compatibility, assigning architect, project manager, developer roles. Our former competence-based team organization (frontend, backend, DevOps, design) hit an efficiency wall when our engineering team reached about 20 members. We saw that the time it took to manage things such as knowledge sharing, new dependencies sharing, awareness of production delays was becoming alarmingly high compared to the time spent doing things. We could easily see it in the time spent debugging code written by other members, people writing the same library feature instead of reusing existing ones or studying languages/tools that were being used by a colleague just a few seats apart.
You might think that 20 is a low number but what made our organization and communication inefficient at such a small scale was the sheer speed things were progressing, added to the big scale of the product.
How we found inspiration through Spotify
So we started thinking about how we should improve and we identified the following objectives:
1) manage motivation pitfalls caused by crunch times;
2) ease new engineer onboarding process, aiming to have him/her to positively contribute to product in two weeks;
3) find a way to improve the competence of everyone in the team without being forced to rely on just personal will to do so;
4) share competence across the organization to prevent “single point of failure” on engineers;
we tried different approaches but what ultimately proved to fit us was something heavily inspired by the following Spotify’s presentation: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/.
Instead of thinking about organization in a mono-dimensional way, we added a second dimension:
- when thinking about product planning, releases and resource allocation we consider teams, each one of them with one analyst and one operation manager in charge of functional analysis and team project management respectively. this organization is supervised by THRON’s COO;
- when thinking about culture, innovation, and research we have guilds, each one of them with a competence leader in direct contact with THRON’s CTO.
Those two views are applied to the same group of people, so each engineer is always part of both one team and one guild, let me explain how it works in our organization.
THRON has 4 teams: one managing DAM features of the product, one managing INTELLIGENCE features of the product, one managing the BILLING integrations and processes and the one managing MARKETPLACE integrations.
Each team has several competencies in it: backend devs, front-end devs, infrastructure DevOps, security, data scientists, designers…
Each competence group acts also as a guild: they have a leader (competence leader) that organizes meetings to discuss culture, tools and experience sharing.
Guild’s goal is to share what’s happening inside and outside the company within the area of that specific competence (eg. “react” would be discussed in frontend guild, “AWS data pipeline” on serverside one).
This “matrix-based” organization neatly separates discussions about “what team has to do” (which requires all competencies for the specific functional are) from the discussions about “how to do things” (which require to focus on the specific competence reality).
This separation helps my job too because I can focus on the competence-specific needs (think about automating tests in javascript compared to scala/java) and ease the task of finding good lessons that can be positively translated to the other competencies thus making internal sharing sessions easier and with a well-defined scope.
What we like
- As the engineering team grows we found out this separation helped us reserving the right “resources” to experiment and that can be lost in the day-by-day tasks each one has to perform to deliver features on time.
- Everyone knows who they should talk to about a specific topic, the organization will sync the information in an ordered way without having to concentrate all ideas/requests on a single person.
- the organization is very flat: coo — operation manager — engineers for planning, CTO — competence leader — engineers for culture and tech and allows very focused and efficient meetings about status updates and planning what to do next.
What we don’t like
- it took a long time (about 12 months) for us to reach the stage where it’s natural to operate in this 2d structure. it has not always been easy to separate competence matters from roadmap ones.
- we were used to organize engineering-wide sessions to share ALL updates but, as the team grew, they became too expensive and less useful. The current guild-focused update is more efficient; the main risk we identified is the probability to filter out people that might be interested regardless of their competence, we are still evaluating if this is a real problem or just a concern caused by the habit of having “broad” sharing sessions.
Plans for the future
We are satisfied with the current structure and we expect it to easily support our growth to a 2x or even 3x size. We plan to keep fine-tuning this model and share our experience in this space as we evolve it.
If your company employs a similar approach or tried this but didn’t work we would like to hear from you, to share opinions and further improve.
