1. Vanilla. Someone decided. Good. No further questions. We can make progress now.
2. Educated. You ask why they decided, and they can clearly explain their reasoning. Not everyone might appreciate the decision, but they will be given the opportunity to understand.¹
3. Calculated. Not only can they explain the decision, but they have math! Wow, I’m super convinced now.
4. Instinct. They attempt to explain their reasoning, but they say “feel” a lot. A lot. Thing is, it feels right, so you don’t press.
5. Inspired. Now you press, and they can tell you want a clear rationale and justification, but none obviously exists. This decision is not meant to be understood; it’s meant to be appreciated for its poetry. It is 100% expected that inspired decisions are going to frustrate those seeking clarity; they are going to point at the lack of a clear explanation. “He doesn’t know what the hell he’s doing. It’s a guess.” It might be a guess, but it also might be art in the making.^{2 3}
6. Minimum Viable. My least favorite. Your investigation into their justification reveals that they chose a decision that was not designed to be good; it was constructed to offend the fewest humans. This is not leadership — it’s fear.
7. Delegated. Rather than doing the minimal work of even making a minimum viable decision, they gave the decision to someone else because — and I quote — “They are more capable of making this decision.” What they are actually saying is, “I would prefer that this human deal with the weight and consequences for this decision.” The good news: at least you got a decision.

Sometimes, they don’t decide. You push, you prod, but they won’t decide. No, they didn’t delegate, no, they didn’t wing it, they just waited and waited… kind’a maybe hoping the need for this decision would vanish. Technically, deciding not to decide is a decision, and that’s a choice, but it’s not leadership.

In our 93rd episode, we wonder aloud about free will, children, and what makes a good ice hockey team.

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

I am of the opinion that when you start a new role, not a new job, a new role that you have not done before, it requires a minimum of three years to become good or competent at that role.

This window of acclimation grows with the complexity of the role. I’d suggest that while you’ll be a good manager in around three years, it’s going to take more like five years to become a competent Director.¹

I’m fond of reducing very complex topics down to a single thought. My primary rule for becoming a good manager is “Delegate until it hurts.”. It’s a counterintuitive strategy of giving the task of work you love to those on your team. It’s not about letting go; it’s about building scale into your team by building those you work with into you. Except it’s them. Read that again. I’m changing your professional life right now.

A Director or Vice-President is an entirely different role. Having mastered delegation skills by the time you reach here, or you’re at a start-up where they are giving the VP title to anyone, in which case you have an entirely different set of issues, which starts with the question, “Are you a good manager?” Big question. Different article.

I wrote this piece towards the end of my time at Slack as the Vice-President of Engineering. I was an OK senior leader after doing the gig for five years. I said OK, I didn’t say great. I suspect great remains years off.

Acting last to let others be heard, reading the room to understand the essential sub-currents of a situation, and thoughtfully asking informed questions to get the best sense of the soup sitting in front of you. I like these three habits, three tactics, but while they are good actions, they don’t have the poetic weight of “Delegate until it hurts.”

Are you a good Director? Vice-President? I don’t know, but I have recently figured out my boiled-down pithy advice for the role: “Become the Consequence.”

A Lack of Experiential Reference Points

Back at the start-up, we were accumulating quality debt. I’d successfully convinced engineering, quality, and customer service to use a single source of truth for issue reporting. Still, now that everyone was filing issues in one spot, no one was fixing them.

Everyone was swamped. It was a start-up. Little had been defined in terms of battle-tested process, so everyone was helpfully attempting to do everything. It worked when we were 50, so why wouldn’t it work at 500?

You have a gut feeling in your head about why it’s hard. More people, more decisions, more tasks, more differing motivations. Your mental model isn’t remotely close to why this is hard. It’s akin to trying to visualize the difference between one million and one billion. Yes, one is bigger than the other, but in your head… they’re kind’a the same? At a distance? They aren’t. A billion is one thousand times more than a million. We lack experiential reference points for both numbers because we’ve never seen one million or one billion anything in one place. You can’t see the new, rapidly evolving, mind-boggling complexity; you just see stuff starting to break.

Back to my quality issue. How do we get a larger group of engaged humans to change their daily process to care about the quality of the product? Everyone nodded and agreed, fixing bugs was a swell idea when we successfully moved to a single tool for issue tracking, so why is the pile just growing weekly?

