Cell leads

The capacity and sustainability manager roles encompass most information required to make decisions about the cell: whether to hire more, to take on more clients, etc. As recruitment manager, I found myself having to constantly either interview @tikr and @daniel, or replicate some of their work to reach the same decisions.

What if instead of distributing these roles to three people, they were unified into one larger Cell Lead role? There would be no option but to make it full time, but the advantages would be many:

  • No dilution of responsibility: the Cell Lead would have a stake in making sure all epics move forward according to plan
  • One person deciding whether to hire more people, with all the information required to do so
  • Other cell members get to focus more on projects instead of managerial tasks
  • Cell reaction time to changes in project availability and scope would be faster
  • One single contact point for inter-cell coordination: @Fox will know who to ask about taking on a new customer, instead of a fuzzy “who wants this customer?”
  • One person at the cell level that evaluates member well-being and performance, and can take action when required: we don’t currently have that and I think we need it. This is less about firing people, and more about findind a stakeholder to take responsibility for the cell’s collective happiness and efficiency.

The precedent is obvious: you, @antoviaque. :slight_smile:


@adolfo These are all good points, thanks for bringing them up. I have some thoughts on this that I’m planning to add next week. (I’m at my EOD right now and will be away for the next couple days.)


You make some excellent points here, @adolfo . I agree, and the stress of managing all of these things is taking its toll on our teams. It’s certainly taking its toll on me.

  • The skills required for a Cell Lead have nothing to do with DevOps, and that is what we hire for. So we should hire a specialist.
  • If it isn’t a full-time job to lead a single cell, then can we hire part time?
  • Alternatively, can we hire someone to lead N cells, and hire more as we add more cells?

I agree we should consider hiring, but I think whenever the role’s vacant we should first ask in a cell if anybody’s interested. Like when @Fox went to sales, for some people it might be attractive for whatever reason. Plus, as we’ve discussed elsewhere in the past, our methods are relatively unique, so it will be difficult to find people that are more versed on them than we are.

Another plus is that when the assignee isn’t working out or isn’t happy, they have the option to step out into regular development without leaving the company. And vice-versa, when somebody isn’t happy developing, they can take “a break” and do meta-development. :man_shrugging:

I very much doubt that unifying sustainability calculation, epic and capacity planning, inter-cell coordination and communication, sprint management (it makes sense to do that too), HR support, and recruitment for cells with a target of 10+ members will be anything but full time.

When I was handling recruitment for Serenity, I was already toying with the idea of making only that full time, let alone all the other responsibilities. As a matter of fact, I’m pretty sure that whoever takes on the full role is going to need help, from time to time. :slight_smile:


I think this would be the right approach for such a role. I think perhaps the more critical aspect and open question of this is that we retain our flat structure as much as we can. This role veers toward a middle-manager role-- it is introducing what looks like hierarchy to me. This is part of why we didn’t go with such a centralized role to begin with.

There are definite and obvious advantages to centralization. There are less obvious and harder won advantages to decentralization. What would we be giving up to do it this way?

1 Like

We’re only flat to an extent. Xavier and Braden still break ties, make final calls, and give added weight to new initiatives when needed.

I think of the cell lead role as rolling back time to when Opencraft was a quarter of its current size and there was only one “cell”. All evidence points to the fact that that worked out fine, and I believe part of the reason for success was the original management-to-developer ratio. We’d just be duplicating the recipe.

Of course. If done right, you get redundancy, tolerance to SPOF, etc. But you also pay a high price in complexity and efficiency, a price which I happen to think is too high for the cells as they exist now.


If the cost is too high now, I imagine it will always be too high. It is not as though these needs are going to get less prevalent or demanding. Is there another way in which cells could exist that wouldn’t require introducing middle-management? Is middle management truly inevitable if we want to keep our sanity and work-life balance?

A hidden downside that I don’t think has been mentioned is that our tendency to be generalists is one of our greatest strengths. ‘Being in OpenCraft is like learning how to run a software consultancy’ seems like a feature rather than a bug to me. After all, it’s one of the things that gives us an edge when dealing with clients-- we understand the larger picture better than most engineering teams can. I agree, though, that too much responsibility is too diffuse, and that we’re spending a lot of time with some fuzzy processes.

