How to be a 10x engineer: Business value for technologists

This is a guest post from Donnie Berkholz, lightly edited. Enjoy!

Dear new developer,

Since joining an enterprise (the world’s largest business-travel company) a while ago to drive their DevOps transformation, my ongoing mental evolution regarding the value of technology has gone through an almost religious rebirth. I now think in a completely different way than I did 10 years ago about what technology is important and when you need it. If you want to become a 10x engineer, you need a different perspective than just working on things because they seem cool. It’s about working toward the right outcomes, whereas most of us focus on the inputs (what tech you use, how many hours you work).

It all comes down to business value. You need to contribute to one of the core factors of business value, or however incredible the technology is, it just doesn’t make a difference. If you don’t know what that really means, you’re not alone — most of the technologists I know have trouble articulating the business model of their employers.

I think about it as 4 primary factors:

  • Money. This comes in two flavors. First, you’re creating new efficiency, which increases the profit margin. This could either be through lowering the underlying fixed costs of running the business, or decreasing the cost of goods/services sold by saving a little money on every one. Second, you’re increasing sales, which grows overall revenue. In a cost center within a larger enterprise, or in saturated markets, the former is the most common mode of operation because it’s hard to capture new opportunities. In the latter, it’s about growth mode – investing to capture new value, and often assuming you can make it profitable later. This could be framed as “land and expand” or with the assumption that your company will increase the price and margin once it’s gained a sufficient market share to do so with lower risk. Do you understand your company’s business model? Where does the money come from, who are the customers, what are their needs, what is the sales process and cycle, and what are they buying?
  • Speed. Again, there’s a couple of versions of this that overlap. The overall goals are either initial time to market or speed of iteration. Time to market can come at the expense of significant technical debt, while long-term accelerated iteration cycles are about product-market fit. If you know of the Lean Startup approach promoted by Eric Ries, this should sound familiar. From a long-term perspective, iteration cycles require a balanced approach of customer perspective and technical debt. Otherwise, your company can’t deliver value to customers quickly due to accruing interest on its tech debt. In practice, this can drive an approach that involves gradual refactors with the assumption that long-term rewrites (or e.g. strangler pattern) will be required. It’s the classic “design for 10x but rewrite before 100x,” to paraphrase Google’s Jeff Dean.
  • Risk. As before, this essentially boils down to executing on new opportunity or loss to existing opportunity. Dan McKinley has a fantastic post on why you should choose boring technology, because the important risks are in the business model vs the tech. You should only make a small number of bets on new technology when it will really make a difference in your ability to deliver on business value. For existing opportunity, it’s more about risk avoidance. Typical approaches tend to end up in some mainframe application that one nearly retirement-age developer knows but is afraid to touch. However, a more sustainable model is to implement heavy automation if it truly is a business-critical application that justifies the investment. Relatedly, risk avoidance is where security shines. One of my favorite perspectives is Google’s BeyondCorp model, which assumes your perimeter is compromised and acts accordingly.
  • Strategy. Often not immediately visible in the above approaches, investing in strategic growth opportunities is consistently a great path to success in your business. Do you know your company’s strategy? They probably have posters up and meetings about it all the time. Could you say it out loud? Do you know how it maps to concrete actions? Although any individual opportunity may fail, your contribution to executing on the technology behind that opportunity will not go unnoticed. Similarly, if you’re involved in divesting from areas your employer wants to leave as part of its strategy, you have a real but often smaller opportunity to leave your mark upon the work.

Although many other factors have an impact upon business value, those are 4 of the most important ones that can make you consistently successful as a technologist. The key is to understand which ones play into your work, so you can act accordingly in your day-to-day efforts and as part of your career strategy. Are you building software for a cost center, a growth incubator, a risk center, or at a company that cares to invest in speed? Taking full advantage of this approach could make you the 10x engineer you’ve always wanted to be. Best of luck in your journey, and may you spend time where it matters!

Sincerely,

Donnie

Donnie Berkholz has been driving the DevOps transformation at CWT (formerly Carlson Wagonlit Travel) since early 2017. Prior to that, he led a global team at 451 Research providing research and consulting around leading-edge trends in software development and DevOps. His background includes roles at RedMonk — where he focused on DevOps and open source — and well over a decade at Gentoo Linux, where he worked his way up from a developer to lead a group of more than 250. One of his passions is the social side of technology, and he’s led initiatives to turn around unhealthy teams as well as measure and act on open-source community metrics.

He got into tech almost by accident, because his role as a biophysicist got increasingly computational and he decided he wanted to focus on the technology. Prior to tech and science, he did a stint as a journalist. Donnie now combines that diverse skillset in communications, data-driven thinking and technology to drive companies toward differentiation with leading-edge technology.

Featured

I’m writing the book I wished I’d read

Dear new developers,

Update July 5, 2020: I now have a launch date and a cover.

You may have noticed the pace of new letters has slowed down a bit. There have been some fantastic guest posts, but there’s only been one new letter per week for a while. There’s a reason for that.

I’m excited to announce that I’m writing a book. It’s the book I wished I’d had when I was beginning my development career.

It’s based on this blog, with ideas, text and guest posts drawn from it. The format is similar: letters covering a variety of topics. However, all the content has been thoroughly reviewed, organized and revised. You’ll also see new letters covering topics left untouched by this blog.

I just shipped off the first half of the book to the publisher. If you want to be in the loop, contact me to be put on the book announcement list.

– Dan

You’re going to put some plates in toasters

Dear new developer,

I saw this insightful tweet:

The whole thread is worth reading, but you get the basic idea. Sometimes you don’t know what you don’t know.

