(You should read Part 1 first)

The elephant in the room. You are wondering why I am putting so much of the burden of being promoted on you. You have a boss. Aren’t they responsible for doing all this work? Shouldn’t they understand job levels and the intricacies of the promotion process?

Yes, they should.

Let’s talk about the word “should’ for a bit. Should doesn’t mean they will, it means they could. Should indicates a desirable future state, not a defined future. Your manager should understand your job level, and they should have a plan for your eventual promotion, but have they? The Big Three, the hardest and highest risk conversations new managers have with an individual, revolve around:

1. Space ¹
2. Title
3. Compensation

The promotion conversation hits two of the Big Three, and sometimes it’s all three when the promotion involves a new office. Managers, especially new managers, walk into these conversations thinking it’s just another conversation, but the Big Three are the hardest because they aren’t about space, title, and compensation; they are answers to fundamental questions:

1. Where do I live?
2. What do I do?
3. How am I valued?

A lack of experience in both preparing for and having these questions will not just make for awkward conversations, but often irrevocable blows to professional trust. So, yeah, your manager should be ready to discuss your promotion, but if they’ve screwed it up before, they might avoid it until the last possible moment.

So, let’s help them prepare.

Simplify

This article began with a simple realization after being a part of vastly different and innumerable promotion processes. There are two core, well-defined deliverables supporting your next promotion:

1. A Pinnacle Accomplishment
2. Network of Trustworthy Feedback

You are wondering about that job level document from Part 1. It has an impressive list of focus areas and expectations that grow increasingly complex with each level. How can these two deliverables address all of those attributes?

They might not.

If there are clearly defined expectations for your role, I recommend understanding them and reflecting on whether or not you’re achieving them. There are likely a couple in there where you are ignoring or are less adept at than others², but I’ve been in the room where we make the decision, and it consistently boils down to two questions:

1. What significant work did they achieve?
2. Who do we trust that agrees?

Let’s start with significant work.

A Pinnacle Achievement

This is a set of work, a deliverable, or an accomplishment that demonstrates you are capable of working at your next job level. There’s a significant assumption baked into this sentence that you need to digest. You mean I am expected to work at a higher level before I am promoted?

Yes.

But I haven’t worked at that level before. How do you expect me to do work where I have no experience?

That’s the rub. Your job is to figure out how to do that work (with help) before you’re promoted to that level. I will acknowledge that this is a prerequisite at the company I’ve worked for the last three decades, and your company’s culture might be different. Still, you know the places I’ve worked, and if you think that this set of companies got it wrong, I’m not sure if much of my writing will resonate with you, but keep reading, ok?

It’s hard to understand this without specifics, so here are real-world examples of what I’d consider Pinnacle work at three levels: junior, experienced, and senior engineers.

Junior:

• Contribute significantly to the development of a feature.
• Support driving a key metric from X to Y.
• Maintain an existing feature with no drama.

Experienced:

• Drive a new feature from design through development and finally deployment.
• Define a new engineering process that was adopted widely with an obvious measurable impact.
• Identify a critical learning for the service/product/process and transformed that idea into a product improvement.

Senior:

• Drove a major new feature that required significant cross-functional work.
• Led a substantive initiative within engineering that greatly affected engineering productivity.
• Solved a complex issue that required collaboration across the entire company.

Real-world is a stretch for these examples. You need to plug in the specifics of your company, the products or services, and your culture. Good news, unless you’re the CEO, you have a boss, and it’s as crucial that they either define or critique this work and agree that it’s sufficient.

I’m going to type that again because this step is critical. You need to suggest to your boss that you consider a piece of work to be grounds for promotion, and then you need to listen hard to their response. The goals in this conversation are:

• Are they clear that you are working to get promoted?
• Is this set of work sufficient to support a promotion? If not, why?
• If this work is insufficient, what similar projects are?

It’s a massive red flag if you leave this conversation either confused or without a concrete set of next steps to get to less confusion. It’s ok if this conversation takes a couple of attempts, but if you’ve done it three times and you can’t define a set of promotion-worthy work with your manager, then… you might be talking to the wrong person.

Yikes.

But it happens. There exist companies where even the managers wonder about the black art of promotions. Where the process happens in a black hole of a room, where information goes in, but can never escape. Sorry. In this unlikely case, my recommendation is to figure out who is in that room and get their advice.

Nervous about talking with other humans? Good news, you’re going to be doing it…. a lot.

A Network of Trustworthy Feedback

Chances are, the folks who are reviewing your promotion are not directly familiar with your work. The likelihood of this occurring increases as a function of the size of your organization, so how are they going to know if you are ready for a promotion? Yes, you have documented your Pinnacle Achievement in great detail, an Achievement that your manager agrees is worthy. Your manager might even be in the room discussing this promotion and is capable of representing you and your fine work. There are a lot of scenarios where this is insufficient. For example:

• Your manager is not a part of the committee, or,
• Your manager is present, but does not have sufficient context, or,
• Your manager is there, has context, but is not trusted by other members, so they ask, “Who else agrees this Pinnacle work was Pinnacle?”

For any achievement, there are a handful of humans around the work that you need to cultivate so that when it comes to promotion time, if they are asked, “Did this person do this work well?” they enthusiastically respond, “Why yes. It was fully Pinnacle.”

But who? And how?

It varies by the work, but there are always a set of humans surrounding your work. They might be:

• Fellow engineers are contributing to the same project.
• Partner teams need this feature to be done in order for them to complete their features.
• Quality, support, or other partners teams who worked closely on the development and can intelligently comment on the effort.

