Hiring pace

[adolfo (Adolfo R. Brandes)]

I’m copy-pasting a recent discussion started about this very topic on Monday. We figured that for discoverability it would be best to continue here.

Tickets to log time:

• BB-283 Epic planning - Bebop
• SE-254 Epic planning - Serenity
• FAL-49 Epic planning - Falcon

I don’t want to risk editorial effects, so it’s going to be a verbatum wall of text. Sorry.

@adolfo

Xavier, I’m pausing recruitment for Serenity as well. July’s covered (Sid’s back at half capacity and we have two newcomers in July), and the problem is now finding more clients to fill excess capacity starting August. :)

Depending on how Bebop’s doing (Paulo ?), it may even make sense to ask Alex to hold off for a while.

@antoviaque

OK - just to check though, does this include:

1. Capacity for all the accelerated epics assigned to the cell?

2. On top of this, the capacity margin that we discussed adding to each of the cells in the 2021 plan? (1-2 extra newcomers in addition to the cell availability requirements?

3. And on top of that, the margin to take into account the ~50% success rate of trial periods, ie counting 2 newcomers to fill 1 core committer spot?

Cf handbook

If you could actually break down those calculations explicitly, that would both allow to review the calculation itself, and to know where the team stands in terms of core vs newcomers vs missing capacity.

Paulo, Raul, I’ll extend the question to you two, to confirm you have both taken all of this into account in your calculations?

@adolfo

1. We’re at capacity, with a little margin, for July. 5.4 person/months needed, versus 6.1 actual. (Epic planning sheet). For August we have an absolute excess capacity of 2.1, then 2.9 in September. So only counting eggs in the basket (or nearly so), and only in terms of brute capacity (versus core member capacity, which I count in terms of epics per core), there is no need for recruitment.

2. While we’re only at 0.7 excess brute capacity for July, August and September are more than good regarding the additional requirements.

3. If during September one of Hadi or Hamza makes the cut, we’ll have 9 core members, and one newcomer (Pedro). AFAICT, that is sufficient in terms of roles and in terms of number of active epics per core member (including internally accelerated ones): I counted 9 such epics in August/September.

Can Serenity get to 10 core members? Sure, but remember that Serenity is behind in terms of sustainability. We don’t want to take accelerated epics - it’s one of the reasons I dropped containerization. We want billable hours. Bringing on people willy-nilly without the hours doesn’t help us.

Plus, there’s the cell’s capacity for mentoring and onboarding. People don’t jump on the opportunity to mentor because if you don’t get lucky with the newcomer, it’s hard work on top of other obligations. Which is to say, if you’re managing a hard epic, or nose down in some difficult development task, you’re not going to want the distraction. I get way more “no thank you’s” when asking for mentors, than otherwise. Which is to say, I don’t see it being worth having more than 2 newcomers at a time on any given cell - and that’s exactly what we’ll have at Serenity for a couple of months.

Feel free to point out problems with my logic, though.

@paulo

I’m basing the cell needs on my previous report on the difficulty of having more newcomers on BEBOP due to the newcomer/core ratio.

We were at the limit, it was very difficult to assign mentors, with some members mentoring two newcomers at the same time. With Mattia leaving, I’ve opened up another slot.

Also, for 2021 Bebop is turning 20% of newcomers into core (2 out of 10, 2 others in extension and not taken into account). We seem to be getting more newcomers but not core members.

@antoviaque

For August we have an absolute excess capacity of 2.1, then 2.9 in September

It’s quite common and normal to have bigger capacity gaps in months – they are usually wider the further away, and within 2-3 months the gaps are quite large. It’s not that there won’t be work – history actually shows that the problem often turn out to be the opposite, ie too much work. It’s more that we don’t yet “see” the work, in the sense that the client hasn’t contracted the work yet, but they will need it. It’s a bit unnerving at first, but we get used to it. :)

Can Serenity get to 10 core members? Sure, but remember that Serenity is behind in terms of sustainability. We don’t want to take accelerated epics - it’s one of the reasons I dropped containerization. We want billable hours. Bringing on people willy-nilly without the
hours doesn’t help us.

The reason I think we want to take accelerated epics is actually sustainability – many of them are investments and attempts to improve long-term sustainability. Like finding a SaaS business that brings money (almost all accelerated epics products will be sold), or shoring up our contribution level and status in the community, as well as improving Open edX (contributions in theming or core committer program) - which itself is our main way to bring clients, through reputation.

It’s definitely more long term than the yearly sustainability ratio, but it’s something important I think the cells and team members would want to help work towards?