I also think a large amount of the current stresses are really derived from the capacity issues to start with. When you’re rationing resources ever more tightly, you spend way more time on overhead managing ever smaller slices of time. We have extended discussions on which projects to put on the backburner.

I wonder if the particular stresses we’re experiencing now will be much more manageable as more team members are confirmed and things like our workflow manager are delivered. Is it that a middle-manager would reduce stress, or that the middle-manager would be the place where all stressful decisions are made? Our concerted push to fix issues with capacity only began a few months ago and it takes a few months to confirm new core team members.

To me it feels like we’re currently going through a critical growth period that is challenging our commitment to keeping things as flat as we can. You are right that @antoviaque and @braden break ties and cast long-term goals and vision, but the pattern with both of them has been to find ways to make their centralized critical functions more and more able to be delegated. So creating a cell lead would be undoing a lot of hard-fought work to prevent the very thing we’re considering now.

All this makes me say: Yes, the current situation sucks, but I think it’s too early to consider throwing in the towel on one of the key structural differences we have from other companies-- one that I think prevents us from falling deep into silos and specialization. Even the specialization we have I think needs to be made a little more redundant (it’s why I’m documenting as much of sales as I can-- and why we’ve been improving training around it.)

I am greatly concerned about what OpenCraft would look like if our team members didn’t have a strong understanding of the responsibilities the proposed cell lead would have, diffused. And without those responsibilities distributed among roles, how else would these disciplines propagate unless someone decided to go ‘all in’ on the cell lead role rather than pick up one of the subdivided roles we currently have?

Continuing with a new post because I don’t think I could edit it in time for me to avoid the email being sent out.

I realize the above post is only talking about problems with your solution and not offering an alternative one.

I feel like a lot of the issue we’re running into can come down to the fact that there are fuzzy edges between roles where it’s not clear what to do. What if we identified these, and started coming up with solutions/processes for each? Here’s an example:

It is , indeed, quite a mess. Synchronization is required between different roles, but it isn’t always clear how it should happen, and when. Such as, markedly, between Epic Planning Manager and Recruitment Manager. Case in point, Tim says:

it’s a little too early to talk about excess capacity for Aug and Sep.

This is basically admitting we can’t predict how much capacity will be necessary until it is too late to hire - or too late to fire - anyone.

We do have a thread where we’re talking about the capacity buffer and what have you. What if we create a task for someone to read over the thread, and come up with a proposed solution with an MR to the handbook (what was the link to that thread again? I’m having a hard time finding it)? Right now it’s an open discussion but we haven’t assigned anyone to put forth a formal proposal from what we’ve discussed. I’d be willing to do this if no one else is.

In fact, reading again, it looks like you alluded to this possibility here:

Or should we just plan (and document) more clear sync-up points between the different role owners?

I think this is the way to go. I think we’ve got technical debt in our processes (process debt?) that we need to resolve, and that this is a matter of cleaning up that debt.

@adolfo Can we get some tickets to log time discussing this? There’s a lot here.

That’s interesting. I didn’t read @adolfo’s original post as a proposal to introduce a new level of hierarchy. In my experience, the work that goes into the different cell roles is mainly supportive, and not so much about making decisions unilaterally. I don’t think this would change when merging the roles; but perhaps I’m missing something? Curious to hear your thoughts :slight_smile:

Agreed, understanding the larger picture better can be helpful when dealing with clients.

But in terms of being generalists, the scope of expectations that are placed on core team members allows for a lot of that even without adding any of the self-management roles that each cell needs to fill (nor any of the other specialist roles that some team members may decide to take):

  • Feature development
  • DevOps
  • Mentoring
  • Firefighting
  • Community relations
  • Discovery duty
  • Epic ownership
  • Client ownership
  • Core committer duties

And a lot of the knowledge that’s required to understand the larger picture better comes from taking on epic management and client ownership alone.