I think of these humans as customers. Who needs this work to succeed, and how can I best deliver that work to them? You need to be aware of who these humans are and their evolving impression of your work.

This relationship does not start with you identifying these humans and declaring, “Hey, so my boss and I agree this is Pinnacle, and I’m really looking to get promoted, so it’d be super if you could eventually support me in this effort.” This starts by identifying which humans are critical to the success of this project and making sure they, like you, are successful. The word “promotion” is never uttered.

Like the Pinnacle Achievement, the amount of work you need to do here scales with the seniority of the role. The group of humans you support as a junior engineer is a much smaller list than the lengthy list of humans necessary to ship a major feature as a senior engineer. Also, the different types of humans increase, as well. For a more senior role, you might have senior engineers, Directors, and VPs on your list of customers.³

As I don’t know what your Pinnacle Achievement is, I can’t advise on how to make you and your customer successful, but you should schedule time outside of regular meetings devoted to the project to check in. 1;1s, a lunch, a walk around the block. The goal is to get their perspective. How’s the work proceeding? Are they feeling progress? Where are they blocked? How can you help? Promotion aside, this is a practice you should deploy for any project of significance with as many disparate humans as possible because complex systems fail in small ways quietly before they fail spectacularly… and loudly.

How do you know you identified the right customers? How do you know when they will share a positive report of your work? How do you know they did? You probably won’t, but the list you want to have ready is when your boss asks, “How can I talk about this work?”

The Elephant in the Room

… is that every promotion process is different. There are critical aspects to your process that are as important as defining a critical project and having a trusted set of supporters. This is why I suggest that you figure this out first. As a manager, when I know I have a tricky promotion coming up for one of my directs, I find the last person who received this promotion and talk with the manager. What worked? What didn’t work? How long did it take? I’m looking for a successful playbook that I can use. It’s harder to find these stories as an individual because many organizations don’t broadcast promotions, but some do. Find those folks; learn the playbook that worked for them.

And understand your promotion might not be approved. Sorry. The reasons are myriad, and if the manager said it was a sure thing, they were wrong. However, once you get past the disappointment, the one piece of information you are looking for in the process is:

• Where was my performance insufficient?
• What do I need to do to improve?

If your manager can’t provide helpful versions of these answers, keep asking. If they can’t answer, ask others who’ve been successful.

I’d say good luck, but luck has nothing to do with your promotion; it’s just hard work.

My expectation early in my career was that promotions just showed up. You worked hard, and you figured out how to get along with your teammates. Every year or so, my boss would have a one-off conversation with me and alert me that I had a new role along with increased compensation. This hands-off cycle went on a lot longer than I am comfortable admitting. Years.

You start your career believing that your boss “knows.” They know how to do the job, how to get the project done, and how to grow you professionally. Most do, but many do not. More importantly, most are compulsively quite busy, and the essential strategic work of growing the team becomes a lower priority than whatever fire drill we’re all worrying about this week.

My advice: while you are not the decision maker regarding your next promotion, you are 100% accountable for driving it.

Before I start, we need to frame this piece:

1. You can replace the word promotion with review for much of this piece. Promotions usually align with the review process, but this article is focused on the promotion, not the review process.
2. Promotion processes are a reflection of a company’s culture. While I’ve seen a lot of different engineering cultures and there are common elements to their processes, there is always something slightly different in each company. One place promotions were never spoken of, ever, to anyone. Another place left it totally up to the manager — no oversight other than budgets. While I hope threads of this article resonate with you, there is something essential about your current promotion process that I’ve never seen.

We good? Ok, we’re going to start this process with you answering three questions:

1. Is there a publicly available rubric that clearly describes the different job levels at your company?
2. Is there a repeating, usually annual, process whereby promotions are reviewed and approved?
3. Do you understand both the rubric and the process?

It would be easier on all of us if your answer to all of the above questions were a confident “Yes,” but, well, there are well-known forces that act in opposition to defining clear rubrics and processes and making sure everyone understands them. The greatest hits of these oppositional forces include:

• Growth. A rapidly growing start-up that has not kept up with the growth of the team and has not invested in job levels or a promotion process.
• Experience. Managers who have not been or have little experience in understanding and applying job levels, or adeptly using the promotion process, and/or managers who are just poor communicators.
• Risk. This is more of a big company oppositional force, but the larger a company becomes, the more it dismantles what used to be a pretty rich job level and promotion process. Why? Risk mitigation. Having a rich and well-documented process that captures a lot of information about the individuals on the team, their accomplishments, and promotions often comes back to bite you — legally speaking, so “Let’s simplify the process and save the team a lot of time!” This is how you end up with a review form comprised of two text fields: Accomplishments and Goals combined with simple 1 to 5 rating systems, “You are 4, but with work I’m certain you can be a solid 5.” I wish I were joking.
• Budget. One of the most disappointing outcomes from a promotion process is when you hear back from your boss, “Sorry, we don’t have the budget this year,” except they don’t say that. They find some aspect of your work this year that barely justifies the lack of a promotion because they know you did the work and deserve the promotion, but budgets didn’t align this year, and that’s the last thing they want to say. This oppositional force increases in intensity and confusion with the seniority of the job, where the compensation is higher and there is more competition for fewer roles.
• Power. Similar to risk, the holders of this information have been burned in the past when they’ve shared this information completely, so they are reluctant to share complete job levels and the detailed promotion process. If you find this odd or unsatisfying, I’ll raise you a “this is complete bullshit.” I’ve professionally screwed up by sharing too much information or sharing job or promotion information sans proper context, and this has blown up in my face. This was my error to learn from, and the lesson wasn’t “share less,” it was “do better.”

