Okay, I know what you’re probably thinking.
Wait, I thought we stopped talking about 10x engineers? A bit too late to jump on THAT bandwagon, eh?
Well, maybe - that’s why I’d like to talk about folks who are much more valuable to their teams.
So what’s up with 10x engineers?
If you’re like me, you probably see an article about 10x engineers (or even 100x - go read this article, it’s better than this post). The whole idea is that there are folks out there who are TEN TIMES BETTER than other software engineers.
They write code ten times as fast, their code has ten times fewer bugs, their code is ten times faster than other’s code (assuming the same language, of course) and their startups have exactly ten users (okay, without that last one).
So… if there are 100 engineers in my company, can we just get 10 really freaking good engineers, pay them three times as much and save 70% in salaries?
Of course!
Provided the software you need to write requires no collaboration, no planning, no estimation, no communication and everything is perfectly documented from day one. Which (to the best of my knowledge) has happened exactly 0 times. If their job is only typing on a keyboard, then it’s obvious that those who can do it 10 times faster are going to be 10 times better at it. But this is not what software engineering is about.
(Note: some software engineers ARE better than others, faster, more skilled, better at shipping reliable software.)
Which doesn’t mean that you can hire a couple of geniuses (geniusii?) to do the work of hundreds. “10x engineer” is an idea of this person who sits alone in a corner, wearing their headphones 40h per week and coding really freaking well. This may be you (and that’s okay!), but I’d like to talk about another path to having a huge impact in your organisation without having to (somehow) code 10 times as fast as others.
1.1 engineers
(Or +10% engineers, you name it)
+10% engineers are those who make their peers 10% better.
They are not better than other engineers in their team, but their team is better than other teams because of them. The idea is that, if you can make others around you more productive, it quickly adds up to a huge impact.
Let me give you an example.
Imagine if you’ve recently joined a company and you had to endure a daunting onboarding process. Nothing was documented, you’ve spent 4 days trying to get access to JIRA, barely managed to set up the project and all in all - you haven’t had a good time. I’ve worked for a couple of companies and I can assure you that onboarding can be bumpy, to say the least.
Once you’ve setup your environment, you can get coding.
Or - you might decide to document the whole process:
Create detailed, friendly README files.
Write a document detailing company jargon (dear C-level managers, I know that everyone knows who you are, but as a new employee at your company, how am I supposed to know who’s “Jim”).
Set up a reminder to IT Support to create JIRA accounts to new employers at the beginning of each month.
Schedule a welcome email to new employers, sharing the most important links with them
Not a single line of code was written that day.
But the impact of your changes is incredible. Everyone who will join that company after you will have a much better experience, they will be more productive from the start (commit on the first day, even!) and your company will save money which was straight up wasted on talented people sitting around and waiting for their Github access.
This is what +10% engineer is all about. Numbers don’t lie. This may be silly, but if you make 25 people 10% more productive then your impact (according to JavaScript, which is incredible at math) is bigger than this mythical 10x.
You have just learned that there's an exponentiation operator in JS.
We can go further, what if we’re talking about 50 people?
Holy. Moly. Maybe you’ll get a 100x bonus?!
How do I make others more productive?
Docs are just an example. Facilitating knowledge sharing within the organisation is an another idea. This can be done online or offline (in the 2019 meaning of the word ‘offline’ which is ‘not live’).
Write a post about this thing that you’ve learned recently and has made you more productive, share it with your team and you’ve already made an impact.
Organise a knowledge sharing session in your team/organisation. You may organise a full blown event with snacks, drinks and 8 talks, which would be cool but you don’t have the time to take care of all that. But not everything is all-the-way or zero. Feel free to just book a room, ask folks is they have something to share (you’ll be surprised how many people would be willing to give a talk if you encourage them) and enjoy!
I’m not saying that you (or especially myself) are a wise sage guru who needs to be encouraged to share their divine knowledge with everybody else. Maybe you know that someone in your team has a lot of experience with that thing you (and probably others) are kinda struggling with. If you ask them to teach you - they will improve as a teacher, and you will improve as an engineer.
But, if you ask them to share it in public (or, you can learn in public - share what you’ve learned) - the impact will be much more greater.
A while ago I’ve had this dum… interesting idea that not everyone can/is willing to travel to conferences (or watch YT videos after work), so how about we bring conference speakers to us? At OLX Group we’re started organising a Conf Talk Cinema where we gather together and watch one or two talks on YouTube together.
You can do it too, sharing a link to this amazing talk that you’ve seen in India and everyone else has to see it to has a really low conversion rate, asking someone to chill with their team members in a cinema (okay, a conference room) for 30 minutes has a much bigger rate of success.
Okay, but I want to code
By all means! It’s your job!
While you’re at it, maybe refactor this part that no one has touched since 1928 and you’re probably the only one who actually understands it?
This is not rocket science, but it goes a long way. By refactoring this massive class/function not only you will gain a better understanding of your codebase, you’ll also make others more productive because they won’t have to endure trying to comprehend this piece of code.
If 100 developers needs to spend 15 minutes to understand a function and you can reduce that time to a minute… I don’t even have to write any code to visualize that - it’s clear how much time and effort of others you’ll save. And not only that - they will feel so much more safer touching this part because they actually understand what’s going on there.
Speaking of feeling more safe:
Maybe write some extra tests if you have more capacity in a given sprint than others? Or cover more of your code with automated tests? Maybe setup automated tests in the first place?
I’m biased when it comes to automated tests, but I don’t care. I’m a huge fan of cypress.io and I strongly feel that adopting more tests makes you more productive.
If by spending 4 hours covering this tricky part of the system with unit tests you may save X hours of someone who has to rollback a production deployment because of a bug - isn’t it worth it?
Covering crucial flows of your system with automated tests allows you (and others!) to make significant changes in the future with a greatly limited risk of breaking major pieces of functionality. Your future self (and your team, hopefully) will thank you for that.
Awesome, but I have features to ship
Don’t worry, I’m in the same boat.
Finding the time to do those (and others, this is by no means a complete list) things may be difficult. Difficult, but definitely worth it.
It’s all a question of priorities and figuring out what’s important. Is it the productivity of this one genius developer who is able to ship 3 features per hour? Or is it the productivity and reliability of their entire team? Or maybe both? There’s no silver bullet but there may be a compromise.
With that being said, I’m strongly convinced that the following is true:
Productivity of the team > Productivity of the individual
What do you think?
...
This piece was originally published by Tomasz Lakomy. You can find the original piece here.
