We are having difficulties with capacity. How do we address this?

Ticket to log time

TL;DR: Over the last year we’ve had an incredible year of growth. However we’ve been having difficulty adding new core members at the rate we’re adding work. This is causing an overall load issue we need to address, and I’m soliciting ideas from the group. Please post them here.

I had intended to write this forum post next week but am finding that the issues that we’re seeing would benefit from this discussion starting as early as possible since they may involve taking actions that do not yield results immediately, but the problem is acute.

We have not managed to confirm a new core member in the last several months. We are working hard to recruit new members, but our high standards mixed with a low number of overall applications has meant that few have been confirmed. I’m of the mind that we cannot lower our standards-- the fact that I can hand any member a critical task and expect it to get done right is core to the camaraderie and culture of this team.

OpenCraft values its members. We have traditionally been able to provide an excellent work-life balance but this has chipped away in recent months. Since I joined, about three to four people have suddenly had to stop work due to burnout. Others are rapidly trying to shed epics or roles because they know they cannot deliver on all commitments, but are finding difficulty with others picking up the tasks.

If you’ve felt like you’re failing over the last few sprints to deliver on everything that’s expected of you, you’re not alone. While there is always some improvement to be made on time management, the organization as a whole is starting to have difficulty meeting all commitments on time. Because each individual is self-managing, those of us who have learned the hard way to rescope responsibility in the face of impossible commitments are shedding it more quickly than it can be picked back up. Those of us still learning this are quietly taking on more work and getting crushed by it until they burn out.

In the latter case, the sudden drop in hours caused by those team members dropping out can lead to cascade failures as others pick up the slack. (This is a reminder to speak up early if you’re feeling overworked! We’d rather rescope your work than you suffer psychological injury. It’s not too late to talk about it now, I promise!)

Even if we all were properly rescoping work, we would be facing long delays in starting projects due to these issues with capacity. More time is being spent on overhead managing the dwindling available time. Spending time context switching and planning like this instead of doing deep work accelerates burnout.

There are three main ways to deal with capacity issues:

  1. Increase hiring
    • We’re currently working hard on this, but as mentioned, we’ve not had members confirmed in a while. If we’re going to push this angle, it may mean rethinking how much time we allocate to recruiting, or else finding novel ways to attract talent.
  2. Rescope work
    • The traditional way we’ve handled being overloaded is by pretending OCIM and related internal tools don’t exist and otherwise deferring non-critical maintenance. This makes us all unhappy-- it often results in technical debt that becomes increasingly difficult to pay off. Aside from that, it’s been one of our goals this year to improve our internal tooling and allocate hours that we have banked to these non-billable projects.
    • Another option might be telling clients they will need to wait a few months for us to start on tasks. This could be a reputational hit, and for some clients the delay might be business critical. However we have built a great deal of goodwill and some projects that aren’t as need critical to clients may be willing to wait a bit longer since they like our quality of work and won’t want to look elsewhere.
  3. Reduce the number of incoming projects until capacity is otherwise under control.
    • This is harder than it sounds because adding new projects is like hiring: It can take a long time to get a project onboard, and it can take months (sometimes years) to land a sale of significance. Suddenly ceasing intake could resolve the problem after a while but then leave us with a drought a few months down the line, which is also bad. We haven’t had a sale in a few months, but…
    • I’m getting better and better at sales and currently have several promising leads. I might land several in short succession soon. After working these clients for an extended period I would prefer to not turn them away. Then again, there’s no guarantee any of them will sign, either.
    • I could work to communicate with clients that the start time will be delayed for new projects. That might cause some of them to turn away on their own and the patient to wait.

One thing that occurs to me is that since I haven’t yet completed a major sale, I’m a little fuzzy on the new client onboarding process. It’s my understanding that cells decide what work they will take on, but I don’t feel I have a great view of knowing which cell is likely to take on more work and how soon they can do so. Is there any standard way of doing that? If not, what are some ideas we have? They could help prevent issues like this in the future.

So-- which angle of attack sounds best to each of you? What things might we try? What things should we avoid doing?


There is a 4th way. Hire contractors who already have experience and familiarity with the Open edX platform. That said, it might be as difficult to hire one as it is to get new team members into the core team. I don’t know.


If I were to guess, harder. Those must be rare, or unavailable, or expensive. Otherwise we’d be seeing more of them.

Plus, we’re already doing it. Xavier posts on the Open edX job forum from time to time. My guess is that it’s not a very fruitful posting.

I have more to add to this thread (a lot more), but I’ll have to leave it for next week.

It occurs to me that we do a lot of posting but as far as I know-- and, recruitment managers, maybe you’re already doing this and I’m just unaware-- we haven’t looked into hiring a headhunting service that specializes in finding interested developers.

I’m sure everyone on this team gets emails from these people from time-to-time and when I was looking for contracts, I’d occasionally respond. They trawl through LinkedIn and find potential candidates proactively rather than waiting for them to apply. Maybe we should try something like that?

1 Like