I have constructive advice on specific work you can do to invest in your future promotion, but this advice will be less helpful until you discover what boils down to two pieces of critical information.

A document that describes the job expectations for your current level. It’s usually a table of some form. It’d be great if you could get the expectations for all levels, but, again, folks get twitchy sharing the complete set of this information. This is one of the reasons I advise you to get a document. Word of mouth on this information guarantees misunderstanding regarding expectations.

A schedule for the promotion process. There is one for managers and one for individuals, but they contain similar information and dates:

• This is when the promotion cycle begins.
• This is the deadline for promotions.
• This is when promotions will be decided.
• This is when promotions will be communicated and take effect.

I’m less tense about finding a document for this information because the core of what we need to know here is timing: when can we expect what?

You have questions. Many questions.

• Who wrote these job levels? In smaller companies, it’s the leadership team along with the HR/People team. In larger organizations, it’s the HR/People team. I’ve written many; here’s a cleaned-up and anonymized one I wrote for a start-up that you can have right now¹.
• Why are promotions at this particular time? It’s usually annual budget dependent, which is why this process happens in the early Fall in the United States. Sometimes, the promotion process happens twice a year, with the non-Fall process existing to error correct a handful of heinous promotion situations.
• How are promotions decided? It’s usually a group of managers with additional oversight for more senior promotions. Some companies have invested a lot in having this review group be an anonymous entity that knows nothing about you except what is included in your promotion packet. The idea is to make the approval as neutral and unbiased as possible. More on the promotion process and this packet shortly.
• What if I can’t find some or all of this information? In this likely scenario, you need to push a little harder because the answer will help you. Ask your boss, ask your HR person. Listen to their answer. What oppositional force do they invoke? Does it make sense? Are you buying it? Pushing a little usually results in more information, and you get all you can get because your initial question remains:

How do I get promoted?

I’m glad you asked. Go ahead and read Part 2 now.²

If you want to teach a Californian kid about cold, have him fly out to New York in January. Have him pack poorly and then have him walk out of JFK airport at 3pm with aforementioned poor packing, and watch what happens.

Wait until the sliding door opens.

Wait for it.

And watch.

I did not understand cold until I walked out of JFK in half a winter outfit. It was likely getting punched in the stomach… with cold. I forgot how to breathe for four seconds. I looked around at compatriots and realized why they stopped INSIDE the terminal to perform what I know is an East Coast (and Midwest) ritual:

1. Pull out the scarf, fold it in half, wrap it around the neck, and tie it like a knot.
2. Gloves. Wool works, but wool won’t always save you from deep cold.
3. Put on that black pea coat that falls well below your waist, and pop that collar up.
4. Beanie. Wool beanie. Over the head.
5. You’re wearing wool socks, right? Gosh, I hope so.

It took a few trips, but one January, I was so proud of my cold-weather habits that after checking into my Tribeca hotel, I decided to walk around in the bitter bitter cold late at night. Stomping around in my fancy black Chelsea boots and eighteen layers of warmth, I turned a corner in Battery Park and saw floodlights on the Hudson. Walking to the river, I looked over the edge and saw a half-sunken plane in the Hudson River.

Are You Prepared?

The two books are on the coffee table next to your bed. Both are being read. Jeans on the floor. The cables for the speaker, the clock, and the desk light — the cables are not organized. Your desk is in the upstairs office. A parking ticket, the reminder to an appointment to get an X-ray for a tooth (probably bad news), both on the left side of the desk. You ate breakfast here this morning, so there is residual… breakfast on and near the keyboard. A clickable gel pen with the tip out on the right side of the desk, the gel dries over time. A plant, well watered.

Is this tidy?

Your staff meeting. Three topics are scheduled. We get through just one of them before we swerve wildly into an unexpected fourth. The unexpected fourth topic has gravity, inescapable organizational gravity, so you stick with it. It’s important to orbit this a bit. Important unrelated information is not conveyed. Important and timely topics are not discussed in a critical meeting.

Are we organized?

The critical presentation. The CEO casually asked you a month ago to define a program (“document the culture”) for the whole company. He asked you in front of the entire executive team, and today you are presenting to all of your peers. You didn’t know it at the time, but the CEO was asking this of you because he didn’t think you could do it.

Are you prepared?

Tidy, organized, and prepared. There’s a deliberate escalating amount of work for each level, going from picking up and folding your jeans all the way to scheduling time with some of the busiest humans in the company to review your drafty thoughts on the slippery topic of culture. Also, at each level, there is a minimum success criterion, an optimal one, and a maximum. For each, there is what you must do, what you should do, and what would represent exceptional work.

Leadership, especially senior leadership, is built on an influential lie: “busy people are more successful.” Now, no one wrote this down and documented this lie. It’s derived from the sense of urgency for this critical project, this high-performing team, or this can’t-fail start-up. In each scenario, the incentive is to act as quickly as possible because there is so much at stake.

The counter to this lie is building a set of small, often inconsequential, thoughtful habits that often pay no obvious immediate dividends, but are essential to your leadership success.

• Being tidy means removing the unnecessary, removing the noise, so that the signal becomes obvious.
• Being organized means taking deliberate action that is efficient, informed, and focused. Organized means eliminating waste.
• Being prepared means anticipating what’s needed before it’s urgent, before you know you need it. It means having the right set of tools ready before you need them.

