Hire based on outcomes instead of role descriptions

The first time I hired someone, I wish I’d known it’s much better to think about the outcomes you’re hiring for. With that in mind, work backwards to the experience and skills required for a person to succeed in this role.

I. Not in chronological order

The first time I went through the process of hiring someone, I thought it through from the first step to the last step. Write a listing for a role. Get resumes, interview people. Hire someone, hand them a laptop. Rinse and repeat.

At the end of the process, I learned that was suboptimal. At no point had I thought about how hiring this actual person (not an abstract role) at this actual company (one with peculiarities and specific needs) would create the outcomes we need to succeed. I wasn’t thinking about how to help this kind-of-person swim instead of sink. That was my mistake!

I should have thought about what it looks like for someone to succeed on our team and solve the problems we’re facing, then shape the hiring milestones around that.

II. Succeed despite yourself

In my defense, it’s really easy to naively approach hiring in chronological order. We need to fill a $language developer role, so write a job listing for a $language developer. Post it to the job sites, review the resumes and cover letters. Talk to people on the phone about that kind of role, in general. Have them do a code exercise to demonstrate how they perform in that role. Schedule face-to-face interviews to make sure they’re the real deal. Extend an offer and set a start date. Greet them when they walk in the door, make them do paperwork, hand them a laptop. Rinse and repeat.

We’ve all been through it, so it seems natural to approach it that way. Yet, the process is so miserable and the outcomes so mediocre. Somehow we stick with it. (There’s more to unpack there, someday.)

Spoiler alert: a great candidate found us, it all worked out, and that person was wildly successful. Everyone lived happily.

The lesson for first time managers is: some of your early successes are because you inherited an excellent team, not because you’re a natural gift to the craft of management.

Luckily, after the offer was out, I put together a 90-day plan for the new hire so they knew what was expected of them, what they would be doing, and how to succeed on this team. Besides being prepared enough to take advantage of our luck, this was my best move.

III. Work backwards from outcomes

What I should have done is thought about the outcomes from the future, backwards.

Suppose it’s three months after a new team member has joined the team and they are wildly successful.

  • What are they doing that makes them so effective?
  • What goals did I give them for the first day, week, month and quarter that led them down that path?
  • What are the outcomes this organization is looking for from this role?
  • What are the learning curves they’ll have to climb to make those outcomes happen?

By thinking through and answering questions about what success looks like at this point at this company I’ll know what would make a successful hire and what I should look for in candidates.

The unreasonable effectiveness of checklists

Checklists are a fantastic tool for thinking. This despite the existence of GTD, Kanban, PARA, and any number of ways to organize projects and figure out how to finish them. When I’m starting a project or when the going gets weird, checklists are usually how I end up thinking my way through.

I am certainly not the first person to espouse the greatness of checklists. There are TED talks and books that are far better at telling you about that. I can only tell you about how checklists make me feel.

First, crossing things off checklists feels great. It’s a rewarding feedback loop that keeps things moving!

Checklists are great because they are the smallest form of planning you can possibly do and get away with it. Checklists are not so dear that if things go weird, I feel bound to them. Change the list based on the new information and keep getting things done.

My experience is that Eisenhower nailed it on the head: “plans are useless, planning is essential.” The essence of planning is thinking through scenarios, outcomes, and how to connect the two. A lack of planning is a lack of thinking. If I can’t be bothered to think it through, why would I even do it?

Checklists are great because they are an easy way to get my brain thinking about the details. They force me to think about all the things that need to happen. They force me to think in time and sequence: this needs to happen before that and this other thing will take a while so that’s probably another checklist. Checklists force me to think about dependencies and who is going to do what part of a project. For example: Bob has access to all the welding tools, so he needs to do all the metalwork which means Alice and Chris are stuck with all the woodwork and painting.

Leading projects over the past couple years, I have found that people appreciate a checklist that tells them exactly what they need to do before they’re done. Production deploys go so much smoother and stress-free when there’s a checklist that thinks for us. I’ll take a well-written feature pitch or requirements doc any day, but a well-considered checklist will do in a pinch.

A checklist is like sending my future self, stressed and at less-than-full-thinking-capacity, a note saying “You got this. Do these things one at a time until they’re all done.”

Onboard new teammates with a 90-day plan


My new boss had written up a 90-day plan for me the week before I started. This was perfect timing. I was already starting to put a bow on my current work and my focus was wandering. Now my brain could start working on ideas for the next gig. Plus, I had a much better idea of what I’d start working on and how to make an impact than I did coming out of my interviews. It was one of the better emails I’ve ever received.

It seems totally obvious that hiring managers should have a plan for new hires. Yet, in more than a decade of work and several jobs, I’d never had a 90-day plan for a new position. In the parlance of our times, a 90-day plan for new team members is one weird trick that is pretty dang easy to pull off.

For all my hires since then, I’ve written up a 90-day plan. I’m convinced that this is one of the best things a hiring manager can do to bring new people onto their team. And it’s relatively easy!

A 90-day plan for onboarding starts off with very specific tasks for the first day and week. Do the paperwork, meet the people, get your digital and/or physical workspace set up. Learn about the team’s process, the rhythm of building and delivering. Meet with a team buddy who will introduce you to folks on the team and explain all the quirks and features of how the team works.

The first 3-4 weeks of a 90-day plan, for hands-on engineers, is about working with a buddy to spin up the flywheel. The goal is to come up to speed on learning the systems and contributing to them. Get the system running on your laptop or development sandbox so you can make quick iterations and one-off experiments. Land your first code change, your first review, and your first change to production.

(My angle here is for folks building SaaS web applications, but it’s the same for any kind of developer: get a few early wins and build from there.)

