The Future of Business/Meta roles at OpenCraft

Ticket to Log Time

Hello, @team!

My onboarding to the Business Development team has presented an opportunity to review some of our existing processes and consider them in light of our continued growth. Up until now we’ve had only a few business-primary team members-- @antoviaque, @braden, and @gabriel. This ‘meta-cell’, if it could be called that, has grown by two more people recently, myself and @douglas.

It might be a misnomer to call it a ‘meta-cell’ at this point. A lot of processes have been the domain of one person, and, not having to share tasks in the same way as traditional cells, members of this meta cell have typically been able to handle work and organize it in a way that only needs to cater to their own needs.

However as we grow we’re now having to share more of the tasks between each other and we find ourselves at a crossroads. The original vision of OpenCraft’s cell structure was that there would be a ‘complete OpenCraft’ in each cell-- each cell self-sufficient, as much as possible, with Xavier and Braden standing outside (if memory serves, Braden became CTO shortly before I left, and I left just before the first cell split). This already violated the idea somewhat, but it was not such a big deal.

However now that we have a team size big enough for us to be properly planning out sprints in this ‘meta-cell’, it begs the question of whether we should officially make it a cell, just of a different kind, or if some or all of its members should be distributed amount the existing cells in some way.

One wrinkle in this is that although we remain a mostly flat organization, the tie-breaking aspect of Xavier’s leadership position remains useful and so he probably shouldn’t be placed in ‘one cell’. However especially as it comes to business development or other tasks, it’s conceivable that there could be a ‘business development specialist’ in each cell, for instance. And perhaps even someone to handle invoicing for each cell.

But you doubtless notice the other problem there-- at this point we do not have two business development specialists and two billing specialists. There’s just one of each of us. @douglas’s addition to the team, helping us with improving our sales capabilities, is still being defined as we go.

This means that we could go ahead and make the ‘meta-cell’ now, with its own processes and procedures, but if we want to continue the paradigm of ‘each cell a mini-OpenCraft’ then we’d have to wait for further growth before we could fan out individuals to both cells.

The way I see it, we have three options:

  1. We go forward with the meta-cell becoming its own ‘tissue’, separate from developer ‘tissue’.
  2. We wait for a bit more growth and then find a way to integrate these meta-roles into the existing cells in such a way that each cell has its own specialists in this area.
  3. Something ‘in-between’ where we let the meta-cell be defined, but when we split it, we assign each meta-cell its own companion development cell.

Some factors for consideration:

  • Part of the reason why the idea of each cell being self-sufficient is appealing is because it prevents divisions and encourages the flat structure we’ve come to enjoy. Meta-cells might have a feel of hierarchy when none is meant or may at the very least result in a feeling of ‘other’ rather than close collaboration.
  • Meta members currently work on one-week sprints, which are more reactive to the people-oriented needs of interacting directly with clients. The original development sprints were one week long but were extended to two because of how frustrating it became to break some tasks down to one-week chunks (someone may have to confirm on that-- I think they were lengthened after I left). So neither sprint length is ‘best’ for both parties.
  • I could be wrong about Xavier’s role being special and maybe we could make each cell completely self-contained. If that’s the case, since I have one foot still in Serenity, I call dibs on @antoviaque’s left half. :)

The most important thing I’d like out of this discussion is a sense of which direction we should go, and some ideas of how to resolve some of the challenges that the direction may present. It might be that, depending on our decision, we can’t act to carry out our vision today, but if we can get an idea of where we’re going, we can use that both to inform intermediary processes and hiring going forward.


I feel like it might be a bit too early to decide, and we should “see how it goes” first, or try some different approaches. Are you hitting any pain points now? I’m unclear what problem we’re trying to solve, other than the minor perceived conflict between the original cell vision and having 4 or 5 people outside of cells, which is more a theoretical than actual problem (for now).

