In literature, the unreliable narrator can be a delightful way to introduce suspense or tension. An unreliable narrator tells lies or misunderstands the world, and therefore can’t be trusted. They seem believable at first, but the reader soon realizes they’re not credible. You need to doubt what they say, and figure out what is really true.

The unreliable narrator is much less delightful as a manager.

Or as your manager’s manager. Or the general manager of your division. Or as the CEO.

The unreliable narrator as manager makes getting work done much less effective, and much less enjoyable besides.

Up front, I’d like to say that I’ve had some good managers in my career. I’ve also had a few that inspired this post.¹ At least one was not my direct manager, but was higher up the reporting chain.

What Does It Look Like?

In literature, there’s really only one way to know if the narrator is unreliable: to compare the events to what the narrator tells you. If they don’t match up—if the evidence casts doubt on the narrator’s interpretation—the narrator is unreliable.²

In being managed, the basic test is pretty similar. If your manager says things that don’t line up with reality, there’s a chance they’re an unreliable narrator.

That said, it can be hard to apply that basic test if you don’t have a way to check in with reality. Sometimes you can: if Finance sends a company-wide email about the new expense reporting system that everybody must use, and your manager says to keep using the old one, you have a few ways to discover the truth.³ On the other hand, if your manager tells you the Jones account is our highest priority and you’ll need to pause your work on the Smith account, you might just have to believe them.

Even when you “just have to believe them”, there can be hints. After your manager paused your work on the Smith account, maybe you hear something in the hallway about how we’re just not getting traction on the Smith account lately and gosh it seems like we’re not working on our priorities. The hints often aren’t completely reliable. But they’re often the first inkling that a manager might be an unreliable narrator.

A common manifestation of a manager as an unreliable narrator is confidence in higher-level buy-in on projects or initiatives that doesn’t materialize. Now, unexpected lack of support is something that happens even to the most reliable of narrators. I would not deem a manager as an unreliable narrator after a single instance. But if there’s a pattern, either your manager is an unreliable narrator, or their reporting/approval chain contains an unreliable narrator, or both.⁴

If confidence in higher-level buy-in shows up simply as confidence or bravado in discussions (“…and so I’m sure we’ll get approval for the Sigma project soon”), the impact of the unreliable narration is limited. Sure, some mental energy is spent planning and thinking about a future that never materializes, and that does slow things down a bit. But if the confidence leads to committing resources to work that’s soon stopped (because there wasn’t buy-in, and those resources are needed for other work that does have buy-in), that’s wasteful.⁵

Another common manifestation, in my experience, is an unwillingness to take a position or make a decision that is clearly the manager’s responsibility.⁶ This one might seem a bit strange—after all, the manager isn’t telling you something that doesn’t line up with reality…right?⁷ In a sense, the manager is only choosing to not tell you what the decision is, and so in that sense, right. But zooming out a bit, the manager is also implicitly communicating that the decision is not needed, at least not from them, or not now.

A simple example of that is a team that’s asking for guidance on scope and timeline for a project. “Okay, boss, we see two basic options. One is two months and includes features A-F. The other is four months and includes features A-M. What fits into our department or company goals?” There are a variety of good ways for a manager to answer that question: making a decision, providing general guidance so the team can decide, saying “I don’t know” and getting more information, or pointing the team to someone else who might be able to decide. All potentially good, reality-based responses. But an unreliable narrator, wanting to seem reliable and knowledgeable, might bluster and deflect: “we’ll need to look at the options and pick the one that’s most appropriate, so keep at it.”⁸ That doesn’t help the team move forward. The manager is also implicitly casting doubt on the notion that their input is needed at all.

I’ve noticed that unreliable narration will often come out in regard to promotions or raises. I suspect there are a lot of reasons that go into that (avoiding uncomfortable conversations, trying to look knowledgeable while actually not, ego protection, and more!), and it can be an area that’s difficult to reality check.

To sum up what an unreliable narrator as manager looks like: it’s when the reality communicated by your manager consistently does not line up with actual reality. It affects you, and it affects your work. Work becomes harder. Work becomes less enjoyable. And you have to spend time playing Scooby-Doo detective to find out what’s really going on.⁹

What Can You Do?

So if you suspect your boss is an unreliable narrator, what can you do to improve your work life?

You could try talking to them about it. It’s possible they’re unaware of what they’re doing. But this can be a dangerous move if you don’t trust your boss. And if you think they’re an unreliable narrator, you already have some level of distrust. I don’t recommend a general conversation. Or sending them this blog post and saying “Boss! It’s you!”

What I do recommend is that you make sure you have a way of knowing what’s real: take notes, talk to others, and test perceptions against reality.

Taking notes is something you should be doing anyway as a professional. Especially as you get older, further along in your career, and gain more responsibilities, your brain can’t hold everything. Taking notes gives you a record of things that have happened. Write down decisions, things your boss has promised, requests, and information you’ve been provided. Then, instead of trying to figure out if you just remembered wrong about the priority list from the staff meeting three months ago, you can find the note and read it and be certain. (I like pen on actual dead-trees paper in a spiral notebook, one page per day, with the date written on the page. You don’t have to do that, and it does have the disadvantage of not being easily searchable, but it also makes sure I don’t accidentally delete a note.)

Talking to others is always important, and even more so when you suspect you have an unreliable narrator for a manager. You need relationships at work outside your boss.¹⁰ You need relationships with peers on your team. They’ll have most of the same context you do, but might interpret things differently or be told different things by your boss. You need relationships with individuals outside your team. They’ll have different context, different sources of information, and can give a much different perspective. You need a relationship with your boss’s boss. They have different concerns than your boss, and might be able to serve as a way to check reality. Note that it’s not enough to have relationships—you need to talk to the folks you have relationships with and use those relationships.

Testing your perceptions against reality is either the easiest or the hardest step. It can be ridiculously easy when reality intrudes on an unreliable narrator’s narrative. There’s a lot of schadenfreude that comes from watching an unreliable narrator confidently explain that “the CEO told me the restructure is going to go like this…” and flail when the actual restructure goes very differently. In those cases, there’s nothing you have to do besides remember and observe. In other cases, it’s harder. Testing might mean asking other folks some uncomfortable questions (“what are you hearing about the restructure?”, “who’s setting your priorities these days, and what are you focused on?”, “hey, I’ve been told we’re ignoring the Jones account for now, do you know why?”, or “sales numbers are way down but the boss says not to worry about it, what are you hearing?”). It can take some care, especially when talking to your boss’s boss about your boss.

Even if testing your perceptions against reality is difficult, you need to do it if you have an inkling that your manager might be an unreliable narrator. Your ability to be effective in your job depends on it. Your next career step, next raise, and next promotion all depend on your ability to be effective in your job.

Ultimately, if you’re stuck with an unreliable narrator for a manager and they’re negatively affecting your career or your life, you might need to leave. Finding a new job elsewhere¹¹ and leaving the company is a pretty straightforward way to leave. So is finding a different role elsewhere in the company (maybe you move to continue doing engineering but in a different department, or you leave the reception desk to supervise on the factory floor). Less straightforward, but more fun¹², is to earn yourself a promotion so you’re peers with your boss. Then maybe another so you’re now managing them and can require them to change their behavior.

As I start wrapping up, I recognize that I have a strong bias toward reality. Truth matters to me. Context also matters to me a lot.¹³ And so I’m probably more sensitive to the unreliable narrator as manager than most.

I’m also currently a manager. I want everyone who reports to me to have as clear a view of reality as possible. I still want them to verify that what I say generally lines up with reality, because I make mistakes.¹⁴ If my team understands reality, they’ll do their jobs better, which makes me look better.

I don’t tell my team everything. Some things I can’t tell them. Some things are irrelevant (“hey, y’all, they rearranged the menu so when I go to approve your time off requests it’s now listed under ‘Team Absence’ rather than ‘Time Off’…why are you all dozing off?”). Some things I can summarize. Some things I’ll tell part of my team (“hey, you’re on the Aardvark project, heads-up, Jenny’s taking over as the Finance lead on it”). But it’s not my job to hoard information. It’s to be a conduit for information. Sometimes I add context, sometimes I summarize, sometimes I interpret and re-shape, but it’s all with the goal of giving my team the best representation of what is really, truly going on that I can. Again, that’ll help them do their jobs better.

I can understand why other managers might be unreliable narrators. That doesn’t mean I approve, though. I certainly don’t want to be one. Or work for one. Or have anyone work for one.

If you are a manager and suspect you may be an unreliable narrator, drop me a line. I might be able to help.

1. If you’re reading this and wondering if you were one of the managers that inspired this post, it’s probably not you. If you still think it might be you, drop me a line and ask. Hint: if you’re reading this and self-reflecting, it’s probably not you; if you’re willing to drop me a line and ask, it’s almost definitely not you. [↩]
2. Yes, it’s more complex than that. There are different types of unreliability, and reliability interacts with point of view and limitations of knowledge. As a quick functional test, it’s a pretty decent way to figure it out. [↩]
3. For example, you could reply to the email from Finance. You could ask your boss’s boss. You could try submitting expenses using the old method and see if they get paid. [↩]
4. If the root is that my boss’s boss regularly offers support that fails to materialize, I would expect my boss to learn from that. If my boss does not learn, fairly quickly, I would still attribute unreliability to my boss—though due to naivete rather than other causes. [↩]
5. A fun useful exercise is to filter this scenario through the “8 Wastes of Lean” (or “TIMWOODS”) and see how many categories of waste such activity creates. It’s at least Skills, Inventory, and Overprocessing; possibly Transport, Motion, and Overproduction as well, depending on the specific tasks. (Okay. It is fun. Let’s be honest. Identifying that your manager’s overconfidence led to waste in six out of eight categories? Fun!) [↩]
6. It’s entirely legitimate to delegate decisions, but that’s not what I’m talking about here. If a manager will neither make a decision nor delegate that decision, that’s what I’m talking about. [↩]
7. With a set-up like that, you know the response has to be “WRONG!” [↩]
8. I’ll note that there are times this is a perfectly valid answer. It’s not valid when offered absent guidance. There are times when a company has a clear limit to its budget (time, dollars, etc.) for a piece of work; pretending that those limits do not exist is intentionally denying useful information to people trying to do the work. It’s that last situation that this scenario reflects. [↩]
9. And your boss would have gotten away with it too, if it weren’t for you pesky kids and your blog posts! [↩]
10. “Outside of a dog, a book is man’s best friend. Inside of a dog, it’s too dark to read.” – Groucho Marx [↩]
11. I hope your new job elsewhere comes with a raise and a promotion. [↩]
12. I’ve never done this myself, so I can only assume it’s more fun. [↩]
13. Truth plus context lead me to say “it depends” a lot. Because, in reality (see what I did there?), it does depend. [↩]
14. If you report to me, and you suspect I’m being an unreliable narrator, please say something. It’s possible there’s information you’re missing. It’s possible there’s information I’m missing. It’s also entirely possible I’m making a mistake in perceiving my narration as generally reliable. Your reality check might be uncomfortable for us both, but it’s welcome. [↩]

Recently, for the first time in my life, I had to report to the county courthouse for jury duty¹. I wasn’t selected for the final jury, but I still spent two days participating in the selection process.

It may surprise you to know that movies and TV don’t dwell on the boring parts of jury duty. There were some truly boring stretches. But even the boring parts are interesting in their own way².

The Summons

I received the usual summons postcard. I’d been summoned for jury duty, reporting to the Linn County courthouse on Monday and Tuesday, March 4 and 5, for a term of one trial. I was required to fill out a questionnaire online. I was further instructed to call after 5PM on Friday, March 1, to find out if I’d need to report.

When I called, I was not required to report on Monday. But I was instructed to call after 5PM on Monday, March 4, to find out if I’d need to report Tuesday.

I forgot to call Monday night.

My brain had reasoned that if there was no trial Monday, there wouldn’t be one Tuesday, either.

Tuesday

Tuesday morning, I noticed the reminder on my phone. I figured I’d call, check the box, and be able to work.³

“If your juror number is between 1 and 261, you are required to report…”

I got a little excited. I’d never had to report!

I also got a little annoyed. I’d need to miss work—oh, I should tell my colleagues I’d be missing work—and that annual check-up I had scheduled—oh, geez, and that eye exam I had scheduled in the afternoon.⁴

So I swapped my jeans and tshirt for a button-down and slacks, grabbed a book, and headed off to the courthouse, arriving about 8:30AM.

The potential jurors checked in, were given a sheet of instructions to read, and a 20-minute orientation video to watch on our own devices⁵. There was not a designated room for the jurors to sit in. Instead, we sat on benches, folding chairs, or at giant law-library tables in the lobby area of the courthouse. It seemed a bit odd that a hundred or so of us were all watching the same video, separately, in the same room.