The second 30 days are when new team members start to come into their own. This is when I want to help my new teammates plant the seeds to realize the potential I saw when they interviewed. Important projects start spinning up. Strategy comes into play. Now is when I re-emphasize to them the potential I saw and brainstorm how to put that special skill, innate talent, or superpower to work improving our team or outcomes.

The final 30 days should start showing evidence that my new teammate is creating good outcomes. The seed of what makes them special (and what compelled me to hire them) is planted and starting to take root. I should be able to talk to teammates and co-workers and hear about how this new person is making an impact on our work and the company’s trajectory.

After 90 days, my new teammate should feel like a productive part of the team. At every point in those first 90 days, they should see little hints that they belong with this group of individuals making a thing together. After 90 days, they should feel confident that they do in fact belong with these folks and made a great choice when they accepted our offer.

Writing a 90-day plan for new hires forces you to think through how to get them started. You won’t just throw them in the pool and say “good luck!” And, it tells your new hire that you’re a smart person who is invested in their success. Every leader should do this.

Use a tag line that means something

I like that Ember’s tagline is about ambition.

It’s easy to write an empty, temporary tagline. “Simple and good”. “Only 4 kilobytes.” It’s harder to write a tagline that generates principles which stand the test of time. “Simple and fast” are in opposition. “Only 4 kilobytes” is unlikely to last if the software evolves.

Ember logo

“Ambitious” as a tagline speaks to a number of qualities, but none of them are in conflict. An ambitious project could choose the boring tactics in favor of rapid delivery. Another ambitious project could aim for longevity. Yet another ambitious project might aim to have a large impact in the world or aim to do something previously considered implausible.

For a framework the size of Ember, that’s an appropriate diversity of goals. But they’re all covered by ambition. The tagline unifies and clarifies as much as it inspires.

Use factories to create jumbo object graphs

The entire time I’ve been using FactoryBot, several years at this point, I’ve used it one factory at a time:

company = create(:company, name: "Acme, Inc.")
alice = create(:user, name: "Alice Smith")
posts = create_list(:post, 3, user: alice)

Do you see the mistake I make all the dang time? Spoiler alert, I forgot the company relation on Alice’s user, so she is either orphaned (unfortunate) or created on an entirely unrelated company. That’s gonna make my test fail in weird ways!

Lately, I’ve been trying something different: create the whole object graph I want to test on in one fell swoop:

company = create(
  :company,
  name: "Acme, Inc",
  user: build(
    :user, 
    name: "Alice Smith",
    posts: build_list(:post, 3)
  )
)

The entire intent of the test scenario is made clear right here. And, the error I so often make is solved structurally rather than by vigilance.

Granted, that’s pretty chunky and way more lines. I feel like it’s a worthy tradeoff!

When I need to reference the models created by my jumbo object graph, I use RSpec let and ActiveRecord finders with a mind towards consistently finding the right thing:

let(:company) do
  create(...) # the whole company bit from above
end
let(:alice) { company.users.find_by(name: "Alice Smith") }
let(:posts) { alice.posts }

Failure = entropy due to adding humans

Here’s a real dinger of a sentence from Michael Lopp’s latest, The Art of Leadership: Small Things, Done Well:

Failure is created by the increasing entropy of a growing number of humans running around the building, good intentions in hand, breaking things.

Growing an organization requires rethinking trust, coordination, and collaboration. The breakpoints where things go from working pretty well to an absolute shamble come faster than we think. They don’t even occur at nice, round numbers like base–2 or base–10 orders of magnitude.

Figuring out how this works for teams, companies, social networks, and whole countries feels like one of the big unsolved problems of the knowledge/attention-era.

Writing is thinking, so write about code

Writing clarifies thinking. Therefore, writing design docs clarifies one’s thinking about code. Design Docs at Google and an example/meta design doc from the same author are great places to start!

I found that writing prose until I run out of clarity and then switching to proof-of-concept code is even better. The constraint of making an ambitious design work with a minimal change-set is a nice way to work for a day or so.

Lots of features or fixes don’t require in-depth thinking to get started. But when they do, sorting out the ideas and tradeoffs in writing helps a lot.

Write until I run out of ideas, flesh those ideas out, write about the nuances I found. It’s a nice feedback loop!

Bradford Fults on feedback and human bias

A Better Approach to 360° Feedback: Bradford Fults shares ways to route around fallible human memory and gather useful information when it comes to review season.

Humans also have a recency bias and suffer from long-term memory distortions that change to fit their current opinions of other people. This means that “observations” from months ago often aren’t so much observations as they are current opinions and emotions repackaged as fixed stories about the past. Most people don’t even intend to distort the truth like this: it’s just the way the human brain works.

Instead, ask questions in the context of how the reviewer works with the reviewed, particularly in the last 90 days or so. Paraphrasing Janet Jackson: “What Have You Done For Me Lately?”

Towards smaller JavaScript

The JavaScript ecosystem’s gone to a strange place where dense frameworks and complex tooling are the status quo. But, there are data-points suggesting the pendulum could swing back sooner than later:

  • Snowpack 2.0 – download all your deps, import them as modules. Snappy development experience ensues.
  • lit-html – generate DOM without going through React/Vue/etc. intricacies
  • Alpine.js – attach dynamic interactions to elements with data elements describing DOM manipulations
  • htmx – attach dynamic networking to elements with data elements describing AJAX/Websocket/SSE events

Caveat: I haven’t tried any of these. But, the trend-line is promising. JavaScript the language, while not perfect, is Pretty Good now. Perhaps the next few years will see the great ideas of the frameworks squeezed into more accessible, less sprawling expressions of those ideas.