Last week I wrote about the technical skills that data engineers bring to the table. The following post in the series is about the non-technical skills that will help you stand out in any team and company.

Today I want to take a pause and view the topic of skills from another angle. A few years ago, the tech industry Twitter discussed a new concept: the 10x engineer. A 10x engineer, people said, produces ten times more code in a unit of time than an average engineer (or, in another definition, than the "slowest" coder on their team). There was a noticeable undertone to that discussion: not anyone can become a 10x engineer; they are rare and valuable. Any team is lucky to hire one or more of those unicorns because they bring a decisive competitive advantage.

After a while, the tone of the conversation changed. People doubted that the speed of coding is the best parameter to judge the productivity in a team. Yes, they said, the 10x engineer can churn out thousands of lines of code in a day. But what good does it do if the rest of the team did not participate in the design of this code, didn't review it, and might not even know it exists? The moment the rock star leaves the company or switches to another project, the team has to spend considerable effort figuring out what the code does and how to support it in the future.

This conversation was really important because people discussed a topic that comes up in every team and in every engineer's career. How much of your success in a workplace depends on your natural talent, the skills you learn, and the team you join? Can any of these things help you become the 10x engineer?

The Elder Scripts blog covers the opportunities and challenges that software engineers and data engineers encounter. I am sharing insights gained from years of work in the industry as an engineer and as a manager of engineering teams. Subscribe to get notified of weekly posts if you haven't already.

Skills over talent

People have different affinities, interests, and temperaments. Some of this variability stems from our childhood, and some of it we pick up from our life experiences. It is safe to assume that some people are naturally better at some aspects of tech jobs.

However, any gifted engineer needs a chance to use their superpower.

Most jobs in the tech industry are knowledge-based. A software developer or a data analyst won't get far if they don't know how to use their tools. The tools themselves are so complex that you can only be proficient in them if you frequently practice for months or years.

Someone who has written Java code for years will consistently outperform a new developer at the same tasks. Even if the rookie has better memory and ability to concentrate, they will inevitably encounter common pitfalls that will trip them up. One of the definitions of an expert is that the expert knows how to avoid the most common mistakes in their field.

Once the newbie puts the necessary 10000 hours into the job, though, they will have a chance to use their natural ability and stand out as an excellent engineer.

Systems over skills

The following story is fictional, but it might sound familiar to you. I myself have had similar jobs that challenged my self-perception as an engineer.

Alice is an experienced, skilled engineer. She knows how to write beautiful code, she is an expert in cloud infrastructure, and she can configure Kubernetes clusters in her sleep. Alice has just joined a team of senior engineers to work on one of the critical pieces of her company's product. Her teammates trust each other, so they don't waste time doing code reviews, complicated tests, and canary deployments. If you need to change a config value in a service, you can just log onto the server and apply the change. Done in 5 minutes, awesome!

Soon Alice begins to notice that something is wrong. The team's services have incidents every weekend and need manual intervention to get back online. Luckily every engineer on the team knows how to debug and fix these problems by now, but even then it takes time and attention. Alice gets a bit tired of spending her Saturday nights firefighting. Her manager looks more and more stressed out, as the team seems to spend more time patching holes in the system than implementing features for the product.

Some of Alice's teammates get fed up and leave the company. New engineers join after a while, but they don't know the system that well, so the firefighting takes even more time. Eventually, emails from recruiters start to look enticing, Alice signs up for a few interviews, and a few months later Alice joins another company.

At first, Alice is a bit frustrated as she picks up her first tasks on the new team. No one can push any code to the master branch, and manual access to production servers is banned. Every change has to go through code reviews and tests, and deployments happen on a regular schedule. Alice spends most of her time discussing the tasks with the team, documenting changes, and updating automated deployment scripts. She asks herself, how on earth do these people get any work done with all these delays. Do they even know how to SSH onto a machine?

But as Alice begins her first support shift, it is a pleasant surprise. All systems are running like clockwork. Yes, incidents happen sometimes, but there are automated recovery procedures. Most of the time, the services recover automatically. In rare cases when they don't, you just need to push a magic button that fixes everything.

After Alice has spent several months in her new team, she sees the benefits of the overhead systems she had previously thought were useless. Code reviews can get nitpicky sometimes, and updating documentation is an acquired taste. But new engineers on the team can start contributing in their first week, and Alice doesn't feel that crippling fear before every release anymore. She is finally working as an engineer full time instead of moonlighting as a firefighter.

Team culture over systems

What magic is responsible for the success of these teams where people have weekends off work and generally get fewer gray hairs?

Is it the tools that they use? Is it enough to configure a continuous deployment tool and forbid SSH access to production servers?

In my experience, no, the tools and systems are secondary to the culture in the team. By culture, I mean the relationships between people, the shared responsibility for delivered work, the mutual trust and respect. The best teams where I had the luck to work had some common characteristics:

• People trusted each other. My teammate Bob didn't think that checking my code changes was useless because I was always right. He didn't trust my skills implicitly. Instead, I trusted his judgment and ability to provide feedback, so I asked him to review my code.
• The team rewarded initiative with action. People shared their ideas, and these ideas were taken seriously. The team set aside time to act on these suggestions. This created a virtuous circle: people saw that their ideas were valued, so they proposed more improvements later.
• People shared their knowledge and mentored each other. This is a vital responsibility of senior engineers and probably the most significant positive change they can bring to their company.

These three qualities of the team culture can multiply the impact of everyone on the team. Each engineer can impact not just their work, but the whole team's work by mentoring teammates, reviewing their code, participating in design sessions, etc. In other words, this approach is what lets people become 10x engineers.