(Since this topic has diverged from the original discussion on Hiring pace - #6 which was more focused on the number of concurrent hires a cell should have, Iām splitting the discussion about cell leads in a different thread.)
About the current situation
Before getting into the details, Iād like to acknowledge that this is definitely a difficult phase, currently. We have all noticed that the current situation is pretty chaotic and confusing, on many topics. 
The sudden growth, and in particular the lack of availability has had deep repercussions on how we work, and put us and our processes through a great deal of pressure, and some of them havenāt held very well to that pressure. When there isnāt enough time to do everything, a lot of things that would otherwise be easily fixed become much more complex and problematic - planning becomes harder, the weight and scope of responsibilities for each increases, problems grow in size, fatigue creeps in, and issues bubble up.
We arenāt alone in facing these issues actually ā talking with other companies and hearing what people say across the development industry, with the changes in the remote market and the accelerated switch to online solutions by society during Covid, development companies as a whole seem to be struggling with hiring and capacity now. There are aspects that are specific to us, but itās useful to know that we are also facing a broader challenge of the current times ā the previously more incremental progression of the industry has been shaken, and forces sudden changes and adaptation, including from us.
The effects of the additional pressure has made apparent the areas where we have not yet found the optimal way to organize ourselves. It puts our blinds spots into the spotlight. The current situation, as every crisis, there is an opportunity for improvement. Just like with iterative software development, the friction points give a good indication of what and where we need to improve. The fact that our processes could be better isnāt actually completely surprising, as on a lot of them, we are still at our v1. We do need to improve how we manage and communicate our work, and maybe also how we split our responsibilities.
Cell leads
That said, we also need to be careful about how we react, and what direction we want to take. During a crisis, itās always tempting to go back to a way of working which is more familiar, especially on things we do differently than the majority ā but we should be careful to not āthrow the baby out with the bath waterā, as we say in French.
Regrouping cell roles to give them to one ācell leadā would indeed be more efficient in terms of communication. Thatās why centralized hierarchies exist, and why most companies use them. But as @Fox noted, this would change our direction, from attempting a mostly flat decentralized structure (with local per-role/project hierarchy and management as a backup), to just going back to the normal hierarchical model. The very principle of the cell roles is to split the responsibilities of a manager into multiple roles, so that it can be shared between several people, avoid having one person centralizing all the important information and decision-making power in a cell, and avoid introducing middle management layers. There would really be nothing that would differentiate the ācell leadā from a lead from any standard company. And as we grow we would end up needing leads of leads, etc. That would be a complete 180 degrees turn on our path, and we would be abandoning our goals a bit quickly imho.
One of the reasons for the current structure to be this way is to enable those who do the work to take the decisions, as much as possible. Though this isnāt democracy, it shares a similar type of benefits vs drawbacks: it is less efficient, more messy at times; but it also ensures that the decisions taken in a decentralized way arenāt absurd, because they are made by the people who have to apply them. I donāt know about your own experience of traditional companies, but Iāve been confronted to the absurdities caused by the dissociation between decision-makers and those who have to execute them too many times, and I donāt believe that we would be able to avoid it if we put in place a middle management layer.
Also ā even if it might look like the distant past now, remember that before the current availability crisis, things were working quite well. We arenāt properly adapted to deal with the current situation, so we need to fix the issues, but itās not like if they were pipe dreams that never proved themselves. There are also many other companies, including large ones with thousands of employees, who use self-management with success. And we have dealt successfully with even larger challenges in the past, while still doing things our way, we can do it again here.
Improvements to make
Now, if not cell leads, then what? A few ideas ā if you see other options donāt hesitate:
Capacity
First, as also noted by Fox, weāll need to solve the capacity issue. Itās already ongoing, and it takes time, but ultimately until we fully solve it, no matter how many changes we make, weāll only be able to work correctly once we have enough people to do the work that needs to be done. That remains priority #1, as that will unblock us on a lot of the points we are currently blocked or having issues with.
There are encouraging signs there, but since it will be taking time to get there, in addition to the work on improving the recruitment, maybe we could also help by limiting the number of new clients we accept, until we do recover proper availability? We could for example limit ourselves to new projects from existing clients (like LabXchange), or really important strategical prospects? @Fox what do you think?
Also, for the future, to avoid getting too easily back into the same type of hard corner, we need to make sure we keep the larger capacity margin that we have discussed putting in place.
Automation
Automation is another aspect that has been affected by our availability ā a majority of the accelerated epics are meant to help lowering the load of metawork on the team (sprint planning automation, workflow manager, sprints v2, billing v2, recruitment automation, onboarding automation), but due to the low availability we havenāt been able to do much of that. We are still dependent on solving the availability issue to make progress here, but as we do restore availability, we need to focus on these epics, and use them to lower our recurring metawork load.
Processes iteration
It would also be useful to do a pass on our current processes, and identify more precisely where the pain and confusion points are, as well as what we could remove or simplify. We already had a few initial discussions on some of these topics, like simplifying the way to calculate sustainability, or the communication/decision-making around recruitment, or even trimming the amount of meta-work that we require ā i.e. do a pass of refactoring on our processes, to make them more efficient, and more resilient to situations where we are under capacity.
This refactoring pass could actually also redefine some roles, or even remove/merge some aspects ā for example the distinction between epic planning manager and sustainability manager is mostly historical, because they were introduced at different times, maybe they should be split differently. Here again, the goal would be to review what we have, and see if there is a better way to arrange it, while keeping in mind the decentralization goal.
Project managers?
Another aspect that I have been thinking about lately to help with the situation, that could potentially help relieving some of the pressure on the planning/organizational part, is to reconsider including project managers in the team. We attempted this a few years ago, and it didnāt work very well, but it might also have been because the person we tried it with wasnāt a good fit. It could be worth giving it another shot.
I donāt have a precise definition of their role set in mind, but the general idea would be to try to hire a non-cell project manager, which would be available to the cell to use as support help. It would be a bit like what Natalia or Michelle at edX do, for those who are familiar with them ā clearly not leads or managers (the roles and epic management would remain assigned with the cells and have the primary responsibility), but able to take on support organizational tasks as needed to offload that work from the cell managers & epic owners. The cells and the people handling the cell roles would however remain responsible for the work, and be the decision makers.
Iām not sure if this would work out, or even go in the right direction as it would move some of the knowledge and decision-making to people who have less context and less skin in the game, but that could be a middle-ground worth experimenting with.
Tim
Interestingly, while I was writing this post today, I had a 121 with @tikr, who mentioned that he would be interested to take on more organizational work, as heās getting increasingly interested by it lately, and less so by the development work itself. So that made me wonder if, instead of hiring a project manager externally, we could maybe try that out with him?
One huge advantage is that we already know that heās really good at this aspect of the work, already understands well the team and the processes, and has a lot of first hand experience with the epic planning management role, as well as its interactions with the other roles, like sustainability.
It could even be worth considering assigning a broader project to @tikr , to manage the iteration pass on the processes and roles definitions that I was mentioning above ā this is something on which @tikr has some ideas, so Iāll let him post them here.
Next steps
Since Iām going to be away for five weeks from next week, Iād like to make sure I donāt block progress on this topic while Iām away.
@tikr You have mentioned that you are busy completing the work for Campus in August, but would have time to start working on this in September. To gain time in the meantime, would you be willing to at least start the discussions on the specific improvement areas, as this always take time? I.e. gather feedback on the friction points, and start listing concrete improvement ideas? Then in September you would compile it into a proper proposal?
@Ali @cassie On the automation side, from a product/UX perspective, the current situation is a good opportunity to collect the feedback on the pain points from our current processes, and see if we can design solutions that would address them. Would you be willing to prioritize gathering feedback on the pain points that could be addressed by better workflows in the coming weeks, and also make proposals?
