How is Swvl Blitzscaling its Engineering Team?

One of the fastest hires ever was Batman hiring the Flash from the Justice League movie. Want to hire faster? Then this article is for you.

Objective:

Have you ever woke up to find that you have a target of hiring 100 Software Engineers in a quarter?
Market may have challenges in having really good talents for sure.
But are you sure you’re doing your best?

If there is a backlog of talents, are you sure you are currently closing offers to the right ones as soon as possible?
Are you sure … you’re playing it the agile way?

Prerequisites:

This article assumes you added your openings and used your referrals & headhuntings, having a backlog of CVs already to go through them.

Current Process:
- CVs screenings taking place
- Simple Task to be sent to screened CVs candidates
- Waiting for candidates to submit their Tasks back
- Checking the tasks results and filter them based on it.
- Sending to the eligible ones the option to pick upcoming times for the culture fit.
- Candidate to have culture fit.
- Candidate to have squad fit.
- Candidate to have live Technical Assessment.
- Debrief taking place in the above.
- If Candidate meets the role expectations, Send offer to him/her.
- If Candidate expectations are far from his/her skills in the debrief, to drop this candidate and begin iterating over the new candidate.

No need to say that the above process is a very good process, and maybe mentioned even in most of the hiring books.

Yet …

It may have shortcomings in the following:

• Although the task could be very simple, the candidates may not know of that, and they may take up to 1–2 days just to be ready to take like half an hour to submit it back.
• After submitting the task, all the people from technical acquisitions or Engineering managers may be occupied already in interviews enough to take another 1–2 days till they check the submitted tasks and filter it.
• Leaving an automated tool for the candidates to book their calendars, they may prefer always before or after their current work, and they may reserve slots after the ones who reserved before or after work, which may be at least after 2–3 days to begin the culture fit interview.
• If a candidate made it in the culture fit interview and it was time to book them in the Squad fit interview, it may take 1–2 days for the manager to interview him/her.
• There is a possibility that the manager after all that finds that this candidate -although proved well in the task- didn’t have an actual work experience that makes him/her fit in the place. (or that to happen even in the technical live assessment after the squad fit interview with 1–2 days)

Which means that it could range from 5 days (Best Case) to 10 days (Maybe more in the worst case) just for a manager to know a candidate who wasn’t fit.

While the goal needs to be that the right Candidate -once the CV is there- needs to be assessed as not a fit in just an hour or 2 (instead of 5 days sometimes), and this who is a fit needs 4 days of investment to be having an offer closed.

So short version of story, if we’re talking the above in terms of OKRs (Objective Key Results), our OKR will be as follows:

Objective: Decreasing the Lead time of closing an offer for a fit candidate.

Key Results: Increasing the frequency of closing the interviews once each 2 weeks, to be once each 2 to 3 days at max and maybe less.

(And Having visible metrics for that)

So let’s take step by step:

Step 1: The Screening

In the old process, screening step was depending on:

• CV Screening
• Sending Task to Candidate
• Waiting for him/her to submit the task.
• Filter from the submitted Tasks.

Let me borrow from the “Making your work visible” book that we need always to optimize over decreasing the number of dependencies even if it makes perfect sense.

The idea behind this is that a system depending on 2 inputs (where each input has 2 possibilities of 1 & 0), could have 4 outcomes (00, 11, 01, 10).

Here we have 4 steps/dependencies just to screen the candidate, imagine the possibilities of outcomes, with a possibility of blockers.

While having one main input will give only 2 outcomes, either 0 or 1.

So with all respect to the task, but it doesn’t give its ROI (Return of investment), it may increase the chance of CV quality, but it decreases remarkably the lead time to close an offer sooner.

Which could be solved by the first step of CV screening only that will happen anyways from the Engineering manager with certain criteria to check (What’s coming is not a checklist that needs all of it to be there in order to proceed, the manager still needs to see all the parameters, what is a must for him and what he can work on, and makes a conscious decision whether to proceed or not, that’s more of example and not a must):

• The Candidate Academic background whether it’s a CS (Computer Sciences) or not.
• How many years did the candidate spend in the market, And whether all of them are in the same path or not (Moving from Android Developer to Senior Android Developer instead of Moving between Web & Android)
• The duration the candidate spent in each company (Average 1.5–2 years is good, less could sometimes mean the candidate is quitter, and more could mean the candidate doesn’t like to go outside of his/her comfort zone)
• Whether the companies -the candidate was working at- were more of software houses or product-based, whether they work on full projects, or consumer-facing apps, and comparing that to your company business model.
• The Skills (Someone could be Senior Android Developer but most of his skill is in Java while the technology required in your company is kotlin)
• Certifications are a plus for sure.

