Delivery Structure 2019
Organising business units with large headcount is often a complex matter. At a high level, I would like to bring you closer to how we have come up with such structure of our IT department in Amplitudo. Imagine a prodigy growing up fast and you are tailoring a suit to- well- suit his needs. Not at all simple, and sometimes painstakingly complicated. But it is, once accomplished- a rewarding feeling.
To create a model that fits well with the company and the colleagues within, and then to allow space for upskilling of individuals and room for the future growth or scalability of the IT department, was truly a hard part of the plan we have had in front of us. Nenad Novovic (Amplitudo CEO) gave me the freedom and trust to implement the structure we felt it could simultaneously (https://fastgood.cheap/) speed up the completion of daily tasks and increase productivity.We were not wrong as the results speak for themselves, both in code quality and with how engaged our code magicians are.
Our whole IT department had about 22 people mid 2019 – mix of developers, testers, and infrastructure engineers.
The practical experience I have in composing and structuring Teams with these phenomenal domain experts is fairly extensive so with it I was able to introduce elements of the popular Spotify model which is used across the globe. Elements: meaning, we have not applied the exact scale of this model in Amplitudo (so-called Tribe, Squads, Chapters, etc.) but took only parts that made sense in using.
How and in what way did we do it that made sense - you may ask?
The very first move was the actual name that responds well with the Agile principles or the DevOps practice. This name was Delivery.
Second stage was structuring a single Team that would later be mimicked across all others. As per the Agile methodology, the ideal Team should consist of 7 members. Our Teams do not grow beyond this number (so far).
Out of 7 colleagues in a Team, we focus that the dev : test ratio does not go over 4 : 1 (4 developers, 1 tester). The Agile “rule” says the ideal ratio is 2,7 : 1 though this depends on whether you use SCRUM, Kanban, do you deal with client projects or you develop in-house products, are you driven by deadlines or perhaps constrained by budgets, etc.
In any case, Tester must exist. I have to amplify an unfortunate fact about the lack of well-seasoned testers in Montenegro. They are harder to find then the Dodo bird (cliché, I know). Of course, I am not talking about our own Test Analysts whom I give credits and who do a great job.
Beside the developers and testers, we also have Designers and, as of recent - Product Owners. I can confidently say that Product Owners do not exist in Montenegro. If you find any, I am taking you to lunch of your choice and offer to take you on board momentarily (small print – experience needed). No kidding!
Both these roles, Design and PO are often “used” by two or three Teams. This is not the official rule but it functions well on our end.
Third segment - quite an important one - is the line management / reporting lines, however implementing it so that fits the so-called flat hierarchy, is a challenge on its own. It looks flat but then it has a dose of control quality which stems from the current processes and the people who are in charge of owning the work in progress – Project Delivery Leads.
Major differences between these two roles (PO and PDL) are – in short:
- Product role (PO) is clearly accountable for the “What” and the “Why” – deeply close to customers and internal stakeholders
- Delivery role (PDL) is focused on the “How” and the “When” making sure we are delivering quality at speed via providing technical estimates and technical decision-making.
Next up – Development Leads, our colleagues who display the ability to lead people but then are in a Team or hands-on. All Dev Leads are Development Manager’s direct reports. Dev Manager is a person with most responsibilities in our Delivery sector and sits outside of a Team though acts as a floating resource by supporting and occasionally provides code fixes on need basis. This is quite rare, btw.
Lastly, those we mentioned a few times, Product Owners, are the true champions of Amplitudo products and projects. Entrepreneurs they are, to say the very least of them.
How did we find POs? Teaching and mentoring for months is the only way to shape such diamond-like creatures in Montenegro and in the region (we have had a similar skills sessions for testers, too). Currently, there are 4 POs and hopefully more are coming.
Our Delivery vertical lives off calculated decisions. We do not change because of a blog (like this one) or because of a bestseller IT book. We do follow competition. In fact, we are context-driven. This is our “secret” weapon.
Is this a structure that works with those who are perhaps used to the current one or nowadays, the old way? Must I say that only through a form of discomfort and the will to face the pressure head on, you can grow.
P.S. I have not mentioned SCRUM Masters. They are here, too. There is plenty to say about them and their processes but perhaps we can touch on this some other time.