A larger number of core team members does reduce the amount of pressure on each cell member to take on additional roles. On the other hand, the faster a cell grows, the sooner it will be time for the next cell split – which will again reduce the number of core team members per cell, and require individual cell members to take on more roles.

(I have some more thoughts on this, but am running out of time to continue working on this post.)

I think that we have too many roles and processes for the size of each cell: 5 “metawork” roles (planning manager, sprint manager, epic planning, hiring manager, sustainability manager) for a minimum of 6 team members seem to be just too much, but it looks bad even when comparing to the size of Bebop (13 members) - just to keep our processes running. Seems to be a bit overkill for a small team, and it’s definitively a burden in terms of stress and context switching.
(nice to have here: the amount of time spent each sprint just on these roles)

Considering we’re looking to keep working in small cells (keep more people with context) simplifying processes and roles seems the best way forward. We can also automate things, but whenever we do that we create a “hard” interface between us and the automated process (form/checklist item) that is not always nice to follow (eg. filling yet another form, increasing checklist size, etc).

I have much more to write about this, but I don’t have a lot of time in the current sprint.

Edit: I’m logging time on FAL-49 since there’s not a dedicated ticket for this.

1 Like

Ok, epic management maks sense as a bucket for this, but Falcon can’t take on everyone’s hours for this discussion. So could everyone please log time on their own cell’s epic management ticket? I’ll also edit the top post here to include these links:

  • BB-283 Epic planning - Bebop
  • SE-254 Epic planning - Serenity
  • FAL-49 Falcon Epic planning

Chiming in here with my 2c. There’s a lot of discussion going on here, so sorry if I’ve missed bits. I’m also a relatively junior developer, so keep in mind.

When I joined OpenCraft, the team was way smaller, the number of clients was less, and everything felt more manageable. It wasn’t long before I felt like I knew where everything was, where to find docs, what did or didn’t exist, which projects were next on the horizon, etc.

Since then, the company has grown massively. During the time, I spent most of my time focusing on a small number of projects, and quickly lost touch of what was going on in other cells or even other projects in the same cell.

Now, in the last month or so, I’ve been forced to spread out to other projects due to budget issues and lack of tasks. Never before have I felt so lost. I’ve studied and trained to do software development, but I’ve been having discussions about topics I thought was out of scope for what I was hired for and that I’m trying to learn on the fly: budgeting, prioritizing projects, sustainability, scheduling, new concepts like accelerated epics, management. And It’s not just me; whenever I ask questions about these topics, I’m met by multiple conflicting answers, confusion, links to partially completed documentation, etc… Something is really wrong.

I think we desperately need specialists now. Almost everyone should be a specialist of some kind. We can’t all be ‘I’ shaped specialists (do one thing only), but ‘T’ shaped specialists who are excellent at one thing but also with a breadth of skills for that bigger picture, and ability to work on other things if required. We need members who can dedicate most or full time to bigger picture planning, prioritising projects, managing and allocating budgets, etc. And they should be hired for those skills.

I think it was probably a good thing earlier on for everyone to be generalised and for everyone to know what was happening everywhere. It allowed for sharing the load, more redundancy (no chance of a specialist in X to be on holidays when X is on fire). But now, that isn’t really a problem. There are plenty of members so redundancy isn’t a problem. The company is also way too large for everyone to keep track of everything.

This sounds awesome!

In response to the comments about centralization and middle management: I’m not sure this would necessarily need to be the case. We already have roles for sustainability, epic management, sprint management, etc. so if a large subset of these roles were all taken by a single person, then they become a specialist, specialising in planning, prioritization, or whatever. They would be hired for taking on these roles, but not necessarily hired to be the ‘boss’ or ‘middle manager’ of a cell.