After the orientation video was done, we waited. About 9:30, someone⁶ called the roll. For some reason, about half the group got sent downstairs, but those left on the main level weren’t told why. And then we waited again. Most of us sat. Some had brought books, and read. Some stood. Some paced. A few talked and made friends. Some alternated between sitting and standing, reading and talking, pacing and waiting. Eventually, several of us started walking laps around the lobby.

Around 11:30, we had another roll call. After roll call finished, we headed up to the 4th floor and were sent into a courtroom. The group that had been sent downstairs re-joined us there. As we filed in, we saw several people seated at the tables up front. The court attendant called out about 30 names of potential jurors to be seated in the jury box and the first few rows of benches. I was not in that group.

Once we’d finally been organized and seated, the court attendant exited the court, presumably stepped into the judge’s chambers to tell him we were ready, and re-entered the courtroom to announce that “court is now in session”, and to tell us to “all rise”. The judge entered, had us sit, and gave us a speech about jury trials, the Constitution, the duty and privilege of serving on a jury—all good stuff.

Then it was down to the business of this particular trial. The judge informed us that “this is trial for murder, in the first degree.” Even though everyone was quiet and well-behaved, I felt people straightening up a bit, paying a bit closer attention.⁷

With our attention focused, the judge swore us in.⁸ Then the lawyers for both sides introduced themselves, and began the process of selecting jurors, known as voir dire.

