Slicing Your Hiring Dinosaur to Pieces

Many companies have gone Agile over the years, undergoing transformations and seeing their teams deliver quicker (hopefully). Organizations seem to lust after delivery teams going faster. And yet as an organization, we hamper them in other ways, such as hiring.

Let me illustrate this with the following scenario. I’ve encountered this scenario many a time at various companies here in Silicon Valley. Some of the details may vary, but I’m sure most folks would commiserate with me.

Godzilla Dinosaur Cartoon

The Scenario

You and your teams are working on a very critical project. Tight deadlines are coming up. Out of the blue, a few people give notice to leave – for whatever reason. What now? The critical product that you’re working on will be severely impacted.

As a manager, you now have to deal with hiring new members and then ramp them up. And to top it off, it takes a while to get your job requisition approved first by Finance before it reaches HR and Recruiting, who then starts posting the job description. If you can get that description up in a week or less, you’re pretty lucky.

Then the wait. For that perfect candidate. That takes time. You might have to compromise on good enough, but the whole process to get a single person replaced takes about two months at best. Now you have multiple people to replace (assuming you even get a replacement opened up with blessings from Finance). This whole thing is going to impact your tight deadlines.

And yet, your senior executives have told you and your teams, “We can’t let any dates slip.” You ask about maybe getting some temporary contractors. Finance says no – budget reasons. Your senior execs say, can’t the engineers work more hours, over weekends? You know this is the nth time you and your teams have heard that. You know there’s going to be an even higher price to pay with possibly more attrition down the road.

All this haggling with senior execs, Finance, HR, recruiting – just to replace departing people – contributes even further to the delay.

Companies are asking teams to deliver continuously and fast using Agile methods. But why does the hiring process today remain a waterfall dinosaur, hampering those Agile teams? Why go Agile when the supporting structures around your Agile teams slow them down?

Can we modernize the dinosaur?

You might be asking, ”How can we streamline the hiring process, so it doesn’t impact the Agile teams?”

Before I continue – I’m going to warn you – the road is fraught with peril. Why? Because some of the changes touch on parts of the organization that may not be tolerant to change. You can start being cautious in your approach and propose small experiments to introduce the change. But once you hit that roadblock, you will still end up with a dinosaur (albeit smaller).

One of the critical things to look at is the flow of your hiring process. I highlighted some of the process flow with the scenario I provided earlier. There’s a lot of phased gates when you start the process of recruiting new talent. (I’m sure you can see how Waterfall-ish the process is.) You need to examine that flow and start experimenting with it. Once you understand the flow, you need to take baby steps to modernize it (i.e., make your hiring process a little more Agile). Let me illustrate with a couple of examples.

Child in Dinosaur Onesie

Baby’s First Step

In my scenario, as an engineering manager, when a person leaves, the first thing I do is go ask my boss, “Can I hire a replacement?” In my 30 years in Silicon Valley, this has always been the case.

So my question is, why? Why is there a need for me, the engineering manager affected, to ask first? The main reason is budget. I need to make sure there’s a budget for me to hire.

One quick solution I’ve found to work is to have that budget be transparent.

“Can I have access to view the hiring budget for our department?” I’ve asked that question to my directors. Some of them said no outright, and some said yes. And for the directors that shared this info, all I needed to do was look at it, inform my boss I was going to hire a replacement, and start the recruiting process with HR.

As you can see, such a small step has varying results, but the main point here is I’ve already improved a part of the process, even by just a tiny bit.

Taking More (Risky) Baby Steps

Another area in hiring that causes teams to slow down is the act of interviewing and finding the right candidate. It takes a long time to find a good enough candidate, and I’ve seen teams and organizations try and search for that perfect candidate (and your chances are slim to nil, mind you).

So, instead of interviewing when you need to hire, why not just interview continuously? Keep interviewing candidates until you find that “perfect candidate” that everyone on the team seems to desire. You can be more stringent with your requirements in your job description. You can let your team know that everyone has to say yes to a possible candidate – no nays or middle ground. You can continuously bring in candidates to interview, mind you, not every day, but maybe once or twice a week, so you don’t overwhelm you or your team, bringing down productivity.

And therein lies the rub why this is risky – you have to get a little bit of buy-in from HR and Finance.

As a director at a start-up, I proposed this solution to our Finance and HR directors. I had to allay the Finance director that I wouldn’t blow the budget. I had to ease the HR director’s concerns that I wasn’t stringing applicants along with an always-open job requisition. I gave them an exit trigger when to take this job posting down.

One reason why I was able to do this is because I had control over my budget. I could shift things around to fit my needs. You might say – yeah, easy for a start-up director. What about a big company?

And therein lies the rub. Are you or your organization willing to unencumber hiring managers by giving them control of their team’s hiring budget to be more Agile when it comes to hiring? If you and your company want to achieve better business agility, you need to move forward towards this direction one small baby step at a time.

Slicing the Dinosaur

From my examples, the main pattern for getting rid of the Hiring Dinosaur is to look at the entire flow. And then see how you can transfer more flow control to the person impacted most – the manager who needs to do the hiring. (Hmm – doesn’t this sound like Lean?) You need to do one small slice of control at a time, one level at a time, in an organization.

