Organizational Structure Changes: Group Leaders!

Up to this point, we haven’t had much of an organizational structure: we’ve had three leads, and… that’s about it. But we’re expanding! We’ve had an explosion of new people in the last two weeks, and huge amounts of enthusiasm to contribute, and to be perfectly honest, keeping up has got hard going! So: we’re expanding organizational structure as well.

Here’s the new structure in a convenient diagram:

In reality, things are much flatter than that makes it look. Here’s a run-down of it:

  • Team Lead is responsible for overall progress, coordinating and communicating between technical and documentation and other areas that come up
  • Docs Lead is responsible for all aspects of our documentation: at the moment, that’s specification and requirements, but as we build there’s going to be much more that needs documenting.
  • Tech Lead is responsible for the technical side of things. That’s a big role: frontend, backend, sysadmin, DBA, etc etc.

We now also have Group Leaders. These folks are responsible for taking ownership and management of a particular aspect of Codidact; the leads are taking a step back here to enable them to coordinate over the bigger picture, and the group leaders will take the day-to-day running and decisions necessary for their area. These folks may also select Project Leaders if they need someone to manage a larger task in their area but don’t have the bandwidth to do so themselves.

The Admins are an administrative function that sits somewhere around the group leader level - they have no responsibility for a particular area, but help keep things ticking over by handling the pushing of buttons and granting of roles and accesses and such that keeps things running smoothly.

To be clear: this structure is a guideline, but we’re not forcing anyone to stick to their roles and only their roles - I do a bunch of stuff that’s outside of my role description, as do many of our admins, as will, I suspect, many of our group leaders. This is a volunteer thing - yes, we’re building a thing, but it’s meant to be fun: do what interests you!

We’re still in the process of figuring out what Group Leader roles we need. @mattjbrent has agreed to take on the Group Leader role for Design, but we’ll need more folks to take on these roles. If you’re interested, please ping @Admin in our Discord server.


I don’t have experience with this for open source projects, but in a professional setting, the direct lines from top to bottom would worry me - it’s the visual representation for micro management.

I remember a blog post from Joel Spolsky telling about his experience at Microsoft; something along the lines “the managers’ job is not to be the “boss”, but rather to move the furniture out of the way so that the engineers aren’t disturbed in doing what they do best”.

The only one of the leads I had a (verbal) talk with is Marc and he seemed like your typical enthusiastic-about-code programmer. Now that there’s 2 layers in between him and contributors, is he willing to say “My first priority now is enabling others to code, then if time is left I can do some myself”?
Because the arrow there indicates the opposite.

And the situation is the same for the other 2 leads; how much will the Team Lead and Docs Lead still argue for their opinions in discussions? Seems like something that could kill a lot of discussion. Not willingly, but just by people seeing “oh, the team lead already said he doesn’t want that”

But again, that is a professional viewpoint, whereas this project is FOSS.
How will this be handled here?

Those arrows are a thing I put in because this is still a small project. It’s small enough that structure is somewhat flexible, and folks may act in multiple roles and cover for others if they’re not available. Take me, for example: have a look at my roles in Discord, and it’ll show you this (abridged):

  • Team lead
  • Admin
  • GitHub admin
  • Project Leader: QPixel
  • Contributor (plus various specifiers)

My main job here is sticking things together and co-ordinating so that the project as a whole works. As part of that, I have Admin and GitHub admin privileges, which help me to do that job, but also mean I can help the admins/GH admins in their role if they need a hand. I’m also a project leader for QPixel, because that made sense. If I’m not doing something else, I also contribute directly in various areas. Beyond that, I’m also acting as a group lead for various teams that don’t yet need a dedicated lead - security comes to mind.

It’s the same for each lead, and more than likely the same for each group lead as well; those connections across multiple levels are there to indicate that as part of the various things each of those people do, they’ll be working with different folks - sometimes it’ll be that furniture-moving so that a group lead can get on with something, and other times it’ll be working with some of the direct contributors writing some code.