You can schedule that X-ray appointment that you are dreading — right now. You can choose to let the rowdy, unexpected 4th staff meeting topic go much longer than expected. You can proactively Slack the CEO right after his request and ask, “I’d like to know what success looks like for this project.”

These are short-term investments in the now, but more importantly, they are long-term investments in your ability to find signal, stay focused, and act thoughtfully when disaster strikes.

Two Minutes and Forty Nine Seconds

On January 15, 2009, US Airways flight 1549 took off from LaGuardia, and roughly one minute after take-off, the plane hit a flock of Canada geese, which disabled both engines. The time from when a flock of Canadian geese struck US Airways Flight 1549 to when the plane successfully made an unpowered ditch in the Hudson River was two minutes and forty-nine seconds. For the crew and passengers on that plane, that was the longest two minutes and forty-nine seconds of their lives. To everyone else, it’s just under three minutes. You’ve likely spent more time reading this article.

The now-famous captain of that flight, Chelsea “Sully” Sullenberger, said, “One way of looking at this might be that for 42 years, I’ve been making small, regular deposits in this bank of experience, education, and training. And on January 15, the balance was sufficient so that I could make a very large withdrawal.”

Disaster strikes unexpectedly. It’s unfamiliar. Its magnitude is hard to fathom. You don’t know what information you need, nor how quickly. Your irrational intuition is to freeze and pray for the danger to pass, which usually means additional disaster.

Find signal, stay focused, and act thoughtfully. It reads like common sense right now, but that’s because you’re reading this in a coffee shop. The biggest disaster currently facing you is the slight chance you spill that flat white on your notebook.

I’ve listened to the cockpit recordings of flight 1549, I’ve watched the interviews, and I’ve seen the movie. What struck me was the captain’s calm response to impending doom. My impression is that he is a human, but my experience is that the habits and skills he used to save those lives are ones you practice every day when the stakes are far lower.

I went back the next day to the Hudson. The plane on a crane was being moved to a barge. Surreal to see a machine meant to fly hanging from a crane. At this point, little was known of what actually happened on the flight except that everyone had survived, and it appeared it was because a competent leader had acted calmly and thoughtfully when it mattered most.

An idea just comes to me. I’ve been writing for a long time, so the ideas come partially formed. Not written but formed into the beginnings of a familiar shape. It is critical in the next hour that I write this idea down somewhere accessible because it’s just an idea, and failure to capture it means it will disappear as simply as it appeared.

Whether this idea becomes an actual piece is defined by the next 72 hours. If I succeed in sitting down and expanding the idea, the probability of a completed piece increases significantly. This first attempt is an hour of my time, perhaps more if the window aligns with a weekend, so call this first investment ninety minutes on average.

In this session, I am taking the wisp of an idea and giving it shape. What was a three-to-five-word reminder is now five to ten paragraphs. If I’m lucky, I can see the beginning and part of the middle. If I’m really lucky, section titles are starting to show up. These section titles are similar to the initial inspiration in that they, to me, elegantly encapsulate part of the idea. If I can’t find a section title but know I’ve moved from beginning to middle, I write a dummy title, usually Something.

Something

If I make it to the middle of a piece, the publishing probability has again increased significantly. Still, as I’ve matured and relaxed about my writing, the number of abandoned articles has increased significantly. If this reads like bad news, I understand, but I’ve learned two important facts that affect this moment of writing.

1. There is always more writing. Every piece doesn’t need to be finished.
2. The remaining work to publish this on the blog is significantly more than I expected. If this piece is for a book, it is twice as much.

In the back of my head, sitting and staring at this half-formed piece, I’m quietly asking, “Is this worth finishing?” What pushes me over is the idea remains stuck in my head. There is still something to discover, to say, that I am curious to find.

I’m wildly guessing that 30% of the work is done now. 30% might be too high because what happens now is much more of a slog. I like writing. No, I love writing, but middle to end means I must continue to ignite what inspired me initially, but now it needs to make sense to you. This isn’t a journal entry; this is an artifact that I am placing into the world for judgment, so I must:

• Finish the middle. The end of the middle is the end of the most challenging part of the writing. A good ending is a work, but it’s usually a clever and synthesized arrangement of your beginning and middle. There’s a chance I’ve already found it, but if I haven’t, I’m not worried. I’ll slap something together.
• First pass edit. I print out the piece, and I edit it somewhere that isn’t near a keyboard. This change of perspective is a coherency pass Does this make sense? Just about anything can happen during this editing. So much so, I have a well-defined system of notation that tells me exactly what I need to do the piece because my regular scribbles are often indecipherable.
• First pass edit changes landed. Taking my written notes, I graft them onto the piece. We’re somewhere between five and ten hours of work now. We’re somewhere between one day and three months from when I started. Pieces languish. Life gets complicated. The half-life of an idea is extended by the amount of work invested, but sometimes… it just fades.

But not this one. This piece will be published, and I know the precise moment: I can see the entire shape of the piece in my head. It’s not a geometric shape; it’s a feeling shape where I understand the beginning, middle, and end. Chances are significant chunks of the piece are not written or edited, but if I can see the end, the publishing probability reaches 90%.

I know the ending of this piece.

I know it because I knew the title was the ending when the idea arrived. This has allowed me not to put a section header where the ending became obvious, which is right here, incidentally. No, I need to finish describing the amount of work because this piece, confusingly, is not about writing.

