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! 
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 
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.
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 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 )
- 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. 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:
- What does it mean for a cell to want something?
- 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
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.
3 Likes