In this post I will give you an overview of what is (and what for is) the escalation matrix, which for some time is helping us in delegating tasks and organizing office life in the eEngine. But let’s start from the beginning …
At first there was chaos…
Well, maybe not quite much of it, but let me tell you a story. Some time ago we did hire a new developer for the project I was managing. The first thing we had to provide him with after our onboarding process was a GitHub account. Sebastian, our TechLead, asked me to go to Paweł, our El Patron and ask him to set up such account. Paweł said that the new accounts on our GitHub are created by Szymon. When I went to Szymon I did learn that we have no more space for new people and we have to pay for new one, hence I should go to Paweł who is our CFO. Finally, I went to Ania and she confirmed to Szymon via e-mail that he is the chamberlain of our GitHub and is free to make any decission regarding the GitHub management. So, after 45 minutes I did manage to bring the process to a happy ending. Perhaps it rings any bell to you?
Disagree and commit
The above principle, which we follow in eEngine is a really cool thing. I can’t recall whether I touched the topic on one of our daily stand-ups or simply went to the HQ with fatal face after the “GitHub account action”. This way or another – I suggest that since our tribe is growing, we (Actually, I) can think of a tool that ITIL calls an “Escalation Matrix” – a (as simple as possible) chart depicting who, to whom and with what questions or problems to address.
Divide to conquer more effectively
The task was not that hard because the areas of responsibilities were long established among eEngine ranks. All I had to do was arranging the areas and directing the arrows (or escalation levels) to the appropriate places to simply show that establishing new e-mail alias for the testing purposes is not a task you should go to the CEO with.
So I have started with a general list with areas of responsibilities:
- Developers
- Tech Leaders
- Project Managers
- Chief Marketing Officer
- Chief Technology Officer
- Chief Tech Lead
- Chief Financial Officer
- Chief Executive Officer
Our developers were my starting point. It is known that the devs always have the most problems developers are the backbone of any eCommerce Software House. I did divide the rest of our team into two groups – “soft” and “technical” ones and such were the first two branches and escalation points of our matrix. Those described as “soft” are, of course – us – the Project Managers, “technical” ones are the Tech Leads of our projects.
Due to the fact that many PM-wise decisions are consulted with Maciek (Chief Marketing Officer in the moment of creating the matrix, Chief Evangelist now), he has become the next escalation point for the soft topics. When in need of consultations, our Tech Leaders should go directly to Krzysiek or Szymon, our CTL and CTO. The last escalation point for the technical issues will be Paweł. Partially because he is an experienced developer and always willing to share his knowledge, partially to emphasize that there are at least two groups of experienced people who can and always want to help our developers in need. The last point of escalation and the person who ties our entire tribe together and makes the most important decisions is, of course, Ania – our CEO.
The first sketch of escalation matrix went to Arek, our graphic maestro, who did his magic and pictured us as planets revolving around our orbits and we had no other choice than baptizing it as the “Gravitational Matrix”.
Continuous Gravitational Matrix Improvement
But wait, there’s more! Like everything in our industry, our Matrix is not a closed entity and develops as our Tribe is developing. After some time, Kamil branched out from the PMs group as our Team Leader and most experienced PM of our tribe. Also, we did add our invaluable UX specialists and graphic designers to the matrix (they became a branch parting from PMs since it is mostly us who ask them to create spectacular mockups for the projects we run).
TCreating our matrix was an interesting experience, during which I have learned a lot about the process of delegating responsibilities within our company. It also did show, that the tool that sounds very corporate, does not have to be
There’s still a lot of work to do!
Since the matrix was introduced to our Tribe recently, we are constantly learning how to use and customise it to be most effective tool to delegate tasks with it. Similarly, I am always eager to hear the improvement suggestions from our team. The main field to shine is certainly its readability and finding out the golden mean between the great looks, amount of information the matrix contains and transparency of them.
Hence my call to action for you – you can find the matrix in the link under this post. Look at it and let me know in the comments, what would you call a fail, and what’s just an item to improve. Or – perhaps – have you created similar tools for your own Tribes and are willing to share your experiences with me?
Thank you for reading and and see you next time!
