@nizar Thanks for the proposal.
Your proposal was also clarified in the video call you had with Fox (https://forum.opencraft.com/t/re-assigning-my-responsibilities-before-leaving/1236/2). I think that’s a good addition, since these type of changes are easier to discuss by speaking than by writing. In that call you mentioned that it could be posted at the forum. So if others are interested, they can watch it.
About your proposal. I grouped my answers by topic, but I’m replying to different people and different sections of the document.
Cell responsibilities and metawork
- I agree with the comments about cell size and roles. If there are more roles than people in the cell, it means everybody gets roles. Rotations like firefighting also become very frequent in a small cell. These topics (cell size, amount of roles) were discussed in the survey about work and metawork and some roles were merged.
- That survey may have produced more changes so it could be a good time to follow up on it
- In a very small cell, capacity changes are noticeable. The effect will be much stronger in project cells: e.g. if there are 3 people in a cell, and 1 person takes holiday to relax from a stressful sprint, then the remaining 2 have more work
Surviving/Stress/Burnout
Members, lately, are dedicating most of their effort and focus towards “surviving” or accomplishing their handbook-defined responsibilities to avoid spillovers.
„Surviving“ to avoid spill-overs has been a very common style of work, even before cells.
When we did 1-week sprints and sprint meetings, a lot of the work happened in the hours before the meetings. Many tasks were reviewed and closed minutes before the end of the sprint.
This has been improved thanks to doing 2-week sprints, and to removing the meetings.
But we also introduced new checklists and deadlines, so the concept of „surviving“ still applies. I think there were discussions to try to help people to do things earlier instead of at the last minute. We’re still seeing that we need to ping people to submit a form, create the social chat, post the ops log, plan the sprint, post a video update, etc.
Instead of blaming people for not doing everything, we could try to understand why or when it’s hard to survive the deadlines, and try to support people.
The „developer advocate“/„pursuer“ role could help.
Role Based Cells
I think the main difference that you are proposing (vs. the current situation with „roles“) is that, in your proposal, people could focus on only doing the role they’ve chosen, with additional tasks being optional.
For instance, someone with the role of „recruitment“ does mainly that, and then if they have time they can help in other tasks, take epics etc.
That would make choosing roles much more intentional, with people taking the roles they want, instead of being forced to take roles (and epics, and clients, and rotations) because the cell is small and someone needs to take the roles.
There’s still the question of „who takes the roles that nobody wants to take“, and I think that with a bigger team, and support cells, there will be more chances of finding someone to take them.
I think another difference you propose is that those roles would be company-wide, so that there wouldn’t need to be a recruitment role inside each cell, but just one group of people in the company to assist all cells.
This looks like „departments“ inside a company and I wonder if we’re slowly rediscovering that. Sales department, accounting department, hiring department, designers, …
There’s a struggle here, because the current structure involves having each cell be more self-sufficient (like a mini-OpenCraft). Though we don’t have a marketing role in each cell, or a prospects role, or a design department in each cell.
It will be interesting to see which roles are inside cells and which roles are in support cells (outside development cells); I’ll track how OpenCraft does it in the future.
Sustainability is complex even with 3 cells, and it will get much more complex with project cells. I’d recommend ignoring detailed calculations about sustainability, at least until the sustainability dashboard can do all the tedious work.
A simpler rule of thumb, like „the company should take much more billed work than unbilled work“, can suffice until then.
Devops cell
By having a project-based DevOps cell, things can be much more organized and members can work much more efficiently without unnecessary context switches.
By the way, there was already a „devops subteam“ when we had subteams.
It doesn’t mean that they worked just in devops tasks.
I don’t remember why subteams were removed.
I found https://forum.opencraft.com/t/new-plan-for-subteams-epic-management/33 but didn’t have time to relearn that part of history.
It looks like a a reason to remove subteams was that they caused „team fragmentation“. Well, cells are doing that too!
Documentation cell
As others mentioned, a „documentation cell“ may be too ambitious, and in addition everyone must do a bit of documentation. But if we expand the scope, and by „documentation“ we mean rules, processes and metawork, then there’s enough work for a person. Some duties in these areas are:
- simplifying (reducing/removing) processes
- meeting with newcomers that went through the onboarding course and handbook, and applying their feedback. Same, for people who are leaving the company
- tracking the parts that are easily skipped or forgotten by newcomers or core (e.g. candidates that don’t learn about the right time-logging practices and are rejected because of that)
- making sure all processes are at least mentioned in the documentation (e.g. right now, trial projects and accelerated epics are 2 important processes we follow, that are not documented in the handbook)
- keeping documentation and processes up to date and pinging others
- automating
- etc.
Pursuers
They look very similar. I don’t mind the name, but let’s define the roles by the functions they do. If we don’t scope the functions, they can change and the spirit of the idea of lost. E.g. the „developer advocate“, someone who had to care about developers’ well-being, was dilluted into a role about collaborating with edX and the community.
I think (and I’m guessing a bit) that in your proposal you expect that a pursuer role would be very temporary, and focus on just one problem at a time and work until it’s fixed (hence the name, I suppose). This is in contrast to the permanent roles and duties of the current cell roles.
(It’s also in contrast with just reporting problems —e.g. in sprint retrospective or stress reports— and not pursuing it).
Combining it with your proposal of role-based cells, we could have a pursuer cell (or problem-fixing cell, or any other name), which supports all cells. I think we have a support cell experiment going on (I don’t know).
Whatever the way it’s implemented, I only wish for having someone actively fixing problems that affect the team.
Proposal, in general
Here’s a possible relationship: Someone (like the developer advocate) should be watching that all the attempts are being implemented and producing good results.
If there isn’t a person pushing them forward, sometimes they lose steam (see for instance how we stopped doing sprint retrospectives).
In order to better prioritize client work, internal projects, and internal issues, it’s important to introduce three new specialized cells: client based cells, project based cells and role based cells.
I’d prefer not to expand the already large handbook with new roles and knowledge.
If we have to change processes, I’d suggest changing some (maybe by opening a PR to change the affected sections), or making more processes optional
But we could start with practical steps first, like for instance having someone taking care of everything you mentioned, but without having to rewrite the handbook yet.
For instance, let’s try having the new developer advocate role spend some time fixing problems, and doing lots of small changes.
If it works, that itself may be enough. If at some point the developer advocate feels blocked because structural changes are required, then we can discuss them. Otherwise, so many PRs could create a lot of metawork for everyone else, and we also wanted to avoid this metawork.
Apparently the changes also need to go slowly, to give time to the recent changes (project cells etc.).
Though I feel that the „project cells“ was complex and not very well defined, and I wouldn’t mind replacing it by something simpler now instead of having to wait until it cracks.
Before any next steps are taken, opinions and comments need to be received about the proposition. Once the proposition has been discussed among members, the future steps can be decided.
@nizar Note that not everyone participates in discussions like this one. Some of them may have time just to read but not to answer. Others prefer to reduce the amount of metawork.
@nizar Thanks again for the discussions!
I hope some of them produce changes.