I was surprised that voir dire was more conversational than it is typically depicted on TV. It’s also much longer. The prosecution went first, and instead of just firing questions at us (e.g., “Juror #1, how much do you believe cops?”), they started by providing information.

Surprisingly, the first information provided was a summary of the case to be tried. It was something along the lines of “have any of you read or seen news about the murder allegedly committed on St. Patrick’s Day, 2023, at Cocktails & Company in Marion, by Duval Walker Jr.?” Around a dozen folks had—and stacking surprises, they were not immediately dismissed. They were asked for their names.

The second information provided was the names of the lawyers around the tables. That information set up the next question: whether any of the prospective jurors knew any of the individuals involved in the trial: the attorneys, the defendant, the judge, the court attendant. Nobody did.

By this point, it was getting close to 12:30. The judge read us a long, detailed “admonition”, which I would summarize as “don’t talk to anyone about the case, and don’t get information about this case outside this courtroom.”

And we were released for lunch.

That felt weird. My first instinct was to tell my wife… my second instinct to tell colleagues… my third to tell friends… tell them all “hey! I’m a potential juror for a murder trial!” But I didn’t tell anyone. I moseyed down the street to a cafe for a delicious and filling bowl of soup. I also made the mistake of finishing my book over lunch.

About 1:30, the prospective jurors were ushered back into the courtroom. There were at least a hundred of us, and probably closer to 150. Once we were seated, we were informed that the lawyers and the judge needed to individually question the jurors with knowledge of the case. We were also informed that the courtroom next door had opened up, so we could wait there. So we all shuffled over to the next courtroom and sat. And waited. And every 5-10 minutes, the court attendant would enter and say “Can I get John Doe?”. And then the court attendant would usher John Doe over to the “real” courtroom to answer a few questions while the rest of us sat.

Some of us chatted with the folks next to us. Some played on our phones.⁹ Some tried to sleep. Some wished we’d brought another book. Some read the books they weren’t done with yet. I stood for a while, and even paced a bit in a five-foot space. As the clock ticked, there was speculation in the group about how long we’d stay, when the courthouse closed, how many prospective jurors were coming back¹⁰, if we’d have to report tomorrow, how many days we’d need to report… Someone in the group remembered seeing that the courthouse closed at 4:30PM.

About 4:25PM, the whole group was told to migrate back to the real courtroom. The judge reminded us not to talk about the case with anyone.

Then the court attendant read a list of four names. My name was #3 on that list.

The judge announced that everyone in the jury pool was required to report at 9:30AM the next day. I dutifully wrote 9:30AM in my pocket notebook. The four names on that list, though, were required to report at 9:00AM. I crossed off 9:30AM and wrote 9:00AM underneath. The four of us were moved up from the general jury pool to the “top 34”.

The “top 34” isn’t quite as competitive as it sounds. After all, the names were all assigned. But the “top 34” are a subset of the full jury pool that allows the attorneys to focus their voir dire questioning. The remainder of the pool remains in case individuals from the top 34 are dismissed¹¹.

With that, we were reminded of the admonition, told that all we could tell anyone is “I am a prospective juror for a criminal trial”, and sent home for the day. Again, that felt weird.

Wednesday

After I arrived outside the courtroom on Wednesday morning, I checked in with the court attendant. He told me he’d recognized me. I wasn’t quite sure whether that was good or not.

I was the third of the four new members of the top 34, so I was the third to go in for individual questioning.

I took my seat in the front row of the jury box.

The judge opened by saying “Good morning. Before these folks ask you a few questions, I’d like to start with one of my own. How do you pronounce your last name?” Once I told him¹², he informed me that none of them had gotten it right. That exchange seemed a lot more relaxed, casual, and human than I’d have expected—especially with the defendant sitting at the defense table.

The questions they asked were basic (Q: “Have you seen any news about the events of this case?” A: “It’s possible I stumbled across headlines at the time, but don’t recall any facts or having read any articles.” Q: “Your juror questionnaire notes that you were once a victim of a minor theft. Will that affect your ability to consider the facts of this case?” A: “No.” Q: “The defendant in this case is a Black man. Will that affect your ability to decide this case on the facts?” A: “No.”), and I was back to a comfy chair the hallway in about five minutes.

About 9:30, after a hundred-plus of my fellow potential jurors had arrived in the hallway outside the courtroom, the court attendant called the roll. I didn’t get called, presumably because I’d already checked in. Was not being mentioned during roll call worth that extra half hour? Probably not.

With the roll called, we were again ushered into the courtroom and the top 34 were seated by number. I was number 31.

The judge welcomed us back for day two. Someone—likely the judge, but it could have been one of the attorneys—said that things were likely to move faster today than yesterday, and that yesterday was necessary preliminary work. Then the judge asked if anyone in the top 34 had seen news about the case since yesterday.

Four people raised their hands. Four! I was really truly astonished. After the judge’s repeated admonition, four of the top 34 had seen news about the case.

The judge decided to take those four back to chambers with the attorneys, one potential juror at a time, to ask questions. While he did, he turned on white noise so we wouldn’t be able to hear what was being said. He warned us in advance that it was a little annoying, but that it was better than having to send us all out and then back in. He was right, both about the white noise being annoying, and that it was better than another mass migration.¹³

All four finished their questioning and were returned to their places in the top 34. That surprised me a bit. I had expected that people who were unable to stay away from news overnight would be dismissed. But I don’t know what they’d seen—maybe it was just headlines, or a story that the trial was about to start.

As we resumed, and the judge was handing voir dire questioning over to the prosecution, someone’s phone rang. Loudly. And kept ringing. The judge calmly told us we all needed to have our phones off.

The questioning surprised me.

The topics and content of the questions started by sounding like an Introduction to Civics class: questions about jury trials, and how we felt about being on a jury, and that kind of thing. Some of the questions were the things you might see on TV (“Mr. Smith, what do you do for a living?”), but a lot were not (“Who is happy to be here today?”).

It was fascinating to watch the questions turn into a bit of a (very formally-facilitated) group discussion. (“Mr. Smith, what would you say the duty of a juror is?” might be followed up with “Ms. Jones, how do you feel about what Mr. Smith just said?”)

It seemed to me that the attorneys were intentionally focusing on a group of about 20 potential jurors. Those 20 got most of the questions. I was not in that group of 20. It also seemed like the attorneys would occasionally decide that a potential juror was not a good fit, and would then start ignoring that juror as a target for later questions. This makes sense—the total jury only needs to be 12 plus alternates, so investing too much time into poor-fit jurors seems like a waste.

Another aspect of the questioning that surprised me was that often, a line of questioning would be prefaced by information or scenarios. There was information about jury service, or the attorneys themselves, or a now-entertaining anecdote about the time the defense attorney’s car broke down.

One particular line of questioning that got me thinking at the time had to do with the definition of “self-defense”, and what would qualify. The defense attorney set up a couple of scenarios, such as a housewife that had been a victim of domestic violence and feared her husband was about to attack her again: would it be okay for her to use her cast iron skillet and take the first swing? Aside from it being an interesting thought experiment, I guessed it had something to do with the case.¹⁴

Another interesting theme of questioning had to do with what I think of as “questions of law”. These are questions like “what is the role of the judge in this trial?” or “What do the words ‘premeditated’ and ‘deliberate’ mean to you?”¹⁵ I was surprised that the attorneys were asking these questions (after all, in a trial, I assume the part of the law that defines what “premeditated” or “murder in the first degree” means would be provided to the jury). As I pondered, I think these questions may have been partly to filter out people who are completely unable to accept authority (e.g., the judge question), and partly to evaluate how potential jurors processed and discussed information (the “premeditated” question had a lot of asking one juror to follow up on another juror’s answer).

Less surprising were some questions that seemed directly focused on reasoning ability. One example was along the lines of “if to prove a crime, the prosecution needs to prove parts A, B, and C, what would you decide if they proved just A and B?”¹⁶

Also unsurprising—if somewhat tedious—were the questions about what the defense needs to prove. You see, in the USA, the prosecution needs to prove¹⁷ the defendant committed the crime. The defense does not need to prove anything. If the prosecution has not proven the case, the defense could skip presenting any argument and doing so should not lead to a guilty verdict.¹⁸ The defense attorney spent quite a bit of time on that point. I think the prosecution may have, as well, come to think of it.

To summarize what surprised me about the way voir dire played out:

• The questioning was designed to educate potential jurors as much as filter them
• The questioning involved potential jurors responding to things other potential jurors had said
• Questions were often prefaced with information and/or scenarios; they weren’t just questions
• Some of the questions were about things that seemed like things we should have just been told
• Questioning was not evenly distributed across the jury pool or even top 34

Lunch on Wednesday was at LP Street Food. I saw a couple of other potential jurors there. I read my (new!) book instead of talking with them, mindful of the judge’s admonition not to talk to anyone, even each other, about the case. And very mindful of the fact that about all we had in common was the case. My lunch was quite good.

About 3:45PM on Wednesday, the defense finished up their questioning (I believe the phrase both sides used was “pass for cause”, but I might have mis-heard). The court attendant brought a clipboard with a list of juror names to the attorneys, and they began passing it back and forth (via the court attendant). I got the impression that each side got to cross off one juror per pass.

It was a bit after 4PM when they finished passing the clipboard. The court attendant called out the names on the list, and 12 jurors and two (?) alternates took their place in the jury box. I was not on that list. The judge asked the attorneys to confirm this was the jury they intended to select. As the attorneys double-checked, the judge told the jurors that sometimes a mistake gets made, and a wrong juror slips through. In this case, the attorneys confirmed.

The judge then thanked all of the jurors that weren’t selected. He made a special point of thanking the ones that were not in the top 34. They hadn’t had to answer questions, and he knew it seemed like they didn’t do any good by being there. He went on to explain that there are rules about the size of the pool jurors need to be drawn from for serious cases, and that their presence was still important. I think I believe him.

With that, those of us that weren’t selected were dismissed. We said goodbye to any acquaintances we’d made on our way out. It was a warm spring-feeling day. It didn’t quite feel like the last day of school, but there was a note of that energy as we dispersed from the courthouse, making our separate ways home.

1. I’ve been summoned three times. This was the first time I’ve had to report. [↩]
2. Especially in the “way” of not having to experience them, and just be told about them! [↩]
3. Being able to work would be great. My department was rolling out a policy change, and a peer manager was going to announce his resignation. It’d be a really, really good day to be able to work. [↩]
4. And some part of me wonders if it’s somehow “my fault” that I had to report. Is leaving appointments scheduled for a possible jury duty day a sign of hubris? Was I tempting the universe? [↩]
5. Which, naturally, I watched at 2x. [↩]
6. Possibly a “court attendant”, which is the new term for what used to be called the “bailiff”. Or it could have been another court employee. [↩]
7. In some ways, it seems wild that murder trials get the same citizen jurors as any other trial. They don’t even let us practice with a trial for shoplifting or arson or light treason! [↩]
8. I don’t recall the exact text of the oath. It was a bit different than the standard witness “tell the truth, the whole, truth, and nothing but the truth” oath I’ve seen on TV. It was tailored to jury service. [↩]
9. This despite the warnings outside the courtroom about phones and other similar devices not being allowed. I suspect the warnings have more to do with recording court proceedings, and there were no actual court proceedings where we waited. [↩]
10. Most of them came back. [↩]
11. I assume this is the reason, anyway. I’m speculating. Believe it or not, I don’t know the full voir dire procedures for the state of Iowa. [↩]
12. It’s a Dutch name, so the “ch” is pronounced like a “k”. “Skowt-in” gets reasonably close. “Scout’n” is also reasonably close. [↩]
13. The sound did sound a lot like white noise, but (being aware of the signs posted about phone use, and my somewhat more visible place in the top 34) I did not pull out my phone to verify that the spectrum looked like white noise. It could have been a different “color” of noise. [↩]
14. Upon my release from jury duty, I promptly looked up articles about the case. The line of questioning was super relevant. The defendant is alleged to have been in a fight with the victim, the two were separated, and then the defendant re-engaged with a gun. [↩]
15. As someone who tends to do well with language, this part of the discussion made me sad. One person said, essentially, “premeditated is when you think about it before, but deliberate is when you don’t.” [↩]
16. The correct answer is “not guilty”. [↩]
17. beyond a reasonable doubt in a criminal case [↩]
18. Whether doing so would be a wise strategy is a whole different discussion. [↩]

Stone Soup is an old folktale. I remember hearing the story well before I was in school. And I remember my brother and I begging our mom to let us try making stone soup!¹

For those not familiar with the story, here’s my short retelling. Then I’ll get to my point.

Stone Soup, A Retelling

Once upon a time, there were two travelers making their way through a poor part of the country. As the sun started to go down, the travelers came upon a village where they decided to stop for the night. They knocked on the door of a house to ask if the villagers might share some food. “Even if we had food, and I’m not saying we do, we wouldn’t share it with you! Haven’t you heard about the famine? Nobody here’s got food to spare!”

The travelers looked at each other, shrugged, and made camp. One traveler filled their soup pot with water and set it on the fire. The other carefully inspected the stones scattered around the village and on the road, even smelling some of them. Finally, he picked a stone and gently dropped it in the soup pot.

By this time, one of the villagers was suspicurious². Trying his best to look nonchalant, he walked down to the travelers’ camp. “What’s that?” he asked? “Why, it’s stone soup!” said one of the travelers. “It’s delicious, and filling, and,” here the second traveler paused to sniff the soup before continuing, “probably will be done fairly soon. If you’d like to join us, you’re welcome.” “Yes,” the first traveler smiled at the villager, “of course! Now, you’ll need to forgive us us because we don’t have any vegetables to add, and they do round out the flavor nicely. But to be sure, we wouldn’t invite you if it wouldn’t be delicious anyway.”

The villager was shocked that the travelers were willing to share their meal. “Now that you mention it, I could go check and see what I have. If I managed to find a potato, would that go well in the soup?” “Nothing quite brings out the flavor of stone soup like a potato!” exclaimed the second traveler. At that, the villager scampered off, returning a few minutes later with a potato.

Now, for the sake of time, I’ll cut this short. But the other villagers became suspicurious about what was going on. One by one, they made their way down to the camp, doing their best to look nonchalant. One by one, they heard about stone soup. One by one, they were invited to share the travelers’ meal. And one by one, they scampered back home to find an ingredient to help bring out the flavor of the stone soup.

Finally, the travelers ladled up bowls of soup for the villagers. “I haven’t seen a carrot in weeks!” one said, marveling at the contents of his bowl. “I didn’t know anyone had meat,” another said. “Stone soup is absolutely delicious,” said a third. They all agreed, as they all ate the best meal any of them had had in weeks. And the next morning, when the travelers departed, the whole town turned out to wave goodbye—and to see if there was any way they could keep helping each other.

The End!

My Point

My point, of course, is that minerals are essential to a balanced diet. Wait, no, that’s actually not it.

In the village³, before the travelers arrived, everyone had something nutritious stashed away. One had potatoes, another carrots, another meat.⁴ But nobody had a healthy, well-balanced meal.

Reactions to the story seem to fall into two broad camps. One says that the travelers mooched off the poor villagers. The villagers provided all the food, while the travelers were freeloaders and provided nothing of value. The second camp says that the travelers provided at least as much value as anyone else by catalyzing the villagers to share. Because of the travelers, the villagers gained.

That’s interesting to consider, and probably tells you something about your approach to life.

But that’s not my point either.

My point has to do with teamwork. Teams.

Each individual on a team has unique skills, knowledge, and other resources. Some people can write code. Some can write prose. Some know everyone. Some ask good questions. Some can fix cars. Some are experts on fluctuations of commodity prices.⁵ Some encourage. Some tell jokes. Some get the joking to stop so we can get work done. Some keep schedules. Some run hydraulic presses.⁶

The more skills team members bring out to share, the more effective the team will be. Just like the more ingredients the village brings out, the better the stone soup will be.

Working in teams isn’t about doing exactly what your job description says. Just because your title is “Software Engineer” doesn’t mean you can’t review—or write—website copy. Just because your title is “Bank Teller” doesn’t mean you can’t design a fraud protection protocol. Just because your title is “Pizza Delivery Driver” doesn’t mean you can’t mop the floor.

The villagers in the story hoarded their food because they were afraid of what might happen if they shared. That’s something that, I believe, is common in the workplace. I would faciliate, but I’m afraid I won’t do a good job or that I won’t get my widgets delivered on time. I would volunteer for the party planning committee, but I’m afraid people will make fun of my ideas. I would try writing TypeScript to help out on this project even though I normally write PHP, but I’m afraid learning the syntax and tooling won’t go well and I’ll feel like a bad programmer.

When folks are afraid to share their skills, it impacts the whole team or company.⁷ Not in good ways, either.

As managers or leaders, we can make that worse. We can demand that our folks “stay in their lane” and work within their job descriptions. Did an engineer whip up a graphic for a prototype? Tsk, tsk, that’s designer work! Did the receptionist put air in a regular customer’s tires? Tsk, tsk, that’s mechanic work! Did an individual contributor offer an idea for how to improve a company-wide process? Tsk, tsk, that’s leader work!

We can train our people to not share their skills with their colleagues. When they hide their skills, they feel disengaged from their work⁸, they don’t contribute as much to the company⁹, and they certainly don’t seize opportunities that present¹⁰.

We can train them that not only are their internal fears valid, but also that they’ll face external opposition if they try to share.

It’s one thing to expect (in the sense of guess, or predict) the village butcher to contribute meat to the soup. It’s another entirely to scold the village baker for showing up with a leg of lamb. “You foolish baker! You’re the baker! Why would you think we’d welcome meat from you? That’s the butcher’s job!”

It might be that the baker could produce marginally more utility for the village by baking bread. If you are the Village Deputy Mayor for Soup-Related Meal Community Contribution Coordination, it might even make sense for you to have a conversation with the baker about how next time might go.¹¹

Perhaps there is no wheat, no flour, so no bread. Would you exclude the baker from contributing and from feeling like a part of the community, like they had a share in what was made?

Or what if there is plenty of flour, but the baker had seen that no meat had been contributed, and knew based on years of training at Baking And Other Culinary Arts Academy that meat would really put the soup over the top flavor-wise, and the butcher happened to be out of good soup meat now?

Here’s my point: working in teams is a lot like Stone Soup. Everyone contributes what they can, out of what they have, as they think is best. Everyone can talk about what would be best to add next. Everyone, working together, will produce a much better results. But if everyone hoards what they have, whether out of fear or out of training, the team will just produce a big pot full of hot, slightly dirty water.

Maybe that’s what you want, maybe not.

Next time you think about how to make teams work, think about Stone Soup.

1. It was long enough ago that I have no actual recollection of whether we made it or how it turned out. I’m guessing we found a suitable stone and made it. I’m also fairly certain that if we did, it was delicious. Way better than the non-stone version of whatever recipe we used. [↩]
2. Obviously a mix of “suspicious” and “curious”. Probably best pronounced sus-pish-urious. [↩]
3. It takes a village! [↩]
4. What this says about the agriculture and economy of the area, I’m not sure. How is it that Potato Guy and Meat Guy didn’t realize what the others had, and set up some kind of barter system? How do you end up with a soup with all kinds of varied ingredients, but nobody has happened to notice what goes on in anybody else’s gardens, fields, or farms? [↩]
5. Grade A medium-kernel free-range organic granite prices typically jump around holidays, so be careful when timing your purchases. [↩]
6. I just distracted myself trying to figure out what kind of team would need all of these skills and resources. [↩]
7. It makes me think of various stories about oracles being asked “who’s the greatest military mind in history?”, and answering with “that random peasant who never got asked to command an army.” So much potential, so little of it realized. [↩]
8. Not talking in terms of engagement surveys, though it probably does show up there, or in job satisfaction surveys. If you’ve been trained that some part of you shouldn’t be brought to work, you’re going to disengage parts of yourself from work. Unfortunately, that leads to the dark opposite of Stone Soup: instead of one flash of good leading to more flashes of good, this leads to a smear of apathy leading to more smears of apathy. [↩]
9. Source: duh. While there might be times as a manager to focus a direct’s attention, it’s foolish to regularly face an employee saying “I see a problem, and I have skills that I would really like to contribute toward fixing that problem!” and respond with “No. Your contribution and enthusiasm are unwelcome. Stay in your lane. By the way, are you feeling like you’re appreciated at work?” [↩]
10. At least not without permission, preferably in writing, confirming they’re allowed just this once to scratch their nose. [↩]
11. Side note. Over the past decade or so, I’ve experienced several instances of people trying to plan out potlucks. For entirely petty reasons, that annoys me. If you wanted a main dish, two kinds of chips, a Jello-based side dish, a chocolate dessert, and an orange-flavored beverage, just hire a caterer. If you’re going to have a potluck, be willing to roll the dice. Someone might get home and decide to make potato salad instead of macaroni salad, and it’d be amazing—well, it would be if they didn’t feel locked in to the macaroni salad signup. Part of the fun of potlucks is seeing how things come together (or don’t!) and chatting about the food. That magic goes away with sign-ups and plans. [↩]

Once upon a time, my family decided our powder room¹ needed some improvements. When we bought the house, we’d noticed the hardwood floor was discolored around the base of the toilet, like there had been condensation or maybe a few overflows. The toilet itself was prone to clogging. So, we hired a contractor friend² to replace the toilet and install laminate flooring.

To save a bit of contractor time and cost, and to make sure we got what we wanted, we researched toilets. Tall vs short. Round bowl vs elongated. Various flushing mechanisms. The ability to flush buckets of golf balls. Lids that slam vs gentle-close lids. Water efficiency. We compared options and purchased a fine porcelain potty product at the local home improvement store. That way, when the project was ready, the toilet would be ready to install.

Work started on schedule. There was a small snag in the project when the plumber noted that the hardwood discoloration was not because of condensation. It turned out there was a misalignment between the existing toilet and the closet (drain) flange that the wax ring didn’t quite bridge. Yep, for some number of years, part of the flush had seeped between the hardwood and the subfloor³. No worries, though. It was nothing a replacement of some subflooring couldn’t fix.

The subfloor fix was quick and the laminate went in nicely. We had allowed time for small delays, so everything was still on schedule. All that was left was to set our new toilet and pay the bill. All the pre-planning and that shopping trip were paying off!

The standard residential toilet in the United States is built for a 12″ rough-in. The “rough-in” is the distance from the back wall to the center of the closet (drain) flange⁴. The less-common rough-in is 10″.

At this point, you’d be justified in thinking something like “I know where this is going! You bought a 12″ toilet for a 10″ rough-in. How silly!” Or maybe “Oh, you must have gotten unlucky and bought a 10″ for a 12″ rough-in. How wacky!”

Close! But wrong.

Up front, I’ll admit that I was not aware that there were multiple common rough-in distances. I didn’t even think to measure. I’m not a plumber. I truly dislike plumbing⁵. I didn’t realize that distance measurement listed on the toilet box mattered, didn’t know it was a big deal, didn’t know what I didn’t know. It’s a toilet. Plumbers are professionals. My house is new enough that it wouldn’t have a weird pre-building-code quirk going on⁶.

The rough-in was what the plumber charmingly called “a short ten”. My tape measure calls it 9.5″⁷.

The difference between 10″ and 9.5″ is enough that, had I been smart enough to measure and get a 10″ rough-in, it wouldn’t have fit anyway. So it didn’t even matter that I got a 12″.

Our careful research didn’t matter anymore. The home improvement stores near me didn’t sell anything that’d fit. But our plumber had a source. In a couple of days, we had our new toilet installed, our powder room functional again, we had returned the “wrong” toilet to the store⁸, and everyone was happy⁹. The end!

I could end this post here and it’d be a fun little anecdote. Educational, too! But let’s tease out just a little bit more wisdom, so this is more than a fun story with useful facts about toilets.

Now, I’m reasonably handy. I built a treehouse for my kids. I did a pretty substantial remodeling project at my old house: demolition¹⁰, framing, electrical, drywall¹¹, flooring¹². I have done plenty of light plumbing tasks (though, as I mentioned earlier, I truly dislike plumbing). I’m good at figuring things out. My wife’s pretty smart too. We had a good plan to save time and had selected a pretty premium potty product.

How hard can it be to pick out a toilet?

There are a lot of things that don’t seem like they’d be that hard. Some of them really aren’t hard at all. Some of them aren’t hard in the general case, but have specifics that are difficult¹³. Some of them don’t seem hard but are nuanced and layered and really are that hard¹⁴. And when things really are that hard, there can be a cost to picking wrong¹⁵. The cost of picking wrong can sometimes dwarf the cost of doing the up-front work with the right specialists and doing the project right.

Some humans¹⁶ want to make things faster and more efficient. Taking care of a bunch of preliminary work up front seems like the smart thing to do. Instead of paying a plumber $100 an hour to go to Home Depot, buy a toilet, and then mark up the price when he resells it to me, I think I should do it myself! Or instead of working through and refining a product idea with a designer, an engineer, a marketer, and maybe a salesperson, I can do a lot of the leg work myself, then hand if off to those teams to design it, build it, and sell it. It seems so much more efficient. So much less wasted time.

So, here are our two propositions:

1. There are nuances in some kinds of work that non-experts are simply not aware of. Getting those nuances wrong can dramatically affect costs or results.
2. Many humans want to move fast and be efficient. (Sometimes, because they just want to be helpful and good to work with!)

Combining those two propositions shows the risks that can be created by well-meaning humans trying to be more efficient. Schedules can be delayed. Budgets can be overrun. Deadlines can be missed. Quality can suffer. Frustration and mistrust can build. Global mockery can be sparked. Again, all these costs despite the best of intentions.

This isn’t an argument that only experts can do certain work. It is an argument for considering expertise and the limits of non-experts¹⁷.

Experts: it’s okay to be an expert. I am glad the plumber gave me an accurate explanation of the issue and the fix. I am glad the plumber had a special source for weird toilets. I wish I’d thought to get his evaluation of whether the one I’d bought was appropriate to the location up front. It’s helpful to assert your knowledge and skill, especially if something seems off. You don’t have to take someone else’s word for it, even if they’re the boss, client, manager, or customer.

Non-experts: it’s okay to not be an expert. It’s fine to want to help. But realize you might actually be wildly wrong. I’m glad I didn’t insist to the plumber that I was perfectly capable of purchasing a toilet, thank you!, and insist he figure out how to install the one I’d bought. I’m okay with having had to return a toilet to the store—though it’s a strange item to return, and I certainly could have found other things to do with the time I spent on all of it. It’s helpful to seek out the advice and early guidance of experts, especially if you’re responsible for the project.

The single best technique for experts and non-experts when trying to understand the other’s perspective is curiosity. The plumber could get curious about what I was thinking and what I knew: “Hey, did you know there’s this thing called rough-in distance? And, uh, aside from that, what were the features of this toilet that were really important?” That would let him switch from an argument into teaching me what I didn’t know, while also letting him find the best possible replacement¹⁸. And I could get curious about what the plumber was thinking and what he knew that I didn’t: “What is it that makes this toilet not fit? How could I have known that? What else should I know here? What else in this project might I be wrong about?”

I’ll wrap this all up here, so when your memory has flushed away everything but the story, there’s a chance of a small takeaway.

Be curious. Focus on effectiveness over efficiency¹⁹.

And most importantly, hire a plumber.

1. Variously referred to as a powder room, half bath, main floor bathroom, guest bathroom… [↩]
2. Master Carpenters, LLC in Cedar Rapids. Layne’s a good guy. [↩]
3. Eww. [↩]
4. If you are curious what the rough-in distance for your toilet is, measure from the wall (not the floor trim!) to the floor bolts (often covered with those little white caps). That’s your rough-in distance. [↩]
5. As I finished typing that sentence, a plumbing van drove down my street in front of my house. I swear I am not making this up. [↩]
6. My dad’s house was built in the late 1800s. The supports for the main floor beams were actual logs, with bark still on. That kind of stuff is hard to standardize. Or I could imagine that once upon a time, before building codes, manufacturers in different parts of the country would just build whatever rough-in they wanted and it’d be fine. You’d have your artisanal hand-crafted toilet and custom-craft your home’s plumbing around it. None of that was the situation here. [↩]
7. I just measured. [↩]
8. Never installed, and unused! [↩]
9. Including friends that we told this story to. Schadenfreude stories about home improvement projects are fun. When the story involves toilets, they’re typically five times funnier. [↩]
10. A small army of friends helped. Demolition parties are way more fun than solo demolition! [↩]
11. Hanging the drywall was mostly solo. My friend Steve helped a lot with the first round of mudding. Then my eldest child was born and I hired out the rest of the mudding and texturing. Professionals are so much faster at finishing drywall—it’s amazing. [↩]
12. I cut and installed the laminate myself. But most of the supervision was done by my weeks-old eldest from her baby swing. [↩]
13. Picking out a toilet that fits in your powder room, for example! [↩]
14. I would put project management into this category. I’d also put coaching and playing most sports into this category. In American football, saying “just throw it to the open receiver” or “yeah, it’s 3rd and 15, of course they’re going to throw it, just keep them from throwing for a first down” is easy, but executing on it is hard. [↩]
15. “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” -Mark Twain [↩]
16. me included [↩]
17. At this point, I believe the Geneva Conventions require me to mention the Dunning-Kruger effect, in which individuals with limited expertise in a domain tend to overestimate their competence in that domain. [↩]
18. The phrasing wasn’t quite so tidy, but this is essentially what the plumber did and said! [↩]
19. Or perhaps “outcomes over output“. [↩]

I don’t have answers in this post. Or probably many words.

I do have an observation.

It’s difficult to be a facilitator while also being a participant. It’s even more difficult if you have strong opinions or key information about the topic.

A few weeks ago, I stumbled across the term “neutral convener”¹. That’s a great description of the role of facilitator. A facilitator’s goal is getting a group to the best decision, having heard all the needed information, without a lot of unnecessary detours².

The easy thing to say here is that a participant, especially one with key information or strong opinions, isn’t positioned well to facilitate.

I would even go a step further: for a participant to also facilitate makes the participant an ineffective facilitator—and an ineffective participant. The job of a participant to share information or to advocate for their position. The job of a facilitator is the process that will achieve the participants’ goal.

A human that has to split their attention between content and process will do both less well. Decisions with higher stakes increase the mental distance between content and process.

A good facilitator can help make progress in tedious or difficult conversations. By paying attention to the process, the facilitator makes the participants more effective.

It seems like bringing in a facilitator is viewed as wasteful³.

I don’t get it.

We don’t usually object to other effectiveness-improving measures⁴. We buy hammers instead of using rocks. We use trucks instead of wheelbarrows. A stand mixer is probably less authentic than hand-kneading, but it’s a lot faster. We hire accountants who use spreadsheets and calculators instead of doing our own accounting on paper. We microwave our lunch instead of digging up some roots, chasing down a rabbit, and making a stew in a large shell balanced over the nearby natural hot spring.

After writing this, I at least think I have a better question. Or at least an additional question. What makes some effectiveness-improving measures hard to accept, while others are adopted quickly?

As for why facilitation is often questioned, well, I still don’t get that.

1. In the podcast I was listening to, Kevin Pulau explained a “neutral convener” as a trusted person or organization, not bringing a personal agenda, that has enough credibility or influence to get people in the room. Source: episode 613 of the Carey Nieuwhof Leadership Podcast, about 33 minutes in. [↩]
2. Sometimes, some detours may be needed. Someone may need to say their piece. A rant may open doors to a deeper discussion. Tedious background information might be the key to a better decision. Figuring out what’s necessary is part of what makes facilitation a valuable skillset. [↩]
3. This sometimes sounds like “You’re all smart people. You have all the knowledge and skills to come up with an answer. We don’t need to bring in someone else.” But it means “don’t waste their time”. Or sometimes, it means “I don’t trust them.” But that last part is a whole separate topic. [↩]
4. Or. Wait. We do, if it conflicts with our preconceived notions. Writing tests, collaborating across organizational boundaries, working iteratively, focus time, limiting queue size or WIP—all these “soft” tools are things that I’ve seen objected to in real situations. And, heck, I’ve seen purchasing equipment that would pay for itself in less than a week in time savings be a contentious decision that dragged on for months. [↩]

Ashley’s legs churned. Her feet flew across the asphalt. Ahead of her, Becky started into a slow jog, gradually picking up her pace, arm extended backwards. “Becky was so tan last fall,” Ashley mused, noticing how pale Becky’s arm was against the track, while another part of her brain noted what a strange thought that was and chalked it up to oxygen deprivation. Ashley willed herself to move just a bit faster, reaching out, putting the baton squarely in Becky’s hand. Becky’s hand closed around the baton and she lunged forward. Ashley coasted to a stop, gasping for breath, careful to stay in her lane. “Come on, Becks!” she shouted, then put her hands on her knees, head up, watching Becky edge out Central’s anchor. Oh, how good the win felt!

Handoffs are an important part of sports. Very literal handoffs happen in relay races, American football, basketball, and more.

Emily dribbled the ball with her right hand, reading the defense. She drove in, hard, toward the right side of the court. Just as her toes touched the three point arc, she changed direction, almost instantly. She crossed the ball to her left hand, running just outside the arc to her left, feeling the defender at her heels, fired a hard pass to Denae at the top of the key. Denae turned to shoot and both inside defenders jumped toward her, arms up for the block. Instead of releasing the shot, Denae pulled the ball down, pivoted, handed the ball to Emily. Emily passed Denae, cut hard to the basket, past the defense tangled up on Denae, up for a left-hand layup.

But I’m not really writing about sports here.

Carl’s legs churned. His feet flew across the asphalt. He was by far the fastest runner at East, and he knew his job was to set up the team for a win. Ahead of him, Darrell stared back, unmoving. Carl extended the baton, while some corner of his brain wondered if he’d be setting the school—or state!—record for fastest relay leg. Darrell’s hand went up, ready to take the baton, but his feet stayed planted. Carl pulled up to avoid knocking Darrell over, slapped the baton in Darrell’s hand. “Go! Come on, Darrell! Let’s go! Come on! You can do this!” Instead of turning and sprinting, Darrell examined the baton. Orange, shiny, 11.5 inches, hollow¹. “Darrell, dude, turn around. Run. Stay in the lane, get to the finish line. Go, dude, go!” Darrell nodded, turned, and jogged off. As Coach would say later, at least they’d stayed out of last, if only because that kid from Lincoln had tripped, hurt himself, and had to be helped to the finish. As for Carl, he had indeed set the state record for his leg.

I’m writing about work. Organizational life.

“Set, hut!” yelled George. The center snapped the ball and George dropped back from the line, ball at the ready, eyes watching his star receiver. No good, bracketed by the defense. George turned and extended the ball to Henry, the running back. Henry ran forward, put two hands on the ball. George noted how high and tight Henry tucked the ball—great work, no possible way the defense could knock that out. George’s satisfaction dissolved as Henry stopped and said “hey George, uh, on this play, which way do I run? And, uh, if it’s inside, which gap is the line expecting me to hit?” Before George could answer, though, two defensive linemen found gaps of their own and barrelled into Henry. Losing four yards on the play hurt, but probably not as much as Henry’s shoulder after that hit.

Everyday, on-the-job working life.

“Now that the poster is ready, let’s get that to the printer before they close.” That’s a handoff.

“The engineering diagrams are done? Great, send those down to manufacturing so they can set up a first run.” Handoff. “The page designs are done? Sweet, send them over to the web developers and ask them when the page can be live.” Handoff.

There is a chance, be it ever so small, that you may have been involved in at least one handoff in your working life.

More than that, there is a chance, be it ever so small, that you may have been involved in at least one handoff in your working life that didn’t go well. Instead of Ashley to Becky, your handoff was Carl to Darrell. Instead of the beautiful flow of Emily and Denae’s play, it felt more like George handing off to Henry. It just didn’t go well.

Unlike those ridiculously contrived examples, though, it wasn’t obvious why it didn’t go well.

It’s strange, really, given all the good reasons for handoffs. Handoffs are a powerful tool. People can work in their area of expertise. Risk can be contained and monitored. Work can flow smoothly through large organizations running complex processes to build complex products. Think of a Honda Civic. There are hundreds or thousands of handoffs involved in building one. There is no way a person, alone, could build one in their lifetime². Honda builds hundreds of Civics every day, handing off parts and assemblies until a finished car rolls off the line.

Despite all those reasons, sometimes handoffs don’t work³. That’s because sometimes, handoffs get in the way of getting work done.

Handoffs have some costs. There’s the need to transfer context (or the cost of not transferring context). When parallel work is involved, there’s a need to integrate work product. Quality can suffer. Dependencies can be ignored, not mentioned, or discovered late in the process. There’s a loss of control over the work as it gets handed off. The costs of handoffs are sometimes hard to notice. They masquerade as other problems⁴.

Let’s start by defining what a handoff is, for the purpose of this essay.

You’ve seen physical handoffs for most of your life. You’ve sat at the dinner table and seen Uncle Frank pass the salt to Cousin Walter. That’s a handoff. You might have watched a relay race and seen sprinters pass a baton at a full-on sprint. That’s a handoff. You might have watched the quarterback hand the football to a running back. Handoff.

Your intuition is right. A handoff is when some thing gets passed from one person or team to another.

But, you might point out, at work it’s not usually quite so physical. “Handoff” in that context is a bit more metaphorical. What “handoff” usually means at work is that a task or unit of work is being passed from one person or team to another. The order from table four is handed off to the kitchen. The TPS report is handed off to your manager. The design is handed off to the programmers.

Even so, the definition stays that simple. A handoff is when some thing gets passed from one person or team to another. It doesn’t have to be physically passed. Any transfer of ownership, responsibility, control, execution (whatever you want to call it) can count.

Now that we have a definition, let’s take a brief look at a couple of the costs of handoffs. This isn’t a comprehensive treatment of any of the problems, and certainly not a look at all of the costs. That might fill a book, but I’m not sure it’d be worth writing⁵.

The first cost I want to look at is transferring context. Work items exist in context. Some of that context is easy to transfer: “the photos you’re taking are for the trade show next month.” Some of that context is less easy to transfer—all those discussions you had with the rest of the team about the nuanced message you’re trying to send at the trade show, and how it differs from the messaging your company has historically done, and how it builds credibility for that important pivot you’re planning for next year, for example. Then there’s the context you’ve forgotten about because you’ve been in it for so long that it just feels like the wallpaper. It’s really easy to forget to clue the next team in about something essential because “everyone knows” it. And the receiving team doesn’t know enough to ask.

Next cost: managing dependencies. A “dependency” is another task that the original task relies on⁶. Dependencies mean teams (or individuals) that are performing tasks must rely on other teams (or individuals). At the very least, relying on other teams⁷ means work is not divided into the nice, neat compartments that handoffs imply⁸. The team handling the original task and the dependency must communicate—and there may be communication back upstream to find out if the team handling the dependency has already been contacted. If that communication among teams breaks down, it’s very, very easy for work to pile up on one dependent team, throwing off the planned schedule. The further removed the planning team is from the deep dependent teams, the more difficult it is for the planning team to recognize the dependencies and where they might pile up⁹.

Last, let’s look at quality and loss of control together. When handoffs occur, a piece of work is passed from team to team. If there are quality issues with that piece of work that affect the receiving team, they’re relatively easy to correct¹⁰. Not all quality issues affect—or are noticeable by—the receiving team¹¹. When quality issues get introduced that are only detectable much later in the process, the cost of those issues can multiply. But aside from the cost of correcting the work, this scenario demonstrates how handoffs reduce control over the work. It’s not possible to control work if visibility into the work is limited. Correcting this is simple in theory (provide sufficient visibility into the work to control it, or provide sufficient context at each step to ensure localized control aligns with overall goals). That said, we’ve already touched on the difficulty of transferring context, and providing enough visibility for control has similar difficulties. To put that a bit differently, solving the problem of maintaining quality of and control over work across handoffs likely requires creating expensive oversight systems¹² or finding an approach that does away with handoffs.

Okay, great. So handoffs have costs. But let’s be honest here. The web designers don’t have the development skills to build the pages they designed. The engineering team honestly doesn’t have a clue what goes into the manufacturing set-up. The accounting team doesn’t know what goes into shipping the product. And yet, we want to make sure the product gets designed, built, shipped, that the accounting gets done, and that we are running our business efficiently and reducing risk where it makes sense.

There are three basic paths for getting the work done when various skillsets are needed: clean, mechanical, well-designed handoffs; overlapping handoffs; or cross-functional delivery teams with tight feedback loops.

Clean, mechanical, well-designed handoffs are exactly what they sound like. They’re what you’d expect to see on an assembly line. Station B expects a partly-completed widget from Station A. Workers at Station B have the materials they need available to complete their work on the widget. Once it’s done, they pass the widget along to Station C. There’s very little thought needed in these processes. The third widget of the day gets the same treatment as the thirty-third widget.

The mechanical handoff approach is a terrible choice for most knowledge work. However, it’s a common choice. Someone writes a specification, draws some diagrams, generates some mock-ups, gives a presentation, and expects the downstream team to be able to instantly take the metaphorical baton and run full speed with the project. Usually the downstream team is as confused as Henry was. Or they dawdle along because, like Darrel, they don’t recognize the urgency of the project.

If handoffs in your work world are clunky, there is a good chance that you’re aiming for the clean, mechanical handoff approach and that you’re thinking about ways to make your handoffs work better. Maybe you’re planning to increase the detail that goes into your specs, draw more diagrams, hold more detailed handoff meetings, spend a bit more time on the presentation, or use reverse briefings¹³. Let me save you some effort: that’s not going to help as much as you’re hoping it will. If you’ve been on the receiving end of a handoff, you know why. Things are obvious when you already know them, and the hander-offer doesn’t want to waste time or insult your intelligence by telling you things that are obvious. Except, of course, they’re not obvious to you, the receiver. Or, in other cases, the time and effort to create handoff materials and truly transfer context in sufficient detail begins to approach—or dwarf—the expected benefit from handing the work off. Instead of trying to find the magical fix for mechanical handoffs, consider one of the other basic paths.

Overlapping handoffs are handoffs in which the hander-offer spends some actual work time working on the task along with the receiver. It’s not simply a presentation or the old “if you have questions, you know where to find me” bit. Instead, the hander-offer joins with the receiver to provide guidance, context, and the right sense of urgency. When the receiver is properly up to speed and is able to independently move the task along, the hander-offer pulls back.

The overlapping handoff approach can be reasonable for many types of knowledge work. It’s often rejected as inefficient (“Why should my web designer waste time working alongside my developer? There’s more designs that need to be done, you know!”), and I’ll admit: it may be less efficient having two people working on one task. However, I’ll argue: it’s often more effective to do a better handoff. It would have been more efficient for Becky to stand still until Ashley had handed off the baton. That would have gotten the baton to Becky faster¹⁴, saved a bit of Ashley’s energy for the next race¹⁵, and even reduced the risk of a dropped baton¹⁶. Wow, I’ve almost convinced myself that relay teams should adopt the more efficient approach—it’s that much better on paper!

The results of relay race handoff techniques are easy to see¹⁷. Knowledge work is harder to measure effectively. If you’re using an efficiency argument for opposing overlapping handoffs, I would make a high-confidence guess that you’re not measuring lead time, cycle time, quality, or organizational alignment on results. You may be optimizing each department or team’s metrics at the expense of overall outcomes. Counterintuitively, optimizing subsystems is a good way to reduce the performance of the overall system!¹⁸

(TL;DR of the last couple paragraphs: don’t reject effectiveness for the sake of efficiency, especially if your current approach is ineffective.)

Trying the overlapping handoff approach takes a small shift in mindset. Instead of keeping each team or work center fully loaded (optimizing for workload efficiency) or racing to pick up the next task (optimizing for speed-to-start or minimizing intake queues), the mindset shifts to ensuring that the work item continues moving toward completion without loss of momentum¹⁹. Teams that are not fully loaded are okay. Period²⁰. Doubly so if by having a team less than 100% loaded allows them to be available to receive a handoff without delay in the work.

The third basic path is cross-functional delivery teams with tight feedback loops. Truthfully, this path bypasses handoffs. Instead of a designer doing a bunch of work and handing it off to a developer, the designer and developer work together. Instead of a product engineer doing a bunch of work and handing it off to the manufacturing team, the product engineer and manufacturing folks work together.

If you’re feeling a deep distaste for the inefficiency of this idea, I’ll invite you to suspend your disbelief for a paragraph or two. You don’t have to implement this, or even try it. But don’t dismiss it so quickly you don’t even consider the possibility there might be something worthwhile lurking inside.

There are some big costs that come with handoffs: transfer of context, dead time when work waits in queues between work centers or teams, loss of focus, loss of ownership, communication overhead, high probability of misalignment, rework, ineffective risk management, and more.

A cross-functional delivery team works together. The entire team knows the context they are operating in. They have a shared focus, so work doesn’t pile up waiting for a downstream team to pick it up. They communicate regularly within the team. The tight feedback loops keep them closely aligned with each other and their stakeholders, which preserves ownership and reduces risk of rework, while making risk management a part of the rhythm of getting the work done. The efficiency of each individual member of the team might be less, but the overall effectiveness of the team at delivering suitable work product quickly can go up.

In the example above with Emily and Denae on the basketball court, neither player was 100% utilized²¹. In fact, Denae only had the ball for a second, maybe two. But she pulled in two inside defenders and let Emily drop a third, making a basket for Emily much easier²². Would Denae have been a more effective player if she had been “doing more”, perhaps by chasing around the court screening off defenders or calling for passes? No. Should she have “gotten ahead on things” by starting on the next play? No. She served the team best by being in position at the right time, knowing the play the team was running, and doing her part quickly²³. It’s pretty obvious in a sports setting, but we somehow feel like a work setting lets us be clever and squeeze more work in.

Enough about cross-functional delivery teams for now. If you don’t want to take that path, don’t²⁴. But if your handoffs feel clunky, consider a path other than clean, mechanical handoffs.

It turns out clean, mechanical handoffs are the most costly option. It’s just harder to see the costs.

Don’t hold handoffs as a sacred requirement. Hold handoffs as a handful of options. Pick the model that best helps you achieve your goals.

1. very rigid! Aluminum is an unusual material for a wand, of course, but … oh. It’s just a baton? [↩]
2. I’d love to be proved wrong. That’d be really cool, actually. [↩]
3. Once upon a time I was working with a team building a stage set. We had some door size constraints that made it hard to have the height we wanted. We came up with a clever design, and a mechanical engineer on the team ran some pretty extensive calculations to make sure the jacks and supports would hold safely. Just to check all our boxes, we checked the designs with the facility’s stage manager. He looked at the design and vetoed it for safety reasons. Our mechanical engineer pulled out the calculations. The stage manager’s response: “Sometimes physics don’t work.” [↩]
4. Sometimes handoff problems are blamed on people: laziness, inattention to detail, not “knowing how we do things around here”, asking too many (or not enough) questions, not “being bought in” to a project. Sometimes handoff problems are blamed on tools or processes: we need to get our project management software configured right, we need to test more, we should get more diligent about capturing all the requirements up front. Those handoff problems are sneaky like that. [↩]
5. “All the Costs of Handoffs: Problems Galore” can get shelved next to “1001 Ways to Mess Up a Cake” and “You Should Open Your Garage Door Before Pulling Out: An Illustrated Guide”. The schadenfreude might be fun, but the usefulness might be limited. [↩]
6. Less often, “dependency” is used to mean resources or teams that the original task relies on—but that is often because the team is needed to perform a task (which is actually a subcase of the “task” definition). [↩]
7. Or individuals! [↩]
8. Or complexity gets added by converting an acyclic graph into a cyclic graph. The easy math of counting up the schedule at each step of an acyclic graph becomes much less deterministic when cycles are introduced. [↩]
9. With sufficient investment into planning, these dependencies can be identified. Unfortunately, an investment sufficient to identify piled up dependencies is often a large enough fraction of the anticipated project schedule that it’s not worth making. Insufficient planning brings obvious costs; over-planning comes with its own set of costs; finding the exact right amount of planning is left as an exercise for the interested reader. [↩]
10. As a super-simple example, imagine Dad just asked Junior to pass him the hammer. Junior passes Dad a screwdriver. Dad will immediately note the error, teach Junior what a hammer is (preventing the error from being repeated!), and get his hands on a hammer. [↩]
11. An example of an issue undetectable by the receiving team, let’s go back to the Honda assembly line. If my job is to install the radio, I’m probably not also testing the radio. If the radio doesn’t work, it might not get noticed until final quality control—or until the finished car ends up on the dealer’s lot with a prospective buyer ready for a test drive. [↩]
12. The expensive oversight systems might be worth it. Factories are a classic example: the quality control and oversight processes involve a large investment, but keeping defect rates and manufacturing expense under control is worth significantly more. That cost/benefit calculation does not always come out in favor of oversight. [↩]
13. A model in which the “sender” gives the broad overview of the task, followed by the “receiver” delivering a briefing on their understanding. This allows quick discovery of misunderstanding and iteration to fill in gaps. It requires a high degree of psychological safety and is best with tasks that are not enormously detailed, or even simply enormous. [↩]
14. Getting started satisfies a manager wanting to “show progress” or insisting “we need to get this moving so they’ll know we’re working on this”. The results of rushing to get started are often every bit as beneficial as asking a sprinter to stand still until the baton has been handed off “just so we can get that checked off a bit sooner”. [↩]
15. Saving resources (often money or time) does not gain you much if you don’t accomplish your goal. If I understaff a project team to save money, and the project fails, I’ve likely wasted far more money than I “saved”. [↩]
16. Risks should be recognized, planned for, monitored, and not feared. If the cost of avoiding or mitigating a risk will cause the project (or the company!) to fail, that risk should be accepted and monitored. But it also sounds like a doozy of a risk. [↩]
17. and things that are easy to see, well, are easy to see the results of attempted improvements. [↩]
18. This is called the principle of suboptimization. As a quick example, imagine a car in which the radiator was optimized at the expense of the rest of the system. You’d have an enormous radiator, so your car would handle heat great, but the overall vehicle would be a terrible car—unbalanced because of the radiator, reduced space for an engine so it might be underpowered, lousy vision because of the enormous radiator up front… [↩]
19. But what if the current work item is less important than the next task? Common question. I can’t give you the right answer for your circumstances, but I can offer you a better question. It sounds to me like you’re asking “what if a work item in process is (relatively) unimportant and is taking resources away from a thing that’s important?” [↩]
20. For more on this, the Theory of Constraints (read The Goal by Goldratt). [↩]
21. For the sake of this example, I’ll go with the very common (and wrong) management approach of “if you’re not ‘working on something’, you’re not being utilized”. That would translate to basketball as “if you’re not handling the ball, preferably shooting, you’re not being utilized”. Given that there’s only one ball, the efficiency argument would suggest putting only a single player on the court at once. Or asking anyone not actively engaged in the play to do something else (cheerlead? fill water bottles?). Let me know how that works out for you, coach. [↩]
22. A “slam dunk”, if you will. [↩]
23. “They also serve who only stand and wait.” [↩]
24. Cross-functional delivery teams have costs, too. They need a psychologically safe organization. The right disciplines need to be represented on the team. Boundaries need to be drawn between the cross-functional team and other functions that are “just dependencies”. [↩]

If you’ve been in the business world for any length of time, you’ve probably heard someone talking about “putting on my __ hat”. It’s helpful phrasing to signal that you’re taking a certain perspective on a discussion. Someone might say, “putting on my manager hat, we need to get this done in two weeks, but putting on my engineer hat that’ll create all kinds of risks.”

That’s not exactly what I’m writing about here. But it’s not completely different either.

There’s a phrase that I use, inside my head, literally “putting on the hat” or “time to ‘put on the hat'”. It means to set aside my natural preferences and become a character or inhabit a role that people around me need.

A few years ago, I went to overnight camp for the very first time. I went as a counselor, not as a camper. Every summer, my church puts on a 4-day, 3-night camp for kids in the elementary grades. The kids are divided up into cabins or “bunks”. Each bunk is assigned a color or a pattern. Everyone gets bandanas in that color, and it’s common to refer to “red bunk” or “tie-dye bunk”. I was assigned as the senior counselor of “camo bunk”¹.

I am fairly prone to sunburn². Four days of outdoor fun sounded like a risk. I own a couple of baseball caps, but I wanted (1) a bit more 360° protection and (2) I wanted a camouflage hat to match my bunk color. I found myself a nice wide-brimmed camouflage bucket hat.

At camp, there are times that counselors get to relax. There are counselor meetings. Camper free time isn’t completely relaxed for the counselors, but it’s certainly less focused. Chapel time at least keeps everyone corralled. Then there are times counselors need to bring energy and guidance. Getting to places (like the dining hall!) on time. Focusing on team challenges. Getting from the bathhouse where we brushed our teeth, past the outdoor games area, and successfully into our cabin for sleep.

During the times counselors get to relax, I often found myself naturally not wearing my hat. Counselor meetings and chapel are indoors, so the hat wasn’t needed. Boys like to spend free time swimming, which is not an activity normally associated with hat wearing. But when I needed to be “on”, I often had my hat on. In fact, when chapel was over, I found myself putting my hat on and clicking into energetic, ready-to-go counselor mode³.

Around the same time⁴, my wife joined the “Family Experience (FX)”⁵ team at our church. I tagged along, expecting I could be useful as a stagehand or some other behind-the-scenes role. As the team met and prepared for the year, one thing led to another and I ended up as one of the four skit characters⁶.

My character: Billy Bob Beaker, hillbilly scientist. Take a classic raggedy barefoot hillbilly character, add a lab coat and lab goggles, and you’ve got a pretty good idea of the character’s appearance. There are two key points relevant to this essay I’ll mention. First, Billy Bob is loud, often wrong but unaware of it, instantly friendly to new people, and occasionally struggles with impulse control. In short, he behaves quite different than I normally do. Second, Billy Bob wears a straw hat⁷.

Before “showtime” for each event, we ran our pre-show checks. We checked mics, made sure props were where they needed to be, ran through the show order so that everyone involved (MCs, actors, tech team, anyone else involved with putting on the event) had the chance to ask questions, and made any last-minute adjustments. I was the one that facilitated the pre-show checks. That required being crisp, organized, and under control—things Billy Bob Beaker most definitely is not.

During pre-show checks, all of us actors wore our costumes. I usually did not wear my hat. Once we finished our checks and were as ready as we’d ever be (or ran out of time to get any more ready), the group dispersed to our places. Tech folks went to the tech booth. MCs went to chat with one eye on the clock so they could start the program. Actors either headed backstage or to greet families as they came in. Whichever direction I was headed, I put my hat on before I headed that way.

When Billy Bob’s straw hat went on, I felt a shift. I didn’t need to be responsible for the whole show anymore⁸. I just needed to play Billy Bob, support the other actors, and do my best to recover when I messed up a line or forgot a key prop⁹. When the hat went on, I clicked into character mode, no matter how well (or poorly!) prep might have gone, or what was left to be done.

“Putting on the hat”, for me, means I’m adopting the energy level, motivations, and concerns that are needed in a given situation. Inside I might be tired, worried about my lines (or wanting to support another actor that’s nervous about their lines), or just don’t want to. But the hat goes on, and I click into the mode I need to be in. Fatigue, irritation, outside things-to-do, those things don’t matter for a time.

Even though I no longer play Billy Bob (like many other things, FX stopped in March 2020), and I’m only a counselor for a few days a year, I find that I “put on the hat” regularly. I work remotely, so my family is often around during the workday. I’ll talk with family—having fun, planning for the weekend, dealing with logistical difficulties—then I’ll walk into my office, close the door, sit down, and click into manager mode¹⁰.

Obviously, I’m not the only one that switches contexts or roles. A lot of folks do that, and some of them have their own ways of making the switch easier for them. But the idea of “putting on the hat” is appealing to me because of the way the metaphor affects my thinking.

If I can “put on the hat” and become the energetic, fun counselor my cabin needs, I can also “take off the hat” at a counselor meeting or at bedtime. Instead of maintaining that level of energy and fun, I can catch my breath and start to re-energize. If I can “put on the hat” and become Billy Bob, I can also “take off the hat” at the end of the production, put any actor concerns aside, hug my kids, and help clean up¹¹. Putting on the hat—whether there’s a physical hat involved—is temporary, and that’s often helpful. The hat itself is just a reminder that it’s a temporary assignment; if the assignment is difficult or I don’t like it, at least I know it will end. And when the assignment ends, I can take off the hat.

1. Camouflage, in a pretty classic woodland green color scheme. Some years there has been a girls’ bunk assigned “pink camo”. I cannot think of an environment in which pink camo would help conceal someone. [↩]
2. Does having gotten giant blisters from sun alone count as “fairly prone”? [↩]
3. That is, as much as I am the energetic, fun, enthusiastic counselor. There are some wonderful friends I’ve made through camp that bring more fun counselor energy when completely exhausted than I do at 150%. [↩]
4. If I remember right, this was the late summer / autumn after my first time at camp. I may be remembering wrong. It was certainly within a year. Not that it matters much for the sake of this post. [↩]
5. FX was a monthly large group mid-week gathering for families with kids, ranging from littles on up, with kids usually switching to other activities around or after 5th grade. The program included skits, games, and slime. Each month was organized around teaching about a character trait. [↩]
6. Five, if you count Steve the Monkey who was actually a puppet. Only four of us characters were live-action humans though. [↩]
7. We found a battered straw hat that fit the character perfectly. It did not, however, fit my head snugly. When I’d nod vigorously (often), do big stage movements (frequently), or take off running (a lot), the hat would fly off my head. The solution we settled on was a loop of duct tape on the inside. The duct tape would stick to the hat well enough, and stick to my hair very well. It made taking off the hat much more difficult than putting it on! [↩]
8. Not to imply I was solely or primarily responsible for the whole program! I served under a great leader, with a great team. There were a lot of things I was responsible for, though, and aspects of those things covered the entire scope of the evening. [↩]
9. Oh yes. That happened. The key prop (the Macguffin, if you will) in the wrap-up to our first school-year “season” storyline. Fortunately, it was quite in character for Billy Bob to have forgotten something, and to sprint offstage to get it while all the other characters looked on, confused. [↩]
10. To be clear, I do not put on an actual physical hat when I sit down to work. [↩]
11. Yep, the very thing I’d expected to do as part of the FX team. [↩]

After onboarding new employees across companies and disciplines, having been onboarded, and working to improve onboarding practices at nearly every company I’ve worked at, I’ve stumbled to the belief that there is a nearly-algorithmic process can lead to an ideal—or at least much more acceptable—onboarding experience. 

Following this algorithm will take work, but it leads step-by-step to a complete, detailed onboarding program.  Contrast it with other articles that suggest you “ensure a positive first day reception” or “create a journey that’s intuitive and easy“.  Plenty of those articles give some broad guidelines.  Broad guidelines can be useful; specific actionable steps are much more so.¹

I recommend following these steps in the order presented, at least the first time².  As you onboard more new employees, you’ll learn things that will help you refine your onboarding process.  You should incorporate those things into your onboarding process³.  If you follow this algorithm and realize there are steps that you wish you had taken, or if you wish the steps had been ordered differently, I’d like to know!

I believe this algorithm can be successfully applied in a wide range of jobs and industries.  It’s likely less helpful in very standardized roles for which detailed onboarding and training already exist—but if that’s your situation, you’re probably not reading this.

Without any further introduction, here is the algorithm, with some brief explanation of each step.

Step 1: Gather your current onboarding process and materials

If anything exists now, find it.  There are two reasons for doing so.  First, it feels good to “get started” and to “do something”.  Second, having the current onboarding steps together will be useful later for making sure you haven’t missed anything important.  If nothing exists, and you’re working completely from scratch, that’s fine too!

Gather up as much as you can.  Documents, emails that get sent to the new hire, links to Slack conversations that always seem to happen when someone new starts, wiki pages, etc.

Step 2: Define your goals (or purpose statement) for your onboarding process

This could sound something like “The purpose of onboarding in the Software Division is to help new employees understand Projects L, M, and N, to establish relationships with our Hardware Division and Testing Division, and to be able to produce production-quality software within three weeks of their start date.”  Or it might be a bit more like GIS technician onboarding, and sound like “Our goals are for us to evaluate the progress of our GIS technicians toward competency in our custom toolset, our field hardware, and industry knowledge; to provide a standardized curriculum for learning; and for all technicians to be fully qualified within six months.”  Don’t copy one of these—it’s almost certainly wrong for your situation.  Think through what your actual goals are, and decide the best way to capture them on paper.  Don’t spend too much time wordsmithing.  You can always come back and improve it later.

Step 3: Create a blank checklist. Put the goals (or purpose statement) you just defined at the top.

This checklist is the core output or “result” the algorithm will produce.  You’ll use a copy of the checklist for each employee that onboards.  It does not matter what tool you use for this⁴.  I like a Google Sheet or an online Excel sheet.  If you prefer Trello, Miro, a Word doc, a Jira project⁵, or Asana, any of those are fine.  The checklist will contain tasks for the new employee and for individuals other than the new employee.  Keep that in mind when selecting a tool.

Yes, it’s going to start blank, except for the goals/purpose.  Don’t worry about it.  We’re going to add a lot to it in the next few steps.If your current onboarding process is all in a single place, and is easy to edit, you can start with that.((In my experience, it probably isn’t.  There’s that Word doc with a bunch of steps that’s a bit outdated, and that wiki page with a bunch of other steps, and that email full of notes that Bob needs to email to the new hire so they know how to do that other thing, and that one Slack message with the corrections to the wiki page…))

I plan to create a Google Sheet template, based on the Manager Tools example, with improvements I’ve stumbled upon at several companies, that you can use.  It’s not ready yet.

Step 4: Add all of the tasks in your current onboarding process and materials to your checklist

Even if you don’t agree with a step, or plan to change it, just add it for now.  Feel free to mark steps that you don’t like, that you plan to expand on, or that don’t make sense anymore.  It’s okay to link to a procedure documented somewhere (e.g., on the intranet or in a Google Doc), but the task must have a line item on the checklist.

Once you finish this step, you’ll have your current process all in one place.

Step 5: Define the guidelines and principles for creating a new employee’s first day task / first project

The difficulty of this step varies pretty wildly depending on the job and the industry.  One of the hardest parts about getting started in a new role is having something productive to do.  If the role you’re creating onboarding materials for does not have a defined training plan⁶ you’ll instead need to create guidelines for what a new employee’s first day task or first project will be.  If you’re hiring software engineers and want them to commit code on Day 1, you’ll need to have a task picked out ahead of time that’s small enough to complete.  If you’re hiring truck drivers and they need to understand your procedures for refueling and the repair shop, you might design a Day 1 task that involves fueling up a truck and driving it to the shop while you ride along.

If you’ll need to come up with a different first day task for each employee, add “Create Day 1 Task” to the checklist as something to do prior to the employee’s start.

If the first day tasks are always the same, add those tasks to the checklist.

Document the guidelines and principles somewhere easily discoverable from within the checklist.  For example, if you’re using a spreadsheet, put it on a tab of the spreadsheet.

Step 6: Add access to corporate accounts and tools to the checklist

Most jobs require access to corporate accounts and tools of some sort.  Email accounts, passwords, key cards, GitHub teams, Slack, corporate credit cards—whatever an employee in this role will need.

For each of these accounts and tools, add an item to the checklist to grant access, prior to the employee’s start date if possible.  Each account / tool should be a stand-alone checklist item.  Employees feel much more welcome when they start and they don’t have to spend several days getting access to everything they need.

Step 7: Add access to team accounts and tools to the checklist

Individual teams or departments often use tools that the rest of the company doesn’t use.  A team of graphic designers might use Adobe’s tools or Figma.  Accountants might be issued stylish green eye shades and printing desk calculators.  Those accounts and tools are just as important as the corporate accounts when it comes to productivity.

For each of these accounts and tools, add an item to the checklist to grant access, prior to the employee’s start date if possible.  Each account / tool should be a stand-alone checklist item.

Step 8: Add scheduling one-on-ones to the checklist

If you’re a manager, and you don’t do one-on-ones, you should. Add a task to brief the new hire on one-on-ones early in their onboarding. Add another task immediately following the briefing to schedule the one-on-one series.

Step 9: Add mandatory corporate trainings to the checklist, as late in the process as possible

Most companies have at least some mandatory training.  Check with HR (and other departments, if applicable) to identify each training, its approximate duration, and how long an employee has to complete it.  Add each training to the checklist.  Each training should be a stand-alone checklist item.

Employees are often encouraged to “get it out of the way early”, but this can slow down onboarding.  Mandatory corporate training is often low-value and impedes developing relationships with new colleagues.  Even in the best situations, it’s not very exciting.  If HR tells you that new employees must complete their compliance training within four weeks, put a four week deadline on that training. ((On the flip side, if you work for a defense contractor and employees must complete International Traffic in Arms Regulation (ITAR) training before joining the project team, give that a much tighter deadline!))

Step 10: Add mandatory corporate paperwork to the checklist, as late in the process as possible

There is certainly paperwork your company requires.  In the U.S., this includes employment eligibility and tax paperwork.  It probably also includes retirement accounts, health insurance, and paperwork for other benefits.  Some of these have required deadlines.  As in the above step, check with HR and assign a deadline as late in the process as possible⁷.  Add each individual piece of paperwork to the checklist as a standalone checklist item.

The wrinkle here is that new employees often want to get their paperwork filled out.  They want to receive their benefits!  If it is possible, provide the paperwork to the employee ahead of their start date.  If you’re able to provide the paperwork ahead of their start date, add a task to the checklist with a due date prior to the employee’s start date to remind you to do so.⁸

Step 11: Interview recent new hires about their onboarding experience

Recent new hires have valuable perspective, especially if they have taken notes on their first few weeks.  They have not completely forgotten the experience of being new.  To get access to that valuable perspective and make things better, interview your most recent new hires.((Recency is important.  If the “new guy” got hired four years ago, he’s not recent any more.  More than six months is probably too long; more than a full year is right out.))

Here are some useful questions:

1. Did you feel welcome?  Why or why not?
2. What worked well?
3. What would have made your first day / week / month better?  How so?
4. What do you still feel like you don’t know?
5. What was the best thing about your first day / week /month?
6. What things didn’t go well?

When interviewing, feel free to probe for more detail about anything interesting the recent new hire shares.  Express gratitude for any feedback they give.  Don’t express anger if they tell you their onboarding experience was rough.  Doing so will make them less likely to give you forthright input in the future⁹.  Honest feedback on the onboarding experience is a gift; it provides an opportunity to improve.

After you have completed your interviews, review the answers.  Identify areas for improvement.  If any improvements can be made with specific onboarding tasks (e.g., ask for sizing information to make sure their uniform will fit before ordering their uniform and embroidering their name on it), add those tasks to the checklist.

One suggestion for an improvement is to send an email about a week before the first day, containing everything the new employee will need to know to be prepared for their first day. Dress code, where to park, that their email / Slack password will be coming in the mail with their laptop—whatever is needed to make them feel comfortable and in control coming into Day One. Add sending that email to the checklist (and consider creating a template for it!).

Step 12: Create materials for a sponsor / buddy / guide

In most roles, it’s helpful for a new employee to spend their first 15 minutes on the job being given a stack of paperwork, a brief tour of the facility, a sticky note with their password, a gesture in the direction of their desk/station, and to be left alone with a quick “good luck!”

Just kidding.  That’s a terrible feeling.  And it’s terrible for retention.

In most roles, it’s helpful for a new employee to be paired up with a sponsor, or onboarding buddy, or guide.  Pick whatever term best suits your culture, but assigning someone to each new employee to help them come up to speed (and letting both the sponsor and the new employee know!) is well worth the time.

If you’re asking “what would a sponsor do?”, well, that’s what you get to define here.  In this step, you are defining specific expectations of the sponsor.  Depending on the role and the industry, there might be a lot to explain.  If you’re onboarding engineers at a company that makes agricultural equipment, you’ll need to explain how the equipment is used and what need it fills for farmers.  If you’re onboarding warehouse workers, you’ll need to explain how material flows through your warehouse and any special handling or safety procedures.

Start with the broad outlines of what you want the sponsor to do (e.g., explain the industry, explain how our team’s output is used in the finished product, explain the departments we interact, help them understand why we play Bagel Toss every Thursday before the staff meeting).

Once you have the broad outlines, you’ll create at least two types of materials.  First, you’ll create tasks on the onboarding checklist.  If the new employee needs to be prepared for Bagel Toss before their first Thursday staff meeting, create a “Prepare the new employee for Bagel Toss” task that’s due by the new employee’s first Wednesday, assigned to the sponsor.  Second, you’ll create supplemental outlines, documents, or other reference materials.  If the new employee needs to get up to speed on an unfamiliar industry, having the outlines of trainings, FAQs, or diagrams for the sponsor to use might help.¹⁰ You do not need to create highly polished reference materials at this time.

Start by creating outlines or documenting high-level expectations.  Let sponsors use their experience and ingenuity to expand them over time.The expectations of a sponsor will vary across roles.  A sponsor for a classroom teacher would need to provide different information at different times than a sponsor for a school receptionist.  Take your time to think through what a sponsor for a particular role will do.

Step 13: Cross check your list of accounts and tools against your Day 1 Task or First Project for the new employee

The purpose of this step is to ensure that you haven’t left accounts or tools out of your onboarding checklist.  Walk through a Day 1 Task or First Project and write down every account or tool that the employee will need.  It might sound a bit like “They’ll clone the repository from GitHub (ah, add them to the Developers team in GitHub!), then run the unit tests (oh! they’ll need to have access to our private Docker image repository), make their change (Jira ticket, add them to Jira!)…”.  When you’re done, make sure every account or tool you identified is on the onboarding checklist.

As an extra layer of assurance, you could ask someone on your team to go through the same exercise independently.

This step is separated enough in time from the original step of creating that list of accounts and tools that you may have remembered some additional items that need to be added besides what you discovered during the cross-check.  That’s great!  Add them to the list, too.

Step 14: Gather up any existing “basic training” for the role

There is probably some existing set of “basic training” that exists.  You’ve probably already found some of it when gathering current onboarding materials, listing the mandatory corporate trainings or working on sponsor expectations.  Think broader than that here.  There will be training on the company, on tooling that’s used, job-specific training, industry training.  Your new software engineers might need Kubernetes training.  Your new warehouse employees might need to be trained on your specific forklift procedures.  Your new dental hygienist might need to be trained on your office’s specific X-ray machines. 

Gathering up anything that exists means you can re-use it, or know what’s missing and create it (that’s the next step!), or know what exists but isn’t good and needs to be revised.

Step 15: Create any additional “basic training” that you need

In previous steps you have gathered up any existing “basic training” for the role, identified some things that a sponsor should cover, and gotten a pretty crisp idea of what new folks in this role will need to know and do.  Figuring out where the gaps are—what other things the new employee needs to become productive—should be pretty straightforward. 

If basic training is missing from what already exists (or is bad enough that it needs to be fixed), this is the time to create it.  You can start with outlines or short documents that depend on more experienced employees delivering the training.  Part of onboarding can be for the person delivering the training to improve it.  Start with at least a skeleton for each training.  It’s better to have something that says “Cash Register Training:  (1) making a sale (2) doing a refund (3) closing out” than to have nothing at all.  That something can be improved over time.

It might take you some time to create your basic training.  Don’t aim for perfection in your first go-round.  Aim for good enough, and better than what exists.  Fill in the most important gaps first.

Step 16: Identify the people inside your department that the new hire needs to meet. Add meetings with those people to the checklist.

New employees start without knowing any of the social landscape of the organization.  It’s terribly difficult for them to understand who has the information they need, or who needs to sign off on work.  Helping your new employee meet people within the department and understand what those people do will help them be more productive faster.

People to meet might include the employee’s team, managers across the department, key individual contributors, executives, support staff, etc.Identify who they need to meet inside the department, and add those meetings to the checklist.  Give reasonable due dates, but those meetings should happen soon after the employee starts. 

Step 17: Identify the people outside your department that people inside your department need to meet. Add meetings with those people to the checklist.

There are often individuals outside your department that are important for your new employee to know.  They could be people that your employee will work with regularly, or control key parts of a process, or understand how work flows through the organization, or are simply individuals that are important in internal politics and therefore good to have relationships with.

Identify who they need to meet outside the department, and add requesting those meetings to the checklist, assigned to the new employee.  Set due dates based on the importance of that person to your new employee’s effectiveness.  Keep the due dates within about 90 days of the new employee’s start date—it is much easier to request a “meet and greet” meeting when you’re new than after you’ve been around for half a year.

Step 18: (BONUS!) Figure out how you want to change the culture of your organization, and how you can drive that with your onboarding.

Every person you add to your organization affects its culture.  The interview process can help you select a new hire that will help improve your organization’s culture, whether that is going from bad to good, good to great, or simply making it slightly better. 

It’s easy to talk about culture as a one-dimensional scale from bad to good, or zero to ten.  Culture is not so linear.  There are multiple dimensions to consider, some of which are common (e.g., speed, quality, innovation) and some of which may be unique to your organization.

Onboarding is a mechanism for culture change.  It’s a new hire’s first experience with your culture, so the impression you make on them is likely to stay with them.  It’s also a project that people already in the organization are part of.  You can structure onboarding in creative ways to influence people already part of the organization.

As a simple example, assume your organization struggles with collaboration.  Perhaps individual, point-to-point communication is preferred, and that leads to the “game of telephone” effect, producing lack of clarity, lack of alignment, and poor results.  Part of onboarding could be holding several meetings in which multiple people (who need to collaborate more day-to-day) jointly explain priorities or projects to the new hire.  The new hire will expect more collaboration, and old-timers will get some experience in collaboration.  It’s not a complete fix, but it is a nudge in the right direction on a potentially large issue.

Step 19: Create a central START HERE for onboarding

You’re almost to the end!  You’ve created a checklist of tasks, identified helpful materials, and created materials that were missing.  Great work!

Make sure they can be found.  All of them.  Including that document that only exists as an email draft right now.

Making sure they can be found looks like a central START HERE location for all things onboarding.  Use the system that makes the most sense for your business (your wiki, your Google Drive, your intranet, etc.).  Communication tools like Slack or Outlook are probably not the right place—they make it much harder to find things and much easier to inadvertently limit access to materials.

Your central START HERE location should have a clearly identified starting point (e.g., a template for new onboarding checklists) and contain all the materials you will need.  Except in rare circumstances, this does not mean links; this means the actual documents, templates, etc.((If you use a third-party tool for some of the materials or your checklist, consider having a picture/PDF/export of those materials.  That will mean you can re-create it more easily if you ever lose access or the company providing the tool disappears.))  If you send a “welcome” email two days before your new hire shows up, the template for that email should exist in your onboarding START HERE location.

This isn’t just for you—although it is much easier to have a central location than having to find your previous “welcome” email in your sent folder.  This is for the entire organization’s benefit.  If you’re on vacation the next time someone is starting¹¹, or if you’ve been promoted (congrats!) or moved to a different department (good luck!), or you’re trying to prepare a direct report to be a hiring manager someday, or any of a dozen other reasons other folks might need to be able to carry out onboarding without you being hands-on with the process, having your onboarding process all in a central location (that’s not just on your computer) is helpful. 

Step 20: Test and improve your onboarding every time an employee starts

The next time an employee starts, use that as an opportunity to test your onboarding experience.  Specifically ask the new employee to help make improvements.  Every time they need access, information, connections, relationships, paperwork, equipment, or anything else, they need to inform you (personally or through their sponsor).  It could be that things are missing from the checklist—or possibly timing just needs to be adjusted. 

In addition to adding or adjusting items, schedule time to get regular feedback about the process.  If there are parts of the onboarding process that feel clunky, badly timed, useless, or off-putting, you should know.  You should also know if there are parts that are helpful, attractive, and empowering. 

Add scheduling regular feedback sessions to the onboarding checklist.  Make it the responsibility of the new employee—that helps them get used to scheduling meetings with you, so that doing so is less scary later on.

Policies and procedures in the rest of the company are likely to change over time.  The ideal time to check for changes and update the onboarding checklist is before an employee starts.  So for each department that has an effect on your employee’s onboarding experience, add a task to the checklist, before the employee starts, to check for updates to their processes, forms, and procedures.  A few departments to consider (this may not be the right list for your company) are HR, IT, and facilities. ¹²

Step 21: Hot wash the whole experience, improve it, and repeat

And now you’ve gotten through it!  You’ve created an entire onboarding process that covers everything you need to the best of your current knowledge.  Congratulations!  Without exaggeration, your onboarding process, by virtue of existing as a process, puts your organization in the top 10% for onboarding.

Now you can print it all out, put it in a binder, put the binder on the shelf, and forget all about it until your next new hire.

Please don’t believe that last sentence.  All this work you’ve done is far too value to put it on a shelf.If you haven’t already, add 30, 60, 90, and 180 day check-ins with your new hire to the checklist.  Make sure, in addition to everything else you might discuss, to talk about the onboarding process (as a process):  what’s working, what’s not, and what can be better.

Add a “hot wash” or “retrospective” to the checklist as well.  The right time to do this depends on your business.  For onboarding a new software engineer, I’d do 45 days and 90 days.  For a grocery store stock clerk, 14 days and 30 days would probably be better.  The “hot wash” should include you, the new employee, the sponsor, and anyone else who is more than tangentially involved in the onboarding process.  Yes, that could be a lot of people, and that’s okay—this is important.  Find out what worked and what didn’t; what was ready in time and what caused friction; what everyone liked and what everyone disliked.

Take all the information you gather, reflect on it, and use it to update your onboarding process.

And again, congratulations:  you have taken another big step!  You have gone from having a process for creating onboarding projects (which is great!), to having a self-improving onboarding program (even better!). 

In Conclusion…

Whew! That was a lot of steps. Turns out, doing onboarding well is difficult. The good news, though, is that a complex, important project can be divided into steps and improved over time.

I wish you the best of luck creating a sustainable, self-improving onboarding program. I’d love to hear about your experiences, and I’d be happy to help if I can!

1. Hat tip to Manager Tools for being a fine example of actionable guidance. For guidance relevant to this post, check out their Onboarding Basics and Onboarding Checklist casts! [↩]
2. algorithms are processes:  sets of steps taken in order [↩]
3. That’s one of the steps! [↩]
4. I’d recommend something electronic and easily editable for initial work, and something easily shared for the final version [↩]
5. Please don’t use a Jira project for onboarding. [↩]
6. Like we didn’t for GIS techs! [↩]
7. Sometimes “as late in the process as possible” is “first thing on Day 1” [↩]
8. At this point, your onboarding plan is already far better than what most companies have.  Congratulations! [↩]
9. about onboarding or anything else [↩]
10. When I was working in railroad safety, most new employees in our office got a “Positive Train Control 101” session with me.  It was an introductory whiteboarding session that covered a lot of ground.  Before I left, we recorded a PTC 101 session for future trainers to refer to.  That’s just one example of materials that might help a sponsor. [↩]
11. If you’re the manager, try to avoid being out of the office when someone is starting. I realize there are circumstances that might require that to happen—but as far as it depends on you, keep it from happening. [↩]
12. Maintenance might be a good word to describe what you’re doing here. [↩]

The team has just finished presenting their recommendations to their leadership. Leadership is happy about their plan for building the next part of the product. After a small adjustment, leadership is on-board with the sequencing, too. Before the meeting wraps up, the team points out the work would go more quickly, with less risk, more sustainably—somehow better—if there were some changes to processes, workflows, structure, or team organization.

Leadership responds with a smile. “We’re ready for change!”

The team smiles back, gathers up their things, and heads out to make things happen.

But somehow, the process, or workflow, or structure, or team organization change doesn’t quite happen.

I’ve seen this happen enough that I now worry when I hear “we’re ready for change” or “we’re change-ready”. It’s a red flag that an organization or a leader is not willing to change.

It’s easy to say “we’re ready for change”. Having the potential to change is easy. Acknowledging that a change should be made is easy. Saying the words is easy.

It’s harder to make a change. Making a change takes energy. Energy, communication, persistence. The leader might need to talk to their peers or their leadership about what’s going to be different—to back up the team. People push back on changes and ask “what if” questions.

Change isn’t free or easy. Change takes work.

That’s why it’s so much easier to say “we’re ready for change” than to work toward a change.

In fact, staying “ready for change” is easy. If you never change, you’re always ready for a change.

To make this a bit more positive, the teams and companies I’ve been part of that have truly changed for the better didn’t constantly talk about “change” as a standalone goal. Change was simply a part of continuing to get better. We would notice something that wasn’t ideal, and we’d find a way to make it better, and we’d turn it into a habit, and later we’d notice something else that wasn’t ideal, and we’d continue the cycle of improvement.

The contrast between expecting change and performative declarations about change readiness expose major differences in the attitude of a company.

So positional leaders: the next time you’re presented with an opportunity to change, and you feel tempted to declare your readiness to change, in the hope that it’ll deflect from your apprehensions about this particular change, check yourself. “Let your yes be yes, and your no, no”, and either approve or deny the proposal.

And those of you that aren’t positional leaders: get a commitment when you ask for change. Don’t gather up your meeting materials, smile at your leader, and head back to work. Get into specifics. “Do we have your approval to require TPS reports starting Monday?” “When do you plan to meet with the VP to confirm we can modify the review process?”

The world around us is changing. To do more than slowly fall behind, you need to change. Declaring “we’re ready for change” just doesn’t quite have the same effect.

I wrote before about two of my onboarding experiences and how they shaped my view of the company I was starting at. Those were remote, senior-level software development roles. In this post, I’m going to write about improving onboarding for roles that were not remote, senior, or for software development.

Once upon a time, I worked for a company that surveyed railroads to provide “maps”¹ of the track. Doing the survey required our GIS technicians to physically traverse the track with our survey equipment. Afterwards, the technicians would return to the office with the data they had gathered, process it, and produce the needed data.

The surveys were done using a mix of custom hardware and software, some built on top of standard industry tools like ArcGIS. The hardware was the easiest part to learn. Most of the custom software was built for processing our specific data formats, according to our specialized workflows, for an unusual niche. It would be impossible for a GIS technician to have any experience or knowledge of our internal tools. It was rare enough to find techs that had worked in railroads.

New technicians needed to learn about railroads, about the track data niche we occupied in railroading, about our processes, and about our tools. Doing that all on-the-job meant it took months of training for a new tech to be able to function with any independence. Besides the long timeline, their knowledge was heavily dependent on what projects had been in what phases during their early learning period. In other words, we took a long time to train them and accidentally pushed them into specializations.

Once upon a time, we had two experienced techs and zero inexperienced techs. We were pursuing contracts that would be far more than the two techs we had², or two techs and our engineering/leadership staff³, could handle. We knew we needed to increase our capacity.

So we did what made sense at the time: we hired a bunch of GIS technicians, explained a bunch of stuff to them, gave them some tasks they could handle, and made ourselves available to answer questions. Some of these techs were pretty experienced in off-the-shelf GIS tools. They were all pretty sharp.

It did not work out well. They did not learn a a lot. Their progress was uneven. Things didn’t get done right, deadlines were missed, important steps were forgotten. All of that led to a lot of frustration everywhere. Long-timers in the GIS department were frustrated with the new techs’ lack of progress and lack of productivity. The new techs were frustrated that they couldn’t make progress, at the expectations that were placed on them, and that “this isn’t what this job is at other companies.” A batch of three technicians hired in April were all gone by August. It was all our fault.

It was not a great return on the investment in hiring and training.

This is where I was brought in more actively⁴.

We reviewed the outcomes we were after. We asked ourselves why we had GIS technicians in the first place, what we needed from them at different stages of their development with the company, and what would show us they could be trusted to work independently.

With an improved understanding of what the GIS technician job was at our company, we revised the job description we posted. We made it much more clear that we were looking for a combination of field and office technician and that a lot of their work would be with custom tools. After all, if we set the expectation early, maybe even “scaring away” techs that might not want to do all of that, we’d put ourselves in a better place—even if it took longer to hire. We posted the job and started to interview candidates.

Concurrently with interviews, we sketched out a 3-6 month training plan with very specific learning modules, labs, and evaluations⁵. In a technician’s early days with the company, we would not expect “productive” work. They needed to learn. We would also reserve time from our senior techs and GIS Director to train them. We were very transparent about the objectives and would be very clear about when a technician did not reach the level they needed to “qualify” in a competency area.

In short, we completely overhauled our original onboarding and our expectations. We started with ad hoc training, trying to train in between “productive” work, with an unclear roadmap. We ended with an onboarding process that started with the very first interview as we set expectations, going through a well-defined training plan with clear goals. We could make empirical measurements of progress and prescribed next steps for each technician (e.g., “Alice qualified on railroad feature identification basics. Bob did not. So next week, Alice is going on to her first error correction lab. Bob will re-take the feature identification module with extra assistance from Carol.”). The training wasn’t made up or slapped together; every module built toward being a fully trained technician.

The results were stark. Over the next couple of months, we hired a new batch of technicians. It was more difficult; more candidates washed out on the more difficult interviews we were conducting, and several candidates we extended offers to turned us down because they didn’t want to do everything we would ask them to do. Of the next batch of technicians we hired, every one lasted at least two years. Some still work for the company, 5+ years later. They all fully qualified within six months. Any specializations were by choice and skill. The onboarding process and training have continued to be used for future techs, while being regularly improved—in part by that very batch of techs.

Both senior techs we had at the time have moved on in their careers and are no longer with that company. But the onboarding process we designed made it fairly easy for the company to survive the loss of skills. One of the techs in that first batch that was hired and trained by the new process is, I believe, leading the technician team. If we hadn’t hired well and trained well, that would probably not be the case.

The point: onboarding isn’t just for fancy remote software development jobs. Good onboarding is a deliberate practice to get the right people the skills and knowledge to do their jobs well. Good onboarding leads to improved retention, improved productivity, and a better feel around the office⁶. Good onboarding is a deliberate investment into the people your company is bringing in. Good onboarding takes work. Whether it’s worth the effort is up to you.

1. Technically, data files in AAR S-9501 and AAR S-9503 Positive Train control track data formats were the primary outputs. Maps, track charts, elevation profiles, and additional data like cellular coverage analysis were optional extras. [↩]
2. both senior, and both excellent [↩]
3. we had designed the internal tools and processes, and trained the current (senior) techs [↩]
4. At the time I was focused mostly on software teams developing PTC Back Office Server software and, if I remember right, tools for validating track data. [↩]
5. I’d been away from the day-to-day GIS work for long enough that even though I could rough out the plan, the senior techs and GIS director had to make some adjustments and fill in all the details. They did great work coming up with labs that pushed the limits of the new techs’ growing knowledge. [↩]
6. real or virtual [↩]