Cell leads

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.


Yes, we can do this. I’ll adjust course and throttle down the selling for the moment.

1 Like

Next sprint (253), Cassie and I are getting back to work on the Workflow Manager, Sprints v2, Billing v2 (and Open edX Theming, which is unrelated to this discussion). Needless to say, we will have a lot on our plates during the coming weeks! That said, some of the issues discussed in this thread are closely related to these projects, and I believe some will be alleviated once these applications are at a stage in which they are usable.

I have scheduled time during 254 to revisit this thread. By then, we should have a better idea about which issues fall with the scope of these projects, and which would require a separate solution. At that point, we’ll decide on the best way to collect feedback and make suggestions.

Does that work for you @antoviaque ?

P.s. As difficult as they are, growing pains are a sign of, well, growth, so congratulations on OpenCraft’s success! :tada:

1 Like

(I’m on vacation, but this thread is fascinating!)

+1 to this. This team is doing stellar work, but project management is an area where we can vastly improve. I think including more proper project management in our projects (lots of Ps here) would make things go smoother, reduce stress, and it would also help lubricate the gears between dev and admin/billing. I don’t think we need to add a whole lot of project management steps/processes in how we manage projects; but a few key items here and there would go a long way. I’ve taken multiple trainings in PM, and would be interested in taking on a PM role for a project too (and help document it along with @tikr, if he’s interested in taking the role).

1 Like

Thanks for the kind words @antoviaque :slight_smile: I’d love to do what I can to help improve our processes, and I’m definitely open to trying out something like the support role for project management that you mentioned.

Regarding timing, I agree that it would make sense to start the process of gathering ideas and feedback on specific pain points sooner rather than later. I can kick that off next sprint. Next steps (including adding my own ideas) will have to wait until the second half of September, though, because of the amount of time and focus that Campus currently requires.

At that point I will probably also need to start transitioning out of some of the roles that I currently have (client ownership for Campus being one of them), so that I can focus more fully on process improvement efforts.

@adolfo @gabriel That’s good to know, thanks guys!


Perfect, thanks! Note that if the project seem to be a bit more long term (at least a few months away), it could still be good to pursue, as many leads take a very long time to bring fruit – the important bit is to not overpromise our availability to new leads/clients. We should prioritize new projects from existing clients though, to not end up losing them to other providers, too.

Perfect, thank you! And just in terms of priority, note that this is affecting the team negatively at the moment, so if there is a choice to make between another internal / accelerated task or project and this, this would come first.

That’s great to hear! I think part of the work @tikr would do would be to clarify what the role of project managers could be. If you are interested, it could make sense to work with @tikr on this – if you have time ahead of September when @tikr you’ll be more free, that could be a way to start making progress earlier? Ie help with the feedback gathering, and starting to make a concrete proposal (ie a merge requrest against the handbook)? @tikr I’ll let you lead this and coordinate, but given the current pressure on the team, the earlier we make progress, the better.

Thanks @tikr! That sounds perfect. :+1:

1 Like

I’m happy to see this happening, but what I’m most concerned about is the cell lead role that this thread was started for.

This might be true for some people, but it’s not true for me. I agreed with this idea when it was just DevOps and client management – that gave us a solid edge. But not when we’re managing cell budgets and deciding hiring and sustainability and everything else. These are a distraction from what I’d rather be doing with my career, and they’re impinging on my focus.

Managing hiring, projects, and sustainability are all intricately intertwined, and it makes solid sense to have a full time person (or people!) deal with these, at least within each cell. Whether these people come from our existing engineering core or whether we hire specialists is up to individuals on the team.

One way to make this happen without having to rewrite the handbook is to ask if there’s one person on each cell who wants to take on multiple cell management roles. If not, then as a self-managing cell, we can decide whether to hire a specialist to do that. Each cell can decide this for themselves, but I’m on Falcon, so I’ll start there.

@falcon team members, would you mind answering this poll? (other cells are welcome to answer this too :slight_smile: )

  • I want to be the cell sustainability + epic manager + recruitment manager and transfer my DevOps tasks and epics to someone else.
  • I want to be the cell sustainability + epic manager and transfer some of my DevOps tasks and epics to someone else.
  • I want to do DevOps and manage my epics/clients, and let someone else manage the cell.
  • I want to do pure DevOps, and let other people manage the epics/clients and the cell.
  • I want things to stay the same: cell management duties, DevOps and client/project management are spread evenly among everyone.
  • I want something else (please clarify in comments).

0 voters


Ok, noted. We will come up with a game plan and tackle this next sprint ahead of the other projects.

I quite like Jill’s idea of using a survey. Perhaps we’ll put together a survey covering all the points mentioned above; I think this would make it nice and easy for everyone to provide their feedback and additional concerns. We’ll come up with the best approach early next week and share it with the team.