With the final shape in mind, I finish the writing. Call this another two hours of work. I do a Grammarly pass (30 minutes) and a technical pass – links and images (another 10). The piece is dropped into Visual Code, where I zap gremlins, I produce the featured image, I push the piece to WordPress, do another read (30 minutes), and then hit publish.

I estimate I’ve devoted ten to fifteen hours of my life to your average blog article. The question is: what makes it…

Worth it?

One compliment. Just one.

When I hit publish, I broadcast to Mastodon, Threads, BlueSky, and the Rands Leadership Slack, and I’m looking for straightforward feedback on having devoted ten to fifteen hours of my life. A compliment.

Now, this can’t be from someone I know because while I trust these folks, they are biased, lovely, and biased. This is a thoughtful compliment from a stranger who I do not know and does not know me, and wants to say something interesting about the piece briefly. When this occurs, I release a deep breath I have held since I hit publish.

Compliments work.

As you climb the leadership ladder, you’ll have the idea of performance management in all its forms beaten into you. Your interpretation of what success looks like is often, “I need to give them feedback to improve effectively.” Advice, constructive advice. Sometimes critical. This is a reasonable interpretation, but half a strategy. Explaining where they need to focus is as important as clearly acknowledging when they have.

But there is another compliment out there. It’s a random selfless acknowledgement. To the stranger. I love those kicks. At work, to the person you’ve never met, interrupting This Keynote template is… stunning. To the human you’ve known forever, I don’t say it enough, but I am glad we are friends.

The rule is: people want to be seen.

You have no idea how much work goes into a human’s chosen passion. When they become adept at their work, the simplicity or approachability of their ‘product’ might give you the erroneous impression that because it’s clever, approachable, or just straight up fun, the work involved was simple, obvious, or… fun.

People want to be seen. Writing as an introvert, I can confirm the last thing I want is public recognition. I would prefer it if you slid a folded note under the desk where I am hiding. Make no eye contact. People are a lot of work for me. The reason I spend so much time writing it down is that I don’t want to explain it to you face-to-face.

But.

I am deeply interested in your folded note. Just tuck it under my foot.

I didn’t much like Wally from the first time I met him. We worked in the same circles, but not on the same projects. I was aware of his work, but not involved or dependent on it. My initial reaction to Wally, “Complains. Nitpicks. Doesn’t act.” I made this judgment in a moment.

Months passed, and none of Wally’s observed actions changed this initial perspective. In conversation, he was the guy who pedantically and exhaustively pointed out flaws, but did not suggest the means by which we address the flaws. My impression was unchanged: “He believes identifying the problem magically fixes the problem.”

Several years after we first met, Wally and I were paired on the same project. I was the technical lead, and he was one of three engineers contributing. From the moment it was announced that we were on the project, I knew there would be a Wally situation.

To his credit, Wally didn’t Wally for almost six months. I figured there was something about the project or the team structure that prevented the endless critique, but I was wrong. Seven months in, the project went sideways, and the Wally flood began. The good news is that I’d been preparing my speech for him for just under a year. I know what I wanted to say, and the moment the debate became unhelpful, I took him aside and executed on my speech.

“Wally, it’s clear that you care about this project. So do I. It’s why they put this on the effort. You have experience. You work hard. You listen to the team, but when it comes to solving hard problems, you… endlessly analyze. You scratch at that problem itch way past the point of uselessness. Yes, we need to understand problems, but the understanding should begin to reveal solutions. Please help us find solutions faster.”

From that moment on, Wally and I got along famously. Problem solved.

I am not joking even a little; I am, however, lying quite a bit.

A Vacuum Full of Fear

I’ve never actually met Wally. Yes, we had a tremendous amount of interaction over the years, but the entirety of our interaction has been text-based; it was online. We never worked together. All of my impressions were real, and, yes, we did end up co-contributing on a volunteer project virtually. And, yes, the Wally talk did finally occur, and it did fix our relationship, but the situation had very little to do with Wally and everything to do with me.

The rule is: “In the absence of information, humans will fill the vacuum with their worst fears.” The reason I lied to you is that I’m wondering: Did your perspective change when I told you I’d never met Wally in person?

Without a doubt, I know that a distributed company can work. I’ve helped build several and watched them work. We can communicate well in a virtual environment. However, if someone is sitting on the other side of Slack, everyone is missing context. A look here. A sideways glance there. Perhaps a critical pause.

What is aggregated with these small bits of missing information is an increasing vacuum. In that vacuum, you do what all humans do: you make an educated guess on how to fill the vacuum. Well, she responded to the message slowly, so I guess she doesn’t care that much about the project. His written answers are always so terse, I guess he’s mad… about something. He keeps typing and typing about the problem. I don’t think he’s that strategic.

Wally is strategic. I’d trust Wally to handle any curveball these days because I have… and he does. Wally isn’t the problem. I’m the problem. From his first few communications, I defined my Wally judgement and hung on for dear life. I never rechecked my assumptions.

Relative to me, the core issue with text communication is that I have decades of senior leadership experience and a truly impressive short attention span. These have served me well, but in order to read the room, I require a physical room populated with real, live humans. I need to see where you’re looking when you’re speaking. I understand more when I hear the length of your pause before you answer the question. I see discomfort as well as I see joy — you don’t have to say a thing.¹

The skills you develop as a senior leader over decades in the room soup tasting have given me the impression that I am good at leaping to judgment or inferring intent quickly based on the vibes in the room. The room is not confident in what this person is saying, I will ask questions. No one is asking any questions about any of this presentation? What are they scared of? I will ask others to speak. He didn’t answer my question. I will ask again.

