Ownership — the secret ingredient
Recruiting is a process that we take very seriously at our company. We strive to hire the best engineers, the best product managers, and the best designers, and guess what; almost every other company out there does too.
Last week I re-read a blog post by Joel Spolsky in which he discusses his take on recruiting. In the post, The Guerrilla Guide to Interviewing, he talks about how to interview and hire new engineers to your development teams and what you should look for while you hire. I believe that this is a must-read for every recruiter. In his post, he mentions only two things that he looks for in an interviewee:
- Is he smart?
- Can he get things done?
Simple right? Although I totally agree with these two key attributes, I will add one more; ownership. In this blog post I will try to explain why ownership is so important and how to spot it while recruiting.
So, why is ownership so important?
If you own, you care
It is as simple as that. If you own something, whether it is your home, your TV, your technology domain, or that little piece of code you just wrote, you tend to care more about it than anything else. 99% of people will treat their own car better than the car they rent at the airport. People care more about a house they own over one they rent for a year. Once you own something, most likely, you will treat it better.
Ownership is about accountability
To put this in simple terms, an engineer that feels accountable for his deliveries and his domain and welcomes responsibility gladly, proves to have strong ownership skills. An engineer that does not do this, well he or she just doesn’t. If all you want to do is to run away from responsibility, or you’re afraid that someone will eventually blame you if something goes wrong, then you will never own anything and you will lack the accountability that your managers look for. Feeling accountable for a piece of code you just wrote and for domain you are in charge of makes you walk the extra mile. Here are a few examples of what I consider walking the extra mile:
- Improving performance a little more, just because you don’t want your users waiting an extra half a second.
- Fixing that annoying bug that never seems to get priority but bothers you so much.
- Making the user experience awesome even if something breaks by being extra careful about resiliency and fallback.
Ownership tends to extend boundaries
If you really care about something being done right, like a piece of a code you wrote, in most cases you will start caring about other things as well, and eventually, you might accept ownership of them too. You will care about how others handle code reviews, and you might revisit the engineering code review policy. You will care about the relationship between the engineering team and the product team and work to improve it. You may not be able to fix your entire organization, but you will start with the one thing that bothers you and work from there. This may start with your own territory and domain, but this ownership tendency has the ability to grow and influence globally, not just locally.
Ownership makes great leaders
Once you feel ownership and accountability not only towards a code but also for people, then I know that you are on the right path for a leadership position. At the end of the day, leaders are responsible for all of the successes and failures of their team, and they should treat their team member as their most valuable assets.
Just as the owner of the domain should feel accountable for the domain’s success and make it the best it can be, a leader should feel the same about his team members and make them the best they can be. In a nutshell, this is what leadership is really all about.
How to spot ownership in a candidate?
So, I hope I convinced you that ownership is super important and why it is one of the first attributes I search for in a candidate. However, the next major question is how to look for it? How do you know if the interviewee in front of you is an owner or not? Will he/she be the perfect fit for your company’s culture, which is already composed of people with strong ownership skills?
Care about what you left behind
Why did they leave their last company? Was it because they wanted to experience and learn new things? Was it because they joined a startup and they already used all of their funds? Did they just get bored? If not any of these reasons, then why did they decide to leave?
People leave for many good reasons. I will not get into that now, maybe in a future post, but if you care and you have that sense of ownership, leaving your company should hurt in almost all cases. Leaving your company is not something you do easily if you care strongly about it. If you feel proud of the work you did and are proud of the people around you, yet you still decide to leave it all behind and look for new opportunities, it should definitely hurt. That does not mean it is not the right decision to leave, however, it should not feel like a trivial thing to do. Leaving for a higher salary, to learn something new, or just because you moved to a new city are all valid reasons to leave. Being nonchalant about leaving your company makes me believe that you saw your last work place only as a place that pays your salary every month.
While recruiting, seek the engineers that shows they care about the parts and people they left behind or what will happen to the rest of the company after they leave.
Work to change the reality
In my interviews, I ask many different questions, I tend to go with the flow and I don’t have a specific list of questions that I normally ask. Having said that, I always ask one particular question in most of my interviews:
If you were not there, (in the last company) what wouldn’t have happened?
I ask candidates with over 10 years of experience and junior candidates with only 2 years of experience this same question. The amount of time in their role is almost irrelevant, and the answers can vary from, “Our testing framework sucked big time and I came with an idea to replace it and did it,” or it can be something like, “I wanted to make our meeting room names more attractive so I asked the other employees to suggest new names and I changed them.” If a candidate does not give me even one case where he/she changed the reality in his/her last position, it automatically raises a red flag for me. Did he/she simply not care that testing takes so long to complete? Did everything work so perfectly that nothing, really nothing, needed to change? But let’s say, in a different situation, that the candidate did change many things and he did care, then this is the time for me to pull out the big guns and I ask:
Give me an example where you asked to change something and your manager\colleagues told you this is not a good idea or will take too long to execute. What did you do about it?
This creates a great discussion. If someone tells you, “I accepted the manager’s opinion and forgot about it,” then again, this is a red flag. If after 2–3 times he continues to get rejected, and he stops suggesting ideas rather than pursing them, becomes passive, and his passion fades, then he is not going to develop strong ownership skills. You want to see the passion in the eyes of the candidate. Good answers vary between, “I pushed my ideas again and again until my manager approved them,” to, “After hearing what my manager explained to me I realized my solution was not optimal, so I went back to the drawing board and fixed my solution,” or even, “I pushed anyway, and I showed my manager that he was wrong.” Those are all reasonable answers that can lead to interesting follow up questions.
Terminology does matter
I know what you are thinking, this is way too nitpicky, but I also listen to the word choice of the candidate carefully. The term them instead of the term us is usually a red flag but it doesn’t automatically disqualify a candidate. Them can refer to the “big” and “scary” teams such as management or HR or any other team across the hall for that matter. Why is it important if a candidate separates the world between us and them? The separation is like saying, “Why fix this bad code I just found in our code base when it belongs to them?” or “Okay, production is on fire but this is their problem and I would rather continue to fix a bug that is related to my team but only impacts 0.0000001% of our users”. This shows that they are not keen on teamwork and do not understand that there is a level of satisfaction achieved when helping others. You would like to recruit people that feel ownership towards things that affect the entire organization, and overall can see the bigger picture of success. If production is down, offer your help to other teams by doing code review because another set of eyes is always beneficial, or at least let them, use you for rubber duck debugging.
The boy scout rule
God, I love this rule, and if you don’t know it, it goes like this, “Always leave the campground cleaner than you found it. If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers.” How is this applied to software and engineering you may ask? Let me give you a few examples. You write your feature and stumble into an important piece of code that you didn’t write and realize that this code isn’t covered by any tests. What do you do? You try to push into production and there is a flaky test that it is not related to you or your new feature. It fails 2 out of the 3 times it runs, so what do you do? Lastly, you are writing a feature and you see an old code that has never been used, what do you do? I think you understand my point now. You want to hire people who treat the entire code base as if they wrote all of it themselves and want to fix any flaky test even if they didn’t write it or make it flaky in the first place.
Summary
Back to Joel Spolsky’s blog post - I do believe that recruiting people who are smart and that get things done is very important and I would not compromise those requirements. However, you also want to recruit people who feel that their team’s success, their engineering success, and that their company’s success is also their own personal success. You do not want to hire engineers who throw out good ideas but do not have the will or motivation to pull them through. Rather, you want to hire engineers who go above and beyond and contribute to the overall greater picture.
What truly shows ownership among a strong candidate is having compassion towards the people you work with, caring about projects that are not only your own, and being passionate about the product you’re working on. Having people that care is so fundamental, and I believe it is one of the key building blocks for creating a healthy and successful engineering culture.
I believe that having colleagues who care about their company and are passionate about what they do can help create a great engineering culture. Working among people with the characteristics I described throughout this post is what will make coming to the office every morning so much greater.
Think otherwise? Have more examples or other ways to look for ownership in an interview? Let me know in the comments below.
And thanks to talented
for the great images.
