How introducing guilds made our engineering team a better one

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 organisation up to current state and why we came up with the current unusual solution. As any other company, we’ve faced several different organisation 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 organisation

(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 few seats apart.

You might think that 20 is a low number but what made our organization and communication inefficient at a such 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 on-boarding process, aiming to have him/her to positively contribute to product in two weeks;3) find a way to improve 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 organisation 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 organisation.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 competences in it: backend devs, frontend devs, infrastructure devops, security, data scientists, designers…

Each competence group acts also as a guild: they have a leader (competence leader) that organises meetings where 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” organisation neatly separates discussions about “what team has to do” (which requires all competences 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 competences thus making internal sharing sessions easier and with a well-defined scope.

What we like

- As 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 do engineering-wide sessions to share ALL updates but, as 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 about 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.