In a remote or virtual set-up, context vanishes. The amount of correct information you have about this person, their true thoughts about this topic, and others’ impressions drops significantly.

The written word gives you a powerful medium to define and refine your thoughts. Continued practice will improve the quality of your writing. However, you are the writer, not the reader. What publishing hundreds of articles and several books has taught me is that the reader plops themselves in the middle of your narrative and reads the story they want to hear. You shape their perspective, but you do not own it; they do.

Check your context. If you rely on written communication on a team: mail, Slack, messaging, the burden is on everyone involved, not just to read, but to understand. My belief: you’re missing 50% (probably more) of the context in the first draft of short-form written communication.

Check your context:

• Any question you have, however small, is worth asking. Ask them. Ask them again. Ask until you are satisfied you understand.
• In text, your impression of the emotion behind their words is your emotions speaking, not theirs. Clarify — do you mean this? I am reading your feelings as that? The incorrect snap judgment on emotion is a sure-fire way to point your understanding in the wrong direction.
• If the writing seems clear, if the conclusions are reasonable, and you believe you understand, great. Does this thought lead us to a high-risk decision? Can you sense enormous consequences if we head down their suggested path? Repeat their thought in your words or use theirs. Watch what happens.

The One Conversation

In person, you are swimming in context. You’re so used to it that you take it for granted. The murmur of agreement — that’s good. The complete silence after the key point — that’s bad. Frank, nodding in the corner when she finishes speaking, Frank never nods unless he’s super on board, and Frank is never on board.

The reason the Wally conversation “fixed” my relationship was it was the first time I took time to give Wally feedback. Lunacy on my part. I know. I was sitting there hiding behind my keyboard, thinking Wally could infer my poorly informed judgment from my silence, from my lack of sharing context.

I find great comfort in the written word. It gives me satisfaction to translate the mess in my head into occasional helpful words and phrases. If you and your team are heavily relying on written communication to get the work done, you, the reader, have extra work to find the errors in their thinking and ask them questions to gauge the substance of what they write.

And, sorry again, Wally. You’re aces. And you already know that because I told you and you heard me.

In our 92nd episode, we talk about the ongoing battle with productivity tool swirl. Again.

Enjoy it now, or download for later. Here’s a handy feed or subscribe via Overcast or iTunes.

Your robot experience started simple. You typed a question into a chatbot… just to see. Can it answer that question? I’d be impressed if it did.

Your query was simple. A simple knowledge question that with a little effort using legacy tools like Google, you would have discovered yourself, but the robots made it trivial, and you thought Hmmm… if it can do that… what else can it do?

Later, you decided to ask the robots to build something for you. A simple tool, application, or script. You wrote a sentence, it wasn’t much, just your simple idea to get the robots dancing, and, wow, they danced. The moment was impressive. Using your two sentences, the robot built the thing. Completely, and when you ran the script, loaded the page, or ran the application, you were impressed.

The robots… they did the thing.

Dance. Robots.

It wasn’t my first attempt to get the robots dancing; it was my third project. I wanted to replace the home page in my browser with something useful. I had the robots design a home page that runs locally. It displays weather for a handful of cities, stock prices for a selection of companies and funds, and loads a random image as a background. Every 60 seconds, the image and weather rotate.

The prior paragraph is roughly what Claude Code built, and it did. After a little back and forth picking APIs to get free weather and stock information, I had a good-looking page that achieved my goals.

I want to talk about what I didn’t specify:

• I didn’t tell it what typeface to use.
• I didn’t specify where to place any elements on the page.
• I didn’t specify what weather or stock details to include.
• I didn’t ask it to include forward/back/pause buttons for image rotation.

In fact, the number of “decisions” the robot made to design the page wildly exceeded the number of requirements I specified. More honestly, I didn’t know what I wanted for this homepage when I started; I was gleefully getting the robots to dance for me.

One of the common knee-jerk responses humans have about robots is, “The robots lie,” except the humans say “hallucinate” because that rolls off the tongue. Here’s the thing: the assumption most folks have is that hallucinations are bad. Incorrect, it’s the hallucinations that you catch that are obviously wrong that you dislike. When the robots hallucinate a helpful thing, you don’t complain. Your eyes widen a little, and you wonder, How did it know? When the robots hallucinate or make a mistake, you shake your finger in their virtual direction and complain that they don’t know how to read your mind.

Here’s the actual thing. Robots:

• Make incorrect assumptions.
• Misinterpret clear direction.
• Claim they know when they don’t.
• Make mistakes.
• Lie.

Who else does this all the time? Every single human. Like. Always.

The Prompt Progression

I’m using Claude Code almost exclusively for personal projects. If you are cutting and pasting code from your favorite chatbot into your favorite editor, you are doing it wrong. One terminal-like window (Loving Ghostty) where you are jamming with your favorite robot, and they have direct access to your file system, allowing them to create and modify files, is the dream.

To date, I’ve created over twenty projects, ranging from a simple Python script to look up populations in towns to a fully deployed Node application that tracks productivity. If you’ve made it this far in the piece and are about to leave because you think I’m about to nerd it up and you aren’t an engineer, please stay. I’m not going just to demonstrate that anyone can get the robots to dance; I’m going to explain that the habits you’ll learn with your robot dancing will make you a better communicator… and maybe a better leader.

Four situations occurred with all these dancing robots, and each taught me a valuable communication lesson.

Situation 1: The robot misinterprets you