As we said, this is not a checklist, it’s totally ok for a candidate to have 3 of them and not the others, you can measure what you need and not.

Depending on the CV screening only with telling a story that makes sense out of it, may give less quality than having the task, but it definitely made you make a decision in 10 mins of reading the CV instead of wasting 3–4 days just for the task back-and-forth submitting and filtering.

Step 2: Time-to-1st-Interview

(With who? and who guarantees the high quality of it?):

Steps taking place after filtering tasks before:

• Talent Acquisition to request the candidate to automatically pick a timing for a culture Fit
• Culture Fit Interview with Talent Acquisition.
• Squad Fit Interview with the Engineering Manager.

Challenges in the above could be the following:

• Candidate 1 interview far from his first technical interview.
• This 1 interview could take 2 days at least to take place.

Borrowing from the agile mindset some concepts to solve the above challenges:

• Product manager comes with a problem statement.
• Product manager validates it with the customer first before proceeding with it, and validates its solution as well.
• If validation is proven right, to proceed execution right away serving the customer before seeking a new problem statement.

Let’s assume that the problem statement that is worth validating in our story here is the screened CV.

Taking this assumption to take place this means the following:

Once a problem statement is spotted, it needs to be validated right away … and therefore,

Once a good CV is spotted, no need to play it waterfall and begin screening a new CV, it’s better to validate this CV first by phone screening the candidate right away on spot.

Making the phone screening to validate whether the story told in the CV making sense or not could take place following the upcoming questions like:

• Asking the candidate to give an introduction about himself reflects how good a communicator he/she is, and that the candidate most probably is ready to work under pressure, because he/she handled the phone screening on the spot without being ready, even if it’s a simple thing, but it reflects something. (Some junior candidates sometimes reply that they’re not ready for a 5 mins introduction)
• Asking whether his/her work experience companies were working waterfall or agile/scrum and with which tools.
• Asking how many people of his/her experience in his/her team (reflects the growth with the team through learning together by discussing or by pull requests)
• Asking a quick technical question (what do you know about SOLID principles maybe?)
• Asking about the reason the candidate is leaving his current place and seeking your company (The candidate who is knowing why he/she wants to join your company reflects awareness of his/her growth and passion)

Phone Screening shouldn’t be taken lightly, it’s like a Hollywood elevator pitch for the upcoming interview full movie, it’s kinda telling the same story to be retold in the squad-fit interview, just without the details, so failing to deliver a good pitch from candidate about himself in a phone screening should save you watching 1 hour of movie with probably no outcome.

Playing it the agile way and validating it by the phone screening on spot (The customer survey way when validating the problem statement) at the same time has the following benefits:

• Quality of the upcoming interview for this candidate became higher. (like in agile, Higher probabilities for the validated product with customers to make an impact)
• If validated, you can ask him/her on spot in the phone screening to make the first squad-fit-interview asap (Which could be right the next day) with a proper negotiation with the candidate that it needs to be sooner in the working hours (instead of the automation tool that doesn’t negotiate and delays having the interview sooner). This kind of negotiation will be based on having a win-win between the manager and the candidate to have the soonest meeting for the manager that could fit the candidate schedule as well.

The above means that after the lead time to the first technical interview was an average of 3 days to book the first technical interview in the old process, It became exactly maximum half an hour spent in a good CV screening/phone screening focusing on candidate by candidate, and not handle a set of candidates together in the waterfall way.

Other benefit for the Phone Screening other than the validation part, that it could be play also as the sprint planning, Phone Screening/Scheduling meetings with as many candidates as you can in the upcoming 1-week where you can take an uninterrupted sprint interviewing all of them, so once you begin interviews not to get interrupted across the week to waste time within it again to try scheduling other candidates.

And after that, once the process begins sooner with the candidate, all the interviews will follow fast, from squad fit to technical live assessment to culture fit.

Step 3: Art of Closing the Offer

One of the main challenges that sometimes -given all the above- at the last stages, the candidate passing all the stages makes him/her have high expectations regarding the role or regarding the salary.

Hearing that of the candidate that at some point was stopping us to close an offer with him/her due that we’re not meeting expectations, increasing the change failure rate to convert an offer although we followed an agile flow.

Because what’s the point of having an agile hiring process, if it won’t close an offer because of high expectations?

But we discovered that it’s not a problem of expectations … It’s just a problem of alignment and communication.

Offering Stage needed to be aligned with the negotiation stage, having in it our feedback to the candidate from the interview first, aligning with the candidate where we see him/her from the role he/she is seeking, and once we set a common ground, we make the offering stage.

This negotiation is a win-win:

• Win for the candidate having feedback to work on it versus his growth. (regardless the role or the salary, there is the more important side of the growth framework, where there is a set of skills that once he/she mastered we will be more than happy giving him/her even more what they’re expecting)
• Win for the company winning this candidate with his/her great potential.

This negotiation contributed in decreasing the change failure rate, closing offers that we thought weren’t to be closed because of the different expectations.

But Clear Growth Framework Alignment and feedback closed these offers.

Step 4: Finding a way to Measure & Iterate

Given that we followed all the agile practices before, It’s a matter of time before saying we need to track it using Jira, right?

To work the hiring as sprints and measure:

• Create Jira Project for hiring
• Set in the roadmap tab, the epics categorized by the platforms having in each one the required target as shown (Figure 1)

Figure 1:The roadmap clarifies that there is a target of 7 Mid iOS candidates who need to be hired under the Epic of Mid iOS.

Also one of the roadmap strengths is that the more you burn closing offer to candidates like we’re gonna discuss, it will reflect in the percentage of the people who were hired in the epic progress bar, and as well the duration of each epic automatically showing that items of this epic haven been closed in the above sprints (Like shown above in the figure that both Android & Backend epics had tickets that had been closed so far in HIR (Hiring Jira Project name) Sprint 1 & Sprint 2, so it will give visibility on the long run, how the hiring took place generally from time perspective)

• With the same concept we considered the candidates as user stories to make an impact by being an addition to us once they join, we should consider the releases as their teams who wait for them to be joining to be released/formed, once a team gets completed it as shown in its progress bar, it will be ready to be deployed. (Figure 2)

Figure 2

Releases don’t have stories other than the ones in the backlog.

With the same concept, teams here are having the same items existing in the roadmap, the only difference is that they’re categorized here the same way.

Team may have candidates from different platform (one team may need 2 backenders, 2 ios, 2 androiders, and a testing engineer, each one of those coming from their platform epic)

• Begin the sprint with no stories with story points, just a non-estimated task to be able to begin the sprint.
• Definition of done (DoD) won’t be sending the offer, nor a verbal communication of approval, as all of these are examples of almost done, but the DoD will be clearly the candidate sending the offer back signed as a sign of joining commitment.
• Once the candidate sends the offer, we add his name to the corresponding story from the epic of his platform, giving it an estimate of 1 Story point, adding it to the sprint and burning it.

Once the sprint is done, you will have 2 important measurements:

Velocity Chart telling you how many story points (How many offers got closed) has been burned each sprint (Figure 3)

Figure 3

In Sprint 1, 3 offers have been rolled and signed.

Burndown Chart but we will play it in a way that’s different from its normal usage.

In the normal state, Burndown chart begins with the story points the squad committed on at the beginning of the sprint, and tracks how the squad burns it across the sprint around the ideal slope (Figure 4)

Figure 4

In our case, we won’t begin the sprint by any story points (Zero story points) which won’t make normal slope, but there will be spike with each burn (Each closed offer) (Figure 5)

Figure 5

So now given that we understand the 2 charts (Velocity & Burndown), let’s see how we will use them.

Velocity chart will reflect 2 things:

• Forecasting what’s coming based on the last sprints. (For example Sprint 1 we closed 3 offers due to some capacity challenges, Sprint 2 we reached 7 offers with full capacity and after adjusting some stuff in the process based on the last sprint retro, this means that most probably our frequency of closing offers will be 7 offers each sprint)
• Seeing where we are from the target. (For exampleWe have 3 sprints remaining with 33 candidates to be hired as target which means we need to hire roughly 11 per sprint while the velocity shows we close 7 offers per sprint, so we can align early based on the forecasting with the challenge)

Burndown chart will reflect what we needed to see in the OKR at the beginning:

The spikes in the burndown chart will represent the frequency of closing the offers per day, and the more this frequency is less, the more it proves we’re on the right track to close offers in less time. (The Shown Example above of the burndown chart had 3 offers in this sprint were closed in the first week of sprint 1, and it seems there was challenge in second week not to close offers)

This metric directed the next retro in knowing what were the challenges like:

• There were no openings for iOS.
• Capacity challenge in having interviews.
• Screening took a lot of time.

Which could be taken into consideration, fixed and iterated over the sprint after to know whether the velocity became better, and the frequency became higher or not.

Conclusion:

Finally, I would like to conclude that what we discussed is mainly a case study and not an established theory.

Applying Agile in Hiring is just a beginning, setting the road for a lot of enhancements appearing in retros that will fit each company the way it sees suitable.

Looking forward to hearing from you and sharing experiences whenever you try it, being here in case you need any help.

Thanks for your time.