Substituting the recruiter
I had the chance recently to get insights into recruitment when my HR colleague was on a three-week vacation and I covered for them. Since I’d previously led efforts to shape people management and performance evaluation, it wasn’t a challenge for me to articulate the company’s value proposition to our candidates.
During these three weeks, I had some interesting phone calls with candidates, introductory-type conversations that aim to save time, for both the candidate and for us. We quickly exchange the most important information and assess interests and motivations as much as possible in a short conversation. We only send out tests and meet in person if this goes well.
One of the candidates, let’s call him Zed for the sake of the story, made it clear that he wouldn’t work for less than a certain salary. He was open to participate in the assessment of his competencies, but regardless of the outcome, he’d set his price and wanted confirmation that we would hire him at that rate. It was higher than what we’d set for the open position. But for him, it was non-negotiable. I told him frankly that I couldn’t commit to his request and explained why.
Aliz was founded by developers to create a likable workplace for developers. Over time, we learned that while competitive wages are important, they’re not all a person needs. We go to a lot of effort to continuously redefine ourselves on the market and win attractive technology projects. We also take care of ourselves as a community and look after our individual members. This last effort could be summarized as investing in our culture.
While salaries can be set individually, the learning opportunities and the wellbeing available in the community are a common investment and benefit.
If we allocate disproportionally to one person’s salary, we take from the others. We believe in both the good of the individual and in the good of the teams and the company. This is understandable for some and inconvenient for others, but we want to work with those who value both. Zed wasn’t one of them and that’s OK.
The following week I talked with another candidate. Let’s call him Alex. Alex had years of experience and instantly understood the value of our efforts. He asked several clarifying questions. I told him we govern without a strong one-person CTO, but still enjoy a strong authority of competences. Our performance evaluation method partly drives this; it’s freer from bias than anything we’ve seen before. It’s not just a 360-degree evaluation where peers, leads, and subordinates give feedback. Our community defines the standards, so everyone is on board with the expectations. Alex asked for two weeks to think about our offer but mailed me the next morning to say that he was on board. We definitely made a better deal with Alex than with Zed: a win-win with no compromise.
By the end of the three weeks, I noticed that many candidates became more attentive when I described how we do the performance evaluation. And it’s not surprising. We have almost three years of careful and inclusive engineering in this social software.
About three years ago, we had a dispute about setting the salaries according to acknowledged competences. This led us to think through how our efforts to contribute could be realistically measured. That was the start of building a performance evaluation based on visible behaviors of key competences.
The performance evaluation matrix
Today we have something that we call a developer competency matrix. It’s as simple as a spreadsheet. But it has proved to be a solid basis for comparing the software development competencies of all our developers. We define it by specific skill dimensions and skill acquisition levels. At the intersection of the specific skill and level, we list observable behaviors, things we can see, verify and sometimes measure. We evaluate performance twice a year and iterate on the matrix where it fails to be accurate enough. Meanwhile, we have built a strong culture of feedback, with bi-weekly 1on1s and monthly retrospectives.
This performance evaluation tool is part of a process in our people leadership. But what’s really interesting is that in creating this tool we have successfully articulated our software development values by listing the desirable behaviors. We have created the strongest ever alignment between our values and our practices. This is what really resonates with our new hires.
If you’re interested in the HR practices that our colleagues and new recruits appreciate, follow our blog. We’ll cover it in a post soon!