So it would remain the same as now - a collection of roles. In fact, why not make developer-related things roles as well? - ‘ops engineer role’, ‘full stack developer role’, ‘linux server management expert role’, ‘devops specialist role’, ‘aws expert’, etc. Then every member would be defined by their selection of roles and the percentage of their time that goes to each role. A ‘cell lead’ would take the sustainability manager, sprint manager, epic planning manager roles. A member who’s a dev and also likes mentoring could take ‘backend developer’ and ‘mentor’ roles. A devops specialist could take ‘devops’ and ‘ops’ roles. etc. I wonder if something like that would retain the decentralised flat structure, while allowing for devs to get on with dev, and experts in planning/management to ensure all that works smoothly?

We can still have decentralisation, but instead of a situation where ‘every member must know everything’, it could be ‘for each role or area of specialisation, at least N members must know everything’ where N is however high we want the bus factor.


This is really good to hear, thank you for posting @swalladge .

It’s a good reminder that even though we’re all hired under the same job description, and using similar review criteria, we all come from different backgrounds, and are at different places in our careers. So for some, the opportunity to take on more management roles is attractive, and learning how to run a startup might be a real bonus here. But for others (me included), I came here to do quality, open source DevOps. I didn’t come here to manage large projects, or self-organise a team. Our BIZ team has specialists for generating leads, because billing + sales ≠ DevOps. But neither do recruiting, capacity management, budget management, or project management – so what’s wrong with hiring specialists to do these roles?


The idea that managers introduce hierarchy is an outdated concept. Managers don’t order people around anymore, they facilitate the work of the team, remove blockers, provide single points of contact.

We’ve talked about this before as well, especially related to the “shared” pieces of infrastructure which we all “own” (which means no one really owns them).

It sounds a lot like the SME (Subject Matter Expert) concept that Google and other companies use. Specialization allows for excellence.



Here’s where I differ. Like @swalladge, I’m of the firm opinion that we need more specialization, not less. Wearing many hats is what you do when there’s no other option. But now it’s looking like the company is big enough to do better than that.

Also, whether you call it middle management, cell leading, or meta development, I’m with @tikr that this does not mean introducing “bosses”. It’s just that we’ll allow people to focus more on whatever it is they’re interested in pursuing, whether it be long-term goals or a particular technology.

In any case, AFAIK there is nothing in the handbook that prevents cells from just giving all those roles (sprint planning manager, sprint manager, epic planning manager, recruitment manager, sustainability manager) to a single person. I’ve also heard many times that “cells hire for themselves”, which would also allow us to hire such a specialist if noone volunteers. We’re responsible for our sustainability, so we should be able to make this decision in that same scope. So aside from some practical matters (does the cell lead firefight?), the main question I have right now is: how does a cell make decisions?

In the BTR group we use “lazy consensus” for process decisions, which basically amounts to somebody suggesting something and if nobody in the group objects in a reasonable timeframe, the suggestion is adopted in the form of an ADR. It has worked reasonably well for the roughly 10-person group. I imagine something similar could work for each cell, with the obvious differences that instead of an ADR we’d have a PR to the handbook, and that @antoviaque and @braden have implicit veto power. :slight_smile:

Any objections to handling this at the cell level? This could lead to small variations in how each cell works, but that may be a good thing. At the very least, if only one cell takes the idea up, it’ll serve as an experiment. :man_shrugging:

Could have fooled me, @swalladge . I’ve seen you pull off some crazy shit! :slight_smile:

I’m feeling more confident after reading the responses of @jill , @adolfo , @swalladge , and @tikr that this is an idea that is worth pursuing. In fact after reflecting on it, I had the same thought that Adolfo did here:

In fact, if I recall, the handbook even specifically says that a person may have multiple roles.

I think this is a solid approach to this problem.

As far as I’m concerned, cell-level experimentation is a key feature of cells that we have leveraged before and should continue to do.

For clarity, I wasn’t expecting EVERY cell member to know how to do anything, but was expressing the need to retain this degree of redundancy. My fear was that we would centralize too many cell planning features without redundancy, which would lead to a potential hierarchy forming by virtue of there being one specialist that had outsized control over cell direction.

