One of my favorite parts of company ops is hiring and retention. How boring is that? It’s true though — since my skillset is largely ‘people’, I like to focus on the folks within as well as those without. In a flat org, that’s crucial. Without being able to promote to fancier titles, to give a clear ladder of progression, it’s hard to create a proper reward structure. Even if you can lure people in with promises of autonomy, ultimately, they need to know what to do with that power and responsibility. Otherwise, they’ll just end up spinning their wheels. Over the next few weeks, I’m going to be posting my thoughts on hiring, onboarding, and retaining employees in a flat structure.
Valve’s handbook talks extensively about how hiring is everyone’s most important job, and how they try to hire ‘better’ than they currently are. It’s important to keep that in mind when hiring for your team too — in a traditional org, there are places for ‘entry level’ employees and managers to keep poor performing people in line. Flatness means we’re counting on drive and peer pressure to get results.
Requirements Gathering and Adapting
If you’re the one leading the hiring charge, you need to treat it like any other project. Find your stakeholders, gather your requirements, and figure out what’s flexible. If you’re hiring a developer, talk to the technical team members. What is the minimum level of experience needed? What’s a nice-to-have level of expertise? Do you have specific language requirements or is the team okay with taking six months to a year to get the new dev up to speed on your language and framework of choice? Talk to whomever holds the purse-strings, your C-Level or HR specialists — what is the ceiling on pay? Are we flexible on hours or PTO? While pay and hours can wait until the offer (in sales-speak, they’re Buying Questions, which mean the candidate is sold on your company), being able to set expectations with a potential hire can save you the headache of scrambling after you’ve fallen in love with a candidate.
You should now have the info you need to create a job description. Theoretically, that’s your requirements document. In practice, it’s a starting point. Once you start culling and interviewing, you may realize there are candidates you want or need who don’t necessarily fit the job description. You need to go back to your stakeholders and consult — ideally they’ve been part of interview process, but it’s unlikely EVERYONE who might have requirements will get to interview every candidate. If you want to hire someone who’s less technically adept but has great team-skills, say it that way. If your marketing candidate doesn’t have five years experience but has extensive UX/Graphic Design experience, see if your marketing stakeholders are willing to budge.
Do not, under any circumstances, bait and switch.
Don’t gather requirements and then deliver a different hire. If you want to hire a candidate, but they don’t fit a specified need, figure out (again, with your C-Level or HR folks) if you can afford to hire both. If not, make sure you communicate why you need to turn away the candidate you like, and keep in contact for when you do have the bandwidth available to hire them. Having a farm team of interested potential candidates will make your life easier in the future.
TL;DR — When hiring, new employees are your deliverables. Don’t piss off your stakeholders by failing to deliver what they asked for. Do be willing to collaborate with stakeholders to see if requirements are flexible for the right candidate.
What to look for in a candidate
So I spent some time talking about the process of hiring, but I want to talk about some attributes we look for in candidates as well as how to know when to (and when not to) pull the trigger.
Cultural fit has to be as important as skillset. In a way, it’s more important. If you’ve got talented people who need specific instructions at every step of the way, you’re going to need too many wranglers to keep work moving. Autonomy isn’t just a benefit in a flat organization — it’s a requirement. Your devs need to be curious about the customers and the market, not just the technology. That means you will have to turn away some very talented people. There are plenty of really productive employees who operate best in silos. They’re great and can end up being VP of Whatever somewhere else. But they won’t work for you.
Project management experience is always a plus, even if this candidate isn’t going to be a wrangler. Understanding software architecture? Good. Understanding project architecture? Better. Knowing how time, stress, and outside forces influence a project is going to make a candidate less likely to lose their mind when shit changes. They’ll understand how backlogs and workflows change. They’ll also be used to speaking up when they see something that needs fixing or changing. “Speaking truth to authority” is a valuable attribute, but is REALLY HARD to interview for. “Would you ever tell your boss something was a bad idea?” “Yes”. Okay. That’s helpful. Project Management experience means that this candidate was tasked with speaking truth to power as part of their everyday job.
Collaboration is a skill. And it’s not one you can ask about. In an interview, “do you like to collaborate with team members?” is going to get “Yes! Of course! I have worked on a team!” Your interview questions need to suss out what a team member is going to do when faced with a vague, open-ended problem to solve. This can be a scenario, a development problem, or a “tell me about a time when.” Just because the candidate got a good solution doesn’t mean their methodology works in a flat team. You’re hearing their highlight reel: if they’re blaming others or throwing shade at managers to make themselves look better in their best story about themselves, what’s going to happen when automated tests start failing when this candidate pushes code?
What if nobody fits?
Don’t be afraid to say ‘no’ to every candidate who applies. Yeah, you probably need asses-in-chairs to get work done as soon as possible. But are you really willing to risk wasting six months to a year of strife in the office? Are you willing to risk losing employees who do fit because you needed a marketing person right this second? There’s always a leadup until employees are useful — is another round of candidates going to kill you in the grand scope of things? Do those extra three weeks mean the difference between success and failure? Probably not.
(And if that time frame DOES mean sink-or-swim, there are some great contractors around to pick up the slack without poisoning your team)A flat organization is powerful because it’s collaborative. Everyone’s voice carries weight. Every member of the team contributes. If you hire someone who’s a shitty fit, then you’re getting shitty contributions. You’re introducing a toxic element into every meeting and you’re compromising the DNA of your company. Don’t do it.I am not experienced enough to take about ‘firing well.’ Historically, my organization has been pretty bad at firing. One silver lining is that our hesitation to pull the trigger on firings means that employees are more willing to take risks and make (well-intentioned) mistakes. Knowing their jobs aren’t on the line for every chance they take is psychologically freeing. I’d love if someone could post some good resources on how and when to fire problem employees. It’s a definite blind spot in my experience.
The coming weeks
Part 2 of this series is going to cover retention — how to create structures that reward employees when you can’t just promote them into feeling good about their jobs. Part 3 will focus on how to manage employees when you’re transitioning to a flat org, instead of hiring directly into it. Spoiler warning: sometimes you can’t keep everyone.
Flatvocate 