Hiring pace

adolfo · July 7, 2021, 1:03pm

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.

antoviaque:

OK - just to check though, does this include:

Capacity for all the accelerated epics assigned to the cell?

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?

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:

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.

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

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.

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.

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

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. :)

antoviaque · July 22, 2021, 9:54am

I have moved the discussion to its current thread - it’s usually easier to follow conversations than on one giant thread.

Thanks for recaping the outcome of that discussion.

What could help making it less messy? Could a better workflow/process help here? We are designing a workflow manager currently - this could be a good area to work on a workflow for? CC @nizar @Ali

For the number of new hires at a given time, it does make sense to keep it to something manageable. Generally one core team member should be able to care for one newcomer, no? If the newcomer isn’t able to make it worthwhile for a core team member to mentor him/her and create/find tasks, then maybe either that newcomer isn’t a good fit, or not enough time is spent thinking about ways to delegate work?

Note in passing that hiring pace (number of newcomers at a time in a cell) is related to capacity buffer (the number of hours not allocated), but they aren’t the same. Ideally, a cell would keep enough capacity buffer, to not need to hire so fast that it would exceed the cell’s maximum hiring pace. That’s still difficult, but gives more time – and it provides an incentive for cells to take on accelerated epics, as the more accelerated work, the more capacity buffer the cell has, potentially allowing the cell to get contracts we might otherwise have refused, like the Singapore lead: https://forum.opencraft.com/t/falcon-resourcing-for-2021-22/1042/23 .

Does anyone want to take a task to update the handbook with the outcome of this conversation?

Ali · July 23, 2021, 8:42am

@antoviaque @nizar

I think this sounds like the perfect candidate for a workflow - or a number of workflows, depending on how the procedure is structured in the handbook.

The plan was to first build the vacation checklist, but perhaps this workflow/s could be tackled thereafter.

paulo · July 27, 2021, 12:31am

Another problem we are facing, at least in @bebop , is the difficulty in assigning mentors to newcomers.

With 8 core members, we currently have only 3 members in mentoring positions. Finding a mentor for Alfred ended up with myself taking the position, despiting leaving for a sprint-break, as no other core members had either the capacity or timezone overlap.

A recurrent theme in Bebop is some members taking more than one mentee; there’s no intrinsic problem here, but that severely limits options and brings problems such as the above.

I don’t want to force anyone to take mentoring, especially given the fact some members enjoy it much more than others. But this situation is limiting our ability to hire at the moment. I actually enjoy mentoring and will gladly take another newcomer if no one is available (there’s one incoming), it’s just that it ends up limiting taking other work.

Finally, the fact Bebop’s newcomer-to-core ratio is less than 20% in 2021 results in a lot of mentoring is required, which points to another problem entirely.

antoviaque · August 3, 2021, 2:46pm

14 posts were split to a new topic: Cell leads