Cell leads

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

I’m feeling more confident after reading the responses of @jill , @adolfo , @anon46505572 , 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:

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?

2 Likes

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

4 Likes

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!

3 Likes

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

3 Likes

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.

If that’s the case, then it could be worth looking into passing or exchanging your epic planning management role with someone else, who might like to deal with those aspects more? This is the role that is the most involved with budgets, and as you note it has a lot of links with the sustainability and hiring roles. If you don’t like those aspects, I can completely imagine this being a huge burden on your every day work. And whether within the current core team, or among the upcoming core team members we are working on hiring, there will likely be someone who would like it more? And the supporting project manager role we are discussing could also help lightening the load on those roles.

To clarify that point in case my previous post didn’t make it clear - we are not going to go the route of cell leads by concentrating multiple roles into one lead. This would effectively be a 180 degrees away from self-management, and even if we were to decide one day that self-management isn’t for us, these are not the right circumstances to take this kind of decision. We first need to solve the availability issue, iterate over our processes based on our recent experience, maybe reshuffle the roles for those who don’t enjoy their current role, and see how the support of project management roles help lightening the coordination load and allow to focus more on code. Otherwise we’ll never know if we could have fixed it. @tikr @Ali @gabriel This is what you will need to focus on, to collect feedback and establish proposals on how to do it.

I know currently the situation is difficult – but this isn’t the first time we end up in a difficult situation, no? We have successfully managed challenges in the past, without necessarily falling back to the norm. We can do this again. I know that the issue has dragged for some time, and that it requires a lot of effort – doing something new requires more effort. At the end though, this kind of efforts and persistence tend to pay up multiple times. We didn’t get OpenCraft to become what it is by taking the easiest road.

1 Like

Yes, it has. And the acceleration you proposed in the 2021 document, while laudable, doesn’t seem to be helping the stalled issues. Yes, the hypothesis is that this was because of he capacity crisis, which @braden’s new recruitment effort is meant to counteract.

But what if we need more than that? I agree that centralized management is only one possible solution, and I have no desire to continue pressing it. But how about if the sustainability calculation for accelerated epics were changed so that hours spent there counted as billable? At the very least, this would remove from capacity/sustainability management the need to deprioritize them vs. client epics. We could then better justify hiring for them as well. And, psychologically, it would be abundantly clear that that work should be dealt with exactly as it should with a bonafide client.

The hypothesis is that this would result in us getting the tools to minimize the price we pay for self-management (because we definitely are paying for it) sooner.

1 Like

+1

That would be nice for the cells sustainability calculations for sure – but since this is time that isn’t billable, it would falsify the whole calculation, pushing it away from reality?

The thing is, sometimes we have to make choices and decide on priorities between the two categories. And while we want to treat our internal epics better than we have done in the past, when we don’t have enough time for both client epics and internal epics, it still makes sense to prioritize the work that’s being billed – thus the difference between the two. Imagine if now all the accelerated epics were client epics (or prioritized at the same level), it would be even more of a crisis no? It’s not like if we had stopped recruiting since we established the accelerated epics?

As for the motivation & justification of working on the accelerated epics for the cells, I don’t think I completely understand what is missing in that regard currently - what am I not seeing? The reasoning is that the accelerated epics help our own work (automating to reduce the overhead of manual & planning work, handling some of the tech debt with Ocim) or allow to work on new cool open source projects (which might one day provide their own source of billing hours for internal projects, if some of them are successful) – these should provide their own intrinsic reward and appeal no? Sure, it doesn’t affect sustainability (so are less of an extrinsic reward, maybe) – but it’s already a big gain compared to working on internal projects which do affect sustainability, but negatively?

As for the incentive for recruitment – the main one is that they provide buffer work to allow to generate an increased availability margin. Which is useful for sustainability (it allows to more readily accept new client projects – passing on opportunities, like in the current situation, means less billed hours), and also to become more resilient against becoming overloaded/overcapacity like currently. Aren’t those huge advantages and reasons for cells to want to take on accelerated epics?