Now, I hear your and Paulo’s point that integrating newcomers requires work, and that it can be distracting. I will be reviewing the cells epic management this week, I’ll think about these points. We’ll need to find a balance between the needs to minimize distractions and the growth needs, to make sure we aren’t passing on opportunities that we would regret not getting. We successfully integrated more than 2 newcomers at a time in the past. Maybe the changes to the recruitment process recently created undesired effects, “process bugs” – it might be worth doing a pass to improve it. Maybe we need to be stricter about the interviews?

Raul, could you post the answer to my questions from the first thread post, above, and answer them for Falcon?

@adolfo

It’s more that we don’t yet “see” the work, in the sense that the client hasn’t contracted the work yet, but they will need it.

Yes, I agree. I’m not actually worried we won’t have work, by the way. But what is hard work is trying to find tickets for newcomers, given the current rules: max 50% internal, and even that’s not easy because those epics are in the back-burner for Serenity, at the moment. It puts a lot of pressure on core members, which are already stretched a little thin. Which is why I’m being conservative.

On the other hand, the recruitment effort so far has already improved things. Along with the fact Sid’s back, Serenity now has 2 more core members than in May. This will make it much easier to distribute the management load. If only one of Hadi and Hamza make it, I think we’ll be in a reasonably good spot.

The point is, as recruitment manager I want to understand what is the sweet spot in terms of risk of not having enough work/too much overhead, versus risk of having too much work/too little hands. We have a few bounds, already: 6 is too little (from June), and 12 is too much (from pre-Falcon split). My current hypothesis is that 9 is the sweet-spot ((6 + 12) / 2).

This brings up another point to discuss: once the sweet spot is reached, what happens? Do we turn down clients to remain in that sweet spot, and only hire when a core member leaves? How long do we remain in the sweet spot?  Will a growth spurt be mandated (by you, presumably), and a cell split planned in advance? To be clear, this is exactly how I think it should be handled: growth beyond the sweet spot should be taken as an epic by somebody in the cell. Presumably by the recruitment manager. But the corresponding added work should be planned ahead, just like any other epic.

It’s definitely more long term than the yearly sustainability ratio, but it’s something important I think the cells and team members would want to help work towards?

I’ll always defer long-term strategy to you, Xavier. First, because it’s your job, but also because you’re much better at it than I am (I’ll never forget the Starcraft ass-beating I took, haha). In any case, I’m not disputing the long-term plan - I agree wholeheartedly. It is also why I took the containerization epic to begin with.

But something that I may not have made clear is how disheartening it was to have to stop working on it because of not only capacity, but sustainability. The current rules have it so that if a) a cell doesn’t have enough capacity, or b) not enough sustainability, it’s an uphill battle to work on not only internal, but accelerated epics. What the book tells us is that we should first achieve capacity (which we have done), then sustainability, and once you have that, you’ll have a 5% sustainability bonus to work on “cool” accelerated stuff.

Serenity is not, at the moment, in a position to want the long-term work, and as recruitment manager I’m just trying to play by the rules and help make sure we eventually are. If my reading of said rules is wrong, again, feel free to enlighten me. I’m still a relative newb. But if I’m right, and the long-term outcome is not as you imagined, then consider this my way of trying to get the rules changed. ;)

PS: we have a 121 later today, so I figure this is as good an opportuniy as any to sync up on this topic.

PPS: Tim and Daniel, I think it’s worth bringing you in here to keep me honest, as I’m speaking for the cell. :) Do my points above reflect reality? I may have missed some nuance.

@paulo

Bebop currently has 3 newcomers and 8 core members. The difficulty now is finding a core member to mentor, who isn’t juggling a lot of epics or deadlines.

With another newcomer, we should reach 33% of the cell composed of newcomers and 50% of core members mentoring. Those mean a not-insignificant overhead, from onboarding to reviews of a lot of newcomer-assigned tickets to providing access to resources.

@daniel

The reason I think we want to take accelerated epics is actually sustainability – many of them are investments and attempts to improve long-term sustainability. Like finding a SaaS business that brings money (almost all accelerated epics products will be sold), or shoring up our contribution level and status in the community, as well as improving Open edX (contributions in theming or core committer program) - which itself is our main way to bring clients, through reputation.

That’s for the company sustainability; it’s definitely for the long term.

But for the ratio we track in cells (also called sustainability), we just need billed hours; not even money would help.

It will help if thanks to a better reputation we find more clients that request projects that bring billed hours.

Adolfo:

the problem is now finding more clients to fill excess capacity starting August. :)

