Recently AVAMAE has undergone some sizable internal restructuring. Which is to say that we now have an internal structure that’s worth writing home about (if the people you have at home are interested in that kind of thing). In that letter would be the sentence “AVAMAE has changed its structure from “flat organisation” to “flatarchy”.
We now successfully run a structure where our software engineers are organised into “pods”, each working toward one or more common goals that are not shared by other pods.
Let’s dive deeper.
Flat as a flat organisational structure
It was clear that the structure we had in place was either going to reach breaking point soon or had already reached a breaking point, depending on who you asked. For as long as AVAMAE had existed (10+ years, go and check out our 10-year anniversary celebrations!) we had been sufficiently small that every engineer knew exactly what they needed to know and they also had a pretty good idea about everything else or knew who to go to about what they didn’t know.
Need an algorithm that procedurally matches up soccer players by skill, or something in that space? You can go to this engineer. A chunk of tried and tested code designed to bring back lightning fast reporting to a dashboard? Well then you want that engineer. Anyone ever integrated with this particular third party? No? Alright then, looks like I’m now the company expert.
Hierarchy, for the first time
Fast-forward a few years, to spring/summer 2020, and the state of affairs looks pretty good for AVAMAE. We were able to transition to work remotely relatively painlessly, and the mixture of industries we’re involved in turned out to be reasonably unscathed, at least on the tech side. Thus begins a robust and healthy growth that is still ongoing, resulting in us expanding our engineering team by upwards of twenty engineers from then to now.
As this began, we created two Engineering Team Leader roles, one specialising in the disciplines of client-side (also known as “frontend” or “app”) code and one in server-side (also known as “backend” or “cloud”) code, each of these acting as the line managers for the engineers who worked with that discipline. This was the first time that engineers at AVAMAE experienced hierarchy beyond “the boss”.
This worked very well in terms of helping to shift the workload of the aforementioned boss from managing engineers to managing the wider company. It also worked great for onboarding and looking after new engineers, with a key figure responsible for them in each discipline. We were able to rally together as two separate teams who could train and be handled separately from an administrative point of view, with collaboration between them when needed.
On the other side of the coin, the downsides included some engineers leaving the AVAMAE team after not achieving the Team Leader, and the inevitable loss of all engineers having close to perfect knowledge about the workings of the company. However, that latter one is probably more of a consequence of a) the number of projects AVAMAE was working on increasing and b) losing the osmosis of ideas and current affairs that is a happy side-effect of being in the same physical office.
As you may have suspected, this success could not last for ever…
Organisational structure, meet code architecture
How many engineers can meaningfully report to a single line manager? Popular consensus puts the number at around seven. How many engineers can a single Team Leader assist and provide meaningful cultivation for? AVAMAE consensus puts this number at probably also seven. And therein lies the problem.
It was rapidly becoming apparent that the Team Leaders were running out of capacity as AVAMAE continued to grow its talented pool of software engineers. Some of our longer-serving engineers were helping out by onboarding and mentoring new engineers, or by taking the technical load of certain projects and becoming the expert on their codebases, which helped immensely.
So then, we needed a new structure that catered for our needs even better, by reducing the workload on the Team Leaders and the product managers, as well as being scalable so that we didn’t have to figure out yet another structure another two years down the line. Luckily, AVAMAE prides itself on the ability of its engineers to write scalable code, on two fronts: handling large amounts of data and being able to later extend the code to add functionality. This helped us as inspiration, and since it’s one of our core tenets when writing code we were all already thinking this way.
Take us to the stars
After some careful work, it soon emerged that a new structure had already been slowly manifesting as the company grew. This one was not centred around disciplines, but around projects (which themselves are linked to exactly one client each). Since this hidden structure was already proving useful, we decided to formalise and expand it.
After much ado, we landed on a system of what we call “pods”. Each pod contains no more than six engineers and no fewer than two. Each pod contains a single “Lead Engineer”, responsible for code oversight, for providing functional scope and estimations, and for making sure that each task is matched up to the engineer in the pod that can get it done the fastest and to the highest standard. The other engineers in the pod, and the Lead Engineer, work together to fulfil the requirements of one or more projects, which is often synonymous with meeting the needs of one or more clients.
On the product management side of things, the pods are arranged into “pod groups”, to which a Product Manager is allocated, and which contain no more than around three pods. The Product Manager works closely with the clients that correspond to the pods in their group, and with the Lead Engineers in those pods. They help direct the long-term focus of each project, plan the work that needs to get done for the upcoming month (our methodology is Agile, but that is best left for another time), and report on progress both internally and externally.
Once this was established, there was a flurry of activity inside AVAMAE to figure out the best way to name these pods. “Pod A”, “Pod B”, etc. or “Pod 1”, “Pod 2”, etc. to us implied that some pods were better or more important than others, which isn’t the case. We decided to bring it to a company-wide vote, putting up first the theme of pod names, and then the individual pod names. Collectively, we settled on “Stars” as the theme, and the names of some of our first pods are “Sirius”, “Antares”, and “Betelgeuse”. If you find yourself exchanging emails with one of our talented engineers, you’ll see their pod name in their email footer.
“Stars” was the perfect theme, and all the better that we decided on it together. They evoke ideas of inspiration, constancy, and simplicity (what could be simpler than a sphere of light that burns the smallest element on the periodic table?), all of which are ideas we’d like to be associated with AVAMAE!
You mentioned scalability?
The final piece of the puzzle is what comes next, after the present moment. As more clients come on board with us, we’ll be able to spin up new pods and new pod groups, making good use of the talent we’ve been cultivating in the pods we already have. The pods will (and do) of course experience some cross-pollination, to ensure that the best AVAMAE has to offer is made accessible to every pod and every project.
Mentoring will fall squarely on the shoulders of the Lead Engineers as we officially transition into this new structure. The Team Leader role will morph into an Engineering Manager role, and will be linked to the pod groups in the same way as the Product Manager role. A Solution Architect sits outside of the pods and pod groups to ensure a high level of quality, and to make sure that each new project starts out on a firm foundation.
As AVAMAE continues to grow, we have planned to add in Senior Lead Engineers who can sit in between pod groups and the Solution Architect. When our size demands it we will create Lead Engineering Manager roles and more Solution Architects, expanding the hierarchy above the pods as and when necessary.
I am of course not saying that what we’ve got here is in any way original. I had never even heard the term “flatarchy” until I started writing this, well after the new structure had been officially implemented. As I’m sure some of you have been screaming at your screen, this pod structure bears at least some resemblance to Agile or Scrum teams. I can assure you that we in no way feel smug that we got to this point from more or less first principles, organically settling on the right structure for us that happens also to be roughly an industry standard.
So what’s next for AVAMAE? Where will our new structure and talented engineers take us? That, I think, is for the stars to decide.