I don’t know how the full internal amount of work is split between doing features and bugfixes on the Open edX stack on the one hand, and OCIM, devops, firefighting and other type of maintenance for which upstream experience is not directly translatable on the other.

Hi, I got here from a link in your job posting that I’ve seen around a few times of recent. I was a bit interested in it the first couple of times I saw it, so if it’s okay I’d like to say why I didn’t apply:

It’s nearly impossible to find any info on what a potential employee can expect. Yes, you’d work remotely with a specific set of tools, but that’s about it. The posting speaks 100% about what is expected from the person and nothing about company, team, benefits or culture. There’s a link to a handbook that also only talks about work processes. Not much about it felt welcoming. I empathize that times are hard lately, but it also isn’t encouraging to be linked to this forum, and the first post I see is from a stressed-out developer.

The work itself seems interesting but you should consider making a broader appeal in your postings/on your website if you aren’t intending to give off the vibe that potential employees will join just to be worked to the bone.


Hello, Diso!

Welcome to the forums. Your feedback is useful here-- I take it you’ve already read about our values and vision and our Open First philosophy in the handbook. You are right that compensation isn’t yet in the handbook-- we’re working on that one. Aside from those items, could you tell us more about what you would like to see in the handbook?

I’m actually one of the less stressed developers right now (in fact-- these days I do mostly sales rather than development)-- it’s my intent to make sure we don’t have issues like this continually and that we don’t leave our team members stressed out-- and not because it’s my specific ‘job’ but because I, like most (perhaps all) on the team, I take ownership of the group’s well being here.

You’ll see that we’re not sweeping the issue under the rug-- we’re facing it head on, and publicly for that matter, because we believe that instead of trying to conceal that we’re having some capacity problems, or pretending that things are perfectly rosy all the time, we’re more interested in dealing as honestly as we can about what’s happening and getting feedback from the team on how to fix it.

I would hope that the fact this thread has been made public and you see team members actively working to solve the problem should demonstrate some of our culture of openness and collaboration. However we are always striving to make things better, so if you have specific feedback on what you’d like to see in the handbook, I will schedule a ticket to add what I can to the handbook, assign it to myself (or one of the recruitment handlers, if they would like to take it), and schedule it for one of the upcoming sprints. Thanks!

Edit: Just realized a lot of what you were talking about was about the posting specifically. You’re right-- the posting could use a workover. I’m going to create a ticket for myself to add more cultural information up front. Right now it does seem intensely generic. Thank you for this feedback!

Thank you so much for replying here @diso! This is really useful feedback.

It’s totally true that we’re not very good at emphasizing the positives about working for OpenCraft on this forum – and there are many. We’re engineers, and so we focus on problems, not the good stuff :slight_smile: We can get better at that.

Maybe a rewrite/refocus of some of the introduction and values areas of our handbook? There’s a lot of technical/process detail in there, but the culture stuff doesn’t get much revision.

Adjusting start dates could buy us some time, so that’s not a bad suggestion. But it doesn’t fix the issue, so it would have to be in combination with other things.

Can we slow down any of our existing large projects by reducing the monthly number of hours committed?

Yep, it’s a goal, and our targets are ambitious, based (I think) on capacity increases continuing the trend started last year. But it’s still less important than client work, so if we have to drop this % down to fulfill our external commitments, we should.

Of the people we trialed who didn’t work out – did anyone have any particular criticisms that might be usefully applied? We’ve been trying to improve our onboarding process, but maybe there’s more we can do there?


I’ve scheduled https://tasks.opencraft.com/browse/BIZ-1794 for updating the job posting. It’s in review already, as it turns :)

I’ve scheduled https://tasks.opencraft.com/browse/BIZ-1796 which covers updating our handbook for the business sprint after this one (or, the next developer sprint, since BizDev sprints are one week and Dev sprints are 2).

I’d also be interested to know this.

We’ll need epic owners to chime in here. Are any of the epics you’re running able to be slowed down?

Great work on rewriting the job ad @Fox @jill :slight_smile:


On a somewhat related note: I feel like we’ve reached a pivotal point in our growth. From some time I’ve been entertaining the idea that OpenCraft should consider retaining the services of an organizational development (O.D.) consultant, specifically one that specializes in remote/software companies. It’s very niched, and therefore would probably be hard to find, but I think receiving ad hoc help from such a person could be very beneficial for OpenCraft. We’ve been able to successfully implement a number of truly ground-breaking work processes, but I think that receiving help from a HR or OD specialist could help us set the course for the future. Or maybe not, but at least we’d have tried! Anyway, my 2 cents.

This made me think a bit.

As far as I can see, all of us are proud that the small white dot at the bottom of the opencraft.com website blinks with our name on the map. We love to work with OpenCraft and we are an entertaining and welcoming community. I can say without any doubt that everyone likes to work with any of the team members, also we always eager to help each other. Despite all these, this is not represented on our “primary” (self-)marketing forum, our website.

As a newcomer or someone who is trying to get information about a company, it is among the first things to check the website. As a developer, check its quality, content, and of course, how is the culture – regardless of the organizational structure or employment type.