That’s one of the main points; Serenity needs large clients, to get billed hours.

It also needs the structure to handle them: people. Exactly at the same time.

The current rules have it so that if a) a cell doesn’t have enough capacity, or b) not enough sustainability, it’s an uphill battle to work on not only internal, but accelerated epics.

Not exactly like that… Accelerated epics use non-cell accounts and are excluded from the sustainability calculations, they are always ok to do when we have capacity. However, as sustainability manager I wish we get clients and billed hours instead of non-cell hours. Billed hours are what will allow Serenity to do more internal unbilled work some day.

then sustainability, and once you have that, you’ll have a 5% sustainability bonus to work on “cool” accelerated stuff.

The high sustainabili ty ratio would allows us to to unbilled cell hours (devops, Ocim, contributions, …). Accelerated epics use unbilled non-cell hours and are ok.

To add here:

• there are many variables to synchronize, many people, many blockers; it’s a mess for everyone. I’ll spare the details

• I agree that there are sweet spots for the number of people in a cell and the ratio of core team members and newcomers

• there are so many roles, that in a small cell everyone will be overloaded with many roles, plus epics

• by the way, couldn’t we have the discussions in JIRA and forum? Just to have them in the same place, and in a place that will probably last longer than monday.com

@tikr

Thanks for the ping. In terms of capacity, I’ll add that it’s a little too early to talk about excess capacity for Aug and Sep. A number of projects don’t have their estimates set (or adjusted based on latest updates) for these months. We’ll only know whether we’ll have excess capacity once that’s done. (I’m still working on my epic planning pass for the current sprint, and did not get around to making a pass over the allocations for Aug and Set yet. Since we’re at the end of Q2 now and will soon want to do another sustainability update, I mainly focused on updating client budgets for now.) CC Daniel and Xavier.

@adolfo

Accelerated epics use unbilled non-cell hours and are ok.

Yes, I realize that. But they’re only “ok” because they’re neutral, in terms of sustainability. We need better than “ok” to directly improve our sustainability ratio.

In any case, I had a short-but-good 121 with Xavier where we discussed this, and the gist of it was that it is in fact correct that client work is higher priority than accelerated epics, especially for Serenity. However, we should also take the long-term view: tackling the accelerated epics raises the chances that Serenity will continue to be able to work on new clients in the future, so we’ll want to help where we can. Plus, the fact that little work beyond discoveries has been done on these accelerated epics in 2021 (not just by Serenity, but all cells) is understandably worrying Xavier.

Long story short, we should strive to do our part and try to get enough capacity to push work forward on at least some accelerated epic(s), and not stick exclusively to billable hours (which is what I was arguing for). To be clear, I stand corrected. :)

However, and I quote Daniel once more:

there are many variables to synchronize, many people, many blockers; it’s a mess for everyone.

It is, indeed, quite a mess. Synchronization is required between different roles, but it isn’t always clear how it should happen, and when. Such as, markedly, between Epic Planning Manager and Recruitment Manager. Case in point, Tim says:

it’s a little too early to talk about excess capacity for Aug and Sep.

This is basically admitting we can’t predict how much capacity will be necessary until it is too late to hire - or too late to fire - anyone. This is exactly why Xavier asked for a capacity buffer to begin with: but what should that buffer be? As we’ve been discussing (here and elsewhere) there are significant hidden costs to hiring: from creating enough tasks, finding enough mentors, to the sustainability concerns I mentioned earlier. With these costs in mind I suggested to limit Serenity to 2 newcomers at a time, until we have more information.

Question is: is that right? Who decides? Xavier says cells hire for themselves. Is it time to elect a cell lead to help organize things and avoid dilution of responsibility? Or should we just plan (and document) more clear sync-up points between the different role owners?

couldn’t we have the discussions in JIRA and forum?

No objections. Should we copy-paste the above into a thread?

In any case, CCing Sid, as he expressed interest in taking the recruitment role back starting on SE.251 - and I agreed. :)

@daniel

couldn’t we have the discussions in JIRA and forum?

As you wish; it was just an idea for discussions like tihs.

Ok with copy-pasting +closing here, unless others want to keep it here.

I think monday.com boards disappear regularly and then are hard to find, so copy+pasting doesn’t seem so bad.

Is it time to elect a cell lead to help organize things and avoid dilution of responsibility? Or should we just plan (and document) more clear sync-up points between the different role owners?

This is a long discussion with many options. What you propose seems good if well implemented (if badly implemented, then instead of synchronizing e.g. 4 roles, we’ll synchronize 5. And more coordination points).

I have too many comments here so I’ll stop here.