After the giddiness fades from your first robot dance, you stare at the artifact it created and discover that the robot didn’t quite hallucinate correctly. It built a feature unexpectedly. When you go back and look at your first prompt, you’ll discover the problem: you didn’t specify this aspect of the feature at all — the robot just guessed.

The robots are pretty good at guessing. They’ve been trained on programming language documentation, code repositories, sites like Stack Overflow, API documentation, and best practices and style guides. This means when you ask the robots to build a home page and specify nothing about the layout (like I did), the robots guess. They look at the corpus of knowledge about homepages and infer, “Well, he doesn’t want to display a lot of information, so let’s tuck the widgets in the upper corners and center the important stuff at the bottom.”

Which, in my case, was correct.

The more I used the initial artifact, the more I found assumptions I didn’t like. Typeface was wrong (Futura now). Stock prices didn’t show percent change… oh, and hey, wouldn’t it be cool if this page reminded me about birthdays and other important dates? Let’s do that!

With each iteration of the project, I found that the more specific my request was, the better the robot performed in implementation.

Please add support for tracking important dates. I am fine editing the HTML to track these dates as I want to keep this homepage portable. Please list all of the critical dates in a calendar window. And if an important date is within 30 days or less, please gently alert me on the home page.

(Sidebar: Why am I so polite with the robots? I don’t know.)

As I progressed through future projects, I learned to devote more time to thinking through the specifics of my ideas. The robots are good at guessing what I mean, but the less room I give them to guess, the less they need to dance.

Situation 2: The robot forgets

As we discussed in the prior article, current robots must work within a finite context window. It’s exactly what it sounds like: it’s all the current information regarding your task. The state of the project, your recent prompts, and the resulting context. If you’ve gone deep down the robot rabbit hole and spent hours on a project, you’ve seen the robot forget everything. Everything.

Your session has grown beyond the robot’s ability to keep track. You’ve exceeded your context window. While your project is fine, your robot is not. In Claude Code, I discovered this situation while working on a now-abandoned productivity app. The robots and I? We were in the zone, and then suddenly the robot knew nothing. Processing my next prompt, the robot said, “Huh, what is the project? I should check it out.”

You’ll experience the same situation if you start a fresh session on an existing project. The robot needs to teach itself. Now. You can let the robot search your files, or you can accelerate the process by asking it to document the project. Documentation is an LLM dream task — Hey robot, look at this code and explain what it does.

Like everything a robot generates, the burden is on you, the human, to confirm that what it generates is sound, but once that’s done, you’ve got context-generation superpowers. In my most recent project, a set of Python scripts that analyze Rands Social Reach, I have four documents:

• SYSTEM_ARCHITECTURE.md (Explains how the various Python scripts work together.)
• DEPENDENCIES.md (Explains how data files work in the system.)
• TESTING.md (Explains how to test the system.)
• TROUBLESHOOTING.md (Weird, I didn’t ask to create this. I wonder what it does? Oh cool, it captures common errors we encountered during development. Sweet. Thanks, robots.)

While the original intent was to give the robots a jump start, as the project grew more complex, I’ve found myself glancing at these documents to refresh my understanding of what we’ve built.

Situation 3: The robot makes an error

While I am writing this piece, I have the robots merrily working on a different project. We just updated an HTML-based configuration tool. I just asked to add additional fields, explaining what data to track and the relationship between the fields.

The robots merrily completed the fix. I loaded the page, and it was blank.

The robots make errors. I’d love to explain why, but after many weeks of productive work, I haven’t found any obvious pattern to why they occasionally write bad HTML or forget to do part of what I asked. You can freak out about this if you want, but it’s somewhat comforting to me because… It’s just like working with humans.

During a particularly heinous session where the robot errors were numerous, I threw up my hands and said, “Hey, write a test script that we run after every change. Ok?”

And it did.

Fast forward to two hours later. I’d forgotten entirely about pre-change test runs when I glanced at the robot working on the most recent change and read, “Running test suite. Ok. I found three errors. Fixing them.”

Oh.

Like everything a robot generates, the burden is on you, the human, to confirm that what it generates is sound, but once that is done, one of your least favorite tasks, test generation, has been jump-started.

Situation 4: The project that collapses on itself

Most of my robot projects started with a random idea and a poorly formed initial prompt. Most of these efforts were one-and-done situations. After being briefly impressed by the robots, I realized I didn’t really need this project. I just wanted to see the robot dance.

Some projects continued. The idea was intriguing. The problem I was solving was valuable. We continued to dance for hours. I hit limits and blew through context windows and, eventually, the robot got confused. I asked them for a significant change, and they happily started working, but I watched them traverse the project, and they were lost. Updating functions or refactoring random parts of the code unnecessarily.

Stop.

Your instinct might be to blame the robots. They do hallucinate, after all.

Blame yourself.

If you pick one of my larger projects and review my series of prompts, here’s the prompt narrative:

• Build this feature.
• Add this other feature.
• Make these changes to both.
• Nuke the second feature.
• Add all of this new functionality to the first feature.
• Wait, we need to make this a node app. Do that now.
• And so on.

Spaghetti code is what we call code that random people have clearly slapped together over the years. Spaghetti thinking is how I build these unstructured projects. It’s just me and robot yolo’ing our way through my unstructured thinking.

After placing the robot in this confusing state a few times, I revised my strategy. Rather than prototyping with code, I prototype in a spec. I explain to the robot what I want to build as a markdown file. This spec is the only thing we create. The process is no different than the first twenty prompts, except that the output is easy to read and easy to change markdown. The robots do a dutiful job of capturing my thoughts and their implications. No code. No APIs. Just writing.