There are a handful of questions that I think we need to address for this role’s case:

  1. Does anyone on the @team actually have an interest in taking this position? We’ve talked in theoretics about having someone from the team fill this role, and it seems to me that would still be the best option, but one thing I’m reading between the lines is that this person is going to ‘do all the things we don’t want to do’, which means this person will likely have to be hired out. Then again, as pointed out, I was probably the only one on the team willing to take the BizDev role for my own reasons. Maybe someone has (as of yet) unstated reasons for wanting this position.
  2. If we DO hire outside it’s worth noting that this position is going to look a lot like middle-management to most applicants. It’s going to take some work to craft the role in such a way that it comes clear what responsibilities/powers this person has and how they fit into the organization so they understand it to be a support role. @jill may be correct that the idea of managers not introducing hierarchy should be considered an outdated concept, but how far has this new paradigm penetrated the market? Everywhere I’ve worked aside from here, managers have been hierarchical.
  3. How will redundancy be assured? I feel like keeping the three separate roles would still be a good thing, and we just assign them to one person in practice. Then, we have other team members be backup, who are kept abreast of their slice of process. If this person goes on vacation or is hit by a bus, we’d still have our redundancy. And we’d also have additional voices to push back on decisions that would otherwise tend to be unilateral because only one person had a bunch of the knowledge.

The main thing that prevents hierarchies from forming is the ability for other team members to act as a check on power. Hierarchies form as a matter of course when not actively planned against. So having redundant access and understanding of processes is going to be key here, even if we have one person be the driver of this role. If we can solve that I have no issue with this role being made.

If it weren’t for LabXchange, which is my shot at specializing on a single project for a long stretch, I totally would. I enjoyed recruiting and the planning that went with it, for instance. But I did not enjoy the context switching in doing it and coding and managing multiple epics.

(I can totally imagine leading a “LabXchange cell” of 4-5 developers while also managing the titular epic - it looks like there’s going to be enough budget for a cell like that to last 5 years - but that’s probably too drastic an experiment to suggest now. I’ll come back to it next month. ;)

(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. :frowning_face: 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:


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 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.


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?


… but diluting responsibility in the process. My hypothesis is that this worked before because there were fewer projects, fewer people, and the central leadership that does exist (you and @braden) was closer to the day-to-day of the company. If I were to go about proving this hypothesis, I’d take the time to scour tickets and forums, where I’m sure I’d find numerous occasions where you or Braden stepping in made the difference in moving things forward. The trick would be in weighing the number of times this happened versus total measurable success.

I’m not interested in going that far to prove this point, though. Specially when you clearly state that it would be contrary to the path of the company.

However, I continue to maintain that dilution of responsibility is contributing to many of our current problems. I know you’re aware this category of problem exists, Xavier, because though in other contexts, I most often hear the term from you :slight_smile:. The concession I see to it in your list is the possibility of unifying epic planning and sustainability (technically, “split differently”) - which I totally support.

In any case, I’ve said my peace. When/if @tikr starts tackling management and/or process iteration, I’ll be glad to contribute with specific ideas for improvement.

@adolfo If there are areas where there is some dilution of responsibility, we should definitely look into it, and solve that. The idea of the roles is that they clearly define who is responsible for what – precisely to avoid that issue, where everyone would be responsible for something, and thus nobody would. Dilution of responsibility != decentralizing, we can decentralize without diluting the responsibilities as long as we are careful to always assign them to specific people, and that we put in place the right workflows for dependencies.

As for the fact that Braden and me were stepping in more before, that’s likely true – though for many things it hasn’t been the case in a while, and before the current availability issue it wasn’t a problem. We have more projects, but since cells are built to handle them independently, it should be able to scale linearly (at least, as long at we don’t try to juggle them between cells, in which case it does become very messy).

There are challenges in delegating some of the responsibilities that Braden and me used to handle, but that’s to be expected - I was actually pretty surprised that these changes had gone so easily so far. It’s bad timing that we have to solve them and iterate in the middle of a capacity crisis, but at the same time this is probably in large part what makes them painful enough to force us to address them. It would still be too bad to stop and abandon the idea when it faces its first big challenge.