What do you think about having a dedicated page about – not the individuals, but – how it feels to work with OpenCraft? I think it is beneficial during the recruitment and it can give some insights even for potential customers.

Don’t take me wrong, I mean it in professional manner, not some random pictures about team buildings and similar.

@Fox I think it is a really great topic that needs attention!

PS: it is so good to see comments from outside of OpenCraft, thank you for the feedback @diso!


This is an interesting idea. Maybe we could have Fixate design something for this? We could rename the ‘Jobs’ page ‘Join Our Team’ and have a sort of overview of the company from a member’s side with nice graphics, and then links to the current postings.

This is a good idea. I think it may help us in the long term. If they are highly specialized, though, it may take us some time to find one. Would we be able to start the search for this specialist and in the meantime contract a more generic headhunting service? @usman, @paulo (and @sid, when you come back) would you be willing to create a ticket to start on next steps for a headhunter/O.D. hiring, if these sound good to you?

Does anybody share the feeling that we’re the experts? Which is to say:

  1. I doubt we’ll find a person that can pull solutions to our highly specialized problems out of a hat. Yes, there are larger remote, open source companies (Canonical, maybe some divisions of Redhat), but none I’ve ever heard of with OpenCraft’s particular blueprint. I’d go as far as saying that in some respects we’re more like Debian than a for-profit company (which is a good thing!).

  2. Once we solve this phase of our growth, I think OpenCraft can start selling O.D. consultancy for this particular niche. (Dead serious: I consider doing it myself, from time to time.) Doing remote right is hard. Doing open source right is hard. Doing it all and making a profit, while being “open first” no less, is even harder.

Which is not to say that we don’t need somebody to sit down and think about the problem and try to find solutions. It’s just that maybe that(those) person(s) should be from our own team… once we have capacity, of course. ;)

PS: Re-reading this, I imagine it can sound like I’m volunteering. I’m not. There are many core members that have been here much longer and are much, much better at OpenCrafting than I am. Pretty much still have my training wheels on.


Now that I’ve had a chance to read closer on the O.D. Wikipedia entry, I have noted how strikingly similar it is to the work we’ve already been doing. I know I’ve actively engaged in many of the activities listed and didn’t even know there was a name for it.

This would probably go with our push to open up the other side of the business alongside the process manager-- since as we’ve discussed previously we want to be able to expand to market and sell consulting and software around our async processes. So yes, that’s a great idea long term-- finding a way to promote from within an O.D. specialist.


That’s a pretty big caveat… luck and timing will play a huge role in getting us through here, so success doesn’t automatically qualify us to bottle our approach and sell it.

But you’re totally right: doing all of this is hard. And the sheer number of hats we all wear, each day, is part of why hiring the right people is so difficult to do. I wouldn’t propose to add yet another hat by adding O.D to our consulting services. But I do think blogging about it would help other organisations like ours.

While I’m totally in favor of requiring previous open-source work for candidates, I think it could be a big barrier to entry for many who would otherwise be good candidates; in my case, most if not all of my contributions were done as part of my job but they only happened because I took the liberty of doing so, some times while omitting the fact to my employer :blush: .

One of the ways in which we could lower this barrier could be introducing bug bounties.


  • candidates without previous open-source contributions can get paid for their work to meet that requirement;
  • might put some candidates that wouldn’t otherwise apply (for whatever reason) on our radar;
  • allows us to offload small but perhaps important pieces of work.


  • extra work to maintain the list of open bounties (but not too much hopefully).

I think this is a very good idea. We have already been discussing adding a step in the interview process where candidates would be paid to submit (and merge) just such a type of issue. But the problem with the during-the-interview approach would be that we’d have to give each candidate their own bug.

If, on the other hand, we have a list of open bounties and some people work on them simultaneously, whoever gets the fix merged first gets paid. :man_shrugging:

I’m not sure we’d want to restrict the pool of candidates to those that got bounties, though. But maybe we could do both simultaneously, until a time when the bounty list is popular enough to generate enough candidates for our hiring needs.

(Cross reference to the help mailing list)

This was a really poor choice of words :scream: what I meant, of course, was that I didn’t think it was necessary to ask for permission and went ahead; by contrast, I’m pretty sure many developers don’t work in an environment where that’s possible.

It’s worth noting that we used to do this. It was part of my interview process-- I’m not sure if we had the extended trial period then, or if this was the last step. An Open edX bug was selected, and then the candidate was to fix and submit the bug. They were paid for the hours, but the biggest problem with this approach was the amount of time it took. It was highly dependent on when Open edX would review a bug.

However… Now we have core committers. So if we made the bugs be within an area where Open Craft has Core Committer access, this might not be as much of an issue anymore.

Would we want to do this for all candidates or just for those for whom we had little to no evidence of open source contribution?

What @joao.cabrita suggested and I seconded was the other way around: we pay a pre-determined sum for merged bounties, and then we interview/trial from the pool of successful bounty-hunters.

1 Like