What makes an A player?
At OpenBB, we’ve been thinking about the attributes of high quality employees over the last few weeks.
Talent density at OpenBB is particularly high.The highest I’ve personally experienced in my professional career so far, in fact.This has largely come down to OpenBB’s philosophy of hiring slowly and firing fast when it becomes obvious someone isn’t a good fit. Because of how OpenBB functions, I generally agree with this approach.OpenBB gives employees and extraordinary amount of flexibility, freedom, and autonomy, but this is paired with high expectations (rightfully so). And we’re currently rethinking what “good” performance looks like.
Naturally, the topic of the mythical “A players” came up, as it inevitably does when talking about identifying talent. (The idea was popularized by Steve Jobs, I think. This is how I first learned about it).
Since I took part in the discussions at OpenBB, I want to share some of my personal opinions on what I think constitutes an A player.
I’ll largely be basing this on my personal and professional experience across academia and my career, where I’ve been involved in hiring decisions across a few different orgs.
I want traits to be somewhat universal, so they should:
- Hold regardless of level of experience.I’ve personally witnessed (and had the pleasure of working with) people who just “have it”, even if they’re fresh out of varsity or been in the industry for 10+ years. It’s hard to describe this about people, but you know it when you see it.
- Hold regardless of role, title, position, or department, and (maybe) even level of experience.
I’m going to use examples specific to (software) engineering, since this is where I have the most experience. Adapt your own analogies to suite your industry.
Here are how I personally identify A players in the wild (and what I look for when hiring them):
1. They’re smart
This goes without saying. A players are bright. Being smart is necessary to do difficult things in the world of technology and software development. I look for creative thinking, problem solving ability, and a person’s capability to abstract problems.
2. They get things done
I look for people who get things done by themselves. They need minimal hand-holding and oversight (give them a description of the problem and some context, and off-they-go). They’re optimistic implementers: they’ll build to the best of their ability and current understanding, and then rapidly iterate based on feedback or further research. They embrace “fuck around and find out”.
These folks don’t mind stepping out of their comfort zone of what they currently know. Things are never not their problem.
Don’t know how to set-up a CI/CD pipeline? They’ll learn. Don’t know how to write an RFC? They’ll learn. Don’t know how to use test fixtures? They’ll learn. Don’t know how to design an API? They’ll try their best, get feedback, iterate, learn. You get the idea – they take the initiative.
Regardless of experience level, they’ll eventually become an expert in whatever they’re working on as a by-product.
3. They’re easy to work with
No one likes working with an asshole. I will always look for people who, while occasionally intimidating due to their technical ability, are generally pleasant to work with. They’re kind when giving feedback to others, and they’re graceful when receiving criticism. They’re accommodating, focus on the problem at hand, patient with people who understand less / have less context than them, willing to mentor, and openly share their ideas (while being equally OK with the team not adopting their proposals, provided there are sound reasons for doing so). They’re open-minded, and never assume they know everything.
You can often identify these people because others want to work with them or on their team. Because one person can’t do everything, engineering will always be a team sport.
I’ve seen organizations make the decision to keep a technically-exceptional asshole around because of their institutional knowledge, but it’s always resulted in negative outcomes in the medium-to-long term. Team morale and communication suffers,When people dislike dealing with you, they’ll simply stop telling you things. Even the bad news you need to hear. and I’ve seen companies loose exceptional people because they couldn’t stomach another day of work an asshole.
4. They pay attention to the small things
Lastly, they have an extraordinary attentiveness to detail. Usually I first notice this in their writing: they use good grammar, punctuation, and spelling (even in their non-native language). They take extra pains to get a diagram slightly more accurate. They make sure to match existing patterns in the code base. They anticipate when things deviate from an expected level of quality. They notice small things that could be better in their own work, and fix it. Everything they touch steadily improves.
I care about attention to detail, because the kind of person to write with punctuation and accurate grammar is also the kind of person to double-check that an S3 bucket isn’t exposed to the public internet, or rate limiting is implemented correctly, or a feature is delivered without obvious bugs. I’ve seen this pattern repeat time and time again. A sloppily thrown-together presentation tends to correlate highly with sloppy architecture and engineering . Maybe “attention to detail” is summarizable as “they put in the effort and do due diligence”, because these people seem to have a natural resistance to doing things lazily. They pursue what is right not necessarily what is easy (although they’re pragmatic enough to identify when a problem can be solved both right and easy). It’s possible though that I’m confusing “attention to detail” with conscientiousness.
It’s one of those weird patterns I’ve noticed from personal experience. A players just really deeply care about the small things that many people don’t just overlook, but are completely oblivious about. Don’t mistake this for misguided perfectionism: it’s because they just like things being “right”. And it’s not because other people will even notice. It’s because they know. It’s often inspiring to other members of the team.
The proof is in the pudding 🧁
Unfortunately, trying to evalute these traits is difficult (if not impossible) in the style and time-constraints most companies like to do employee evaluations. I don’t have pragmatic solutions here. Sometimes all it takes is having them talk through some code they’ve written. Sometimes it’s just casually discussing a problem with a whiteboard over a cup of coffee.
But sometimes you just know. And the best people at “knowing”? They’re A players themselves.