Improve Your Resume by Focusing on Outcomes

I’ve been on both sides of the hiring aisle throughout my career. I’ve been a job seeker more times than I care to count, and I’ve been a hiring manager and on hiring teams on several occasions. I wrote about resumes in 2010, and I’d like to think most of it holds true today (I will say my thinking has evolved, especially with #8 and #9); but what I’ve noticed since then is a formula for ensuring your resume stands out amongst your peers. All programmers write code, and the best programmers figure out how to solve the problem with as little code as possible (if you believe that code is a liability, then this isn’t a logical stretch), but since you’re applying for a job as a programmer, it puts you into a counumdrum. How do you make writing code sound as appealing as possible?

You focus on the outcome, and the impact you had towards that outcome.

I love to write code for code’s sake, but on someone else’s dime they want me to solve problems and deliver value. That’s what you should focus on on your resume. We love to talk about which hammers we use to drive nails, but we sometimes forget we’re driving those nails for a reason.

You’ve been tasked with hiring a carpenter (because hiring a progammer example would be a bit on the nose). All else being equal, would you rather hire the carpenter that says:

I created a method to allow builders to reduce the time it took to frame a house from 3 days to 1 day, resulting in a 66% cost decrease using the pneumatic bfg nailgun 5000.


I used the pneumatic bfg nailgun 5000 to frame this house, and was able to do it in one day.

We all intuitively know that the first approach is better, but why? It had the same details as the second, and was shorter to boot. The reason why it is better lies in how the information is laid out.

  1. Start off with a strong action verb. Created, Shipped, Spearheaded, Drove, or one of 185 other action verbs.
  2. Describe the outcome. You did something, what was the outcome of that something? Programming doesn’t exist in a vacuum.
  3. Describe the impact that outcome had. You framed a house in one day! Great! What’s the story behind that outcome. Did it lead to higher revenues? Did it lower costs? Even if you can’t directly associate a dollar value to the outcome, can you associate something else that’s quantifiable? Like support costs/time or developer cost/time? If you wrote an optimization routine that took a 30 minute build time down to 5 minutes and you have 20 developers on the team, that’s an entire developer’s daily salary in cost saved, every day!
  4. Finally, describe the means. How did you do it? What did you use to do it? This part is less important for business people than it is for other developers who may be on the hiring team.
    The developers who read your resume still get what they want (“What hammer did you use to drive this nail?”), but the business people and non-technical people who read your resume get what they want, first.
  5. These bullets (and your resume in general) should be written to reflect where you’re applying to work, and the work they do. If you’re applying to work at a consultancy, on-time and on-budget matter a lot more than it would if you were applying to a team that care most about eeking out performance (say a financial trading firm). You want to emphasize what the company you’re applying to cares about.

In short, if you follow this format:

<Action verb> <Outcome> <Impact> <Means>

By showing what you did, what it resulted in, and the business impact of your actions, you’ll already be ahead of your peers in showing that you can communicate well. This format also has the added benefit of working for robo-reviewers, as it still includes the keywords our machine overlords are looking for.

So take a look at your resume, and think about how you can reframe it to put the impact to the business first. And if you’d like help, drop me a line. I’ll be happy to help.

Leave a Reply