Why Microsoft’s Reorganization Is a Bad Idea is a classic blog post about some of these ideas on company organization, whether each cell should be “complete” or not. My read from that is that as long as all the cells are doing similar work and involving Open edX, it may be better to keep biz dev expertise separate or in its own cell.

1 Like

It’s just starting to become practical since we now have enough people working together that we’re starting our own sprints with sprint planning meetings. Our first one is this coming Monday. The reason I’m querying now is that I’m now documenting and creating processes as we begin this team, and how I go about it will be influenced by whether I expect our team to eventually be incorporated into cells or to stay its own separate unit.

I’m expecting that we’ll need to make further hires (or transitioners) that fit into this pool sooner rather than later, so I’d rather have it in mind moving forward.

+1 to take our time on this topic, and focus on small steps that solve concrete issues we face – like for example allowing you to use similar planning tools and techniques as you did before as a developer, ie expanding the good practices we developed there to the rest of the team. As discussed in BIZ-1639, for the deeper issue about how to structure the company outside of developer roles, I want to take the time think a bit more about this.

I read the lessons from this article a bit differently – the structure of a self-sufficient “mini-OpenCraft” per cell/team seems like pushing further the divisional approach. Each cell can be seen as its own division, self-sufficient, with its P&L (the sustainability ratio), its own development team, sales, etc. While removing some of the roles from the cells and spreading those resources between all cells seem closer to the functional approach, where it is “organized by function”, ie which part of the organization one belongs to is dictated by the type of role held (developer vs bizdev), and one bizdev works across many unrelated projects/cells.

I agree with your breakdown, but I thought what the article was saying was that a functional approach works better when the teams are doing similar work, and the divisional approach works better when the teams are doing quite different work (e.g. if we had one cell selling the new workflow manager to individuals as SaaS, and another cell selling Open edX hosting to universities, then divisional makes more sense). But anyhow, it’s just one article and these things have been debated both ways - it’s important to do what seems to work best for us.

1 Like

Jumping in here to add wood to the fire. It’s something that’s been on my mind after working on SE-4147, an Ocim infrastructure investigation, as a devops specialist from Serenity, in collaboration with @giovannicimolin as a devops specialist from Bebop.

Simply put, while OpenCraft is quickly becoming divisional via cells, each with their own P&L, Ocim is exactly the opposite: its goal is to be used as the basis of infrastructure for all Open edX projects in the company, and is run at a loss. This introduces a cascade of problems:

  1. A developer that is interested in (or required to, as devops specialist) furthering Ocim may not be able to do it because their cell is not currently sustainable enough to do it.

  2. Because working on Ocim always decreases sustainability, coordinating work between different cells is difficult: there’s a counter-incentive to do it.

  3. Because the work then falls to the cell with the most sustainability, knowledge about Ocim starts to get concentrated, reducing the efficiency of other cells when working on it, making them even less likely to be able to take on the work.

  4. (Purely theoretically) The cell with the most sustainability may not be host to the people most interested in working on Ocim-related tasks, which may result in quality which could have otherwise been better.

I could go on. The best example is SE-4147 itself. I’m about to the scolded by @daniel as Serenity’s sustanability manager for spending so much time on it, but somebody needed to do it and I was essentially the most interested - so I took the lead. It was orthogonal to regular sprint work: @antoviaque had to step in to help push tickets out of mine and @giovannicimolin’s sprints.

This latter occurrence, and the fact that devops (which is 90% Ocim) work usually happens more slowly than anything else at OpenCraft, and the fact that some of it had to be accelerated artificially via non-cell budgets, suggests that something’s wrong, organizationally - which is why I’m posting in this thread.

Maybe OpenCraft has grown enough to graduate from being a startup (as described in the article), and needs to own up to being either divisional or functional, and proceed accordingly. Trying to be both is probably not going to scale very well, IMHO.

To be clear, I’m very much in favor of taking the divisional approach to it’s ultimate consequences: which, in Ocim’s case, means giving it to an epic owner in a cell.