And when I like what I’m reading, I ask the robot to build it.

This is the third time I’m writing this, but it’s the most important part of this piece. Like everything a robot generates, the burden is on you, the human, to confirm that what it generates is sound.

I Lied

Robots don’t lie. Lying requires intent to deceive, and when a robot provides you with plausible-sounding, but incorrect statements, it’s either following its programming or making an error. Or both. Humans lie. They boast, they are tragically optimistic, they exaggerate, they forget, I could go on for a long, long while. It’s a list of foibles that make them familiar… that makes them human.

What do I do as a leader to work with these troublesome humans? Well, here’s a short, essential list:

• I speak clearly and specifically, so my intent is clear.
• I frame conversations with context so everyone understands my ideas.
• I understand errors are part of the process and work to build tools to prevent them.
• I debate and plan big ideas before I begin.

As a writer, I am giddy about working with the robots. The better I write, the better they can interpret. As an engineer, I feel empowered — that weird Python syntax convention? Who cares? Let the robots worry about that pattern; you have strategic work to do. As a leader, I am surprised to find that improving my core skills in communication, setting expectations, and planning benefits both the robots and the humans.

Learning how to get the robots to dance for you will make you a better leader of both robots and humans.

Now go build stuff. It will give you joy. Would I lie to you?

There’s a lot of content hiding in the Rands archives from the past three decades. Over the years, some of that content keeps showing up. I keep forwarding the same links to the same articles; I get asked the same questions at Q&A. I’ve decided to synthesize the advice into a single artifact.

My writing style has historically been nice and introverted. I don’t tell you what to do; I tell you a story, usually about my experience. If you want, you can derive lessons from this story, but I’m not insistent that you learn anything. I just want to tell you a story.

I suspect humans need more direction.

Download PDF Rands Cheat Sheet #1 — 1:1s

I’m fond of 1:1s not just because they are immediately useful meetings, but because they were one of the first leadership topics I wrote about, where the response from the Internet instantly demonstrated a clear hunger for leadership mentorship. It was the beginning of a literary love affair with documenting leadership habits I found to be obvious, but that were not obvious to everyone. I have just explained the primary reason you are reading this sentence right now. Hi.

Another goal for the cheat sheet is to make Rands Ltd more accessible elsewhere. Blogs make no sense on platforms like Instagram or TikTok, and I am unlikely to start filming 37-second shorts, but I am going to see how tight, well-designed, and digestible content fares elsewhere. We’ll see.

There are two definitions of cheating out there right now: one definition is akin to hacks, clever approaches to beginning to solve a complex issue. The second is dishonestly or unfairly acting to gain an advantage. A non-goal for this cheat sheet is the latter. The fact that I’ve distilled decades of knowledge into an easy-to-read one-pager doesn’t make the act of scheduling, preparing, and running a 1:1 any easier. If you don’t do the work, you won’t learn the lesson.

One of the more interesting robot-assisted tools I’ve built in the last few months is tracking the various metrics for Rands-related properties. Think social like Mastodon, BlueSky, and
Threads. Think blog analytics like new users, session duration, and popular articles. I’ve been plopping this data into a spreadsheet every month for the last two years. This month, I decided to have the robots take a swing at a dashboard.

And suddenly, the weekend vanished, and I had multiple dashboards, including basic and advanced analysis, as well as a system where I set monthly goals for the metrics. The advanced analysis was mostly robot-suggested metrics, such as:

• Compound Annual Growth (The average annual growth rate over the entire period, accounting for compounding)
• Volatility (Standard deviation of monthly growth rates. Higher values mean more erratic growth)
• Momentum (Compares recent growth acceleration to previous periods)

Did all of this robot wizardry give me major insight? No, it gave me a refined view of data I could already intuit by skimming the dashboard, but the addition of sparklines put a clear picture on two stats. Both Rands Leadership Slack members and newsletter subscribers grow steadily like nothing else.

While I invest daily in the Rands Leadership Slack, the newsletter is an afterthought. The subscription link is buried at the bottom of the About page, and while I post most new articles there… sometimes I forget. Sorry. Doesn’t matter, subscriber growth isn’t a flood, but it’s constantly up and to the right. Every month. For years.

I moved to Substack after years of attempting to twist MailChimp into doing something it didn’t really want to do. Substack was easy to set up — someone had clearly done their design work — and the buzz about the product was intriguing. Once set up, I promptly forgot about the newsletter, and subscribers continued to grow.

There’s another buzz about Substack, and I’m not going to go into details because others have… competently and loudly. Here’s the thing about this buzz: as far as I can tell, Substack has done little to nothing to counter that buzz. Actions. Words. Zip. I’m sure they have told themselves they’ve done work, but… as a distant outsider, the original damning buzz still bouncing around. My internal monologue: “They don’t believe it’s important enough to counter-program the buzz.”

Ok, so, bye then.

Ghost has all the knobs and dials I need (and more¹) for a new home for the Leadership Newsletter. The migration was trivial. The design options were rich. And they charge customers for the service, which means the customers aren’t the product… the product is the product.

This is where I’m supposed to tell you there’s lots more content coming for the Newsletter. Maybe? I think newsletter subscribers and I have a good deal worked out. I’ll post occasionally, and they’ll just keep showing up.

In our 91st episode, we talked about Founder Mode long after everyone else had moved on.

Enjoy it now, or download for later. Here’s a handy feed or subscribe via Overcast or iTunes.