The issue: the number of aspects of change required to make 500 humans care about quality (or anything) is unfathomable. I can tell you what a handful of people need to prioritize, but I can’t predict every single change that needs to occur. No one can. It’s a distributed process across dozens of leaders who must imagine what they need to change to support this strategy, vet it with their team, update their strategy, and then deploy. And that is just one team trying for the first time. There are twelve teams with different leaders and micro-cultures, and what they need to deploy is slightly different from the first team.

Welcome to Senior Leadership! You made it! There’s no delegating this task, but it’s not a task. It’s a strategy, and you don’t delegate strategy; you explain it loudly, repeatedly, and then you become The Consequence.

Ominous, Right?

Becoming the Consequence. Feels like impending doom? Heavy. This is why I like this colorful phrase. It makes you feel something, which means you’ll remember it.

Becoming the Consequence could be read as a threat, but this is not the approach or tone I’d recommend. My version of becoming the Consequence reads:

• Hi, we, this large group of humans, have a challenge ahead of us.
• We, this company, have values and goals, and this challenge is not aligned with our values and goals.
• I, the leader of this group, believe that if we don’t address this challenge, the following undesirable outcomes will occur. Here is the data, graphs, and anecdotes/experiences that prove this belief.
• Addressing this challenge will require a fundamental shift in how we work.
• I am asking the team to do X; if we don’t, I’ll do Y.

You will note that I did not say a thing regarding achieving this goal. This is because I do not currently know. All I know is Y, and Y is the Consequence. That’s me.

Too abstract, yeah, yeah, I get it. Let’s go back to the quality issue.

• Hi, we have an emerging issue regarding quality. The quality of our service is measurably decreasing month over month. See this graph if you don’t believe me.
• Our customers’ impression of our quality is our reputation. They count on us to do their work, and if they can’t do their work, we’re not doing our job.
• If we don’t get a handle on quality, we’re going to see a decrease in revenue per customer, and a lack of growth in that key metric is a long-term threat to our business. Yes, we are a start-up and enjoy focusing on the bright and shiny parts of delivering new features, but the features we shipped got us to where we are today, and they are getting crufty and unreliable.
• The team should spend 25% of their time each month focused not on new features, but on the quality of current features. I’m going to review each team’s proposal for doing this work at my staff meeting in two weeks.

Great! Did I fix it?

Not even close. You will note, again, I didn’t say how we were going to do this. I set a goal, not a strategy.

The first Consequence was “bring your strategy to staff and we’ll review it.” Six directors brought six different proposals. My recollection of the impressions of these six proposals:

• One was credible, actionable.
• Three seemed not to understand what I meant by improving quality.
• Two were made up on the spot because they forgot to do the assignment.
• One declined to participate with the justification that the team was too busy.

We talked about the first four proposals. We discussed what I liked about the first one, debated my definition of quality for the next three, and borrowed ideas from the first proposal. We ran out of time for the last two, but the next Consequence of their lack of engagement was the first topic of conversation in our next 1:1.

Was I frustrated about the non-compliance of the last three? A bit, but I also remained curious. Did I not explain the challenge? Did I not justify its existence? Did I not structure my argument sensibly? Did I not convey urgency? The assumption that an argument that makes sense in your head will make sense when spoken aloud is bad because you have all those delightful tidbits of unspoken justification, motivation, and backstory tucked away. Chances are, I forgot to share part of that initially, hence the various forms of non-compliance.

Did I fix it? Still, no. Not even close.

The non-compliant directors heard the message loud and clear and brought their team-vetted proposals to the next meeting. From the seven different proposals, we found common themes, we found new questions, and we discovered not everyone was aligned with the core quality thesis, so we litigated that thesis.

See, I did not know how to fix the quality problem at the start-up. I could tell you the various successes and failures I had at other companies, but the idea that precisely the same approach would work at this start-up is flawed. This unique combination of humans, working on this particular project, on this particular date, requires a unique approach in framing the problem, designing a strategy, and deploying that strategy.

Three meetings on this topic now, and the seven directors are mostly aligned on how they are going to spend 25% time. I could tell that at least two of the directors were relieved; the vibes were “Whew. Done with that. Now we can get back to the real work.”

