10x Engineers 10x Teams
We’ve all heard the story of the “10x engineer”–the unicorn who gets 10 times as much done as her peers. I can attest to the fact that such engineers do exist. We have some at Gladly: engineers who can solve in a day, something that takes a typical engineer a week or more.
Being a 10x engineer feels great. Why wouldn’t it? You’re getting 10 times as much done as others. I just said you’re a unicorn!
But being 10x faster than other engineers doesn’t automatically make you a 10x engineer. In fact, it’s entirely possible to 10x yourself by making things so complex that nobody else understands them! If you’re making yourself 10x more productive at the expense of slowing down your entire team in the process, you can’t call yourself a 10x engineer.
So that begs the question: who can call themselves a 10x engineer? Engineers that don’t just 10x themselves, but also 10x the capacity of everybody around them.
So how do you 10x a team? It’s instructive to take a case study from open source: Ruby on Rails.
Why Rails?
While we don’t use Rails at Gladly, we do find it full of inspiring examples of improving team efficiency.
The introduction of Ruby on Rails clearly 10x’d not just a team, but an entire industry. In 2005 David Heinemeier Hansson introduced the world to Rails in a video where he both built a blog engine and explained the framework in 15 minutes. At the time, building a blog engine was a popular starter project for people first learning web development. And doing it would take days, if not weeks, of work. It only took 15 minutes with Rails.
But more than that, the code that David wrote in that intro video was clean. It followed an established architectural pattern (MVC) and it clearly separated the presentation from the backend logic. This was a clear improvement over the spaghetti PHP code that was popular in the day.
Almost overnight, 100s of startups popped up building web software on Rails better and faster, helping lift Silicon Valley out of the doldrums of the dot-com crash, and into the web 2.0 revolution.
So, what does Rails do right?
Leverage existing knowledge and convention
People are faster when they’re comfortable. And it’s easier to be comfortable when you’re building on existing skills rather than starting from scratch.
Rails introduced much of the world to Ruby, true. But the ERB templates used for display were very similar to the PHP that most web developers at the time were already using. The MVC architecture that Rails adopted was again familiar to most sophisticated engineers, and there were already plenty of existing resources available for those who wanted to learn more about it.
Rails also famously preaches convention over configuration. The benefits are obvious: you learn to do it once and you’re comfortable doing it many times for many different projects. Limiting flexibility also means you aren’t slowed down by having to make choices nor confused by non-standard choices made by others.
And it’s not just Rails that does this. Many of the most productive technologies in use today allow teams to build on existing foundational knowledge and get comfortable quickly. To take some examples from technologies we use at Gladly: Go is easy to pick up since its syntax is heavily inspired by C. Node.js gained rapid popularity because it allowed people to leverage their front-end skills on the backend. And Kubernetes uses roughly the same command line API as Docker.
Invest in documentation and tooling
While it’s important to strive for code that is readable and self-documenting, the reality is that it’s much easier to skim and understand prose than it is to read code. Yet too often we don’t document the work that we do ourselves. Ask yourself this: when you want to use your favorite open source library, how often do you go to its code vs going to its documentation?
Most of the first converts to Rails famously found it through its intro video–a form of documentation. And the Rails Guides were also incredibly well-produced.
Almost every great open source project has great documentation. Many a web developer first learned their trade by reading the incredibly accessible PHP documentation (why don’t more docs allow comments?). Perl has the camel book. Java’s API docs were as important to the project as its byte code interpreter. Almost any popular open source project you name has incredible documentation.
Not only did Rails have incredible documentation, it had great tooling. It had scaffolding and generators to quickly get development started, and rake tasks to perform common actions like running migrations.
Outside Rails, Go is thoughtfully designed to make teams more productive and efficient, and ships with great tooling for building, testing, and even formatting, installing, and linting code. Apple has Xcode and Microsoft has Visual Studio. All of which make developers way more productive.
Contain complexity behind understandable APIs
The most efficient engineers keep things as simple as possible, making it easier for others to contribute. Reading somebody else’s code (or even your own code a month later) is difficult enough without the added work of having to disambiguate unnecessary indirection.
But there are times when it’s impossible to keep things simple. Some problems that we need to solve are, by their very nature, complex. In situations like these, the best open source projects contain that complexity behind well-designed and documented APIs.
Creating a well-designed API is best done by starting from the documentation: write down some examples of how you’d expect the API to be used and run them by coworkers to see if they make sense. Think through these examples and make them simple, consistent, and human-centered–instead of designing the API from the point of view of the underlying implementation. More than test-driven design, documentation-driven design leads to clear, concise, consistent, and–most importantly–productive APIs.
For example, the simplicity of Rails’ Active Record API makes it easy to pick up not just how to use the system, but also a lot of the best practices for database structure and normalization. And this is not limited to Rails. Picking from technologies we use daily at Gladly: Elasticsearch exposes a lot of the power of Lucene over a simple, well-documented and understandable REST API, while Docker and Kubernetes allow incredible power to be harnessed by a simple configuration and command line.
Conclusion
Even though most of us aren’t creating a new web development framework, programming language, or orchestration platform, the principles from these 10x projects can guide us:
- Leverage existing knowledge and convention
- Invest in documentation and tooling
- Contain complexity behind understandable APIs
Ultimately, it all just boils down to being thoughtful and disciplined about making your code easy for others to adopt and use. And this is something that we all can and should do, especially those of us who aspire to be true 10x engineers.
