I've been lucky to be part of several powerful organisations and startups, and even more so luckier now that I get to run my own firm.
Like many, I've made pretty bad hiring decisions, and when I trackback on them, several patterns emerge that cluster my bad hires from the good ones. Of course in any situation, a bad hire's root cause is the hiring manager because they picked the wrong personality.
And this is the topic I wanted to touch on.
Hiring Failure Tolerant Personalities
This was the most obvious trait I could find when I tracked back on the many many people I've hired in my corporate, SME and Startup career. People who are tolerant of failure and are open to taking risks in coding or approaches were the ones who flourished the most in my experience.
A friend who's scaling his company from 60 to 80 people said the same thing, "we don't need people who just listen to orders, we need people who are daring enough to try something, fail quickly, dust themselves and move on to bigger things."
This can come in many ways:
1) Employing a new folder structure
2) Trying a new machine learning algorithm to better fence your data
3) Introducing coding patterns that were read online
4) Trying a new database that might be faster which is newer
5) Implementing a new git-flow that might remove bottlenecks in Pull Requests etc
Another thing I noticed with failure tolerant personalities was that they were willing to own up to their mistakes and grow when the upper management enabled them to. I would classify myself as a failure tolerant personality and remembered struggling at one of my first firms because the executive team wanted innovation but didn't understand the process of innovation (i.e try - fail - repeat) till something works.
Which brings me to the next segment, if you're a hiring manager or you're someone looking to hire, look out for failure tolerant people because they're the ones who will innovate and grow your company and engineering practice. More importantly, make sure you give them the arena to try and fail.
We recently wanted to improve our server interaction on the front end, and decided to try Apollo's front end store and it just didn't work for us. So 2 of my team members literally took a week off day time duties to just try and test different ways to make sure the new pattern would match our needs, which of course meant a lot of grunts and failures along the way but we finally came up with a super slick pattern and a mechanism that does caching really well for us whilst keeping the dev API simple
What does this mean for you as a developer (if you're reading as a dev)? Push yourself to enter into a mindset where it's okay to continuously try, fail and not get demotivated. I mean this is quite literally Data Science in its core - trying different algorithms and bias factors and variances until something finally matches a desirable pattern we're looking for.
Actionable steps you can take to create this mindset:
Analyse
Assess the current work environment, look into areas that you would personally like to see improvements in. Do some research into plausible solutions and work towards implementing them.
Iterate
At all points in implementation, look not to achieve the end result in step one but grow your solution in an iterative path. When implementing a new GQL and Apollo service, we didn't just pull out REST and put this in, we introduced the experimentation in phases so all parties were happy
Abstract
Abstract your emotion from your solution. The common saying in startup land goes "Love the problem not the solution" So work your heart out of your approach, because you'll make your mind access newer ways to experiment ideas, rather just iterative into a rabbit hole
Communicate
My team, the 2 devs on the task at least, would chat with me on a more regular basis to keep me updated on what they were doing. This really flexed their learning and helped them further grasp the concepts of their solution, more about this on the next blog - Feynman Technique
This is also the bit you let your senior management team know that no code is permanent, so let's not get too attached to a solution, and hence let's try new ways to succeed.
People respect new solutions that are better ways to solve problems, not because they're just better for the sake of being better.
So in short? Hiring managers, look for this personality and Engineers, experiment - people will really appreciate you! Trust me 😀
Top comments (8)
This article is honestly great.
Mate thanks so much! I'm super keen to see the new stuff you post out soon!
They're all great! I mean it! Super keen to see your growth online!!!🙏🙏🙏
No need for thanks, your article was great.
Glad you’ve been enjoying my content, I’ll keep it coming.
This is a good article, and I absolutely agree with the concepts you are driving at, I'm just not sure "failure tolerant" is quite the right term for this.
Failure is bad as far as I'm concerned, and I try to avoid it, easier said than done of course... I am though failure intolerant in my approach to software development.
What I think you're really looking for in developers, and what your post alludes to, is:
When I've hired developers I look for people who are almost relentless in their approach to learning and who can understand the wider context within which they are working. These developers have perspective and they know it's not just a code problem. And the really great developers are the ones who can communicate well and have soft skills.
None of this is to say the "f**k up fast" approach as I like to call it is a bad thing. It's just it often comes from a bad place. I often advise developers and companies to fail fast and iterate because they have no interest in doing any domain discovery work. So I see fail fast as a way to quickly understand a domain without causing too much damage. Of course to do this you have to be failure tolerant, but I don't see failure tolerance and fail fast as things to aspire to. I see learning, perspective and communication as traits to aspire to and I think this is what your post is really getting at.
Hey Rob!
"Failure is bad as far as I'm concerned" you are absolutely right on this part. And while I agree the article reads to encourage this, I think what I was getting to was, the mindset shouldn't be to actively look to ways to fail haha but incase it happens, dust yourself - which is exactly what you said so you're definitely on the money!
" I look for people who are almost relentless in their approach to learning and who can understand the wider context within which they are working"
Yes this is so critical!
"It's just it often comes from a bad place." Agreed - the Valley mindset isn't the most effective, true!
" I see learning, perspective and communication as traits to aspire to and I think this is what your post is really getting at."
Nailed it!
What do you say to those who say "Boring is Good"? i.e. choose the less exciting, older database over the new one except when it's intensely unsuited for the task at hand.
In terms of innovation, it's the product or real pain points/provable big wins in the development process that should drive this.
Example: I wrote the backend for a user chat feature quite quickly with postgres. With default config it's not the optimal database for the job. Chat has append only semantics and low locking requirements so the right kind of database can get many multiples better latency. But crucially, taking this step would have no appreciable effect for the user with the low traffic we had. The risk and learning time cost of introducing unfamiliar new tech would have been considerable and required much more complex code to get to the fully optimised async version.
In practice, that part of the backend has worked away faithfully for nearly 2 years, not exposing bugs and with lower latency than any other user interaction.
I see part of my job as resisting the urge to learn new fun stuff on someone else's dime without great justification.
I say, choose a tool that is correct for the job, if its old, but it is the tool needed to do the job due to backwards compatibility issues.
I was watching a youtube video from the cofounder of wufoo yesterday who gave an example of another incredible company where they would keep tech support phones in the middle of the dev floor, because if the devs are directly involved in supporting solutions for customers they will best find a great solution to fix the issue.
Perhaps I should mention/overcommunicate that this mindset should be when your firm is in growth mode and is specifically looking to improve their current practice because it needs to improve. I personally would never wander into new waters when building a new product, I wander into new waters when my current approach isn't enough for the outcome i want to deliver to my customers.
So in short, you are absolutely right to do what you have done in your example sir! In the end elegancy doesn't mean "new" shit, it means building things that work better than before, BECAUSE it's necessary.
"People respect new solutions that are better ways to solve problems, not because they're just better for the sake of being better." 💪
Absolutely agree, very well said.