At this point of the process, you can lump your leaders into one of three buckets: Believers, Wait-and-See-ers, and Non-Believers.

• Believers: I am on board with this plan and will do everything I can to support.
• Wait-and-See-ers: I understand the plan and will do what is reasonable to support, but I’m not going to drive — let the Believers drive this.
• Non-Believers: I understand what my manager is asking, but I am not on board. This is yet another leadership boondoggle asking us to do more with less. I am not going to say this, but my lack of forward progress will demonstrate this lack of belief.

Their bucket allegiance might already be evident to you, or it might show up later, but never have you made Believers out of the entire team early on when it comes to significant shifts in strategy. Humans fear change. They like their things… just so. As long as I’ve got close to 50% in the Believer bucket, I am going to charge forward.

The Consequence

From the litigation process, I discovered how I can become the Consequence. In the case of the start-up, it was a complex JIRA query that demonstrated how many issues we had in one of three critical states. The size of each of these sets of JIRAs demonstrated how much work we’d done in terms of understanding our backlog and sizing the remaining work.

The Consequence was this: each week, on a Wednesday, there is a meeting with me. Each team had a goal, which was a total of X number of issues in the bucket. These numbers were set by the team. If the team did not hit the number they set, the director and manager review the buckets with me. If you hit your numbers, no meeting for anyone except the Director.

As a new manager, I viewed this type of meeting as punishment: you failed to accomplish the task, so here’s your punishment: a meeting with senior leadership where we review a list of JIRAs. Feels like micromanagement, right?

Yeah, it does.

Let’s refresh ourselves on why this meeting exists:

1. We have a fundamental and well-communicated problem with how we are working.
2. We, the leaders, have (mostly) agreed this is a problem and have proposed a strategy.
3. Our strategy has measurable goals.
4. Given where we are in the process, our measures should have accomplished X by this date.
5. Let’s make sure that’s happening. Together.

A manager or individual who has a problem with my meeting has an issue somewhere in this list of reasons. They might be fine with the measures, but disagree with the strategy, or even if there is a fundamental problem. There might be a fundamental flaw in the strategy. There literally might not be enough time in the week to complete the work, given other priorities.

Doesn’t matter. Every week. This meeting happens. Tick Tock

For those of you still with me who are grinding your teeth because of past micromanagement scenarios that feel exactly like this. I feel you. Those are bad managers. Those are micro-managers. Those are managers who have their specific process stuck in their head, and they believe that changing their process is an admission that they are wrong, which means they will be trusted less, and everyone will discover that they are just making it up like everyone else.

A micromanager is a manager who is unwilling to listen to the collective wisdom of their team. It’s usually not because they don’t care or aren’t smart enough; it’s because somewhere along the line, someone taught them that demonstrating weakness was a character flaw.

First, listening to your team is required. Second, understanding what they are saying is essential. Third, when you change your strategy because of their feedback, you need to acknowledge it loudly.

Micromanagers might listen, but they don’t understand because they don’t change strategy. There are even worse variants who listen, understand, and change strategy, but claim it was their idea in the first place. It is your historical experience with these failing, flailing, and flawed managers that makes you hesitant to be the Consequence.

I’m the Consequence

Fact: You learn more from those who disagree with you.

Fact: The skills you develop listening to those you disagree with are more important than the ones developed by agreeing with them.

Fact: The consequence of being a senior leader is that you will not always have a concrete plan. You have a direction informed by goals and values, but your plan is built with your team. When they see you do this, you strengthen the team.

Becoming the Consequence does not mean you become a fixed point in time and space; it means that you demonstrate to the team that you understand what is essential to the health of the team, product, or process. It means you consistently and visibly reinforce this understanding. It means that when they tell you what’s wrong, you listen hard for the wisdom. It means when you find the wisdom, you adapt your plans. You do this over and over until what was a change in strategy becomes this is how we do this.

A year and a half. It took a year and a half of quality meetings for us to make our quality strategy a habit. The meeting changed drastically over the course of the months. I remember the last meeting vividly. It was the third meeting, just Directors, where we didn’t do anything except look at charts and say, “Yeah, well, the team is on it” over and over again. The work was being done habitually by the team because we all eventually agreed on how much we consistently invested in quality.

I looked around the table, nodded, and said, “Okay, we’re done here.”

(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?