Good question. (No sarcasm.) Please indulge me as I take a step back. We’ve been having discussions on several fronts, now, all stemming from organizational difficulties that are pretty self-evident. The arguments you’ve given in defense of what I’m calling The Blueprint are all very good: it means the plan was put in motion with careful thought, which is reassuring. Thank you for that - both for actually thinking ahead, and for taking the time to explaining the reasoning.

However, we can’t dodge the fact that The Blueprint isn’t perfect, either in principle or execution, or both. I’ve been making suggestions that have clearly challenged a couple of the principles (cell leadership, member movement between cells, changes in sustainability calculations), while you’ve been generally countering that the problem is actually either situational or in execution.

I’ll grant you that it makes total sense to tweak execution before toppling principles. So let’s do that. But it’s difficult to even suggest tweaks such as the one I just did (change the sustainability calculation), because, to finally answer your question, you see a whole lot. :slight_smile: You’ve evidently thought of this before.

BUT…

This an example of where I see a disconnect between principle and execution. In the majority of companies, answering this question would amount to asking team leads. But as things stand, I can’t answer the question because I don’t know:

  1. What does it mean for a cell to want something?
  2. To what extent can a cell want something?

Earlier in the thread I asked a related question (“how does a cell make decisions?”), and @jill answered indirectly by suggesting a poll - one that was unceremoniously cut short. It shed a little light on Question 2 (we can’t decide to unify roles), but still both questions remain: one of process, one of limitations. As more is delegated to the cell, I believe answering them clearly is paramount.

To give examples of situations I’ve faced personally where the answer would be important:

  • How does a cell decide when to hire more people? Is it the recruitment manager’s responsibility, or the sustainability manager’s, or the capacity manager’s? Is it all of them together? In the latter case, is there a prescribed process to do so? If not, are we free to self-organize and make a strategic decision without C-level approval? If so, to what extent?

  • How should a cell handle a core member’s unannounced performance dip? Who’s responsible for keeping tabs on whether individual members are doing ok, and in case they’re not… What then?

  • Can two cells agree to exchange members, or for one to donate a member to another? If so, how is this decision reached? If not, shouldn’t this limitation be documented in the handbook?

  • Can cells swap epics, say, in case of not having enough capacity or sustainability? What happens in case of an impass?

  • What happens when there are no volunteers for a role? For a client epic, that means the cell is “passing” on it, which I’ve seen happen. But I’ve seen roles get perilously close to abandonment. Who’s responsible for making sure this doesn’t happen?

In democracies, such unforeseen questions are answered by judges and juries, with the caveat that it takes a long time and it is very expensive to do so in every case. (Plus, it requires lawyers to make it work.) We need to be faster than that: this is a for-profit company in a market with competitors. Sure, I believe it’s possible to achieve enough efficiency without cell leads… but how?

The handbook is pretty clear that this is the responsibility of the epic planning manager, and the process is pretty clearly defined?

The epic planning managers are responsible for determining when the availability needs of their cells will require to launch a recruitment round. (src)

The recruitment manager role is responsible for organizing the selection of candidate hires to match the needs of…the cell, as determined by the epic planning manager. (src)

And as a reminder, if you see some inefficiencies in how the roles are currently split, we should revisit them: Process Iteration


I think there’s been a discussion of this already, that this is something we need to add to our processes that doesn’t currently fall under anyone’s responsibility, other than of course Xavier who tries to do 121s with people on both a regular and an as-needed basis. With his vacation, now would be a particularly good time to experiment with someone else doing this, if there is interest.

Re your other questions, I’m not sure if there is a clear answer yet, so next time it happens is a good opportunity to open a handbook PR with your proposed approach. The principle we try to follow is that the people who are involved/affected should be proposing the approach to try, which is aligned with the general principle @antoviaque mentioned:


There is a process defined in the handbook: Making Decisions. And there was a huge discussion around this process and these principles when they were first introduced: https://forum.opencraft.com/t/opencraft-v3-scaling-up-some-self-management/141


BTW this is something that I personally think is important right now. As time has gone on, we’ve accumulated a lot of processes and overhead. A natural first instinct is to add more, more processes, more rules, more structure, more management, but if there’s a way to improve things by doing less, that’s even better. Case in point, my proposed simplification of our trial period to a trial project, or the proposed consolidation of sustainability and epic planning managers, etc. Another example: we have community support, OSPR liaison, official forum moderator(s), community liaison, and core committers - perhaps there’s some overlap there that we can simplify.

2 Likes

23 posts were split to a new topic: Team Survey - Pain Points

I’ve been meaning to chime in here for a while now, but I’m afraid every time I try to the conversation has moved forward a lot, and I don’t get time to go through it all. I’ve had some thoughts about distributed responsibility, cell sizes and roles. They may have already been addressed, in which case I’m sorry to bring them up again.

What I’m seeing is a conflict based on the following factors:

  • Cells are meant to be small, they’ll usually start at 6 and go up to 12 at most. Ideally they’d be around 8 members.
  • There is an increasing number of roles, 8, possibly more.
  • Not everyone wants a role. Some people are happy with more management, others with less.
  • So you have 8 roles distributed to anywhere between 4 and 8 people.
  • Not every epic or client has the same size or contribution to a cell.
  • Some roles need more context from other roles than others. The OSPR liaison doesn’t really need to deal with recruitment, for instance. On the other hand, as @antoviaque mentioned, epic manager and sustainability manager are very closely linked.

The end result is that you necessarily have some people juggling multiple roles, and potentially clients/projects.

What I feel is that having people take multiple roles is unavoidable, so we should try to reduce the number of roles by combining existing roles that work better together. This will reduce some meta-work that comes from communicating between these roles as well.

A long time ago, back when I took the epic manager role, I was also the client owner for Yonkers, and they were responsible for the majority of the client work in the cell, at times accounting for 2/3rds of the cell’s hours. Having two big roles should have made things harder for, but in retrospect I realise it did the opposite. The fact that I was already dealing with having context about the largest client in the cell made epic planning easy. I already had all the context from another role.

As the work from Yonkers reduced, epic planning became harder for me. Eventually, with other stuff going on in my life it because overwhelming, and I took time off from that role this year and that might be a permanent role change.

I don’t think this means that the person with the biggest client should necessarily take epic planning, but I do feel that we should keep in mind the context needed for each role, and try to reduce context sharing between roles as much as possible. If we’re redesigning roles, we should keep this in mind.

4 Likes

The Scrum Master Acts as a…

  • Servant Leader whose focus is on the needs of the team members and those they serve (the customer), with the goal of achieving results in line with the organization’s values, principles, and business objectives.

  • Facilitator by setting the stage and providing clear boundaries in which the team can collaborate.

  • Coach coaching the individual with a focus on mindset and behavior, the team in continuous improvement and the organization in truly collaborating with the Scrum Team.

  • Manager responsible for managing impediments, eliminating waste, managing the process, managing the team’s health, managing the boundaries of self‐organization, and managing the culture.

  • Mentor that transfers agile knowledge and experience to the team.

  • Teacher to ensure Scrum and other relevant methods are understood and enacted.

  • Impediment Remover solving blocking issues to the team’s progress, taking into account the self‐organizing capabilities of the Development Team.

  • Change Agent to enable a culture in which Scrum Teams can flourish.

I’m really keen on this description of the Scrum Master, which is something we might look at if we decide to go with a new role to take work developers aren’t really keen on doing.

Of course, those are specific to Scrum but the Facilitator, Manager, Mentor and Impediment Remover seems prime for this imaginary role.

ref: The 8 Stances of a Scrum Master | Scrum.org

3 Likes