And a lot of trust is needed if you’re going to do this. The quintessential question to ask in these gates is “For <person> to relinquish control, they need to be assured that <manager> will do ______ and will not do ______.”

What makes this hard, though, is that you involve very sensitive parts of the organization. Specifically, you need to loop in HR and Finance. And yes, you may need to go all the way up to the C-Suite level as well, depending on how far you want to take this. You need their trust and buy-in to experiment and enact these changes.

And you will need time since the changes don’t happen overnight. You can’t roll this out to the entire company in one big bang.

This example is one of the reasons why I believe that Agile transformations never end. You’re only as Agile as your least Agile department. To achieve overall business agility, you need to start tackling organizational problems such as hiring that slow down your delivery teams.

Your Ineffective Job Descriptions are So Last Century

I’ve been skimming over the Silicon Valley job descriptions for the past few months. And practically all the job postings look the same, with the trite conventional wordings that have been in use for the last 20 to 30 years. They contain a lot of fluffy words, with minimal impact. 

To me, the job descriptions are stuck in the patterns of the 1990s (when I first entered the workforce). Job descriptions seem to be all about checkboxes, buzzwords, and catchphrases – nothing more.

Here are a few examples of job descriptions that I’ve seen on LinkedIn (I’ve changed a few words to obfuscate actual companies):

  • Company X is seeking an individual with rich experiential depth in the classical program management paradigm of balancing venture against core product initiatives within the linear constraints of scope, time, cost, and quality.
  • We believe in empowering our teams to own all aspects of bringing Company B to life. As a software engineer, you’ll get the opportunity to make key contributions across our engineering stack – this includes developing and improving frameworks across our frontend and backend services, in addition to making direct contributions to your team’s product area.
  • What You’ll Bring to The Table: 3+ years of experience as a Software Engineer and a Bachelor’s degree in Computer Science, or equivalent work experience. Strong coding abilities in at least one language. Python or Java experience preferred. Experience building and deploying flexible backend systems at scale. Strong fundamental understanding of data structures and algorithms. Strong collaboration and communication skills, both verbal and written. Ability to be flexible and adaptable in a dynamic startup environment. Strong desire to learn about new technologies and systems.

Notice the pattern? It’s a lot of very generic stuff. Ho-hum. Very boring.

 

Join Us - cropped

And because it’s generic stuff, guess what – the resumes you attract will also be somewhat generic. The resumes you get will tick off the checkboxes of your requirements. Yes, I’ve worked to balance initiatives against constraints of time, scope, cost, and quality. Sure, I have fantastic verbal and written skills – can’t you see it already in my resume with similar buzzwords?

Shifting the Job Description: More Outcomes, Less Outputs

A majority of the world has shifted to Agile since the Agile Manifesto was published in 2001. And yet the Recruiting paradigms seem to be stuck in the past, not moving forward all these years. How do you start changing the way you recruit through your job descriptions (or, conversely, the way you present yourself on resumes)?

Agile has always been about value and outcomes (though many people still think it’s all about processes like Scrum or outputs like a backlog or story map release plan). Checkboxes like Programming in Python, or Ability to Lead Product Initiatives with Constraints, are still needed to provide a baseline for the types of candidates you want to attract. But they don’t have to take up a majority of what you provide in your job description. 

One way to start bringing the job descriptions forward to today is patterning it after the Agile principles. Why not highlight the outcomes that your delivery teams have achieved, instead of concentrating on a checklist of outputs? Show real examples in your job descriptions by highlighting actual stories of what your teams have accomplished. Heck, if I see these kinds of stories, I’d feel more inspired and more likely to apply for that job, since I’d like to be in on the fun and experience. 

Here is how I would have changed a few of the above examples:

  • Our program managers help our executives providing easily readable dashboards of our delivery team capacities. These dashboards help executives make decisions faster, shortening our strategic planning meetings from a full day to just one hour.
  • Our engineering teams are very empowered to solve problems in both the frontend and backend. Along with their respective product managers and customer support reps, they have devised solutions that helped propel our product to fantastic reviews. Our reviews on the Apple and Google App Stores went from an average of 3.2 stars to 4.6 stars in the last two years.
  • What You’ll Bring to The Table: 3+ years of experience as a Software Engineer and a Bachelor’s degree in Computer Science, or equivalent work experience. Your strong coding abilities in any language (Java and Python preferred) will further help our teams scale up and build flexible systems. Our teams are continuing to build flexible backends and automation that enabled us to scale from a single colo to 4 regional data centers. Our deploy process used to take 5 hours for a single colo with 35 machines. We’ve now brought it down to 3.5 hours for all four regional data centers with hundreds of machines, and are looking to bring it down to 2 or less.

Of course, I made-up the changes from the initial copies I got from LinkedIn. I hope, though, that what I did shows you what I mean by using real value and outcomes of your teams in your job descriptions. Doing these kinds of changes will make your job descriptions more effective. It gives people a better idea of your organization and what it values. And it’s another way to differentiate your company from all the others. Job descriptions like these show potential applicants what’s in store from them, aside from the trite benefits packages that also seem to be highlighted in these job descriptions.

And if you were a potential applicant, wouldn’t you clamor to work at a company when you see job descriptions such as these?