When I think back over the years, I am amazed at how many things I can do without thinking now that would have been baffling to me at the beginning of my career, including technical and non technical knowledge). This list includes:

  • navigate files and directories work
  • examine an HTTP call
  • determine the performance characteristics of an application
  • refactor an application
  • architect a large application
  • run a meeting
  • plan a project
  • exit vi

The road is long. And I still put plates in toasters periodically.

Recently at work, I energetically revised a planning document, adding what I thought was a ton of insight and value. Later I found out that the value I added was actually negative and that I’d done more harm than good to the organization’s goals when adding my thoughts. Man, was that a humbling and learning experience. Actually, that was more like putting a fork in a electrical socket than putting a plate in a toaster.

Much of what I know is at a high level with the idea that I can dive in (using resources like Google or Stackoverflow or a mentor) if I determine a need. Just knowing that something exists means that I can leverage all the great learning resources available if I see a place where it might appy. I also do a lot of pattern matching, where I compare how one system or process worked and see if and how that knowledge applies to a new problem.

So when you find yourself floundering, take a deep breath, forgive yourself, and dig in to learn. Foundational competence is something that you will acquire with time and study. But until you do, you’ll be putting plates in toasters.

Sincerely,

Dan

Learn an IDE

Dear new developer,

Just like you should learn a text editor, you should learn an integrated development environment (aka IDE). This is typically a standalone program focused on one or more programming languages. They range from free to a couple of hundred bucks in pricing.

Using an IDE will give you the following benefits:

  • It will be easier to navigate a project. Typically IDEs have a tree view of the entire project. Especially if you are not familiar with the command line, having this may make it easier for you to see how pieces of the project fit together. If the language supports it, an IDE can provide powerful searching capabilities, allowing you to see where a function, method or class is used.
  • Often these have refactoring support. Refactoring allows you to easily rename variables, functions/methods and files. If the language or IDE support it, references to the renamed entity can be updated as well. This will help make the code more fluid.
  • Debugging and code inspecting capabilities can be very useful. You can walk through code that is running locally and see the state of variables and make function calls. This is especially helpful if you have a test that can drive the code and replicate a bug. You can also, if the language supports it, connect to remote servers. (Many languages have command line debuggers as well, but it’s usually easier for a new developer to use an IDE.)
  • The IDE can provide text manipulation functionality. For instance, if you want to add documentation comments to every method, or an easy way to generate boilerplate methods, IDEs can provide this. It’s often easy to customize to your needs as well.
  • Easier learning the language or framework. If you are not sure of the exact name or syntax of a library call, an IDE can suggest it (often based on you typing a few letters). The documentation is often integrated as well, so you can, for example, see the javadoc by mousing over a method call (in a Java friendly IDE).

Obviously, as you see above, an IDE is very powerful. It’s also very tied to a language and the language’s features. If you are using a dynamic language (PHP, ruby) your IDE will have different capabilities than if you are using a statically typed language (C#, Java). But in either case, mastering your IDE will make it easier to write and debug code on your development computer.

Sincerely,

Dan

How to go through a layoff

Dear new developer,

At some point in your career, you might get laid off. This is different than being fired for performance reasons (which might happen too, unfortunately). First off, I am not a lawyer, so this is based on experience, reading and research, not a law degree.

Please don’t take this as legal advice or anything other than an informative blog post.

So, you get called in for the meeting. Your boss is there. Likely someone from HR is there. They tell you the news that the company has decided to part ways with you.

Your heart sinks. You get a big fat packet of paper. The HR person runs through it quickly and asks if you have any questions. You feel a bit dazed.

Take a deep breath. Realize that no matter how crushing this feels, two things are true:

  • this isn’t personal.
  • you’ll get through this.

Ask any questions you have. Some important questions:

  • when do you have to sign this packet of documents by
  • is there a severance, and if so, how much
  • what about other things that were yours (401k, FSA, HSA)
  • how to say goodbye to your teammates
  • what about other things that are the company’s (computer, books, equipment, etc)
  • who at the company you should contact if you have other questions

Don’t be unprofessional. Don’t get mad.

Don’t try to get your job back (it’s gone, sorry!). Don’t agree to anything other than reviewing the paperwork.

Make sure they have a non work email for you so they can send you additional docs if needed.

By the way, if they have their act together, you won’t have access to your work accounts after the meeting, for better or worse.

You can ask why you are being let go. Don’t be surprised if you don’t get many details.

Email or LinkedIn are good options for saying goodbye. Write a quick note to your former co-workers stating that you enjoyed working with them. You can express regret at leaving, but there’s no sense in badmouthing anyone. You never know if you’ll end up working with these folks again.

After the meeting, take some notes on what happened during the meeting. Use your own computer or a notebook. This will help make sure you understood everything that happened. If you want, add some details about anything leading up to the layoff (some things are more obvious warning signs in retrospect, and you want to remember them in the future).

Before you sign anything, it’s always a good idea to run any agreement by an employment lawyer. Yes, they cost a lot of money ($X00/hr) but they’ve seen these kind of contracts before and are legally obligated to do right by you–unlike the company’s lawyers who wrote up the agreements, who are obligated to look out for the company. At this point it’s “just business”, and you want to protect yourself. Ask the lawyer for their advice (“does this seem reasonable, are there other clauses I should ask for”), but make clear your budget and timeline. (If you don’t know a lawyer, ask for a referral from a friend.) There may be some back and forth with the company over the documents.

After the lawyer has looked any agreements and you’ve had some time to think, you can sign the agreement. Or you don’t, based on their advice and your feelings.

After that take a bit of time to grieve, if you can. Even if the company or job wasn’t the perfect fit for you, it hurts to part ways.

Then, roll up your sleeves and start looking for a new opportunity. Is it time to try contracting? Maybe something else that is risky? Or to reach out to your network and see what is available?

A layoff feels like a defeat. But you’ll get through it.

Sincerely,

Dan