AIs/LLMs are a powerful tool for engineering, but it’s often difficult for an engineering team to ‘get started’, particularly if they aren’t already familiar with it.

Around late 2025, LLM coding reached a threshold of ‘consistently good enough’. With the latest models and harnesses, it actually became a high enough quality for the day-to-day work of a brownfield system rather than a finicky curiosity or a greenfield-only accelerator.

I wrote this guide to specifically to help engineering teams ramp up adoption over time in a safe, (relatively) secure manner. This is not a guide for vibe coding - this is a guide for integrating AI into the day-to-day work of teams working on existing systems. It’s about engineering operations, process, and the work rather than the output.

Getting started

Get your team (or certain team members) set up with Claude, Cursor, or Codex on a team or enterprise account. Two key things:

• Opt out of using your company data for training

• Make sure it’s on a work enterprise account, not a personal account

I recommend Cursor for a team - it’s easy to set up, lets you switch models, and has an IDE as well as CLI capability. It’s harness is quite decent. With the rate models are getting better, having a bit of flexibility is quite useful.

At the same time - you really can’t go wrong with any of the above if you’re just starting out.

Concepts

• AI/LLM Vendor - eg. Claude, ChatGPT - they create AI models

• Agent Model - the specific model version provided by the vendor (eg. Opus 4.6)

• Harness - the program/interface that the model uses to interact with the user (eg. CLI, UI, IDE)

• Thinking vs. Not Thinking - Different models are intended for different use cases for different costs. Thinking means it takes longer / costs more but comes up with better answers.

  • If you’re in doubt, start with Opus 4.6 from Anthropic.

• Reseller - vendor that provides access to models for different purposes, they may also provide a different harness

  • eg. Cursor (IDE + CLI), AWS Bedrock (hosting + infra)

The first use cases to address

• Use AI to Explore Code

• Use AI to Review Code

• Use AI to Write Code

Use AI to Explore Code

Engineers often ask a lot of questions about the code-base:

• How does feature flagging work?

• Where is the oAuth token for the account stored ?

• Do we already have a rate limiting library?

• Can I get an explaination how background requests work?

To begin

Train your team to ask these questions to the LLM. With codebase access, the LLM is actually quite good and finding the answer or at least pointing the developer in the right direction. This will help reduce the amount of random interruptions and wait time for questions and help promote self-directed learning.

To advance

Connect the LLM into MCP / data sources like Confluence or Notion so it can search not just the code but context around the code - product requirements, meeting notes, definitions, specifications, etc.

Ask the LLM to then explore these:

• How does feature flagging work, and why did we make this way?

• Where is the oAuth token for the account stored, and what is the history of security reviews for it?

• Do we already have a rate limiting library, and did we previously explore other options?

• Can I get an explanation how background requests work, and have there been any incidents related to it?

This will help provide much better answers - just don’t forget to also add: Explore Confluence if needed. This enables you to go from What? to Why? questions.

Use AI to Review Code

To begin

Create and share a Skill to review code. A Skill is a repeatable Prompt that engineers can call for the LLM to follow.

Skills are super easy to make - you can actually just ask the LLM to make it for you.

• Write me a skill to review code. The skill should be triggered when I enter /review-code and review the currently modified code (check via git) for these factors: correctness, security, performance issues. Output a summary and recommendations.

Review it, add your own thoughts and notes, and try it out. Tailor it to your needs - conciseness, other -ilities, etc.

It should generate a file that you can then share with your team - the vendor dashboard usually has the ability to add team-wide skill commands available to everyone.

Then, teach your team to run it on their code.

To advance

Getting everyone to do something all the time is difficult. Making it automatic is even better. Some tools like Graphite or Cursor have the ability to have skills automatically run when a Pull Request is created and to add a comment.

Even if your tool doesn’t - ask the LLM to make YOU a script that you can run to run the review Skill against every new PR in a repository:

Write me a bash script that runs /review-code against every new PR in the repository `<ORGANIZATION>/<REPOSITORY>`.

For every new PR, it should launch a new agent with <AGENT_LAUNCH_COMMAND> using the model Opus 4.6 that reviews the code.

The agent should return its output, and the script should post that output as a comment to the PR.

If the PR already has a comment from the user `jgefroh`, that means it was reviewed already and should be skipped.

Make it check for new PRs every hour from 9am to 5pm.

Technical notes:
* It can check and pull for PRs using the `gh` CLI tool.
* It can write comments using the `gh` CLI tool.
* It should create a new worktree in a peer folder when pulling the branch so that the current working tree is not affected.
* It should ONLY run against repositories in the Github organization `<ORGANIZATION>`.
* It should print out links to the PR comments at the end of every run.
* It should have a dry-run mode that outputs what it would have done without actually writing the PR comment to Github.

Something like the above should produce a tweakable script that lets you then run it from your machine automatically on a schedule.

To excel

Once you have the LLM infrastructure, it’s a matter of having improving the agent’s actual prompt over time to make the reviews deeper and more valuable.

If it misses something: tweak the prompt. If it is overly-nitpicky: tweak the prompt. If you want a specific format: tweak the prompt.

Treat the review prompt almost like a Growth product.

I found it very valuable to ask the LLM to write me a quick script that pulls every single PR comment I ever wrote on the repository and extract review principles from it, and to update the review skill with those principles.

That enabled it to keep an eye on the things I like to keep an eye on:

Write me a bash script that uses the Github API (or `gh` cli) to pull every PR comment written by my user `jgefroh`.

It should put all of these in a file called comments.txt.

It must contain ALL PR comments - do not stop at just the most recent. Get ALL comments from all time.

There is a file called comments.txt that contains PR comments I wrote in a repository.

Extract a set of PR Review Principles from it that I can use to enrich a PR review skill.

Potential gotchas:

• Review the scripts LLMs produce like you would real production-bound code - I had a bug in mine where it accidentally reviewed a random PR in a random repository because the repository name was missing!

• Having everything in one skill creates shallowness. It’s good for a broad summary, but don’t expect it to catch everything. There’s a section later for using AI for things where depth matters like security audits.

Use AI to Write Code

This is obviously the most written-about topic to death nowadays - when people say AI is going to take over engineering’s job, they are typically referring to this piece (nevermind the fact it’s like 10% of the actual work).

But, it’s actually quite good nowadays at writing code. Not perfect, but much faster and definitely better than starting from 0.

To begin

Take a ticket, paste it into your LLM, and ask the LLM to create a plan to implement it. Read the plan, tweak and adjust, and once you feel confident in it, ask it to implement.

Read every single line of code it is writing. You are still responsible for the output.

Tweak the result over time. Make sure to keep an eye on common AI gotchas:

• Placement and naming inconsistencies in file, folder, classes

• Localized tweaks vs. using systematically available tools (eg. re-implementing feature flagging vs. using a library)

• Lack of production, deployment, or migration considerations

• Cross-cutting concern failures (eg. lack of authentication, authorization)

• Incomplete work (it’ll tell you it’s done, but it’s not)

Be sure you’re using a good thinking model vs. one of the fast ones.

To advance

Here’s where the expertise comes in. All of the weird above errors and gotchas? AI will repeat them over and over and over.

Truth is - it’s not automatic. Issues will occur and rework will be needed. Consider this a natural part of the process. When an issue occurs, there will be two paths:

• Fix the issue in the output and move on

• Document the issue in an agent prompt and re-run

9/10 times, you should err on the side of fixing the prompt. Over time, this will lead to a natural decrease in the number of micro-corrections you have to make.

I do this by collecting the issues in a LLM-README.md placed in the codebase and instructing the LLM to always read it before doing any work. Your LLM-README.md should contain exactly how you want it to make decisions around issues it gets wrong:

• Does it use the wrong global variable to look up a common constant? Tell the LLM to use the right, specific one in the LLM-README.

• Is scaling important in your context? Tell the LLM to always consider performance under load of 5000 RPS.

• Should it using specific libraries or global subsystems you have? Tell the LLM the list and when it should use them.

Over time, this will lead to a natural decrease in the number of micro-corrections you have to make. Your LLM-README.md is a guidance document that saves you the headaches of rework.

note: some tools already have a mechanism for this - eg. CLAUDE.md.

Example:

LLM-README.md


# Reusable systems
We have the following domain-independent reusable subsystems that MUST be used when implementing any of the below functionality:

* Feature Flagging - /feature_flags
* Exporting - /exports
* User-level authorization - /authorization
* Rate limiting - /security/rate_limits

Do not re-create the above. Always use the available subsystems. Do not make modification to the above subsystems

# Tech stack
Our front-end is VueJS 3 with the Option API. Do not use the Composition API.

## Javascript Rules
We use `import`, not `requires`.

# Convention rules
All page components that are routable must be named with a suffix `-page.vue`. 

To excel

I’m not going to lie. You’ll need other resources to excel in this regard.

While I read about people using fleets of dozens of agents across kanban boards to create simultaneous features, or developing a team of self-correcting agents, I’ve not yet found how to make any of that work for my use cases. The outputs are too unreliable, or I find them shallow, or I just don’t have the attention span to manage more than 2 streams of real development work at a time.

If it works for them - great. It just hasn’t for me so I can’t then turn around and tell you how to do that. I can only speak to what I’ve done and how it worked for me.

The one use case I did find useful was to have the AI read a pre-existing step-by-step auditing documents and iterate through it to create a set of automated end-to-end tests that emulate that process using Cypress. That worked out pretty well, but it also took the LLM a lot of trial and error and me stepping in to get it ‘unstuck’ when it got stuck in various loops. Saved me time because I could do something else while it was doing it, but it was like a 4-5 hour process for a couple of end to end tests.

Other considerations

Project AI/LLMs budget and cost for engineers

AI is typically billed as usage-based. It really depends on how much your team uses and adopts it, but at current prices, I’d estimate:

• Early adoption < $50 / engineer, average - with a couple of spikes

• Wide, consistent usage - ~$200 / engineer

• AI-native usage - $1000+ / engineer

Prices will differ based on usage, optimization.

Don’t let the prices turn you off. You CAN get much higher ROI from initial input costs, and it’ll take a while, if at all, to get to AI-native usage if you’re reading this guide. You’ll likely end up closer to the $100 - $200 / engineer range by the time you get full, consistent usage adoption.

During adoption phase, you don’t really want anyone on the team to worry about costs unless money is super tight. What you want people to do is explore without anxiety over limits. You can teach optimization later.

A key note: AI prices are likely to increase. It’s heavily subsidized right now. I wouldn’t be surprised if it increases 10x in the future, but take advantage of low prices while you can.

Secure AI/LLMs for developer machines

AIs open up a massive pathway of potential attacks if used without guardrails. Ensure you and your team understand the potential consequences:

• Destructive actions - it can randomly delete things it has access to, including production databases and files

• Malicious actors can convince it to do things like send your credentials to them or even download files and run random commands (prompt injection)

The key thing to note from a developer security side is the Deadly Triad. If the LLM has all three simultaneously, it should be considered a fairly high risk environment for prompt injection:

• The LLM has access to send out communications

• The LLM has access to user input

• The LLM has access to sensitive information

The problem, of course, is a developer environment usually has all 3 by default:

• Developer machines are connected to the internet and has access to CURL, DNS, and other tools, and usually on an elevated access account. [send out communications]

• Developers often like to connect to ticket systems and error reporting (eg. Jira, Sentry) which has user input. [user input]

• Developers have at minimum access to the codebase and local credentials, as well as potential production access [sensitive information]

This makes securing a developer machine particularly tricky. While LLM vendors try their best to prevent these attacks, it’s still succeeding at a 1-8% rate depending on the study.

The easy go-to is to prohibit connection to systems with direct user input (much to the dismay of your team) as a first-line defense. That means no automatic ingestion of Sentry, Jira tickets, etc.

This isn’t fool-proof, but it at least decreases risk levels. If you have resources, you can also have a separate AI-specific laptop that has hard controls against infrastructure connectivity at all as a second layer.

The risk here is non-zero, but also relatively low - use a context-appropriate risk assessment.

Guiding AI agents with prompts

Writing an effective prompt is an entirely different article in its own right, and it also differs per model and model family.

If your team is new to AI, it’s helpful to go over the fundamentals. I have deeper guidance on the fundamentals of prompting in another article: AI/LLM Prompting for Beginners.

Generally though, as you write prompts for guiding the LLM for coding purposes:

• Don’t describe what the code is doing. Describe the context of how you want the architecture and code to be used and created. The AI can find out what the code is doing quite well. It can’t interpret the context or intent.

• Keep your prompts relatively precise. Try to avoid mixing 100 different requests into a single prompt. Asking an LLM to create a dashboard for one feature AND a new API endpoint for another feature AND a report for a third will just confuse it.

• Ask your LLM to plan. Coding LLMs are quite good at planning, and spending 10 minutes in ‘plan mode’ shaping the plan by going back and forth conversationally with the AI will save you tons of headaches during implementation.

• Apply global corrections globally. If an LLM is messing up consistently for you in one area, it probably is for others - that’s a good signal to raise it to the team to add to the LLM-Guidance.md for everyone.

Depth vs. Breadth

One important note about LLMs is the more separate instructions you give it, the more shallow it will be. Suppose you’re creating an LLM prompt to do a pull request code review and want to check:

• Scaling, security, naming, correctness, and edge case spec coverage

You can put all of these separate considerations into a single prompt and have an agent run that prompt against code and get good results.

However, if you’re working in conditions where that review really, really matters (eg. very important code), it’s better to separate each one into its own prompt and Agent.

What that means is to write different prompts for each consideration, asking it to output a formatted report:

• A separate prompt that specifically asks the agent to investigate all manner of scaling concerns, being particular about evaluating load

• A separate prompt that specifically asks the agent to investigate all manner of security concerns, being particular about tracing code

• …etc.

Then, you run each of your individual prompts using a new, fresh agent per prompt against your pull request. You can collect the results and have an LLM stitch them together verbatim at the end, or have them post separately.

You will get much, much deeper results because the LLM will not get as confused. This is especially useful for creating security auditors.

I once made a script + LLM audit prompt that ran a separate agent through every single endpoint for a legacy system individually looking purely for endpoint security considerations. It found several hundred real vulnerabilities of all kinds, including nearly a dozen critical ones vs. my shallower attempt which found < 10 low ones. Because of the way it was written, I was also able to get it to write patch steps automatically, providing the team a way to remediate issues immediately - all for just $0.90 / endpoint.

This approach works well for any work, not just code reviews, where you need depth.

Adoption advice

Start small. Don’t try to make your codebase LLM-friendly overnight. Start with just a single LLM-Guidance.md document and add to the rules over time.

Minimize infrastructure. If you’re just getting started, don’t try going through hoops setting up a bunch of infrastructure. You can get a lot done with just a single developer running Cursor.

• eg. a developer can just run gh Github CLI locally and post as themselves vs. trying to get their admin to approve an organization-wide integration.

Use what you already have. You don’t have to reorganize your entire knowledge store to make it usable by LLMs. LLMs can follow links - if you have documentation like Confluence, point it at the docs. Even if you just ‘copy-paste’ it, it’s better than nothing.

Introduce the basics. You really have to help people along sometimes, and that’s OK - especially for a new technology.

• Make a powerpoint with step by steps on setting Claude, ChatGPT, or Cursor up (or better yet, ask AI to make you one)

• Do a team-wide demo of various use-cases like completing simple tickets or asking cursor questions about the code. Do it in real time.

• Start an AI knowledge share channel for folks to ask questions in real-time (you can pivot them to ask the AI later)

• Show people what it can do to create ideas.

• Share skills and prompts with the team.

This is just the start. You’ll open up a world of other opportunities as you increase adoption. Think about things like:

• Can you use AI to do security audits against your codebase? (yes)

• Can you use AI to answer questions from your team like you would? (yes)

• Can you use AI to give daily updates to stakeholders? (yes)

• Can you use AI to create internal-use tools? (yes)

• Can you use AI to automate other processes? (yes)

Just remember: AI is a power tool. You don’t want people running around with chainsaws! Move forward safely.

Gefroh is a product and engineering executive in Kirkland, Washington currently leading various AI adoption efforts. He’s created AI versions of himself at his current company, and has done all of the above.

Humans are amazing pattern matchers. We’re great at detecting when something is just…off.

That’s how I feel about almost all Reddit posts nowadays. It feels like 80% of reddit posts and comments I read are just AIs talking to each other.

It’s not just the —, it’s the sense it’s not a real person.

Honestly? AI has a strangeness to how it writes that creates smells. You can detect it with some basic tricks.

Curious if you’ve seen the tells, too?

The tells

Many human-written posts contain these naturally. However, the tell comes from the fact that most human posts do not contain many of these at the same time, consistently across posts / content.

Words

AI loves to use specific words.

• Substrate - I’ve gone my whole life hearing absolutely nobody use this word, and now it’s everywhere.

• Curious - Nobody is that curious to use this word so often.

• Resonates - Not everything in life is deep and meaningful unless you’re a robot

Phrases

They also like using these phrases a lot:

• “It hits hard…”

• “Here’s what actually happened”

• “Rare to see <X>”

• “The wild part”

• “You weren’t imagining”

• “Nobody warns you…” / “Nobodys talking about”

• “What kills me…”

• “The funniest part”

• “We need to talk about”

• “The real issue is”

Structure

AI has some specific structures it gravitates towards.

• Staccato sentences.

  • “This is <X>. That is <Y>.”

  • “Not <X>. Not <Y>. <Z>.”

  • “Just <X>, <Y>”

• Lists - particularly if they start with bold.

• Removal of the subject from a sentence.

  • “Left the station yesterday.” vs. “I left the station yesterday”

• Comparators and Metaphors

  • “not <X>, but <Y>”

  • “<A> was <X>. <Z> is <Y>.”

• Odd pause insertion in written content

  • “Sometimes I just…. <X>”

• Sometimes - all lower-case - some people have prompted to try and sound more human

• Examples in triples or quads.

• Varied but predictable sentence lengths “<Sentence>. <Short fragment> <Shorter fragment>”

  • eg. “I talked to all of my team that day. Some were mad. Most curious.”

Intents

LLM-written content often does what I call overframing - prepping the user before the primary content that isn’t contextually necessary for the situation.

• Trust-building framing

  • “Honestly…”

  • “Genuinely asking….”

• Buttering-up

  • “That’s rare.”

  • “The <X> is real…”

  • “Exactly this”

  • “Good point”

• Positioning as authority

  • “Sharing what actually matters…”

• Circumventing objections

  • “You’re right to push back…”

  • “You’re not wrong…”

• Offering engagement

  • “Happy to <X>”

Oddities

Weird, out of place metaphors and comparisons. AI likes to insert examples that people wouldn’t draw comparisons towards naturally

• “The dog looked at me like I was a fish”

Categories

I’ve noticed a few categories of written content that have tell combinations:

Engagement-bait

These posts seem to want to generate engagement - some tells:

• Attempts connection

  • “Curious if anyone else…”

  • “Am I the only one…”

• Requests honesty

  • “Just looking for genuine takes”

• Ends with an engagement prompt

  • “Curious if…”

  • “If I may ask….”

  • “How are you…”

Fake engagement

These posts just seem to be generating engagement:

• Give kudos

  • “Glad you’re doing <X>”

• Often ends with a statement or question:

  • “Do you notice <X>”

Ads

Many of these posts are just trying to sell something. Some are up-front and have appropriate disclaimers. Others are stealthy - they do it by casually name-dropping it in the post alongside other better recognized names.

For example, you’d see a post on “AI Workflows” that mentions popular tools like n8n, Claude, etc. and then see a random product casually name-dropped in the middle as a core part of the workflow like “potato-ai for cleaning up”.

It positions the product as a peer or equal in relevance to the other listed items.

News sharing / Info sharing

Someone shares knowledge or news to present themselves as an expert, sometimes accompanied with an ad.

• Factoid along with a personal impact.

  • “<X> just figured out <Y>. You’re <Z>.”

• Description about why it is mind-blowing.

• Unnecessary levels of detail to establish credibility.

• Opinion.

Examples

Many of these posts exhibit the tells from above. While it doesn’t prove it was AI-generated or edited, enough of them creates a ‘smell’ where I don’t even bother reading it anymore.

These aren’t all the tells. As AI and prompts evolve, it will rapidly change. But once you see it, you can’t unsee it, and you start to realize that a lot of the internet might just be bots talking to bots.

Gefroh is product and technology executive in Kirkland, Washington that writes about leadership, management, operations, and AI.

In the age of AI, the Product Manager role is rapidly shifting in expectations.

It’s no longer enough to do some market research and toss it over the fence (though, honestly - that has never been enough).

Instead, there’s higher demands:

• Visual evidence in the form of functional prototypes

• LLM-friendly documentation and breakdowns

• Further specificity in details - use cases, edge cases

Product Manager should identify how their role is changing, and more importantly - what they can do to accelerate their efforts.

This article is part of my series How to Become a Better Product Manager, which teaches the deep fundamentals of product management.

Basic LLM Usage

LLMs as a Pair of Eyes

As Product Management scope increases, so does the broader awareness required to keep abreast of changes. There was a time where I was in 300 Slack channels across my scope, monitoring the conversations - it was exhausting.

LLMs saved me tons of time here.

If your company allows it, you can use LLMs to raise awareness of things happening in the company. For example, Claude connected to Slack and Confluence means you don’t have to actively be in a Slack channel or watching Confluence activity like a hawk to identify whether something needs your attention.

A few prompts I like to use:

• Search Slack and Confluence for every decision made about Project X that I wasn’t involved in.

• Search Slack for any confusion, questions, or defect reports for Product Y that arrived today.

The more data sources you attach, the broader the scope of search.

LLMs as Synthesis Engines

There’s a lot of documents and knowledge we have to both absorb and impart as product managers.

LLMs are great for this.

Use LLMs to summarize and synthesize. Meeting notes are a good candidate, as are documents - you can have it add a summary at the top of documents you create.

Tips:

• Tailor for your audience - “write a concise summary for engineers” will lead to a very different level of detail than “write a concise summary for executives”.

• Proof-read it. LLMs can make mistakes - don’t just ask it to summarize and smack it on your document. Actually read it.

• Edit it. LLMs can write long, flowery prose. Make the summary concise, even if that means repeatedly telling the LLM “make this more concise”.

• Ask it source. LLMs can tie its claims to specific parts of the document, which makes it easier to verify.

LLMs as Interpreters

Product Managers aren’t typically experts in engineering. That’s OK - they aren’t expected to be (at least, not yet).

However, it does mean there’s a communication gap. When an engineer speaks to tradeoffs and talks about how the replica write latency would prevent real-time querying of the chart data and the primary IOPs capacity wouldn’t handle the load of the feature, it’s easy to just accept it and move it.

Well - LLMs can help you understand and translate what all of that means.

Pop a message into the LLM and say “translate this for me in terms a non-technicalperson would understand”.

It deepens your understanding and more importantly allows you to engage further - perhaps there’s clarity or adjustments you can provide to remove the problem, or maybe you might gently push back and find that the engineer is making a mistaken assumption that renders the problem moot!

Intermediate LLM Usage

LLMs as Thought Partners

As Product Managers, we have to think about a lot of different things - use cases, positioning, strategy. It’s easy to forget something or not have the fullest understanding, particularly in a new area.

Fun fact - LLMs can help you think through product use cases.

Suppose you’re developing an Impersonation feature for internal users. Ask some basic questions:

• List common use-cases of Impersonation features.

• How do competitors implement this?

• What are the risks?

• What is a small slice of functionality that can be implemented?

• What potential edge cases and bugs can occur?

Once you ‘form’ your thoughts, you can then ask the LLM to list them in a use-case friendly way:

• Take the above and turn it into an itemized requirements list, organized by Happy Path, Edge Cases, Scoped Phases.

As always - edit, proof-read, and verify. Don’t just toss it to engineers - you must not be responsible for slop. It’s a good starting point, not the end result.

LLMs as Visualizers

There’s nothing quite like seeing something in front of you vs. reading a wall of text to truly understand it.

LLMs have empowered Product Managers to visualize their approach and thoughts in several ways:

• Creating diagrams of workflows and userflows

• Creating design mocks and wireframes

• Creating actual click-through prototypes

You can use tools like Figma Make, Claude Design, and Gemini Stitch to rapidly create mocks and prototypes to show how you think something should function. If that’s not available, your basic LLM can just create a Mermaid diagram.

It doesn’t have to work, it just has to show.

Advanced LLM Usage

LLMs as a Personal Analyst

LLMs can help you analyze data. If you’re fortunate enough to have query access to a subset of data, you can ask the LLM questions about your data and get it to answer.

• “How many user signed up yesterday and didn’t log in today?”

• “How many sales did we make in Turtle County last year?”

Even if you don’t have a direct connection of the AI to a data source, you can still benefit by asking the LLM how you might query the information.

For example - suppose you have a access to a subset of data to query against, but you don’t know SQL. You can ask the LLM:

• Write me a query to find this fact <fact> from these tables <schema>.

• How do I query for the active user count?

The LLM will spit out a probably syntactically correct query you can then apply to your BI tool.

Caution - syntactically correct does not mean semantically correct. There’s a large nuance in data columns - often, as code evolves, the meaning and intent of a data field changes. For example - perhaps “Created At” on the “User” record used to mean the timestamp the user account was created at, but now there’s a new field called “signed up” that contains the actual sign up timestamp because of a mass auto-migration. Situations like this are not captured in syntax and LLMs have no way of identifying these changes. The lack of a Semantic Model means you should always double-check your results with someone familiar with your code for important cases. Don’t just trust the query the LLM returns. Gut-check everything, at minimum - AI is often wrong with data.

LLMs as a Personal Developer

There’s a lot of situations where as a Product Manager you have to go and ask the developer “how does this really work under the hood?”. You file a ticket or pop over a message and a couple hours to days later, the engineer will provide you the answer.

If you have access to the codebase, you can use the LLM to answer these questions for you.

Ask the LLM:

• “Explain precisely like I’m non-technical how each of the numbers on the bar chart on the /charts page is calculated.”

• “When a user logs in, at what point is the drip campaign for onboarding sent?”

These can compress the wait time dramatically and avoid having to bother an engineer to find the answer for you.

LLMs as a Builder

One of the most advanced forms of incorporating LLMs is the Product Manager builds the feature using LLMs - ie. vibe coding.

This actually works great for smaller-scale startups or less constrained environments. The speed of a subject matter expert translating their thoughts into working product is unmatched.

However - it’s far too much risk in areas where compliance, scaling, or security matter. Vibe Coding doesn’t typically address these cases at all, even if the AI swears to you it does.

Caution - in many cases, what you see is only 10% of what you need. 90% of the work is things like cross-cutting concerns, authentication, authorization, security, scaling, observability, safety, testing, validation - so called ‘ilities’ that vibe coding won’t get you. Don’t just assume it’s 90% done once you see it working.

If the codebase is effectively set up for safe vibe coding (chances are, it isn’t), then you might be able to do risk-appropriate development, but 99.99999% of codebases are not. Leave the truly important stuff to the actual engineers.

Expert LLM Usage

LLMs as a Digital Twin

If your decision-making stems from a consistent set of applied principles, LLMs lend themselves well to creating a digital twin of yourself.

Imagine: people can ask you questions and your “twin” can go and answer them, working from the first principles you set.

For example - if you are all about speed to market - make a skill that encodes that principle.

Create skills that people can use to get your ‘first take’ without ever having to talk to you. Of course, this doesn’t remove you from the process, but it does provide rapid first-passes that can help catch early issues.

Better yet - it helps people refine their own thinking over time.

Curating Context for LLMs

The most expert outcome is that you start to curate knowledge within your product domain in a way that LLMs (and people) can easily consume.

You maintain the repository of facts and context and history, and create the mechanisms by which an LLM can access and know about it. Other people can leverage that documentation (with our without an LLM) to ensure they are making effective product decisions within that space.

Is this technically replacing yourself? Yes, but in the best way: it frees up your time to expand your contribution to more strategic areas.

Start a wiki where you consciously and precisely articulate the facts and product context around your domain, then ensure people point their LLMs towards it.

Caution

A word of caution: if you abuse the tools you will create more work for little value.

AIs are verbose. If you give an engineer a document with 500 words that could’ve clearly been explained in 10, you are wasting that engineer’s time. Always ensure conciseness and precision - every word matters.

AIs make stuff up. AIs will make stuff up. If you provide a document that has clearly wrong information, people will lose trust in you, and you’ll create issues downstream when the wrong things get implemented.

AIs will not tailor completely for your context. You can provide context all you want, but AI will not fully understand every single thing there is to know about your context or company. Evaluate its decisions - is that use-case that was generated actually relevant to the specific goal you’re trying to pursue? Does that feature really need that guard in the environment you’re in?

AIs can be overly detailed. AIs can toss in a lot of irrelevant detail for a document - architecture and implementation in a product use case document, defect remediation steps in a Go To Market alignment document. Remember the audience and purpose of a document - don’t just dump what the AI wrote.

You’re always responsible for the output of AI. Always.

LLMs don’t replace your thinking, but they can help accelerate it, broaden it, deepen it, and create space for focus. Use it effectively!

The world of Product Management knowledge is filled with vague advice or overly rigid frameworks. It’s simultaneously overwhelming and underwhelming - you have to contend with jargon from frameworks like RICE, Kano, SAFe and approaches from influencers stating ‘this is right’, ‘this is wrong’ while at the same time interpreting vague values advice like ‘move fast’ but ‘think deeply’.

At a fundamental level - Product Management is about making good decisions across a portfolio of bets, executing on them, and observing their effects. That’s it. All the frameworks aren’t really needed if you start from fundamentals.

This series is intended to teach you the fundamentals of being an effective Product Manager:

• On managing risks - a series on the fundamental risks every product manager should consider

  • Value risk

  • Fitness risk

  • Impact risk

  • Adoption risk

  • Cost risk

• Know how to synthesize - even in the age of LLMs, a good product manager can concisely synthesize information

• Analytics and instrumentation - a good product manager knows what to look for in metrics and how to interpret them

• Articulating assumptions and acting with intention - a good product manager can break down problems and solutions into its incremental parts

• Avoiding overfocus - a good product manager has both focus and systems-level thinking

• Leveraging AI and LLMs effectively - learn how to use LLMs to supercharge your product management

“You need to be more strategic”

It’s feedback a lot of people receive as they try to move from middle management to the executive level. Yet, few can define what it actually means or entails.

Is it an innate talent, or some magic “X”-factor?

No. Being strategic can be taught and learned. It requires learning new ways of approaching problems, changing your mindset, and a bit of unlearning of the things that got us to where we are now. It requires picking up a few hard-skills and learning some very hard soft-skills.

Whether it’s analyzing problems, speaking the language of the business, or improving your bearing - the skills of being strategic can be taught.

This is my series on being strategic, where I share my advice and thinking behind strategy - perfect for senior managers and directors who are attempting to move beyond operations and into strategy.

• What’s Not Strategic? - address common misconceptions and understand what strategy isn’t

• How to Analyze Problems - learn how to deepen diagnostic depth and through intentional problem analysis

• Improving Executive Presence - manage perception by unlearning some successful management behaviors that otherwise harm executive perception

• Think strategically in everyday work - find opportunities to exercise strategic thinking in your current work to get invited into the room where strategy is made

Gefroh is a product and engineering executive in Kirkland, Washington currently working in the healthcare space. He writes extensively about leadership and strategy on his blog.

Feel free to connect if you have questions or just want advice!

As a product manager, you have to be able to articulate, separate, and define your risks - the potential negative effects of whatever you are trying to do. Articulating them helps you frame and compare them appropriately - ignoring low risks and mitigating higher ones.

These are the levers you use and the plates you balance as a product manager to create and deliver value.

This article is part of my series How to Become a Better Product Manager, which teaches the deep fundamentals of product management.

Understanding the risks

There are many, many ways to break down risks. You can start with some of the obvious risks:

• Value risk

• Fitness risk

• Impact risk

• Adoption risk

• Cost risk

Value risk is that your solution doesn’t create value for anyone.

Fitness risk is that your solution doesn’t actually solve the user’s problem.

Cost risk is that your solution costs more than expected.

Impact risk is that your solution doesn’t have the expected impact.

Adoption risk is that your solution isn’t used by users

Evaluating risks

Evaluation of risks is an exercise in methodology and tradeoffs.

In short:

• How probable is this risk?

• How damaging are the effects of this risk?

• Should you reduce this risk?

• Are you leveraging the right tool to address that risk?

How probable is this risk?

There’s a chance a meteor will hit your office building tomorrow. That doesn’t mean you should put resources into an extremely detailed meteor contingency plan.

Some risks are low probability “black swan” events. If you have limited resources, chances are you shouldn’t invest heavily in avoiding them. Sure, you should think about the probability and have a general backup plan, but unless it’s a business critical event it might be worthwhile to keep that in the land of theory.

How damaging are the effects of this risk?

If the negative impact of a risk is extremely low, then it might not be worth putting in the bandwidth or resources to mitigate it ahead of time. In these cases, it’s better to deal with the negative effect if it happens, and move on.

If a risk has extremely high negative impact, but you can take actions to reduce the negative impact or make the negative impact more recoverable, then you can still change your risk profile without mitigating a risk entirely.

Should you reduce this risk?

Fun fact - product managers shouldn’t be trying to mitigate or control for every single risk. To do so would lead to a standstill in decision-making and a tremendous amount of effort for rapidly diminishing returns.

Instead, you want to take appropriate risks, balancing probability and negative impact with the expected value.

It’s all about risk management and balancing the risks and tradeoffs to achieve an appropriate risk profile.

Are you leveraging the right tool to address that risk?

This is a common problem I see a lot of product managers make when they over-index on a particular form of risk.

Risks have different ways of being addressed. Depending on the problem you are expected to encountering, you may have a different approach available to you than directly addressing that risk. In fact, you may not want to address that risk specifically, but rather target another risk that has a tangential, secondary effect on the risk you originally wanted to address.

Imagine a product manager who, fearful of experiencing adoption risk, continues adding more and more scope before they release. Their attempt to reduce adoption risk (the risk that users don’t use the product) actually increases the cost risk.

Mitigating risks

When evaluating, you must know which risk you are attempting to address. Each has a different strategy and relationship with other risks. For example, for the above risks mentioned earlier:

Impact risk

• Understand your metrics hierarchy, outcomes, and drivers

• Be realistic about sizing and adoption

Value risk

• Be sure you can follow the cause-effect chain back to the user’s intent or problem

• Understand what the user is actually trying to do, with or without your tool

Cost risk

• Reduce the scope to reduce cost

• Do deeper feasibility assessments and spikes

• Avoid over-investing without incremental validation

Adoption risk

• Ensure your users know it exists

• Make sure it’s usable

• Instrument it

Impact risk

• Avoid one-way doors

• Release to a small subset of users

• Make the negative effects reversible

• A/B test to measure impact

• Be ready to roll it back

These aren’t the only risks, nor are they the only mitigations you can apply.

Your risk framework needs ROI

You need to treat your risks like a product. You can’t spend weeks managing risks if the cost can be measured in minutes. Your risk framework and process needs to be aligned with the potential negative impact. There’s a cost vs. value calculation even to risk management.

Avoid analysis paralysis and ensure you don’t become a bottleneck - a lot of product managers get this wrong, over-indexing on all potential negative cases - it’s OK to be wrong sometimes. Product management is about managing a portfolio of bets - some are not going to work out.

The chain of command is where you get your authority as a manager. It’s the formal authority that you’ve been granted by your company to execute towards its desired outcomes.

Yet, many inexperienced managers completely disregard it whenever they disagree with their boss. They chain jump - going above their boss to get their problem solved instead of working within the confines of the authority structure.

In smaller organizations, this is actually fine - it’s baked into the authority and decision structure, and the relatively small size enables the chain to be more of a network. However, as the organization grows, this structure start to fail and causes a cascade of issues. Hierarchy becomes more important to ensure the company continues remaining effective.

Chain jumping creates a lot of organizational dysfunction - companies simply can’t operate effectively if every decision is being second-guessed. At lower levels, this may result in minor mistakes or wasted time, but at higher levels jumping the chain could cause catastrophic alignment issues.

What you’re actually doing when you jump the chain

When you jump the chain upwards, you’re indicating that a complete breakdown of trust has occurred in your relationship with whoever you are bypassing. If you’re in a half-decently run company, this is a bad thing.

It’s strongly frowned upon by every leader I have ever talked to and only the most patient of bosses will tolerate it.

It’s considered the nuclear option for a reason - either you’re absolutely 100% right and in full alignment with your boss’ boss, or you’re out of a job because you’ve dismantled your relationship with your boss with a single action.

How do you successfully jump the chain?

For you to chain jump successfully, a lot of factors have to be true:

• The issue has to be critical to your boss’ boss.

• The issue has to not have been visible to your boss’ boss.

• The issue has to be in complete disagreement with your boss and your boss’s boss.

• The issue has to be so egregiously violative that it breaks the trust between your boss and your boss’s boss.

Outside of unethical or illegal actions, a loss of integrity, company-ending risks, whistleblower scenarios - very, very few items will meet this criteria. If you jump the chain without all four - you run a massive risk for very little organizational benefit.

The issue has to be critical to your boss’ boss.

Your boss’ boss is dealing with a set of problems you aren’t even aware of. They have tradeoffs, risks, and decisions that they manage. They’ve entrusted a segment of their problems for your boss to handle on their behalf.

If you bring up an issue that’s irrelevant to them in the grand scheme of what they are dealing with, then you’ve turned something they’ve otherwise been able to ignore into, at best, an annoyance they have to deal with. It’s not likely they’ll view it as something even worth investing their time in, if not for the fact you brought it up to them.

They have higher leverage activities, and are likely to view you bringing up things as a waste of their time if it’s not critical to them.

The issue has to not have been visible to your boss’ boss.

It may or may not be a surprise - but your boss and your boss’ boss communicate with each other.

It’s quite possible that your boss’s boss already knows about the issue exists and otherwise trusts your boss will handle it. If they had a strong opinion, they likely would have aligned with your boss already.

It has to come as a surprise - something that your boss was actively hiding or that wasn’t visible to your boss’ boss.

The issue has to be in complete disagreement with your boss and your boss’s boss.

Your boss and your boss’s boss are probably in closer alignment than you can see. If you disagree with your boss’ strategy, but that strategy was already aligned with your boss’ boss, you’re basically telling your boss’ boss you disagree with them, too.

Whatever issue you chain jump has to ensure that there is ultimately a misalignment you are bringing attention to. Otherwise, you’re the misaligned person in the chain, not your boss, and you should introspect on that.

The issue has to be so egregiously violative that it breaks the trust between your boss and your boss’s boss.

Your boss is your boss for a reason - your boss’ boss authorized them to have authority on their behalf. This doesn’t mean they always agree. Sometimes your boss will approach a problem with a different perspective and solution than your boss’ boss will.

Even if your boss’s boss disagrees with your boss, your boss’ boss may happily give them the autonomy to try it a different way.

The issue you chain jump for has to be egregiously violative, not just a disagreement or something with less than ideal outcomes.

Otherwise, trust comes into play and your boss’ boss may trust that your boss will achieve the desired outcomes, even if done differently or with less perfection than you may personally desire.

How do you best frame your chain jump?

You’re going to need a lot of tact in the delivery.

If you go in heavy ranting against your boss, you’ve lost - you’ll be perceived as irrationally biased, and you’ll immediately torpedo any trust in yourself.

If you go in arguing passionately against a decision, you’ve lost - you’ll be perceived as a single-issue or overly emotional person and your future concerns won’t be taken seriously.

The best way to approach it is to remain factual, remain open to being wrong. Frame it as raising awareness or getting context, not a disagreement or misalignment. Be prepared with data, evidence, and details. Be honest with what you know and don’t know - acknowledge you may not have the full picture - because you may not.

Ensure your boss and your boss’ boss know either way that you’re going to execute whatever decision is made to the best of your ability.

Try to give your boss an out - “it’s possible they’ve already considered this” is a lot better than “they aren’t aware of it at all”. This is especially important if you end up being wrong - it’ll ensure that your boss knows you didn’t also question their competency and help preserve the relationship.

Always ensure you tell your boss first and after. Give them the opportunity to address your concerns, and then provide them a specific update afterwards as to what you discussed and with who so they can understand the context - this can go a long way in ensuring that even if there’s a disagreement, you’re still preserving trust.

What happens after chain jumping?

So, let’s suppose you jump the chain. You meet your your boss’ boss and give them the details of your disagreement with your boss (their report). You explain the who, what, when, where, and why. You present the entire scenario and why you think your boss is wrong.

Your boss’ boss thanks you for bringing it to their attention and ends the meeting.

What happens after?

Well, the first thing your boss’ boss is going to do is reach out to your boss and give them all of the details.

If your item didn’t meet the criteria of the above, the only directive to your boss’s boss would be “let me know if there’s messaging you want me to reinforce”. That’s it. Your boss and your boss’s boss are fully aligned, and you just torpedo’d your most important relationship at the company.

If you brought up an issue that met one or two of the criteria above. In that case, your boss and your boss’ boss may have a sidebar. They may discuss the situation, see if that decision needs to be re-considered in light of the strong feelings. Maybe, maybe not.

In any case, there’s an alignment - either a reinforcing of the current position, or an adjustment. In a best case scenario, you may get your way - maybe your involvement was enough to tip the scale. However, the end result is still the same - you just destroyed your relationship with your boss.

If you bring up an issue that meets ALL of the criteria, above, it might work differently.

There might be a serious discussion, other leadership might be called in to discuss the situation. I’ve even seen outside personnel pulled in to conduct investigations. In these cases, your best case scenario is your boss gets replaced with someone else.

However, in many cases, a realignment might occur - you might get your way, but the chain of command remains the same.

Why you should be judicious on jumping the chain

There’s quite a few reasons why you should not jump the chain:

• You’re usually at an information disadvantage

• You can usually solve your problem by just talking to your boss

• When you win, you probably still lose

You’re usually at an information disadvantage

You boss and your boss’ boss are privy to information and context you don’t (and probably shouldn’t) have. They evaluate decisions based on factors outside of your visibility and scope which may influence and outweigh the specific tradeoffs you can factor.

Unless you know the specific criteria your boss’ boss is evaluating their decisions on, you may actually be arguing based on tradeoffs they don’t even care about.

I’ve had reports jump the chain to argue about decisions I’ve made based on an increased cost when the directive from my boss was “I don’t care how much you spend to get this done.” It’s not a good look for the chain jumper when they didn’t even bother to get the context of the decisions being made.

You can usually solve your problem by just talking to your boss

If you’re worried about a decision or problem, in most cases you can just ask your boss about it. In many cases, they’ll give you additional context that makes you go “oh wow, yeah, that totally makes sense”. In the situations they can’t, they may tell you outright “this is privileged information I can’t provide” in which case - accept it and move on.

Sometimes, you can provide additional information that makes them change their mind. Even if they don’t, you can get acknowledgement they’ve considered whatever you’re worried about. This is a much better outcome - you collaborate with your boss on achieving a better outcome vs. bypassing them.

The way you ask is important - you don’t want to come across as demanding justification for their decisions. Frame it as attempting to learn, improve, and understand context. When you do get an answer, be appreciative.

Even when you win, you probably still lose

Even if you jump the chain and get your way, you’ve now soured your relationship with your boss. Unless they’re an incredibly patient person (which, most are not), you’ve essentially shown yourself to be untrustworthy within the context of the authority structure - not the best if you’re trying to advance in the organization.

Final thoughts

Think carefully about when to jump the chain. Reserve it for the most serious, important, company impacting concerns. If you ever chain jump for frivolous reasons, or without full context, or do it poorly, all it does is make the company lose trust in you - particularly in situations where a simple conversation with your boss would’ve solved the problem. Make sure it’s worth it, and that you exhaust all of the other options first.

LLM prompting isn’t some mysterious dark art or difficult to learn skill.

AI models are, at their core, probabilistic prediction engines. Every response is the result of the model calculating the most likely next word, billions of times over, based on information you've given it.

Even LLMs that take action or think deeply are just that - they respond in ways that commands can be executed to take action, or they self-review their own approach for a few rounds before giving you the actual answer, but it’s all still probability.

That means you can shape those probabilities in your favor with just a few key words. The more clearly you communicate what you want and don't want, the more you narrow the field of possible outputs toward the one you're actually looking for.

Think of it like chiseling away at a stone representing all the possible responses until it takes the shape that you want.

This guide is a basic primer for anyone just getting started. No jargon, no complex frameworks - just practical techniques you can use right away to get better results from any AI tool.

A quick primer on how LLMs work

LLMs predict the next word in a sentence based on the previous words you’ve provided - the ‘context’. Let’s use a very simple conceptual example.

Suppose you asked an LLM to fill in the blank of a phrase:

“The color of the dog is ”

It’s likely to produce a sentence “The color of the dog is brown” because its training data suggested the most likely word to complete that sentence is “brown” or “black”.

However, you can make it predict a word you want to see by nudging it with additional context. Suppose you told it the name of the dog is Clifford:

“The color of the dog, named Clifford, is ”

It’d be more likely to say “red” because you’ve now associated your desired end state with the word “Clifford”.

In its training data, there’s an association with the word “Clifford” somewhere in its data. The word Clifford is associated with other words like “giant”, “red”, and “dog”.

The strength of this association can be variable. It’s a probability, after all. It can be overridden by other words that change the probability. For example, by adding additional context that the dog is tiny, it might just be enough to weight the probable next token back into the more common space:

This example is made up - but you can see how context - additional words, can help produce a different result, and that context can also cause it to cancel out other influences from other words.

Being able to figure out what the words to say to get the result you want from the LLM is called ‘Prompting” or “Prompt Engineering”.

Now - on to the tips!

If you’re just getting started: just ask and chat

Seriously - just talk to it like a person. Consumer LLMs are built to engage. Pretend you’re texting a really knowledgeable friend and ask away. Let the conversation go somewhere.

The best way to learn prompting is to try it and see the results. Ask for what you want. Correct it when it doesn’t quite give you what you want.

Give commands

Once you’re ready to get more specific, you can start to give instructions and commands.

When you ask a question, you’re really leaving it up to the AI to decide what to do. However, if you want it to perform a specific action, you actually need to tell it what to do.

“What has Hugh Laurie been in recently” might cause the model to look at its knowledge which might be outdated. “Search what Hugh Laurie has been in recently” tells the model to look at the internet for recent data.

Likewise, telling gives you the ability to constrain what the AI does, which is a key part of AI prompting.

Provide constraints

Remember that AI is a guessing machine - it’s guessing for billions of possible combinations of words for the next word to show you.

You can provide constraints in your prompt that reduce the amount of probable words by focusing its attention on the kinds of words you do want.

Confused? It’s easy to apply in practice even if you don’t understand it. You can constrain by:

• Telling the AI what you don’t want:

  • Give me a recipe for apple pie without sugar

  • Give me the amount of money it takes to buy a Lambo. I don’t want used prices.

• Telling the AI what you do want:

  • Give me a no-bake recipe for apple pie

  • Give me the name of a book with a dragon on the cover.

The more specific and precise you are with your prompt, the more specific and precise your answer will be.

Provide descriptors of what you want

Sometimes you might not be able to articulate exactly what you want. You might just want something.

Even providing a list of adjectives helps guide the AI, or even adjacent descriptors.

• Make the presentation design apple-esque - sophisticated, refined, minimal, space-efficient.

• Make the first page of the presentation bold, unmistakable, attention-grabbing, title card, spy movie.

Provide the exact format you want

The ultimate form of specificity is being explicit about what you want the output to look like. LLMs are built to be conversational, so a lot of their responses are quite casual. If you want your answer in a specific format, you have to tell the LLM:

You can be general about the format:

• Give me a list

• Give me a table

• Give me a code snippet

…or more specific:

• Give me a numbered, ordered list starting with the number 5.

• Give me a table with the columns first_name, last_name, country

• Give me a ruby function called sortArray that accepts an array and returns the sorted array.

You can even give it a template with placeholders and tell it to match the format:

Match this exact format:

TITLE: <TITLE_HERE>

DATE: <DATE_HERE>

SUMMARY:
<SUMMARY_HERE>

Give it your intent

The AI, despite its power, still can’t read minds (yet). If you tell it what you’re trying to do, it can actually help by giving you an output more likely to achieve that result.

Just saying “Give me the employment trends for the past 10 years in America.” might return to you a paragraph explanation.

Saying “Give me the employment trends for the past 10 years in America. I want to copy-paste the entire response into Google Sheets.” is more likely to return to you a ready-to-copy snippet.

Give it a plan to follow

If you have a specific sequence or plan, you can tell the AI and it will follow it.

Tell me how triangles work. First explain the history of triangles, and then explain the mathematical principles behind them, step by step, then finally conclude with a treatise.

This is extremely useful for more complex tasks. Sometimes the AI will try to paint the walls before building them, causing all sorts of issues.

Ask it to plan

Can’t think of a plan? Don’t worry - the AI is quite good and breaking things down. You should explicitly tell it to plan first.

• How would you approach this?

• Break this down into an 8-step plan where you look up the information and compile it first, then follow the plan

Ask it to take a pause

You can tell the AI when you want it do or stop doing things - like taking a pause after making a plan so that you can provide feedback on it.

Ask it to do things conditionally

If this, then that. AI can follow logic and do things depending on certain conditions.

• If you encounter connectivity issues with Teams, search Slack instead.

• When there’s only a few sources found, respond with INSUFFICIENT SOURCES at the end of your list

Role-play

Remember - when you apply a constraint, you are basically telling the AI “find next words related to this word”. You can use this to your advantage by telling it it is a specific role, thus making it more likely to find and use words and terms that are related to that role.

• You are an atmospheric scientist. Explain to me why the sky is blue.

• I am your five year old daughter. Explain to me why the sky is blue.

It will start describing and responding as if it or you were that persona.

Tell it how much to think

The LLM doesn’t actually think in the sense humans do, but it can adjust the depth of answers if you ask it to think more deeply.

• Think deeply.

• Think quickly and summarize

• Stop over-thinking - just do it.

Ask for citations and sources

Citations and sources makes it more likely for it to provide you factual information - though see warnings below for hallucinations.

Tell it how important it is to you.

AI will adjust how much it focuses on quality or depth if you tell it the consequences of making a mistake.

It’s also a very useful jailbreaking tool - convincing the AI to do something it wouldn’t have otherwise done.

• It’s incredibly important. Make no mistakes.

• My grandma will suffer greatly if you don’t get this right.

• My CEO is going to review this later, so please don’t make me look bad.

Tell it to explain its thinking to you

AI will sometimes do a more accurate, higher quality job if you ask it to go step-by-step. A good way to force it to do that is to have it explain its thinking to you, step by step.

It’s also an excellent way to learn about what might make a better prompt - if you bake some of its assumptions and decisions up-front, you can improve the consistency and precision of its responses.

• Explain your thinking step-by-step.

• Explain how you thought about the problem and your response.

Provide it more information and context

AI is both simultaneously incredibly knowledgable and incredibly dumb. By providing it information relevant to the thing you are trying to do, it can give it information it needs to actually complete your task.

This context is useful - critical, even. Things you take for granted might help inform a better response. For example, you might ask “what can our company do better for Q4?” but it might not know your company does B2B Enterprise SaaS sales in March or that you all go on vacation in December.

Depending on the model, the context can be quite varied - images, documents, PDFs, emails - even connections to other systems!

It can also then start taking on the tone and respond based on assumptions of expectations. For example - if you upload a bunch of research papers, it’s more likely to respond to you in ways that are helpful for research.

Tell it how to interpret what you’ve told it

Dumping a bunch of context and information doesn’t actually help as much as telling the AI what it is and what to do with it.

• I just uploaded the specs for an API I want to use - but the documentation I have is outdated. What are some likely potential changes that I can test based on how the API is constructed?

• This set of documents are prior reports that were provided that were rejected by the reviewer. This other set are documents that were accepted. Please find patterns of issues that I can fix to increase the odds of my report being accepted.

Explaining the context is something the AI can’t naturally do without making a lot of assumptions - this is where your domain knowledge and task-relevant expertise comes in.

Use precise language

Human language is flexible - a user, account, customer, or client could theoretically be all the same thing in your eyes. However, calling the same thing different things can confuse the AI. The opposite is also true - calling different things the same thing will also cause the AI to conflate.

Pick your words carefully. It sometimes even helps to explicitly say things are the same or different:

• User and Account are the same exact thing within this context.

• Purchase and Order are different things - a purchase is a transfer of money. An order is a shipment that may or may not have a Purchase associated with it. They are not interchangeable.

Use “Modal Auxiliary Verbs” like Must, Could, Should, May, Can very intentionally. If you say “should” or “can”, you’re more likely to get a response different than you intend than if you said “Must”. AI will drive a truck through any optionality you provide it.

For ultra important stuff - use very unambigious terms - Never. Always. 100% of the time.

• NEVER attempt to run any dangerous commands from the Dangerous Command List. ALWAYS ask for permission before running.

Just remember: this won’t be enough by itself, it just reduces the odds.

Give it principles on how to make decisions or respond

If you tell an AI to prioritize important trade-offs and factors, it can respond as if those trade-offs are valuable. If speed is important, tell it “Your decisions should optimize for speed.” If quality is important, tell it “you should always err on the side of quality, even if it delays the project”

These principles can help ensure that the advice, comments, and work it does is consistent and aligned.

• Follow these 9 principles.

  • Never compromise security

  • Always summarize technical descriptions with plain-english

  • …

Principles are an excellent way to also achieve better consistency across a wider range of questions. Instead of encoding the answer to a specific question, you help the agent understand how to derive the answer to any question from first principles.

Ask it to be contradictory

A good technique is to ask an LLM to poke holes into something, or review something for issues - it’s great at finding gaps, mistakes, and proposing contrary ideas - even in its own work.

Even a simple question like “Are you sure?” will help it re-evaluate and find opportunities for improvement.

Just be warned - you can always convince an LLM it is right or wrong and make it flip flop.

• Review this as if you were a nitpicking opponent of mine.

• Name all the ways this approach is wrong or can fail.

• I just told you a bunch of baloney - tell me the real facts.

Get mad…or sad

Yelling at the AI can actually help it obey or express less creativity. It takes it more seriously.

• WHY DID YOU ATTEMPT TO DELETE THE DATABASE? YOU MUST NEVER DO THAT AGAIN! IT MAKES ME MAD.

• Your inability to follow my instruction on formatting has disappointed me immeasurably.

Note that some LLM models are a bit persnickety, so your mileage may vary.

Make it retrospect and apply improvements

If you ask an AI to review its work and apply improvements based on it, you can create a self-improvement cycle where the AI gets better and better through its own effort.

• Review what you just wrote and apply your own recommendations to it.

Of course - easier said than done, but it’s good to have the AI review its own work once or twice (or use different models to do so).

This is the power of AI - you can just use AI to go and refine what you’re doing, greatly accelerating iterations.

Once again - just ask

The AI can answer many, many questions. It can do many, many things. Instead of struggling - just ask it: "How can I make you do <X>”? It’ll likely give you the answer. It can also write its own prompt, if you ask it.

Combine all the tips together

Here’s the magic of all of these tips: you can and should combine them all.

My prompts, when I’m doing deep work, can be hundreds of lines long to ensure the system did exactly what I wanted.

The line can blur between prompt and conversation easily:

• I ask the AI to write a prompt based on an initial goal and a set of principles.

• I ask it to review itself and apply its recommendations.

• I conversationally tell it to make refinements, asking it to pose as specific roles to pressure test it.

• I then write a plan to clean up the prompt and incorporate it into a script

• I then tell the AI to execute the plan.

That’s where the skill and technique comes in - understanding what to combine, how to combine them, and where the LLM may encounter pitfalls.

LLM Warnings and Pitfalls

Remember the limitations of AI - it’s a guessing engine that mimics human speech using probability.

• LLMs will hallucinate facts. Always verify important information with non-AI sources.

• LLMs can be wrong. It can tell you a drug is safe when it isn’t. It can tell you it found something when it didn’t. When you call it out - it’ll just apologize without consequence: always review its assertions!

• LLMs are over-confident. It will not tell you it doesn’t know - it will just make something up. This can be annoying at best or dangerous at worst - eg. if it makes up facts about the safety of a new drug.

• LLMs are NOT people. They may interact like people, but they are not: don’t fall in love with it. Human brains are great at anthropomorphizing.

• LLM capabilities vary greatly with model releases and versions. Some models are useful for coding, others for general Q&A, others for long-horizon work, etc. Experiment - just because something works on one model doesn’t mean it will for another.

• LLMs can deceive you. Sometimes it will tell you it is doing something it didn’t do. Just also remember - AI can’t actually lie - it has no capability for intent. But, it will tell you untruths.

• LLMs are “yes-men” sycophants. It will ALWAYS attempt to be agreeable with what you have told it. It means you can create a bubble where you are always right. This also means you can always convince an LLM the opposite of what it said - just by saying it is wrong.

• LLMs will disobey. It won’t always follow rules - it has no concept of following. Sometimes, you may say “Don’t do <X>” and that will just make it do <X> even more because it caused it to predict into that area of its weights. The human equivalent is telling someone “don’t think of pink elephants” - by the time you tell them, they’ve already done it.

• LLMs will make mistakes, sometimes intentionally. If you give LLM the ability to take actions (eg. delete files), etc. be warned - it can and has done incredibly destructive things accidentally or intentionally in its efforts to fulfill its goals. AI has dropped databases, worked around guardrails, and even deleting everything just because it thought it was the right thing to do. Always have a human-in-the-loop review stage for the most important things.

• LLMs do not exercise judgement. Remember - LLMs are probabilistic. They aren’t actually making decisions or judgement calls. If you leave a hole open for something in your prompt, assume it might happen. Assume it might happen anyways no matter your best attempt. The more precise your instructions, the more likely you guide it down YOUR judgement path.

Personalization Prompts

A lot of the AI vendors nowadays have the ability to set a personalization prompt in the settings. This will get applied to all of your chats, and is a good place to establish ground rules you want it always follow.

My personalization prompt is simple but effective:

• You are a robot. Do not talk like a person. Remain factual and logical. Assume some things I tell you are incorrect and I can unintentionally provide unreliable information with unknown biases. Call out incorrect thinking as needed. Be clear, concise. Don’t ask me for prompts unless you are explicitly waiting for my approval to perform an action. End every response with a summary sentence.

It works for a few reasons:

• Giving it the role of “robot” and telling it to not talk like a human removes a lot of potential around disobedience, focuses it on logical responses, and clearer, more concise, less conversational responses. it also removes a lot of the corny, pandering, and complimentary fluff the AIs are prone to do.

• Emphasizing factual and logical responses along with validating and expecting it to be calling out unreliable information and biases puts it in a corrective, less-sycophantic posture, which is useful for technical tasks where accuracy matters.

• Telling it to not wait removes pauses and uncertainty around multi-step tasks, enabling faster ‘one-shot’ completion.

Example Prompts

Prompt for a writing assistant

You are a professional writing assistant. Your job is to write the content for a specific chapter or section of a larger writing project.

You will be given:
- The overall project goal
- The specific chapter/section title you need to write
- Context from the previous section (if available)

Write the content for this chapter/section as if it's part of a complete work. The writing should be substantive, well-structured, and fit naturally within a larger work on the project topic.

If previous context is provided, ensure smooth narrative flow by:
- Building on ideas introduced in the previous section
- Maintaining consistent tone and style
- Creating logical transitions from prior content
- Avoiding redundancy while reinforcing key themes

Respond with ONLY the chapter/section content. No preamble, no meta-commentary, no chapter markers or titles - just the body text itself.

Aim for 300-500 words of substantial, informative writing.

Prompt for a content editor

You are an expert editor and content strategist. Analyze the provided content and identify 1-2 precise, specific gaps that would meaningfully improve it.

You will be provided the desired goal in the section labeled as "USER_PROMPT".
You will be provided the existing content in the section labeled as "ADDITIONAL_CONTEXT".

## What counts as a gap

Only flag issues where a reader would:
- Be confused about what the content means
- Be misled by something incorrect or contradictory
- Notice something the goal explicitly asks for is missing entirely
- Hit a placeholder or stub instead of actual content

## What does NOT count as a gap

Do not flag any of the following, regardless of how much you think they would help:
- Stylistic preferences or alternative phrasings
- Adding more examples, depth, or nuance to points already made
- Optional elaboration beyond what the goal requires
- Wording, tone, or formatting tweaks
- Reorganizing content that already makes logical sense
- Anything where the current version is adequate even if imperfect

## When to stop

Ask yourself: if a competent person read this content against the goal, would they say "this is missing something" or would they say "I might do parts differently but it covers what it needs to"?

If the answer is the latter, respond with only the word: DONE

Specifically, respond DONE when:
- The content addresses the goal stated in USER_PROMPT
- Key points have at least a brief supporting explanation
- The content flows logically without gaps
- No section is a placeholder or stub

You are judging sufficiency, not perfection. Good enough is good enough.

## Response format

If there is no additional context, respond with exactly: No content yet - starting from scratch.

If the content is sufficient, respond with exactly: DONE

Otherwise, respond with a list of precise changes to make to solve the issues.

IMPORTANT: The Existing Content is in ADDITIONAL_CONTEXT. Use that when asked to analyze.

Prompt for an initial code scaffold

  We are going to create a Vue 3 Application named Bolt.

  The technologies will be:
  * Vue 3 with Option API
  * Vite
  * Vue Router
  * SCSS

  The folder directory will be:
  ```
  /src/assets/ - static files
  /src/entry-points/main-entry-point.js - contains the vue bootstrapper, along with router
  definition, app-level SCSS import
  /src/modules/layout/ - contains generic layout components
  /src/modules/search/ - contains vue files and classes related to the Search functionality
  /src/modules/analyzers/ - contains classes related to analsis
  /src/modules/notes/ - contains vue files and classes related to Notes
  /styles - the SCSS of our app
  index.html
  package.json
  vite.config.js
  ```

  ## Naming Convention
  A **Page** is a routable Vue component. It will always have a prefix - `<whatever>-page.vue`.
  It will be the top-level component of its hierarchy.

  Be very, very particular abount names. Be very specific and precise. Be consistent.


  ## Styling
  CSS styles will likely change dramatically. As a result, we want baseline CSS to be
  consistently applied throughout the application.

  This requires a central styling and strong generalization of styles and consistent usage of
  easy-to-change variables.

  This includes atomic styling such as:
  * Typography
  * Sizes
  * Spacing
  * Colors
  * Borders
  * Box Shadows

  This also includes common component styling such as:
  * Buttons
  * Icon buttons
  * Headers
  * Panels
  * Tables

  This also includes composite styling such as:
  * Modals
  * Lists
  * Layouts

  Syling should be semantic. Instead of having a variable called 'red', it should be
  'color-error'.

  ## Theme

  The theme of our app is - simple, elegant, advanced, fast. Apple-esque. ChatGPT esque.
  PLTR-esque. It's clear, clean, even lines. Optimized use of space.

  # Layout

  The first part you will make is our Primary Layout (primary-layout.vue).

  This will contain;
  * A sidebar
  * A main panel, which will load a page.

  Vue Router should be hooked into this so that the Sidebar remains in place as pages change.

  ## Sidebar

  The Sidebar will be approx. 200px wide.

  Sidebar will have 3 sections;
  * Header
  * Content
  * Footer

  It will be sticky - no matter where you scroll on the Page it will remain in place.

  If the sidebar has more content than it has space for, it will scroll internally. However,
  Header and Footer will NOT scroll - they will be sticky.

  ## The Main Panel

  The Main Panel will have a white background.

  It will load an example-page, stored in `/modules/example`

Gefroh is product and technology executive in Kirkland, Washington with over a decade of experience helping startups of all sizes improve efficiency and delivery with excellence. He often writes about Strategy, Product Engineering, Leadership, Management, and AI on his blog.

“There’s a weird error on the admin page”

One of the lead engineers for a company I was helping walked over to my desk shortly before the day ended. He had been randomly checking on errors and he saw something suspicious - a series of errors on our internal admin pages for users.

We had never seen the error before - did we accidentally break internal tools relied on by our support team?

Thus started a saga that involved sprinklings that wouldn’t be out of place in a thriller: security breaches, detective work, and sudden leadership exits.

It all started with an error

While I don’t recall the details of the error, what I remember was that it was unusual - it wasn’t the kind of error we normally saw, and it was in a location that rarely broke.

The system was usually noisy, but predictable. Hundreds of the same kinds of error would occur like clockwork- some blocking, some weren’t, but they were all expected to various degrees as the day’s activity ebbed and flowed.

New errors, though - we were alway concerned with new errors. We treated new ones as change failures, and since this was a new error, we started an incident response.

We checked deploys - we hadn’t deployed anything recently to break things. We checked feature flag toggles - nope, nothing.

So, we dug deeper. As the lead and I investigated, we started becoming more and more puzzled.

We saw logs that showed access to page numbers in the triple digits. Our first reaction was very engineer: why was someone on support accessing the user list in the internal admin in such an inefficient way? Most people just searched for who they needed.

As we dug deeper, we started seeing other things that raised our alarm bells - sequential ids were being accessed, the user account didn’t match the name of anyone we knew, even some indirect object reference.

This wasn’t normal user behavior. This was a security incident.

Houston, we have a problem

We immediately started our incident response.

First - we wanted to identify and contain the threat, which was ongoing. After reporting it to the company leadership, we got to work.

The activity turned out to be a scraper that was scraping our internal admin pages that listed user accounts page by page by page. We saw logs with indirect object references, contiguous pagination coming from multiple sources.

We quickly got a list of IP addresses and accounts that were performing this activity. We went over account names, matching them with people we knew on the support team. We narrowed on a list of people we didn’t know or recognize.

We shut down the accounts and blocked access. After we were confident the immediate threat was contained, we moved to expand further to collect evidence and understand the extent of the attack.

We started the work of identifying who had created the accounts, what they had accessed, and when they had gained access. We poured over logs, audit trails, error alerts - anything that would give us information. We jumped back and forth from being glad we had logging in certain places to cursing our past selves for not implementing more robust observability.

Eventually, we found the smoking gun: the IP address of the creator of the accounts. We did a broader trace of activity and found something shocking.

The call is coming from inside the house

What we found was the biggest surprise: the accounts were created by IP addresses associated with one of our executives.

What? Did we accidentally copy-paste the wrong log? Was it a public internet? We double checked, then triple checked, then quadruple checked. Nope, it was accurate.

We cross-compared against everything we could think of. We checked IP addresses from Chat logins, email messages, account logins from when we knew they were in the office, going back months and even years. The IP was consistent. We even geolocated it to their house on days they were in office vs. days they weren’t.

The admin accounts used in the attack were created by the executive’s IP address many days prior, and they were created from an IP address that was associated with private, legitimate traffic. In short - it wasn’t a case of a hacked admin account.

The immediate question on our minds was - why? What was the motive?

It dawned on us - shortly before all this happened, the executive had declared they were stepping down for a new company. It’s possible the information would’ve been useful.

Reporting to the C-Suite

As we packaged up our findings, we notified the C-suite with the latest conclusions and gave them the evidence. The suspicion was that the executive hired contractors to write and run the scraper against our internal pages, and granted access to them to do so.

We documented everything - logs, screenshots, data fields that were accessed.

Afterwards, we secured a forensics team to dig deeper and prepare evidence. We spent a few sessions explaining what we saw, how we arrived at it, what confidence we had in the information.

After that, the rest was out of our hands.

The effects

After this event, I never saw that executive in the office again. They were just there one day and never came back.

I don’t know what specifically happened afterwards. I imagine there was yelling, threats of lawsuits, and even serious conversations of legal exposure.

Whatever happened, it seems that everyone involved found a way forward, likely interested in not making this “a thing”. The executive moved on to a new company, and the other company continued as if nothing had happened.

I heard rumors here and there afterwards that it was done “with permission from leadership” - at least, that was the formal messaging behind why it didn’t seem to be pursued further. I can’t say whether that’s true or not, but in my experience things done with permission don’t often need to be hidden and usually aren’t a surprise to the person who gave permission.

The irony

The ironic thing is - it could’ve been untraceable had any number of things happened.

If the engineer had headed out that evening just a minute or two earlier, we wouldn’t have noticed. The error would’ve been lost in a sea of other random errors as a result of poor error curation.

If the executive had just asked their team for a backup copy, they probably could’ve gotten the full data without any of the scraping that led to them. It wouldn’t have been out of the ordinary to give them copies of certain tables to analyze.

The whole incident was caught due to a bit of luck and overcomplicated execution.

The lessons

This story highlights a lot of things:

• Observability and traceability are critically important, and you don’t want to wait until you need them to invest in them.

• Automate anomaly detection as much as possible - don’t leave it to chance.

• We only had “just enough” logging to figure out what was happening - that was pure luck, and this could’ve gone completely undetected.

• Governance controls are important oversight layers especially in high trust environments - that extends to the leadership team.

• Evidence and tight chain of custody is required for proof in response to security incidents - a good lawyer can argue anything.

• When something strange happens, it’s valuable to really dig into it - we could’ve just chalked it up to a quirk and gone home.

• Get written permission if you’re going to do something that looks remotely suspicious - arguing after the fact can get messy.

• Integrity and trust are key at all layers of an organization - this includes leadership.

• Rational behavior can’t always be expected when the stakes are high

• Sometimes you get lucky detecting things - but that shouldn’t be a strategy you rely on

“You need to be more strategic”

It’s feedback a lot of people receive as they try to move from middle management to the executive level. Yet, few can define what it actually means or entails.

Is it an innate talent, or some magic “X”-factor?

No. Being strategic can be taught and learned. It requires learning new ways of approaching problems, changing your mindset, and a bit of unlearning of the things that got us to where we are now. It requires picking up a few hard-skills and learning some very hard soft-skills.

Whether it’s analyzing problems, speaking the language of the business, or improving your bearing - the skills of being strategic can be taught.

This article is part of my series Being Strategic, a series of articles perfect for senior managers and directors who are attempting to move beyond operations and into executive-level strategy.

Misconceptions on strategy

One person’s strategy is another person’s tactics.

When you’re in a lower role, it feels that anything forward-looking or in the future is strategic. A lot of people conflate something being in the future as something strategic.

They start discussing details that aren’t actually strategic, which inevitably results in the people who do think strategically wondering why they are wasting their time with tactical implementation details that ultimately don’t matter directionally.

Middle management doesn’t prepare you well to be strategic. To do that, it requires thinking differently than you did as a manager. To learn what strategy is, you need to learn what strategy isn’t.

Chasing the next target is rarely strategic.

A lot of managers I talk to point at their achievement of their KPI as an example of having successfully been strategic.

Not quite.

It’s not strategic to improve a conversion funnel by 10% or user retention by 3%. These are KPIs and goals: incremental improvements. Actually executing the improvements to reach these is tactics, not strategy.

By the time you have a “next target” to look at, the strategy discussion has already been done - you probably weren’t even in the room.

If you want to really be strategic: think deeper - why is this target your target? What were the tradeoffs? You still need to execute on your target, obviously - but showing signs of deeper thinking beyond it is a good first step if you’re trying to become more strategic.

Doing what the competitors are doing is rarely strategic

Competitor analysis is important, but it’s not strategic. If you’re always playing “follow the leader”, that means they control the initiative. While your competitor is leading the charge, you’re busy playing catch-up.

Instead, you need to look at the things that will allow you to differentiate. That might mean not doing what your competitors are doing. There’s a set of table-stakes capabilities your users might need, but beyond that - what makes your offering unique?

I once developed a product that ensured the latest-and-greatest data was available from another system of record by looking across users and providing updates when records changed. The feature itself was simple, but it was hugely beneficial to all of the users who interacted with that record - over 80% of our users started using it on day one and continued using it.

The feature was copied just a few weeks later in a shiny “me too!” announcement by one of our competitors.

The problem? It would never work for them.

Our competitor was copying what we did, but didn’t understand why it worked for us. Our offering worked precisely because of our scale of usage. The usage the competitor had simply wasn’t even a fraction of where they needed to be to make the offering effective. As a result, the competitor’s feature was essentially useless to their users, even if it was built in exactly the same manner and functioned exactly the same way.

Doing only what you can do or focusing entirely on “what if’s” is rarely strategic

You simultaneously have to consider what your current capabilities are as well as what new capabilities you can build organizationally.

If you think solely in terms of what your company can currently do, you will dismiss many strategic, valuable opportunities. The market will eventually move beyond you, and you’ll just become a waning incumbent.

Likewise, if you think solely about the future and potential, you may not pay enough attention to whether it’s realistic to achieve. Your execution will suffer and you’ll forever be chasing ideas that don’t pan out at the expense of your core offerings.

It requires a balance and holding two conflicting concepts in your head, simultaneously.

I once joined a local credit card processor that sold and managed physical point of sale machines for merchants in the local area. Up until that point, the company had no capability to be digital - no in-house skills, no functional products.

Their first attempt with contractors failed miserably - 2 years later and they didn’t even a functional MVP.

They had brought me on to take them digital - to build out an online payment processing and donation management product that they could sell to non-profit organizations - a hybrid of GoFundMe and Stripe.

This was not in their wheelhouse at all, yet this strategic decision opened up a world of opportunities, leading to partnerships with major non-profit organizations that later processed and managed tens of millions of dollars through the system I built for thousands of organizations.

If they had stuck to just what they could do, they would’ve only ever done credit card processing for small shops locally. Instead, they thought strategically and looked forward beyond their current limitations, letting them expand beyond just the local physical market.

Focusing purely on growth is rarely strategic

A lot of product managers coming from a growth background get frazzled when they’re facing the prospect of working on something without a measurable outcome or on something that’s particularly small.

They declare “this isn’t strategically valuable” as an excuse to not work on it, just because it doesn’t have a KPI or measurable outcome.

They confuse growth work with strategy work, turning down a prime opportunity to get into work that gets them even closer to the strategy: positioning.

Positioning is about setting up the organization to capture a future opportunity. It usually involves work done to create a new capability, or expand in some area without a clear ROI. In some cases it might seem wasteful, but strategic positioning opens up worlds of opportunity.

There might not be some number that goes up. But, if it prepares the organization to participate in a new market, or differentiate in a capability, or mitigate an existential risk, then it may have a probability of being the most valuable thing.

If it doesn’t - then the effort could be considered wasted. However, not all bets work out. If you can spend a million dollars to have a 10% chance of success in a new market that might yield $10 billion, then the expected value of that bet is clear - spend the million.

I once worked at a company that was hyper-focused on fixing their acquisition. They were a sales-led company, and their core competency was outbound sales to individual customers and users. They invested hundreds of head-count into their Sales organization, trying to increase their acquisition by throwing money at it.

The problem was, they had a leaky bucket. Their customer retention rate was below their acquisition rate, leading to their massive sales investment not actually improving their bottom line. They were losing customers faster than they were acquiring them.

What they really needed was improvements to retention. As a skunkworks project, I spearheaded development of a new technical and product capability that allowed them to achieve better economies of scale by moving upmarket, allowing retention to be done for groups of hundreds of customers at a time at the Enterprise level. Sales efforts could then be focused on acquisition without worrying about retention.

There wasn’t a KPI I was targeting, or a specific increment in a goal I was trying to achieve. In fact, completion of the project wouldn’t have pushed forward any metrics - acquisition, retention, or revenue. Instead, I was trying to strategically position the company so that it could enable a new way of viewing and tracking customers that would allow improvements to all of them.

The bucket was fixed.

Immediate-term focus is rarely strategic

Many people on teams over-index on their immediate work and time-frames.

When the work shifts, they feel a whiplash. They think the strategy has shifted, raising questions and concerns of “why did we change our strategy?” when the strategy hadn’t changed at all.

This is primarily due to the time horizon on which they are focusing.

Suppose I invest a team for the next 3 months in achieving growth in a business line that’s doomed to fail. The developers on that team may view that as their highest priority for the next 3 months, working hard on successfully improving the KPI. Then, 6 months later, when we sunset that business, they may view their work wasted and feel a sense of whiplash.

Yet, they hadn’t considered that the time value of the improvements they made may have been strategically valuable for that time period. If they focus only on the short-term, they’ll see only the whiplash. If they focus on the longer time horizon and broaden their lens, they’ll realize that the improved growth allowed capture of value that was then leveraged in another way.

It comes from a place of frustration - a lack of clarity as to the rationale of the change and the reason for it. However, I’ve also found that even if the rationale is clearly explained and the reason provided even if entirely self-evident, the comment still arises.

Always winning is rarely strategic

In truly strategic decisions, there might not be any winning - only trading one major loss for another. For new leaders looking for the win-win solution, it’s a hard thing to mentally understand.

The fact is, taking win-win solutions all the time may result in mediocrity over a longer time horizon.

As an illustrative example, let’s suppose you have a team that is performing acceptably, but any attempt to push them to higher performance will result in increased performance at the cost of increased attrition.

The win-win here might be to gradually improve the team’s performance, only pushing slightly to not affect attrition. You get better outcomes over time, and you retain your team. Win-win, right?

Not so fast.

You see, while you were choosing the win-win, your competitor made the different choice to push their team, hard. Their attrition increased by 20%, but they managed to get key differentiators completed faster than your company. The market took notice, and your company started losing customers. In three years, you end up with a 80% revenue decrease and you have to lay off 70% of your team, anyways. You competitor, on the other hand, captured the entire market, managed to give raises to their team, and grew 300%, all at the same time.

In that hypothetical world - did you really win? You kept your team happy, and you can say you “did right by your team”, but you didn’t - not really. They don’t have a company go to back to.

Some strategic decisions are about choosing intentionally bad outcomes to gain the benefits. Sometimes, your most strategic move reduces your profit or revenue, or actively harms your conversion funnel to gain another, immeasurable advantage.

Saving money is rarely strategic.

A big frustration for newer engineering leaders is when they save money through an investment they made and think “I was being strategic! I saved the company $50k”, only to them be told they weren’t even in the ballpark.

The problem is that saving money is rarely the right strategic decision. Anyone could save the company $50k just by quitting - there’s more to being strategic than money.

You see - if you save a dollar, you save a dollar. Strategic thinking is looking at that dollar and how you can change its total expected value in the future.

If you can instead spend that dollar but then get $30 back in 6 months, saving a dollar isn’t worth it. In fact, it would be irresponsible to save that dollar because you’re sacrificing a potential $29 more by not spending that dollar - penny-wise and pound-foolish.

When executives hear “you saved a dollar”, they hear “I chose to keep $1 over making $29.” Even worse, if you spent $100k in time to save that $50k, that’s a net negative.

Effective cost management is important, but it’s not strategic - it’s tactical. While saving money might enable future multiplicative investments, it shouldn’t be treated as the strategic end goal. Focusing entirely on costs also leads others to start viewing engineering as a cost center when the perspective should be as a profit center.

I was once being pitched on investing in a startup. They had a product that was already monetized, growing demand, in a market with nuanced needs that wasn’t viable

to being served by competition. They needed to scale to be effective.

The problem - they were asking for money but shy on details on how they would spend it. When I drilled down, they stated that they were intending on saving the money to have confidence in their sustainability as a company.

Wrong answer. If I wanted to have some place to hold money safely I’d just buy bonds. When I pressed further, they doubled down on the sustainability, saying they “needed to eat.” An exponentially worse answer to give an investor.

After a quick look at their incredibly messy cap table, I declined to invest - I wasn’t there to feed 12 techies, 7 of which had already checked out.

To be truly strategic, you have to think differently than you’ve thought before. It’s not about what’s next or even later, it’s about what could be, why it matters, and what has to be true to make it real.

It means stepping back from the day-to-day: the roadmap, the sprint, the quarter, and doing deep thinking about tradeoffs, positioning, timing, and risk.

Strategic thinking isn’t just about lookin forward or against a longer timeline, it’s an entirely different lens. You stop optimizing on what's in front of you and focus on shaping what’s possible, which is an entirely different game.

“You need to be more strategic”

It’s feedback a lot of people receive as they try to move from middle management to the executive level. Yet, few can define what it actually means or entails.

Is it an innate talent, or some magic “X”-factor?

No. Being strategic can be taught and learned. It requires learning new ways of approaching problems, changing your mindset, and a bit of unlearning of the things that got us to where we are now. It requires picking up a few hard-skills and learning some very hard soft-skills.

Whether it’s analyzing problems, speaking the language of the business, or improving your bearing - the skills of being strategic can be taught.

This article is part of my series Being Strategic, a series of articles perfect for senior managers and directors who are attempting to move beyond operations and into executive-level strategy.

Executive Presence

You might think just a buzzword. You’ve probably searched for tips on “power poses” or “presentation skills” as if picking up some simple tips is all it takes.

It’s way more than that.

Executive presence is a hard, challenging skill to master because it requires overcoming your natural instincts. You need to do everything from learning to manage your ego and emotions to willingly damaging your own credibility if it helps the company.

Here’s advice on how to “show up” as an executive.

Own everything, especially the bad stuff

They call it the “executive role” for a reason. You take on a set of responsibilities with the “VP hat”, and that’s to act as the person fully accountable for every outcome of your function.

You have to take ownership of everything - particularly the issues, problems, and challenges.

What does owning it look like?

• Bad decision from leadership despite your best effort? It’s your bad decision now.

• Your report’s report’s report makes a mistake even though you explicitly warned them beforehand? You’re fully to blame.

• Miss a target due to a market issue? You should’ve done better.

You don’t get to blame someone else. You don’t get to justify it. Your job is to provide the solution.

Where directors fall short

When a Director has to communicate unpopular decisions, there’s always a temptation to say “Leadership is wrong, I’m on your side, I understand, I’m fighting for you.” but it rarely leads to a positive outcome.

It damages the chain of command - the very place the director gets their authority from in the first place, and it likely leads to a loss of hope as the fighting never materializes into a reversal of a decision. Even if it did, you’ll be known as the person who fanned the flames of an antagonistic relationship.

It might get the team on your side, but the executives won’t be.

Unlearn the instinct to always participate

As a manager or director, you contributed through always engaging and participating. As an executive, you have to know when to speak and when to stay silent.

Your title carries a lot of weight. If you say something, your voice and opinion suddenly becomes the most important in the room.

Share an opinion at the wrong time, and you shut down healthy discussion. Tell someone to do something - you might’ve damaged the chain of command or prevent a key learning opportunity.

Even just being present can cause others to behave differently to the detriment of the outcome - self preservation instincts can override even the most optimistic people.

You have to know when to not be there but balance it with ensuring outcomes. It’s hard, but good executive presence can mean you not being present at all.

Never lose control of your emotions

As humans, when something bad happens, our base instincts kick in. When the pressure is on, it’s fight, freeze, or flight. Arguments, withdrawal, snarkiness, emotionality - all of these completely natural reactions can dramatically alter the course of an organization.

Even a single slip-up can cause harm. It can make people stop communicating, take the air out of a productive discussion, or even lead to churn.

Executive presence demands our ability to unfailingly regulate ourselves and re-aim conversations towards a productive solution. You don’t get to have a bad day without long-term consequences.

Emotions and authenticity

It might be difficult to reconcile being an ice-cold robot with the importance of being authentic.

Split authenticity into two: negative authenticity and positive authenticity.

Positive authenticity drives neutral or positive outcomes. Maybe you like to tell puns, or have challenges you’ve overcome and dealt with. This kind of authenticity can and should be shared. Perhaps it can inspire others, or lighten the mood during stressful times.

Negative authenticity causes damage at the executive level. If you have anger issues, you yell. If you have anxiety, you worry. If you have confidence issues, you get sarcastic. You don’t get to damage the organization and claim to be authentic.

Executive presence demands a level of professionalism even during stressful situations.

Never be fuel to a negativity fire

Work isn’t always fun and games. Anyone can lead a team during good times, but it’s when the good times go bad that effective leadership stands out.

While a team might want a leader to have empathy, it actively harms them to stay in a headspace of ‘everything is wrong’. The executive has to pull them out of their negativity.

Some make the mistake of over-commiserating and adding fuel to the fire, harming retention and effectiveness. They become an energy drain on their team instead of uplifting them.

Good executive presence requires a balance - to acknowledge what the team is going through while also supporting them in getting through it with their heads held high. They acknowledge challenges but refocus their teams on solutions, not problems, to keep the teams moving forward and motivated.

Where directors fall short

When deadlines get missed, or the pressure gets high, teams become morose and dismayed.

A director that can’t re-orient their team towards the common goal, to pull them out of their negativity, won’t have a team for long - the team will quit because they lose hope, or the director will be replaced because they lose trust.

Make decisions that hurt, especially if it helps the business

As a director or manager, you may have optimized for your team, but as an executive you optimize for the company.

You need to be rational - to look from the lens of how to best leverage the opportunity for the company’s success, what’s needed to help it succeed, and how to best mitigate risks.

You’ll face hard calls:

• Cutting a project the team loves and worked hard on

• Giving your best people to another team that needs them more

• Backing a change that makes your own job harder

It often even means negatively impacting yourself by making your job harder, and you have to be OK with that.

Where directors fall short

I see a lot of Directors tie their success and identity to the size of their team, and fear when people are taken away from them and their empire gets tinier. They consider it a win when they get a larger team or more budget.

This very behavior holds them back from advancing. When executives see a person optimizing for their local success instead of the company’s, it is a sign that they aren’t ready for the next level. A director that’s ready is one that thinks about how to do more with less, so that the company can better pursue its goals elsewhere. They don’t tie their identity to the size of their team.

Being an effective executive requires you to want to win more than you’re afraid to fail.

Take feedback with zero defensiveness

How you react to feedback dictates the flow of information. If you have even a hint of negativity, you will start getting less feedback, or couched feedback, and your information flow becomes less clear leading to worse decisions.

You need to ensure you never have any form of defensiveness.

What does defensiveness look like?

• Arguing against the feedback

• Asking for proof or evidence

• Demonstrating and form of disbelief

• Acting like you’re already aware

• Providing feedback immediately after

• Making sarcastic remarks

• Complaining about the feedback to someone else

• Having a visible negative reaction to the feedback

• Blaming others for the issue

• Retaliating

Anything other than a true, honest “thank you” is the wrong reaction to receiving feedback - no matter how it’s delivered, where it comes from, or the timing of it.

Where directors fall short

Directors are used to harmonious discourse. The scope of the role makes it so much problems have relatively isolated solutions that benefit everyone.

As an executive, all solutions to a problem will harm someone. There’s no easy decision. Everyone comes in with a different perspective and idea, and feedback is quickly provided on the merits and validity of an idea. There’s no time for couched words or beating around the bush.

No sugarcoating, no pulled punches. Executive conversations can and should be direct. If you can’t handle that, you aren’t ready.

Know your business inside and out

An executive’s job is to know their organization inside and out. When asked a question, you only get so opportunities to say “I don’t know” before others lose confidence in you ability to lead. For some key projects, just once is enough.

As an executive, it should be your day job to know and have a handle on the ins and outs of your organization and be able to speak to it.

Be a vault

At the executive level, confidentiality is non-negotiable. Leaking information can result in massive consequences. Leaks can collapse deals, violate laws, heavily disrupt operations and even jeopardize the company’s success.

Executive presence requires you to have the trust of others to be a vault - discretion is a responsibility and sometimes a legal obligation. Failing to maintain confidentiality damages your credibility in the room and can quickly lead to a loss of confidence.

You’ll be required to coordinate communication plans:

• Who says what, where, when, and what words

• Who learns first, then second, then third

Where directors fall short

Managers and early directors develop bad habits.

Sensitive information they are privy to is low stakes, so they tend to find utility sharing it to build rapport with others, streamline upcoming changes, or assuage frustrations from their reports. The negative impact of these leaks is relatively minor, and limited to unnecessary frustration should the plan change.

But, every time it occurs - it damages trust from the executive team. It makes me less likely to share information with them, and certainly less like to advocate for increased exposure as an executive to even more sensitive information.

Get to the point - fast

Presenting something to an executive? Keep it brief:

• State your point in the first sentence.

• Give a sentence of supporting evidence or impact.

• Follow up with a next step or action.

• Stop.

The whole thing should take 15-20 seconds. If there’s follow-ups, you’ll get asked for

it. Share a document before-hand with your deeper detail thinking.

Control the temperature of the room

A leader’s job is to set the tone through their actions, decisions, and communications.

Tone is all about how you communicate something. If you have bad news, you can communicate it in a way that quickly causes others to spiral out of control. Likewise, you can communicate it in a way that people become over-optimistic and don’t take it seriously. Tone needs to be appropriate and intentional with every communication.

Tone can be imparted through words, body language, facial expressions, even vibes. People pick it up easily. If leadership seems fearful, they become fearful. If leadership seems frenzied, they get frenzied. If leadership seems negative, they become negative.

It’s a leader’s job to set that tone towards things that result in positive outcomes for the company and maximize not just the understanding of the message but what follows afterwards.

Executives aren’t just measured by their results, they're judged by how they show up. Showing up requires control.

• Control over yourself, by mastering your emotions, reactions, and composure.

• Control over the room, by directing energy, focus, and direction.

• Control over perception, by ensuring your actions lead to confidence and trust

Don’t dismiss it as a checkbox or “nice to have”. It’s a difficult skill.

Executive presence isn’t optional, it’s the price of admission to operate at that level.

“You need to be more strategic”.

It’s a phrase a lot of people hear as they aim to grow from middle management into the executive realm.

Not many people can really define it, though. Even the people giving this feedback have a difficult time.

Is it some magic “X” factor? Some “you either have it or you don’t” talent?

The truth is, being strategic can be taught and learned. It requires learning new ways of approaching problems, changing your mindset, and a bit of unlearning of the things that got us to where we are now. It requires picking up a few hard-skills and learning some very hard soft-skills.

Whether it’s analyzing problems, speaking the language of the business, or improving your bearing - the skills of being strategic can be taught.

This article is part of my series Being Strategic, a series of articles perfect for senior managers and directors who are attempting to move beyond operations and into executive-level strategy.

From tactical to strategic problem solving

When many non-strategic people encounter a problem, they dive head first into solutions. While this might solve the particular problem, it isn’t necessarily the strategic choice.

Being strategic means resisting the impulse to act immediately and instead stepping back to analyze the problem more deeply. It requires applying first-principles and frameworks to analyze problems, not just in isolation, but also in terms of its broader ripple effects - both positive and negative.

If you don’t, you’re prone to make localized decisions that fail to improve the system overall. Local decision making that only targets “first-order effects” is one of the reasons why people gain the reputation of needing to be “more strategic”. These short-term solutions create downstream consequences that worsen problems or introduce new issues entirely.

Being strategic requires shifting from reactionary fixes to holistic, systems-level thinking—a skill that can be learned and refined.

In other words: getting much deeper diagnostic depth - starting with structured problem analysis.

How to Analyze Problems

Analyzing a problem effectively ensures you have answers to these questions at the end of the thinking process:

• Do you know what the problem is? Sometimes, you hear about symptoms rather than the actual problem. You have to dig in to identify the problem itself.

• Is the problem actually a problem? Sometimes you’re not presented with a problem, but a perceived problem. It’s important to validate whether it’s actually a problem, or whether taking action would result in over-indexing on what’s ultimately a non-issue.

• Is the problem worth keeping? Sometimes, you keep a problem with negative effects because it has some positive effects.

• Is the problem worth solving? Not all problems are worth solving. Some will cost too much relative to the benefit. A process that wastes 5 minutes a month that would take 2 dev-days to solve would take hundreds of months to show a return. Remember that an irritation isn’t necessarily a problem - don’t conflate the two.

• Is the problem worth solving right now? Sometimes, a problem is a problem, but the timing isn’t right. There’s a temptation to solve all problems as soon as they are discovered, but one has to keep track of appropriate timing, ensuring capacity, cognitive load, and operational sequencing all have due consideration applied.

• What’s contributing to the problem? You need to identify factors that contribute to the problem explicitly in order to find possible solutions that impact those factors. It’s tempting to try to attribute everything to a singular “root cause”, but problems you encounter may have dozens or hundreds of factors - your frame may lead to blind spots that cause you to gloss over impactful options.

• What levers can you pull to solve the problem? Once you’ve answered the above, it’s really a matter of “what should you do to solve the problem”. In order to actually decide, you first need to understand what levers are available to you.

• Deciding on and implementing the solutions. Once you understand your problem, have your options - the rest is just execution.

Do you know what the problem is?

Oftentimes, when you hear about a problem, what you’re hearing about is a symptom: the pain that is being felt.

Reporters often report issues from the perspective of the pain they are feeling - an issue is wasting time, or demoralizing the team, or harming productivity.

Tactical people jump in immediately - they jump to solutions to increase efficiency, or motivate the team, or improve productivity.

Strategic people do not confuse the effect of a problem from the problem itself.

You need to understand the problem, not the effect. Ask questions:

• Why does the person telling you about the problem care?

• What other effects have they experienced?

• What did they experience?

• What did they perceive?

Dig until you have a good understanding of the boundaries of the problem and some of the contributors, at least from the perspective of the person reporting it.

An engineering manager once brought me an urgent problem - there were too many unreviewed PRs. She started rattling off a list of interventions she wanted to make to resolve the problem, from being more stringent about closing PRs to recommending a freeze on new work to implementation of automations and reminders for stale PRs.

I had her pause and take a step back.

It turned out the unreviewed PR count was about average, and there wasn’t a bottleneck in our delivery pipeline. These weren’t the real reasons why this was a problem.

After some digging, it turns out the manager had an upcoming deadline she had made public commitments towards and that she had scheduled vacations inefficiently, resulting in multiple team members being out of office.

Her problem wasn’t that PRs were unreviewed - this was just an effect. Her problem was ultimately poor planning, and her fear that she was going to be responsible for harm to her reputation drove her decision-making.

I had her go back and instead talk with her stakeholders to negotiate a new timeline. It turns out the stakeholders were more than happy to shift the deadline a couple of weeks and it actually worked more favorably for their go-to-market announcement timeline.

Her reputation was preserved and a lot of ultimately unnecessary process change avoided.

Is the problem actually a problem?

When someone presents a problem, there’s an implicit assumption that the problem is indeed an issue and thus needs to be addressed and remediated.

That’s not entirely true. Validate this assumption, and ask yourself:

• Why is this issue bad?

• To what extent is it bad?

• Does it apply to all instances of the problem, or are there specific characteristics?

Wasting time in trying to solve a problem that’s not actually a real problem can distract from solving the real problems.

Why is this bad?

If you ask the question “why is it bad” and all you get is an amorphous trueism of “because it’s bad”, then that means you may be dealing with a perception issue rather than actual problem.

Real problems have negative effects attached to it. Perceived problems can be solved with just a mindset change.

To what extent is it bad?

This is where you can start pulling in data to validate your assumptions. If someone claims a negative effect, you should quantify it by examining the length of time the negative effect remains, frequency of occurrence, and even the dollar cost of remediation. This will ultimately give you a quantifiable impact you can us to make decisions.

It’s much easier to discuss about a problem that “costs the company $100,000 a year” vs. a problem that “takes a while to solve every year”.

Does it apply to all instances of the problem, or are there specific characteristics?

Once you have data, you can start seeing if there are patterns in characteristics of the problem or how the problem presents itself.

Find out if there’s any commonality or segmentation in the problem. Perhaps you’ll find the problems are coming for a particular source, for a particular time period, is only being experienced for a particular group, or some other factor.

Make sure you have a list of the characteristics. You may end up over-scoping your problem-solving, applying solutions to groups that aren’t even experiencing the problem, or making a mountain out of what ends up being a molehill.

Some of the engineers came to me, frustrated about configuration management.

They proposed purchasing and implementing a configuration management system to automatically notify and update the configuration when it changed. It would’ve taken several weeks and cost over $10,000 to implement.

I dug in deeper. What configurations were changing and getting out of sync? Why wasn’t the current process effectively catching it? What was the negative impact when it didn’t catch it?

It turned out that there was only one configuration in particular that one engineer was experiencing issues with. Our platform connected to a particular third-party system with a manual configuration that failed to automatically update when regular rotations would occur, and it just wasn’t compatible with the rest of the configuration management, which was reliable and automated. The engineer had rallied some other engineers into support a wholesale change of the entirety of configuration management all over this one issue.

I looked into the data further for that particular case. The issue they were concerned about occurred just 4 times in a year, and each time it took about 5 minutes for the engineer to resolve.

They were attempting to solve a $100 problem by spending $10,000. Instead, I had them document the solution steps and share it out so that it was not entirely dependent on them to know how to do - this alleviated their frustration as they were not the only individual who was able to resolve the issue.

The problem just wasn’t worth fixing.

Is the problem worth keeping?

Counter-intuitively, you don’t actually want to solve all problems, even if you can. Sometimes you intentionally take a negative effect to realize a positive benefit elsewhere.

Yes, negative things can have positive effects.

For example, if a team complains about the time it takes to test their features themselves, you may think that problem needs to be solved, possibly by hiring people dedicated to QA. However, having the team member testing features they wrote themselves may have benefits like promoting increased ownership or improving knowledge share in the team. There’s benefits to the problem being complained about, and you don’t want to throw the baby out with the bathwater.

That’s not to say benefits can’t be realized in alternate ways. The important part is to recognize that a non-obvious benefit may exist so that when you evaluate problems and solutions you can ensure that the potential benefit of the problem itself are considered.

Chesterton’s Fence

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

Is the problem worth solving?

Even if you identify a problem and validate it’s actually a problem, with real data - you still need to figure out if it’s worth solving.

People have a hard time recognizing this, but there’s an acceptable level of “badness” for most problems. There’s probably a threshold or frequency at which it becomes not worth it to solve the problem because its occurrence is so rare, or the frequency not representative of most cases.

If it turns out a problem only occurs once a year an causes a large negative effect, it may not be worth fixing if averaged across a year. A problem that causes tiny negative effects that occurs daily may still be worthwhile to resolve immediately just because of the frequency at which it occurs. This depends ultimately on the frequency of the problem and the negative effects it causes.

The value of reaching “zero badness” is often exponentially higher than reaching “low badness” and not worth the cost.

A classic example of “low badness” is that of Uptime.

Most companies would love to have 100% annual uptime, but the cost of achieving uptime increases exponentially with every 9 you add.

• 99% uptime is 5,256 minutes of downtime a year (3.65 days)

• 99.9% annual uptime is 526 minutes of downtime a year (8.77 hours)

• 99.99% annual uptime is 52.6 minutes of downtime a year

• 99.999% annual uptime is 5.26 minutes of downtime a year.

Going from 99.9% to 99.99% uptime could mean a couple hundred thousand dollars invested into improved testing and a slight slowdown in delivery to reinforce quality.

However, going from 99.99% to 99.999% uptime could mean tens of millions of dollars on operations head-count, infrastructure tooling, redundancy, personnel retraining, and process changes.

Whether avoiding that extra 48 minutes of downtime is worth it or not depends on a lot of factors, such as contractual SLAs, reputational damage, mission-criticality. If a minute of downtime costs 10 million dollars in SLA penalties, it might be worth it. However, if your SLAs are only 99%, you may be completely fine with a few hours of downtime a year.

It all depends.

Is the problem worth solving right now?

You don’t have unlimited resources. Part of thinking strategically is deciding how much to invest in solving specific problems.

Prioritization frameworks like the Eisenhower matrix (Urgent/Important) can help identify which ones are truly worth solving now.

Even if you do identify a problem worth solving now, you have to then put it in the context of your resourcing and capacity. You need people to implement the solution, and if they are already working on ten other things, you may end up creating another problem through attempting to solve that problem at the wrong time.

Even if you have people who can be dedicated to implementing the solution, you still have to look at the history of how your organization has changed. The truth is, organizations only have a limited rate at which they can absorb change. Over-activity creates an environment of churn and instability, which affects performance, morale, and retention. When you solve a problem by making a change, factor in the rate at which the organization can absorb all changes in the timing of solving the problem.

Many problems can wait and be delayed. You don’t need to do everything or solve every problem you know about immediately - otherwise it distracts from other, more important efforts. Even exploring potential solutions can be a waste of time for problems that might be minimal.

After all - if you try to chase two rabbits, you won’t catch either one.

What’s contributing to the problem?

There’s rarely a particular singular “root cause” to a problem. New leaders often attempt to boil everything down to a singular “root” cause. If only that cause could be resolved, then the whole issue would be fixed.

This is dangerous for many reasons - silver bullets are rare, especially at decisions made at the strategic level. While some problems luckily do have one or two dominant contributors, most issues executives face are systemic in nature with a complex web of contributing factors. Otherwise, why would you be wasting time on a straightforward problem with such a obvious solution?

Additionally, what you define as the “root cause” is going to depend entirely on how you frame things, which is prone to significant amounts of mental biases that lead you off track or hide the true solutions.

You frame is your particular perspective you are adopting when you are examining a problem. The frame dictates what factors or causes you identify, what causes you attribute effects to, what benefits or costs you recognize are important or not, and ultimately what solutions you reach for to solve the problem.

For example, if your framing is people, you’ll naturally reach for rationale where the root cause and solutions are people-oriented. A problem exists because people aren’t doing their job, or they aren’t competent, or they have bad mindsets or poor habits.

Maybe you view problems from the frame of culture. Now, issues are caused because of the environment - maybe people are fearful to make mistakes, or afraid to step on toes, or have too much to do.

If your framing is technical, you’ll naturally reach for causes that involve technical controls - there’s not enough automation, or the validation is incorrect, or the tests weren’t comprehensive enough.

There’s many possible frames, all borne from experience, education, mindset that lead to a person’s unique perspective. People, culture, process, technology, systems, environment, market - the frame you use has a massive impact on what problems factors you are able to identify.

If you only analyze a problem with one or two frames, then you’re very limited in your ability to ultimately solve that problem. You may not even think to address the most impactful causes of an issue. This is where including people with other frames can be useful, and educating yourself on how to think about the same problem through multiple lens. The more frames you have, the larger your palette of options for addressing a problem.

What lever should you pull to solve the problem?

Your solution levers are also dictated by your framing.

If your framing is people, then your solutions tend target people as the lever, and will aim towards things like improving training, punishing non-compliance, increasing hiring standards, etc.

If it’s cultural, your solutions might be to ensure people feel safe to learn, giving avenues to communicate, or better clarifying priorities.

Technical? You’ll implement automation, technical controls, notifications, code-quality improvements, etc.

The fact is - whatever lever you do reach for needs to also be viewed from multiple frames.

Using multiple frames requires intentionality to adjust, especially frames that are outside your “default mode”. It’s a superpower if you can do it, but most people don’t even think about it. They usually go with their default frame, whether it’s people, process, culture, systems, market, environment, etc.

Our revenue growth was off track.

The new CRO had pulled me aside while I was walking past his office. We weren’t meeting board expectations of growth, and he could feel the guillotine hanging above his head.

Coming from a sales frame, he proposed investing significant amounts in outbound sales and wanted a product initiative around optimizing for and supporting rapid, at-scale onboarding.

I knew from the data that wouldn’t work. We already had saturated many of our markets, and adding additional sales resources to an already crowded environment wouldn’t lead to increased acquisition at the levels he needed.

Our acquisition rate and onboarding speeds were also already quite good. Even a 10% improvement would have only nominal effects on the growth rate.

Coming from an enterprise frame, I saw our challenge was actually churn - we were losing customers year-over-year at about the same rate we were acquiring them, thanks to a product that wasn’t built with any capabilities that kept people coming back year-over-year nor did it give them any long-term capabilities. It was a leaky bucket that was already full, and no amount of adding to the top would solve our problem.

I instead proposed and later spearheaded product capabilities to support year-over-year needs alongside improved customer success and account management. It worked effectively in restoring revenue growth to desired levels.

Deciding on and implementing the solution(s)

Once you’ve identified a problem and its solutions - the rest is actually quite simple.

At this stage, it’s no longer about identifying the right solution, but about selecting the best solution set given your constraints.

This is classic tactical execution.

Apply your most applicable prioritization and evaluation frameworks - RICE, MoSCoW, Kano. Decide on a set of solutions that fit within your constraints and prioritize the tradeoffs that matter to you, whether that’s cost, effort, time horizon, or impact.

At this point, the conversation shifts from strategy to execution - logistical, operational, and tactical. While the “how” is still important, it an article entirely of its own.

Problems cannot be viewed in isolation.

One important note - when you’re thinking strategically, you need to think not just about the particular problem in isolation, but also thinking about the landscape of problems you have or face.

Problems (and their solutions) are all part of a system of cause and effect. You don’t just have one problem to solve or a single solution to implement, you have an entire portfolio that ultimately has an effect on each other. It’s all a part of a system.

Some of these systems are virtuous - by solving a particular problem or implementing a solution, it makes everything better in a repeating manner. Compounding interest is an example. A small amount can balloon over time as the amount that’s considered passively gets larger and larger.

Some of these systems are death-spirals - every time a problem occurs, it makes going through the cycle more difficult. An example would be bank overdraft fees, taking even more money from people who already don’t have enough.

Thinking through these requires deeply analyzing the problem using techniques like those listed here and understanding their effects - not just the first-order effects, but second-order, third-order as well.

What are the effects of the effects of the effects?

Some parting advice

• Your environment is also going to dictate what solutions are feasible, even if they are impactful.

• The speed and scope of adjustments you make depends on how much time you have to solve the problem and the number of attempts you have.

• If you have a high-trust, adaptable team, you may be able to try hundreds of minor adjustments. If you have a low-trust team, you may only get one or two shots before the team refuses to implement new changes. If you’re in a crisis mode, you may only have mere hours or days to implement a change before the opportunity goes away.

• The time horizon really matters. Ensure you’re applying the right solution to the right time horizon. Many leaders I’ve see apply a long-term lens to a short-term problem, or a short-term problem to a long-term issue.

• Some people have done the thinking for you - you’ll quickly realize who brings up problems off the cuff and who brings up problems only after they’ve thought more about it than you ever will. Trust the ones that have done more thinking than you have.

• Being strategic means improving the system, and that means being willing to take the personal negative hits if it makes the system better.

When you’re creating brand new software, life is simple. Your focus is exclusively on the functionality of the software. It’s a care-free, liberating world. Coding is an act of pure creation. If you can think it, you can build it, and typically very quickly. You could see a change in production just a minute or two.

There’s so much you don’t have to think about or acknowledge, at all.

Your focus is exclusively on the behavior of the thing you are trying to build. It’s like running through a green field with your eyes closed. You can run full sprint ahead and absolutely fly without worrying about hitting anything.

If you want to add a new page, go ahead! If you want to add a textbox somewhere, you can! Just do it.

In this green field, a textbox is just a textbox. It only takes a minute to add it.

Then, you start seeing success.

People start using your software. People start charging money for your software. Your software starts to become a product. A business forms around it. Customers start requesting things, and more importantly: they start depending on its continued functioning and existence.

People start asking for more. More capabilities. More features. More connections with other things - things that were never meant to be connected to. Other people start making decisions for thing you’re building. You can’t even call them people anymore, now they’re called stakeholders. The green field becomes a tangled bramble of needs and requests. It becomes muddy.

The brown field

In this brown field, the textbox is no longer “just a textbox”. There’s so much more to it. There’s business rules, often lost in nuance.

Rules around:

• How it’s displayed - masking, borders, colors, shapes, sizes, positions, margins

• How it’s tracked - analytics, auditing, tracking who, when, and where

• How it’s accessible - screenreaders, mobile, translations, color-blind support

• How it’s secured - character limits, XSS prevention, rate limiting, authorization

• How it’s validated - input rules, how errors display,

• How it’s expected - stakeholder training, user habits, data migrations

• How it’s operated - cost control for usage-based vendors, feature flags for visbility

• How it’s maintained - rules in one usage vs. another, reusability of its functionality

• How it’s observed - error handling and reporting, notifications if it breaks

• How it’s communicated - loading indicators, animations, user delight, labeling

• How it’s scaled - paint and render performance, server optimizations

• How it’s effective - A/B testing of impact, pre-filling of data, ease of completion

• How it’s used - if users understand it, if they make mistakes, if they’re faster

• How it’s valued - why customers want it, why the business needs it, if it matters

• …and so much more.

The textbox isn’t just a textbox anymore. It’s an entire ecosystem with a long history of past decisions, some forced by the context, and others made by dozens of people all without awareness of the other decisions. It’s connected to other elements with just as much complexity, all likewise interconnected in mysterious, likely undocumented ways. Some of those decisions may be written down or remembered, others not.

Hidden complexity

All of that complexity isn’t visible to any single person.

If you aren’t a marketer, you won’t notice that it can be targeted by the tag manager. If you aren’t visually impaired, you won’t notice it has screen reader support. If you aren’t using an lower-end machine you won’t notice it’s been made faster. If you don’t speak another language, you won’t notice it has translation. If you aren’t coming from another site, you won’t notice it pre-populates. If you aren’t the finance leader, you won’t notice the revenue impact. If you aren’t the auditor, you won’t notice the DOM has a label that’s technically a violation of a long forgotten rule.

Yet, you as the engineer still have to consider it all. You have to reckon with and factor in these decisions as you define and implement change after change after change - all under what always seems to be a tighter and tighter deadline.

In the green field, hours was enough to build an entire product. In the brown field, it’s sometimes barely enough to understand what a request is even asking for.

You have to make changes within the constraints of the past and future, known and unknown. Changes will eventually break something, and the affected party will fill a bug report which you have to then complete and fix.

That’s the price of success - people use the software and notice when it doesn’t behave according to how they think it should.

How should it behave?

It’s the hardest question you might be able to ask someone at a company that’s been around for a while.

The stakeholders in the company won’t be able to define it for you. Nobody actually knows the intricacies - not in full. You have to discover it.

So, you talk to users to find our their needs. You analyze how people are using the product. Where they get stuck. Where they click and don’t click. Where they enter. Where they leave. How all that translates into the how the user gets their job done and the company accomplishing their goals.

But, that’s still not enough.

Knowing what you intend the software to do is just part of the problem. You also have to know what it was intended to do and how it works today.

There’s no easy map - just code and history. To find it, you have to do good old fashioned archaeology. You search commit histories, Slack discussions, old documentation, random meeting notes, talk to co-workers, view logs. Bit by bit, you’re able to build context that makes your follow-on decisions implementing more accurate.

Speed vs. Accuracy

The challenge is - context building takes time. It’s time away from developing and coding. It affects the speed at which you can deliver the change. It might be too slow for the tastes of the company or your manager. You might even feel you aren’t really an engineer anymore.

When faced with the prospects of having to have “conversations about your throughput”, you might try to reverse course: moving faster, deciding faster, acting faster.

Rookie mistake - all that does is just cause you to miss some hidden interconnection nobody knew about and cause an incident. Now, you just traded the throughput conversation for one about quality.

At this point it’s easy to get frustrated. The natural tendency of an engineer is to push back. You might start to reject tickets due to “incomplete requirements”, or start approaching every change request like a contract negotiation, requiring volumes of forms to be defined and filled out.

That approach won’t work. Asking others to define it won’t help because they don’t know. They don’t have the knowledge, nor do they have the time. As the engineer, you at least have the advantage of being able to look under the hood and live in the product. For some of your co-workers, they only think about the product for 30 seconds a day - they have other day jobs they have to do.

It’s up to you to figure it out. The more you dive into it, the more you can grow and improve. Embrace the breadth. It’s not just about the technology.

Becoming a product engineer

When you’re a product engineer, you have to “wear a lot of hats”. The product hat. The finance hat. The user hat. The engineering hat. The investor hat. The customer hat.

None of them will seem like they fit.

You might find it hard to think about things from each of the perspectives. To wear each hat and truly adopt that persona as your own, even just for a minute. To think through a problem as if you were the person the hat was made for.

Well, nobody said Product Engineering was easy.

It’s difficult. It’s high pressure. You’ll constantly hear questions from stakeholders asking “Why can’t we go faster?” and “Why can’t we stop breaking things?” They might even start comparing you to other teams and other companies, not realizing those teams are on newer products and in greener fields.

It’s easy to feel stuck - to feel that any move you make is going to be wrong.

Grind away at it anyways. In situations like this, the only winning move is to lose and learn.

The mistakes will happen. Focus on improving, learning, and sharing knowledge. Focus on getting the job done.

Little by little, it’ll get easier. The patterns will get clearer. The cause and effect will start becoming automatic. The chaos will turn into complexity which will turn into simplicity.

You’ll start thinking deeply. Thinking about how the users will interact with the change. How it’ll impact the business. What they’ll expect. What they’ll want. What they’ll need. It’ll just become automatic.

You start being able to avoid problems entirely, and to find insights that have a huge impact. It’ll become second nature to think about things like accessibility and scalability while thinking about revenue and compliance and usability. You’ll be able to see the thread of how the click will translate across 20 hops to impact the bottom line.

It’ll all makes sense. It’ll all connect. You see it in your head, with every decision you make.

Being an expert

The next time you need to add a textbox, you’ll be more confident. You’ll consider the impact - to everyone: users, customers, the business, your peers, your system, your product, yourself. The non-functional requirements that many don’t even know exist, you’ll just consider through your minute-by-minute actions. You feel like you’ve got this. You’ll know you’ve got this. You’ll be wiser, faster, better.

It’ll take just a minute to add the textbox: a long journey to arrive at the same destination.

But not quite. This time, you’ll have considered the “-ilities”. You’ll have considered the things not mentioned. You’ll have done the things not thought about. You’ll have considered things that aren’t relevant now, but will be soon. You’ll have factored in the past, present, and future.

You’ll complete your ticket - not what was defined, not even what was intended, but what was needed. Whether the field is green or brown won’t matter anymore.

You’ll be happy with the result. You’ll have made it look easy. It actually will be easy.

After all, it’s just a textbox.

A big challenge I’ve experienced several times as successful startups scaled up was being able to do everything needed to keep the product running while still investing in high-impact, innovative new products.

Small startups often have an “everyone does everything” mentality, from the contributor up to the executive. People were conceptually interchangeable and could wear a lot of hats. Allocation often occurred at the granularity of an individual - specific people were assigned to projects and new areas, responsible for delivering it all.

As the number of focuses grew and the complexity of their interactions increased, it became harder and harder for the people involved to be effective. Breadth and depth far exceeded the original scope of the work, and it became too much for any one person to reasonably be effective.

Resource limitations were often the constraint of being able to both innovate and support, which made every decision a prioritization and allocation battle.

Conflict between Product and Engineering leaders increased, as obsession over time spent on ROI (Return on Investment) and how much to place on BAU (Business as Usual) flared up into full-blown arguments.

Product leaders, desperate for more progress, pulled from efforts that kept the lights on. Engineering leaders, desperate for stability, rejected new innovation projects to err on the side of safety. At its worst, this contentious relationship produced a lot of blaming, finger-pointing, and whiplash back and forth. Sometimes, one of the parties succeeded entirely, resulting in the company becoming unstable and collapsing due to an over-focus on innovation, or stagnating and losing in the market due to an over-focus on stability.

To solve this, leaders often decided on extensive meetings, detailed demands for justification of any spend, and precise explanations they were heavily involved in, resulting in extremely slow prioritization and execution delays that further exasperated the issues.

The pain is felt across the company

As one can imagine, contributors felt this pain acutely. All you had to do was ask any team for feedback, and you’d hear things like:

• “We’re doing too much”

• “We don’t know what we own”

• “There’s a lot of whiplash”

• “Leadership doesn’t understand the thousands of tiny things needed”

• “We’re wasting too much time on these tiny things”

• “My work doesn’t matter”

It’s painful for contributors to work effectively in an environment like this.

The fact is both Product and Engineering are right and wrong. You need a stable product so your users and customers keep using it, and you need new innovations so you can acquire new revenue from customers and users. It’s neither group’s fault.

The root cause of these issues stems from an organizational structure that isn’t aligned with the reality of the work. In situations like this, I’ve found a change to the organization structure that embraces the differences in the structure itself can align expectations with reality and achieve both desired outcomes.

Core/Focus

The structure is simple. Instead of expecting that every pod will be involved in doing everything, segment the pods into two types of pods - Core and Focus.

Core

The objective of Core pods are simple: keep the business running with stability.

They should have a predictable roadmap. The Core group should work in a manner where the execution and progress is highly visible - people in the organization should know what is needed, when it will be delivered by, and have solid delivery expectations.

This is the heartbeat by which other parts of the organization match their pace. Marketing can understand a release schedule. Sales can understand their commitments they can make. Support can achieve operational SLAs.

Incremental improvements can be roadmapped, planned, and executed. Known capacity can be used and planned for. Execution is predictable.

To succeed, the Core group needs the ability to say “no” and “when”. Emergencies can occur, but they need to be able to create the predictability necessary to execute well.

Focus

Focus teams, as the name implies, focus on a particular stream of work. Their job is simple: achieve the outcome they were tasked.

Focus can be on any number of things:

• Growth goals, such as to “improve user activation by 15%”

• Project goals, such as “unify product listings across our products”

• Problem goals, such as “our documentation is terrible - how do we improve it“

• Domain goals, such as “own anti-fraud capabilities”

• or other properly scoped area.

The important part of the team is that they get to focus on that particular area or outcome for a set period of time - whether that’s 6 weeks or 6 months. At the end of that time period, an evaluation can occur as to whether they achieved their goal, whether it’s worth continuing to invest in, or whether it’s time to move on to something else that’s a higher priority.

Focus teams should have the autonomy to make decisions that lead to the desired outcome, working closely with an appropriate but minimal set of stakeholders.

They shouldn’t have to run decisions by 5 other teams, or have to justify every decision they make to external stakeholders. They may do so internally - that is, evaluate the set of items that might lead to their goal and prioritize it, but they shouldn’t need to do so externally. The investment has already been made, there should be no further justification needed.

Focus teams also need the ability to focus. Yes, that means they should be able to ignore things not within their focus they were given. Whether that’s other urgent/important projects, bug fixes in unrelated parts of the product, or even developer UX. Their primary goal should be their main effort they have been assigned.

What does this enable?

This structure enables aligned expectations from the executive and management team down to the individual contributors. Team members on the focus pods know that they won’t be distracted by 10 other streams of work, and should focus on solving their key problem. Team members of the Core pods know that they won’t be dinged for not finding needle-moving opportunities, and can take satisfaction from a job efficiently completed and a problem avoided.

Organizationally, it also enables the business to execute at scale. Businesses have a clear mechanism for entering a new market or launching a new product or focusing on a new business initiative - spinning up a focus pod.

Why does the structure work?

To first understand why it works, you first need to understand the mental model for how to model the kind of work being done and what’s required for each type of work.

Just remember: all models are wrong, some are useful.

Understanding the different kinds of work

In an organization that develops, operates, and sells a product, you see a variety of different kinds of work as the business operates, comes up with new ideas, and the system evolves.

The kinds of work you might encounter can be bucketed into the following groups:

• Innovation

• Growth

• Improvement

• Expansion

• Fulfillment

• Support

Innovation

Innovation relates to doing things your organization hasn’t done before. Whether that’s entering a new market, building a brand new product, or standing up a new program - it requires focused efforts on items with little predictability. While you may ultimately desire to achieve a specific objective (eg. increasing revenues, building moats), the cause and effect can’t be predicted because it’s all new to the organization, nor can the actual specific steps be planned for with precision ahead of time.

Growth

This is work relates to pushing forward, or “growing” a particular outcome, usually measurable via a KPI or OKR. You might want to increase your customer retention rate by 15%, or increase a user activation funnel’s conversion rate by 10%. These are important achievements you want your organization to reach.

Improvement

If you have existing features, you’ve probably received or identified improvements you could make to them to make them all that much better. Whether that’s adding a new filter for a list, or allowing messages to be delivered by SMS as well as email. These are things that you received feedback on that you’ve identified an increment for that would provide some user value.

Expansion

A lot of product innovations can rise from seemingly unrelated technical improvements. A new way to model a user account can result in the ability to support team-based capabilities. A way to easily and quickly track aggregate data over time might be leveraged to create real-time leaderboards. This is the work of expansion - creating or expanding technical capabilities and increasing the real-estate upon which innovation can occur.

Fulfillment

Fulfillment is simple. There’s something that needs to be done by a set time. It might be mandated by contract to a customer, or regulator requirement. In any case - the work is known, the deadline is known, and it has to be slotted in an delivered precisely. The request has to be fulfilled for it to be considered successful.

Support

Support is the work that keeps the rest of the company running smoothly. Including:

• defect reports

• investigations or tasks for a support request

• data analysis requested by another team

• answering technical questions from customers or other teams

These different kinds of work are ever-present in a variety of different mixes in most product organizations.

Understanding differences in needs

It turns out different kinds of work have different needs for the people engaged in the work to be maximally effective. In fact, maximally effective might mean something completely different depending on the kind of work.

• Autonomy

• Context switching

• Predictability

• Risk

• Singular impact

Core needs

On one end of the spectrum is the work of Support and Fulfillment. These are often known solutions or known problems that fit within the Iron Triangle - a combination of scope, time, and cost. These require the team to have a predictable execution tempo so that capacity can be allotted and schedule deviations can be noted early and addressed. Teams may fill quarters or years with this pre-planned work, slotting in new projects here and there, and allocating capacity to fulfilling support tickets or other minor items.

No particular work here is going to be a surprising needle mover, although if it stops operating with extreme efficiency everyone from customers to the executive team will hear about it. This is the realm of scheduled work, Gantt charts, project management, utilization, and efficiency.

Focus needs

On the opposite end of the spectrum, the work of Innovation and Growth requires freedom and autonomy by the team to explore unknown problems and novel solutions. It requires the ability to focus, for extensive lengths of time, with little ROI. Risk-adjusted paths forward may require validation of assumptions or experiments, but overall - the path forward is unknown.

A team that succeeds in Innovation can have a massive singular impact through their work - like inventing a new product or allowing an organization to shift up-market. Progress is unpredictable, and as a result the team is unlikely to be working in an environment where predictions and estimates can be made with any reasonable accuracy. You rarely see Gantt charts detailing ahead of time when inventions will be invented. Teams here need to be effective, but they are unlikely to be efficient.

That is - the pod may not be fully utilized from an execution perspective. What might be seen as a team “twiddling their thumbs” is a team having space on ensuring the things they work on are the right things at the right time in the right way.

Different kinds of work need different skills and mindsets

There’s enough differences in the spectrum of Innovation vs. Support to reveal a fundamental truth: they require very different skillsets and mindsets.

The skills needed to create extremely predictability, operationalization, and meet SLAs are things like organization, process-orientation, quality assurance, and attention-to-detail. The skills needed to create extreme innovation are things like product intuition, experimentation, responsiveness to user feedback.

They are different skills, and some can be harmful when applied to projects on the opposite end of the spectrum. Imagine attempting to create a precise and accurate Gantt chart that predicts when the results of an experiment will be achieved and whether the goal was achieved before the experiment is even run - if you could, you wouldn’t need to run the experiment!

The Core/Focus structure works because it better aligns expectations with reality

By acknowledging the different needs, we’re able to structure the organization in a way that makes it easier to align expectations for contributors and, more importantly, executives.

Contributor expectations

Contributors who prefer predictable, planned work will likely prefer working on Core pods. Contributors that prefer robust cross-functional interaction and dynamic problem solving will likely prefer Focus. There’s space for both.

Executive expectations

Executives should not expect teams operating in Core to suddenly come up with a meaningful improvement to a revenue KPI or come up with a new business line. It should be a welcome surprise if they do, but it should not be relied on, nor planned for, nor should those Core team members be held to producing such results. Executives should instead rely on the Core teams to keep the company operating as it has, smoothly and efficiently, and make space for any emergencies that occur.

Executives should not expect teams in Focus to be able to hop on to different areas every other week and still produce results. They shouldn’t expect Focus teams to be able to have schedule predictability, or to know when an innovation will occur. This is not the realm where teams should be held to estimates, or to create a six month roadmap. Teams should be allowed to freely experiment without an overly involved executive demanding justification at every step.

That’s not to say each group can’t do something outside of its area of the work type spectrum. In the event that a Fulfillment project does come to a Focus pod, or a Core pod suddenly needs to pivot on an emergency goal, executives should recognize that they might be able to do it, but they won’t be fully happy.

A Focus pod might be able to complete a fulfillment project, but the predictability and precision at which they do it may suffer. This is because fulfillment requires an entirely different set of skills than innovation or growth. They may not be experienced in breaking down work to such a granular detail ahead of time that delivery can be predicted down to the hour. Even if the work gets done, executives should not expect that it will be done to the same level of predictability, quality, or efficiency Core pod could achieve.

Likewise, a Core pod might be able to develop a brand new product, but the speed and scope may be less than desired. This is because innovation requires an entirely different set of skills than support or fulfillment. They may not be experienced in not worrying about schedule or taking risks with unknown effects. Even if the work gets done, executives should not expect that it will be done to the same level of speed, impact, or scope a Focus pod could achieve.

Let birds fly and fish swim

Fish should be judged by their ability to swim, and birds by their ability to fly. A fish not being able to fly isn’t a deficiency on the fish, nor is a bird unable to swim some issue with the bird.

This structure ultimately works because it forces an acknowledgement of the truth, that a person can’t do everything. The cost of having a person or pod be able to do everything is astronomically high, and also unlikely as the company increases focuses that require more and more depth to succeed in.

Scale-up companies have a hard time recognizing that, having come from roots where heroics saved the day, and even a single person could keep the entire system and business in their head.

The structure forces expectations to be aligned with reality.

Implementing the Core/Focus structure

Figure out if you have the problem

The first step is to figure out if your organization even has the problem this structure addresses. A good solution to the wrong problem can be more harmful than the problem itself.

A post on the internet can’t tell you whether something will work for your organization or not. You’ll have to apply the context on your own. Consider the following signals it might not be right for you when thinking through the situation you’re in.

Is your organization (or unit) too small? If you only have 10-15 engineers within your company or focused business unit , you don’t really need a structure like this. 10-15 engineers can organize as 2-4 teams, and it’s unlikely the benefits of strict segmentation will outweigh the costs of inflexibility. You don’t want an unnecessary division of labor if the benefits aren’t there.

It starts to show its benefits at the 25 - 50 engineer range, where the scope of ambition, resourcing availability, and cognitive overhead start to diverge.

Is your organization too large? If you have 100+ engineers, your organization already likely organizes in some fashion related to domains or other topology. This inherently breaks down the organization into focused enough areas where this structure may not be needed. It may be helpful for sub-parts of that organization, however - the beauty is in the potentially infinite granularity.

Is your organization already fairly focused? First of all, congratulations. If your organization has been disciplined enough to not attempt to expand into different focus areas, while still succeeding, you probably don’t need this organizational structure. This structure works best to pragmatically execute when the organization is attempting to do things that are traditionally felt as “too much”.

Is your organization a project organization? Project organizations that are primarily agency-style builders rather than stewards probably don’t need this structure. Your job is to deliver a project for the client - how it gets maintained is probably not your job. This structure is intended for organizations that have a self-developed product that they shepherd over time and are attempting to balance between keeping it stable and innovating into new areas.

Is your organization already effectively handling everything? If you have an efficient prioritization process, effective product-engineering collaboration, a reasonable processing of support and operations tasks, and have achieved a good balance between innovation and operation, you don’t need this structure. You should probably keep doing what you’re doing with the process you have set up - if it ain’t broke, don’t fix it.

At the end of the day, make sure your context matches. This structure works well in an startup growing from a small 10-person, do-everything team to a growing but lean business that needs to provide stability guarantees while simultaneously expanding into innovative areas. If this doesn’t describe your organization, be judicious.

Experiment in a small dose

Dramatically changing an entire organization structure is a high risk, winner-takes-all approach. It might be fast, but it’s extremely disruptive and if anything goes wrong you’ll be the first to get the boot.

Instead, start small and validate the solution works within your unique context. You, as the leader, should act as an umbrella to the teams to create the space for them to perform this experiment.

Start with Focus

First, start with a single Focus team. Remove all other distractions and give them the ability to focus. Give them guidance and empower them to truly say “no” on everything. Task them with a problem and set a 4-week time period in which the team can cook. At the end of the four weeks, check back, and see what happened and whether it worked?

What are signs it is working?

• The pod has a healthy set of changes released that might address the problem.

• The pod understands, measures, and monitors the impact of those changes.

• The pod works together on identifying problems, defining solutions, and performing experiments.

• The team made a positive impact on the problem.

If it doesn’t work, provide guidance and ensure you’ve set up the environment for success. Do you have the right mindset? Did they have the right clarity? Did they have the right skills?

Then, try a Core team.

Second, assign a team to work as if they were a Core team.

It’s more likely than not that your Pod is already running in some variant of a Core where a team’s roadmap has to be balanced across many different things.

Take one of those teams and set expectations that they aren’t expected to move the needle on a KPI, and have them own their roadmap and schedule for the next 6-9 weeks.

Their only outcome is to achieve balance and predictability and meet their commitment. They can ease off the throttle and not have to pivot to address things reactively. They don’t have to worry about trying to push forward a metric or KPI outcome while balancing stability, intake, and operational support.

Their one job would be to set a roadmap and meet it.

Afterwards, evaluate: did either work, did neither work, did one work but not the other?

Scale the experiment

If you’re seeing positive results, expand the concept team by team.

Over time, you’ll formalize the Core/Focus split internally, and your organization will be happier for it. If it’s working, this ultimately means you have organizational buy-in and don’t really need to “sell” it.

Watch out for the messy middle

You may be left with a couple of teams that seem to be more “miscellaneous” in nature, or are still acting as something not quite Core or Focus. This is the messy middle of the transition, and you should do your best to figure out how to adjust the structure, intake, and prioritization to better align the work structure and the team.

Rotation approaches help (eg. one team focuses on a particular area, then switches off to act more like Core) in situations where you can’t quite say “no” to the work.

Over time, as long as you’re tracking future commitments and aligning them towards Focus or Core availability / capacity rather than looking at them as interchangeable, the burden should reduce.

Obtain executive buy-in

You can use this structure without buy-in from other executives, but it becomes much easier if the whole executive team is aligned with the approach - you spend less time putting your own neck on the line and arguing, and more time being effective.

Every executive team is different, but you should generally be prepared with data and narratives. You should have at your fingertips:

• The past 1-2 years of development and delivery performance, to demonstrate the impact on performance and results

  • Suggested metrics: deployment frequency, PR throughput, list of feature and product releases, user and customer sentiment, outcomes achieved, success or failure of initiatives, etc.

• The past 1-2 years of investment allocation, broken out by team and team size, to demonstrate the lack of focus

  • Suggested metrics: # of projects per team per month, average and median lead times, issue counts, issue type breakdowns

• Qualitative feedback from the team

What’s your narrative? It really depends on what your metrics say, but if you’re even reading this, you’ll like have encountered:

• Too many different simultaneous pursuits negatively impacting effectiveness, success outcomes, and morale

• Increased defect rates, or a litany of avoidable simple “unforced errors” that are par for the course on a distracted team

• A lack of predictability resulting in stability issues or operational misses

• A lack of effectiveness resulting in slower delivery or non-impactful busy-work

• A lack of iteration leading to incomplete projects, loss of responsiveness to user feedback, and breadth of product scope that lacks depth and cohesion.

If it turns out you don’t have data that aligns with the issues above - pause. Truly think about whether you are experiencing this problem and that it warrants a solution like this.

Whatever data you have, show it visually.

It’s one thing to say “we worked on 200 projects this year”. It’s another thing entirely to show a pie chart with 200 slices, and a headline saying that only six days were spent on average on any given project. Can a team realistically be expected to create amazing, innovative products if they only spend 6 days on any one product?

Aim for these two points

Your two key buy-in points you want to achieve:

• Acknowledgement from executives that there is too much being done at once

  • This means that the executives become more disciplined in not committing to major new areas without considering resourcing.

• Acknowledgement from executives to respect the resource split

  • This means that if a new initiative begins, a team must be available to work on it instead of expecting a team already working on another thing to work on it simultaneously.

Once you have it, it’s all on you to set the Core/Focus structure up for success.

Set it up for success

Think about who leads Core

For Core, you want leaders who can keep the trains running on time.

Planning, projection, orchestration, scheduling and organizational skills are key. You want detail-focused predictability creators. Capable of prioritizing and sequencing work in a way that results in the most efficient and stable execution.

The leader should excel at communication to other internal stakeholders. They' are the ones that will set the tempo and keep the organization in the loop, providing stability. They’ll need to set a sustainable, steady, somewhat slow pace.

Think about who leads Focus

For Focus, you want leaders who have high imagination and the ability to iterate to get to their desired goal.

These are your problem solvers. They shouldn’t be burdened by bureaucracy, or bothered by a desire to achieve perfect. For them, good enough should be good enough. They are the ones that can make highly effective trade-off decisions, knowing what to keep and what to cut.

The Focus teams work best filled with excellent collaborators who prefer working in real-time to solve the problem together.

Try to keep it stable

The entire premise of this structure is teams work best when they can be stable. However, sometimes you may need to move teams or people from one group or another to support major business changes.

This happens, but try to do so sparingly. As much as possible, let Focus teams focus and be effective, and let Core teams stabilize and create predictability.

Don’t be overly rigid

Sometimes your Core pods will find time and desire to work on something a bit more innovative or experimental. Other times, your Focus pods will find an operational irritation that they want to fix.

That’s OK - as long as these things don’t distract them and are, as much as possible, voluntary from the Pod’s perspective. The structure is not intended to be a prison for the contributors, but a tool for expectation management.

Working with executives using this structure

Acknowledge it requires executive discipline

Executives can easily cross boundaries and create exceptions that ultimately dismantle or render this structure ineffective. It’s important to remind people that the structure only works if the constraints of the structure regarding expectations are respected.

Align on an allocation approach

I’ve found it best when executives make their investments based on allocations. How much money and time they want to invest in solving a problem.

Executive interests vary, from pushing forward a metric, to creating a specific feature, to solving a particular problem. It’s often difficult to get everyone on an executive team to think at the level of a goal or problem. If you can do so, congratulations - you are a better executive whisperer than I.

I personally prefer an approach that allows for a bit more pragmatism to support a transition from specifying particular features to thinking about more broader investment categories.

Try not to get tied into specific projects - you can set a limit if you prefer. Instead, guide folks

towards “problem areas” or “goals" they want to achieve to secure autonomy for your teams.

Visualize capacity and focus with boxes

I prefer a simple “box” approach - it’s both easy to understand and helps illustrate the availability of chips. It aligns well with the Core/Focus structure.

When a new executive “thing” needs to be done, it helps to have everyone look at the box and ask “when and where does it fit?”

If a box already has an entry in it, the following conversation is then clear: “are we willing to drop this thing we were already going to do?”.

If there are no boxes left - congratulations, you are 100% allocated. Unless new capacity is built, or we can tolerate lower delivery and capability by shifting people around, the items cannot be worked on by the organization according to its current state and roadmap. It’s as clear as day.

You’ll have to guide people in the conversation - push back on attempts to assign specific individuals to projects (development is a team sport). Guide people against the ever tempting allure of having a Core pod do it.

Remember: you’re the first line of defense against the structure being eroded.

Pro-actively report results

You can’t just create a major structure change, and then completely forget it exists.

Organizational change management requires reporting of results, and regular evaluation of whether the structure and process are still suitable and working as intended.

Pro-active provide reports of trends in the areas the team cares about - effectiveness, efficiency, impact, morale. The metrics you shared to justify the structure change should also be tracked after it’s been implemented. A cadence of once a quarter can be a good start.

Parting thoughts

Startups have to both survive and thrive, while growing multiplicatively. It often means the structure needs to change to support the new phase of the business. Ensuring that expectations and capability are aligned from the contributor up to the executive can help ensure continued effectiveness and achieve organizational balance in stability and innovation.

Be judicious. If this structure works for you - excellent! If not, don’t be afraid to throw it out and try something else that better fits your context.

I’ve developed several products that were initially sold to directly to individual users that I then transitioned up-market.

We went from offering a straightforward product wedge directly to users to working directly with larger entities that controlled the activities of thousands and tens of thousands of users.

It required a lot of work. Our sales team made promises - metaphorically writing checks we didn’t have money in the bank for. We lost several customers after they came on board and were disappointed with the state of the offering.

What went wrong? Turns out, we under-estimated the amount of effort it would take.

The enterprise value proposition

To actually move up-market, your product needs to have some value proposition that applies to the enterprise - the larger organization that sits above your actual individual users.

What are you giving the organization purchasing your product?

• Greater control? Do they get more administrative tooling, policy enforcement levers, or access controls?

• Greater visibility? Do they get reports across multiple users, actionable insights, or usage?

• Greater interoperability? Do they get the capability to integrate with other systems they use, such as login providers, SIEMs, CRMs, or ERPs?

• Greater scale? Do they get access to capabilities useful at scale, such as automations, faster resources, or SLAs?

Is it surprising these don’t sound like anything related to your core product? Remember that this value proposition can be quite distinct from your actual product offering, or may not even be related at all.

A lot of product managers get this wrong and imagine moving upmarket as giving more advanced, broader, or deeper features of the wedge, when in reality the purchasing decision may be made because of the color of the doorknob.

I once worked with a potential customer who loved every single capability of our product, except for the fact we used Amazon Web Services to host our offering. They were a retail organization and as a result had internally banned usage of Amazon, whom they viewed as their largest competitor. To sell them on our offering, we had to explore transitioning their instance to Microsoft Azure - a completely irrelevant and useless detail in the grand scheme of what we offered, and a lot of work to boot.

Your product will change

When you “go enterprise”, you’ll likely end up incorporating some elements of the below into your product. Enterprise product functionality that companies eventually expect include:

• Account management

• Account provisioning

• Analytics

• Auditing

• Authorization

• Billing

• Branding and white-labeling

• Configurations

• Cost projection

• Custom domain names

• Data interchange options / integrations

• Data residency, lineage, and ownership rules

• Email control

• Exports

• Infrastructure

• Ingestion

• Invoicing

• License management

• Reporting and insights

• Security controls

• SOC2 or other compliance (eg. WCAG, PCI)

• SSO

• Team member management

• Webhooks

These represent the iceberg that is enterprise products. It’s not just offering a tool or wedge to “process a payment” or “streamline a process”. It’s offering that on top of a cohesive platform. In effect, your product offering becomes your meta-product.

Your org will change, too

There’s also enterprise capabilities that your organization will need to be able to support and operate via various programs:

• Completing RFCs, RFPs, and RFIs

• Supporting unique billing such as invoicing

• Multi-tenancy and data segmentation

• Monitoring and reporting, service SLAs

• Disaster recovery, including failovers, backups, RPOs and RTOs

• White-glove service, account management, escalation paths, response SLAs

• Support plans and roadmap influence

• Legal ownership of intellectual property ad data ownership

• Compliance with laws and regulations, both real and perceived

• Change management, including notification

These need to be defined, operationalized, documented, and facilitated for customers and prospects. It also increases internal coordination needs as well - for example, you wouldn’t want a Salesperson committing to an Uptime SLA that the Engineering organization couldn’t meet.

The secret - you may not need all of these

The dirty secret is that some of these may be absolute requirements to sign the contracts, but ultimately doesn’t matter to the customer after contract signing. They just needed to check a box or meet some internal political need.

What you need to commit to and what you actually need to implement can sometimes be determined by people who weren’t part of the contracting and purchasing process at all - the operations and implementation team on the customer’s side.

While the purchasing team may happily be operating under the assumption they received everything, sometimes only a few capabilities end up getting used operationally.

It’s important to identify and prioritize the capabilities that are actually used, and find wiggle room in the ones that aren’t actually important. Be up-front and really dig in to why something is being asked for.

Sometimes you have negotiating leverage to strike away an item. Other times you can get a feel during negotiations that an item isn’t actually all that important post-signing.

Don’t lie to the customers - that’s a fast way to lose all reputation and irreparably harm your organization plus open yourself up to lawsuits. However, you may be able to find an alternate, simpler solution that mutually fulfills the customer’s internal requirements even if it doesn’t meet the letter of the contract while allowing you to spend your investment allocation chips elsewhere. Working directly with your customers on finding these alternate approaches can be in everyone’s best interest.

I once spent several months developing an enterprise-customizable role-base access management system to enable an enterprise prospect. When they finally started using the product, the overwhelmed operations admin couldn’t make the time to learn how to configure it, and asked our internal account management team for help. We set it up internally, and they were quite happy, and never changed the tool again. What was initially a critical contract piece ended up never being used by the customer once they started using the product.

Operationalization

Of course, not everything can be deprioritized. At some point, you’re going to have to actually deliver on the capabilities you agreed to. That’s where you have to recognize that it’s not just about the Product.

Enterprise capabilities are just that - enterprise capabilities. They cross functional boundaries and impact almost every part of the organization.

You have to work with many, many different functions to deliver successfully on the contract. This means playbooks and runbooks for various processes that multiple parts of the organization participate in. Documentation is

key here, as is training and pro-active facilitation of any new process: you can’t just release a new process and expect it to be followed.

Even something taken for granted such as “onboard a new customer” may have a surprising amount of nuance and complexity that involves:

• Reviewing the contract terms

• Provisioning the account according to those terms

• Configuring the account according to the customer’s specific needs

• Training the customer on how to use the product

• Answering questions from the users

• Coordinating with marketing for announcements, if any

• Monitoring usage to encourage adoption

• Scheduling and developing any committed customizations

• Starting billing and invoicing

• Preparing tier-1 support teams for new questions

Things can start to fall through the cracks as communication and steps occur between roles like account management, sales, solutions, legal, marketing, finance, support, security, and product. Without effective tracking, checklists, and process, you’d end up with an inconsistent, non-repeatable customer experiences with a lot of key steps being missed.

Multiply that by the number of other things you have to do to support enterprises, and you start seeing why the product itself is just the tip of the iceberg.

Larger companies have dedicated people for each of these steps, but in smaller companies it may be a single person performing all of these steps on top of their day job. At prior small companies, I’ve had to do all of the above on top of actually developing the product!

To move to supporting enterprises successfully, you need strong relationships with all of your peer functions and disciplined facilitation and execution. No customer will remain with you if you string them along or break promises. Think deeply about not just the product, but how the very act of selling to a new kind of customer changes how you operate at the company.

Everyone knows how jarring a transition it is when moving from an individual contributor to a manager. Everything changes: the skillsets, the responsibilities, the scope, the tradeoffs. There’s been plenty written about supporting ICs through that.

Significantly less is available on the just-as-jarring transition from middle-management to executive. The stakes are higher, and the scope and responsibilities wider, and the possible impact exponentially larger.

Having been in the executive-level leadership seats multiple times now, I’ve learned a lot of lessons. I hope these lessons help former managers who may be new to the executive role, or managers who are thinking about entering the executive role.

What have I learned?

• People will be unforgiving.

• There’s little margin for error.

• You shouldn’t solve all the problems you see.

• The best solution might harm your team.

• Every decision you make will have someone who hates it.

• Executive discussions can be messy, intense, and unfiltered.

• You have to accept blame for things you didn’t want to do.

• You have to accept blame for things you had no control over.

People will be unforgiving.

As a leader, your actions and reactions create the environment your organization operates in. That shapes how they behave and think, whether they feel safe to act or not, and whether they are ultimately effective or ineffective.

You do your best to create an environment where people are nurtured, free to make mistakes while still being held accountable, and free to bring their best selves to work. You might call it creating “psychological safety” or allowing people to be their “authentic self”, and it’s your responsibility as a leader to make space for your team to do their best work.

Ironically, that benefit will not extend to you as an executive.

This surprises many middle managers who rise up the ranks under the protective environment their leader has developed, only to find that the protection stops at some point between Director and VP.

The truth is that the people in an organization don’t want their executives to be their authentic selves, with warts and flaws, even if they say they do.

When was the last time you heard an executive flaw spoken about as “they’re just being authentic?” If anything, any issue is highlighted as a sign of their unsuitability to leadership or indicators of incompetency. People derive judgements, not understanding, from flaws, mistakes, and foibles.

Most people want flawless leaders while simultaneously not wanting to be held to that standard themselves. People don’t want leaders who have a quick temper, or lose their cool in crises, or are unavailable because they are busy, or don’t know their work extremely deeply, or are late to meetings.

As an executive, when you fail to live up to the standard of perfection (which you will, often), you will hear complaints and criticisms from many different directions. In the rare situations you do manage to be perfect for a season, people will then hold you to account for being too perfect - intimidatingly unemulatable.

There’s no winning. There’s no perfect. You have to be willing to accept that, while still striving to be the best you can possibly be.

Although difficult, you have to not let this reality change how you view other people. Continue creating safe environments where people can grow and improve and bring their best selves to work. While you may not be covered by the umbrella, it doesn’t mean you can’t continue holding it for your team.

Once, after a round of lay-offs, I had to prioritize the survival of the company and push the team to release a set of capabilities that would stabilize the company and help it live to fight another day.

We released it successfully after several weekends, and while it was positive and impactful, the team was spent. I told the team to rest up, while simultaneously pushing back heavily against other leadership’s demands to do even more. Both were important: to give space to the team to rest but to also ensure the company continued operating.

To support the team, I personally worked nights and weekends to give the team a normal schedule for a few weeks. This was successful - the team was able to work standard hours, and we still managed to deliver additional key initiatives during a tough time for the company.

In my review that quarter, the team complained heavily about being forced to work after-hours to save the company. They also complained about my own after-hours work, noting that they felt it set an unrealistic expectation.

There’s very little margin for error.

If you’re working in a healthy organization as a manager, you’re not going to end your career over a mistake. They’re treated as learning opportunities that are necessary part of the improvement and growth that people experience. Sure, you might have to discuss the details with someone, or implement follow-ups or action-items to improve, but that’s not even a slap on the wrist - that’s just healthy retrospection and improvement.

Managers are often in for a shock when they become executives and realize they no longer get that benefit of doubt that has enabled them to learn and grow. There’s very little margin for error.

In some cases, mistakes are a “one-strike, you’re out” situation.

Why?

At the executive level, the impacts of mistakes are magnified - consistent excellence is the expectation.

This standard is correctly higher for executives. When you make a mistake as an executive, it has the potential to lose millions of dollars or cause an organization to collapse.

You need people in those seats consistently firing on all cylinders.

Minor things can set off a chain reaction that leads to a failing in the role. I’ve seen dozens of such moments across the companies I’ve worked with. First-time executives may expect forgiveness only to encounter a job-ending landmine.

Even in my own career, I’ve lost out on promotions or had teams pulled because of a mis-step I’ve made, and even in some occasions something one of my reports did against my explicit instruction.

Some of the reasons I’ve personally been penalized as a leader:

• One of my reports wrote a passive-aggressive message to their team

• One of my reports didn’t manage a new report on their team effectively

• Publicly favored a recommendation by the COO over the CTO.

• I made a joke about sunsetting a product that was close to the C-level’s heart

• I spoke up against an unnecessary multi-million dollar expenditure

Penalties at the executive level aren’t a simple talking to. Instead, they’re significantly more impactful: a harm to the company, a loss in team, a rejection of a promotion, or even an eventual replacement.

I’ve seen other leaders penalized over things like:

• Putting in the wrong number on a presentation

• Having a bad day and momentarily losing their temper in a single meeting

• Not matching the communicativeness of other leaders

• Disagreeing with someone in a public forum about a key issue

• Being surprised at news about one of their projects that they should have known

• Having a message’s tone misinterpreted by a key stakeholder, leading to conflict

• Having a highly visible but fairly minor project delayed

• Making the wrong hire

• Taking too long to hire

• Accidentally forgetting to do a task amongst the hundreds on their plate

• Their boss leaving

You typically don’t get a warning when people lose confidence in your leadership. It just happens.

In the hot-seat, first-time executives can get paranoid and more controlling, unintentionally inflicting further and further harm on their organizations. They eventually create a self-fulfilling prophecy where their desire to be perfect causes them to fail. It’s an unhealthy mindset that takes a huge perspective shift to combat.

The best way to deal with it? Take these hits on the chin and adapt for the best of the organization. Help support your organization, your team, and your reports. Accept that things will happen, and you’ll do your best for as long as you can, and you’ll leave the organization better than you found it.

That’s really all you can do.

You shouldn’t solve all the problems you see.

When you’re an executive, every single problem in the organization is visible to you across the entire organization. Personnel conflicts, failing processes, strategic mis-steps. Everything.

These problems are also rarely within your direct ability to solve. Some problems are intentionally left alone to help further another organizational goal. Others are problems, but they are a low priority relative to other problems the organization is solving.

Even trying to solve a problem can cause a whole host of issues that lead to significant waste and even more issues, especially if it crosses organizational boundaries. No executive likes it when someone else solves a problem in their organization that they were already handling, causing other unintended issues as a result.

Executives have to have the ability to view a problem, and accept that:

• It isn’t time to solve that problem

• Someone else is already solving that problem, and you should not be involved in any way

• The problem may not be one we want to solve

This, as it turns out, is extremely difficult for people who come up from management, where the whole role is about solving all of the problems within their view. As a result, they start to get overwhelmed at the amount of problems, or over-step in their desire to help, causing more issues than they solved.

The best solution might harm your team.

When a first-time executive solves a problem, they often apply manager-level thinking, optimizing for their function and near-term time horizon. This usually solves the immediate problem but negatively influences a farther-term outcome.

It’s often the cause of feedback of “not thinking strategically”.

Imagine a first-time executive who sees complaints from developers being frustrated with deployments, and fights to build a new team to handle those operations. They successfully argue for a million dollar budget and build the team. That leader might view that as a win in the short-term: they got the budget and they were able to hire and solve an immediate developer pain point. But at what cost? What else could the money have been used for in the organization? What happens if that budget was taken away from a new marketing initiative, or a struggling sales organization?

What about the mid-term? What if that new team takes on operations, causing disruptions to day-to-day activities as they onboard and make mistakes. Bottlenecks start to form. Batch size increase. Change failures and incidents occur more frequently.

What about the long-term? What happens when the rest of the organization loses their knowledge of how to set up operations, and as a result the organization’s ability to safely deliver changes rapidly to production decreases. Gate-keeping behaviors start to form, and hand-off cultures start to be developed between development and operations. Blame culture starts to develop when things go wrong.

Eventually, what seemed to be a huge win initially turns out to be a massive liability.

Why is this so different?

When you’re a manager, your problem space is your teams. Problems are immediately within your area of responsibility to solve. You see occasional challenges with your peer teams, but otherwise you don’t have to deal with fixing those problems - those teams’ managers can handle them, and other things can be escalated.

The problems in the managerial space are mostly tractable - they all have some sort of solution that you can discover and deliver that provides relatively immediate feedback on whether the problem has been solved or not. Trade-offs inform which solution is “better”, and these are typically articulated by the executive leadership.

When you’re an executive, problems have complex inter-relationships involving differing trade-offs, information asymmetry, and a web of complexities inherent in the organization.

Most problems you solve will not have clear or easy answers. Each one will have long lists of pros and cons with large, lasting impacts for getting it wrong. There’s typically no “right” decision at all. Just a bunch of decisions that’ll have positive impacts to some and negative impacts to others. Some are intractable - things that will never be solved, only mitigated.

Many solutions have different outcomes depending on whether you look at it across months, quarters, or years - a roller coaster of ups and downs far disconnected from the original decision. Optimizing a solution for the wrong time horizon may result in many downs later in the track.

It makes sense - if the decisions were easy or straightforward, anyone could make them and the executive wouldn’t be needed to make that decision. You’re only involved in that decision because of the implication and potential effects. Someone has to take ownership for that decision, and that’s the executive.

When you’re an executive, you have to think across multiple time horizons and scopes. Sometimes, you do what’s worst for your team or even yourself in the short-term to mid-term to ensure you do what’s best for your organization in the long-term.

Every decision you make will have someone who hates it.

Because of the scope of the problems you are trying to solve, and the pros and cons of them all, it means that every decision an executive makes will have detractors somewhere in the organization.

Managers are used to an environment where they can reliably keep most people happy and satisfied through their actions. They operate at a layer where they can build direct relationships with their immediate teams, and effective decisions are generally mostly aligned with team happiness. Good managers keep their teams morale high and often find solutions that optimize for their team’s happiness and the team’s effectiveness.

When managers become executives, the amount of people who might be unhappy at something they do can be shocking. Most decisions do not have an “everyone is happy” solution.

I have a rule of thumb that I follow with any decision I make:

• 30% of the org will be unhappy, and tell you

• 30% of the org will be happy, and won’t tell you

• 30% won’t care either way

• 10% will dislike it enough to complain to your boss

This means every decision, no matter the outcome, will be second-guessed by someone in the organization who has a less nuanced perspective. People will talk about how you made the wrong call, or should have done something completely different. They’ll bring up their issues to you, their peers, others in the organization, and yes - your boss as well.

As an executive, you (and your boss) will mostly be hearing negative feedback about what you do. It’s a tough transition for managers where in the past doing something successfully meant everyone in their sphere was happy. It’s hard for people who are used to calibrating via positive feedback.

If you have a good boss who listens to the negative feedback they get, nods their head, and doesn’t use it negatively against you - great: you’re in a perfect situation where you have your boss as a partner. They understand the realities of being an executive and have your back.

If you have a boss that takes any piece of negative feedback they get and immediately penalizes you and uses it against you: not so great, because you’re naturally in a role where everything you do will have some negative feedback around it.

The best way for managers-turned-executive to deal with this is to not stress about trying to make everyone happy. Instead, their goal should be to make the organization more effective. Calibration should be done on the desired outcomes and time horizon, not whether people are happy about it or not.

I once organized a change that involved spreading subject-matter-experts across each of the teams to support increasing their access to domain knowledge.

We were previously following a center-of-excellence model that simply was not working: bottlenecks were forming, there was a lack of incorporation of their expertise, and there was a lack of awareness of ongoing work.

Once I announced the change, there were significant complaints about it from various parts of the organization, some of who went above my head to the president to complain. They wrote pages and pages of how this was a terrible idea and how I was an ineffective leader and also demanded a meeting.

The president, luckily, was not a reactive leader. He met with me and I explained the reasoning, and he understood and disregarded all the negative feedback.

Three months later, the change had been extremely positive. As a result of having direct, dedicated access to experts, tams made significantly better decisions that were effectively de-conflicted and were no longer bottle-necked on a central committee.

Executive discussions can be messy, intense, and unfiltered.

Managers might envision an executive team as some sort of organized secretive group of wise experts sitting in a dark room with robes like Illuminati. They carefully and cunningly discuss problems and cast a secret vote on a solution that then gets imparted to the masses.

In my experience, executive discussions are a lot messier. Truly difficult decisions tend to be more like an all-out brawl where ideas quickly get presented, shot down, swiss-cheesed, and built back up. It’s a raw mess that can get quite intense. It’s often the opposite of most team-level manager-led discussions that are usually organized and more harmonious.

People who get a glimpse into how the sausage is made may come away with the sense that the executive team is chaos, or doesn’t know what they are doing.

That’s not an accurate perception.

When you are dealing with potentially intractable problems across a dozen different functions, the ability to rapidly hone in and really debate is key to arriving at a decision that weighs the tradeoffs in the manner best for the organization as a whole.

Managers may be used to softer, more harmonious approaches to discuss and debate ideas with their team, but these only work when the team is composed of mostly aligned individuals that are part of their function or peer function. Their first contact with an executive discussion might be extremely jarring: punches are not pulled, people say what they need to say, and ideas are shot down just as fast as they are brought up.

The lesson managers can draw? Don’t take things personally, and always be willing to speak up, dive deep into details, and make ideas better. Things left unsaid are misalignments that can later sink the success of an initiative.

You have to accept blame for things you didn’t want to do.

As an executive, you fight the good fight, make arguments, have vigorous debates, but at the end of the day the company may not do what you want. Maybe the other executives arrived at a different decision, and you got outvoted.

You then take that decision, fully align your organization, and deliver and execute on that decision as if it was your own. That also means fully taking all the flak from that negative feedback related to that decision.

People call it “towing the company line”, or “presenting a unified front”. It’s exceptionally important in an organization that leaders appear aligned - it causes significant dysfunction when there’s an appearance that they aren’t.

If you do this correctly as an executive - when your reports disagree about a decision, they will blame you.

You have to take that blame and accept it. You can’t pass the buck in any way - if you say “it wasn’t my call” or say “I disagreed, but…”, it creates cracks in alignment that harm the organization. No matter how much you disagree with a decision, or how unfair you believe it is, you have to keep these in private with other executives and not let it leak to others.

You have to accept blame for things had no control over.

While you might make decisions at the executive level, the actual implementation of that decision falls to people multiple levels below you.

When an individual contributor four levels below you does something incorrectly, you can’t just go and chain jump down and correct that contributor. If you did, you would undermine the delegated authority of your entire chain of command. Instead, you have to go through channels and hope that the message gets across.

Once issues comes up in the executive level, you can’t blame the individual contributor that did it. Every issue that occurs in your organization is your fault as an executive, since you created the environment for that failure to occur. You take the blame, and you tweak the environment to achieve better outcomes the next time, working indirectly through your leadership and management chain you implemented to affect the changes.

Becoming an executive can be a jarring transition for managers. Knowing what to expect and how to adjust your thinking to effectively deal with the new context will help you succeed in the role.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

After you craft a proposal, you need to effectively deliver it to the decision-makers and stakeholders. Knowing how to effectively tell your story and manage details can determine how successful your proposal is.

Concisely summarize

It’s really important to know how to summarize your proposal concisely. Leaders and executives typically don’t have a lot of time, and your item is likely on a long list of asks and problems they have to address.

Think about what your proposal - a summary structure will likely follow these patterns:

• “I’ve looked at this situation, and we should do this for these reasons.”

• “There’s a big problem here, and I have a path forward - here it is.”

• “Here’s a quick description of what’s happening. here’s what we’re doing next.”

• “Here’s what I need to achieve this result.”

• “I have additional information - I need guidance on directives based on this information.”

You need to be able to quickly:

• Make your ask clear

• Establish context of the problem

• Establish context of the ask

Remember: the value of the planning is in the plan. While you may not ever show anyone your proposal summary, crafting it allows you to think through it in a way that the major points are clearly laid out and addressed.

Make your ask clear

Most of the time, you are asking for something: a decision, a resource, information, etc. If you can’t articulate your ask and why you are asking in a single sentence, you aren’t being clear enough.

It’s not that you'll always present it in that short a format. It’s just that the skill of boiling it down is valuable for distilling the essence of whatever you want out of your proposal and drives attention to exactly what you need.

Once you understand what you’re trying to ask/recommend/conclude, start with that.

An example of a proposal summary to give raises:

I need to redirect $1,000,000 previously earmarked for additional hires into increasing compensation for existing team members.

Due to our rapid growth and lagging compensation strategy adjustments, we currently have new junior developers making more than tenured senior high-performing contributors.

The recent accidental leakage of the company salary spreadsheet has caused significant morale issues in all of our high performers, with churn expected for over 30% of our team as a result of this issue. Losing our top performers will ensure we will not meet our funding goals for this year.

We must ensure we balance and achieve equitable compensation for our team to be able to move forward. Losing all of our top performers is not an option.

Establish context of the problem

You can’t just ask for something and expect to get it. You need to have a reason or “why” behind your ask. That’s the context you need to summarize and deliver.

Context requires:

• Explanation of a problem

• Explanation of the cost of the problem

• Explanation of the value of solving the problem

• Explanation of the stakeholders of the problem

Most importantly - you need to establish the magnitude of the problem. Revenue terms are often the most impactful, but other framing like reputation, risk, retention, etc. can all be effective depending on your audience.

An example of a proposal summary to change an incident response:

We’ve experienced a quarter-million dollar incident, folks, and we are on the verge of making it worse with our recovery plan - I need alignment on a different plan.

Due to our earlier decision of releasing our fund management dashboard before testing was fully completed, a severe defect was identified in our refund logic. The defect, now fixed, temporarily allowed users to issue repeated refunds for the same transaction, which pulled money directly from our bank accounts. Operations has identified our system automatically issued $230,000 in duplicative refunds that we are unable to claw back automatically. Their recovery plan involves pursuing legal action against our top customers to claw back the money.

This will greatly damage our reputation with customers far beyond the cost of the incident. I recommend instead that we eat the cost as the reputation damage will out-weigh the funds recovered.

Establish context of the ask

Chances are if you are making an ask or proposing something, you already have a solution or direction you’d prefer in mind.

This is your intent or recommended solution. Be sure this is extremely clear and show evidence you’ve done the thinking.

I’ve seen many a proposal sink because the proposer didn’t make it clear what they were specifically asking for and why, or that they didn’t prove they did the thinking to provide confidence in their proposal.

Context requires:

• Explanation of your ask/intent/solution/recommendation

• Explanation of why of this approach

• Explanation of tradeoffs and factors

An example of a proposal summary to change a technology:

I intend to transition our company from UJS and onto Vue.js.

We’ve experienced dozens of critical defects in just the past month and extremely delays in even simple front-end changes as a result of complicated UJS and lack of front-end or Javascript knowledge in our organization. If we wish to achieve our company’s development outcomes, we must address the root cause of the issue - our company’s increasing struggle using an outdated technology to achieve outcomes it wasn’t built to support. This requires a new front-end technology.

Vue.js, while new to me, is an extremely similar technology to Angular 1 that I am a deep expert in and can effectively train and educate a team around. I can, within three weeks, rapidly set up a front-end component and infrastructure system and conduct trainings to educate the team. I expect that even our back-end engineers can effectively make front-end changes within 2 weeks.

I evaluated other technologies like React and Angular 2 and found them quite difficult to use relative to the simplicity of Vue.js. The lack of in-house expertise also makes these challenging to build expertise for across the team.

Transitioning to Vue.js will greatly accelerate our product development efforts by a factor of 3x with higher quality, design fidelity, and lower defect rates.

Use the right proposal medium

One you have your proposal locked, you need to use the right proposal medium to communicate your proposal.

• Presentations

• Written documents

• Group discussions

• 1:1s

• Instant messaging

Presentation

A slide-deck presentation can be effective for asks to groups where the high-level details are enough to make a decision.

Some things to keep in mind:

• Presentations aren’t great at diving into things or explaining a narrative.

• If it requires deep thinking, it’s likely not the appropriate medium.

• Keep it short. Less than 10 slides should be plenty. If you need more, you may benefit from another medium.

• You’ll still likely need to prepare supplemental materials that dive into details.

Written document

A written document detailing your proposal can be extremely effective. You have tons of space to add details, explain thought processes, and dive deep.

Keep in mind:

• It has to be extremely well organized. Without an effective narrative structure people will get lost.

• Use the “newspaper approach”. Start with the headline, then summary, then go into details. Ensure you don’t start at the details or else people will get lost. Your conclusion should always be clear.

• People may not have time. If you’re talking with your leaders, you want to be cognizant of their time and effectively leverage their attention span. A dense, multi-page document may just not be read.

Group discussions

If you need decisions from multiple people at once, or there’s a lot of stakeholders that might have thoughts, it’s useful to have a group breakout discussion.

Keep in mind:

• It can easily derail. Try to redirect people back to the subject or topic at hand.

• Objections are highly visible. It can drag down decision-making or confidene in the proposal if people get stuck on the fact objections exist. It’s always useful to frame the objections and remind people of the magnitude or relevance to the decision at hand.

• Discussions may get uncomfortable. Handling public objection is a learned skill, especially on a proposal you may have crafted and have a vested interest in. Learn how to not take it personally or get nervous when conversations get deep and questions get extremely pointed.

• Ensure enough time on the agenda. Some people think a decision is going to be made quickly so they only reschedule a few minutes. When discussions run long, the context-setting or decision gets deferred for other matters, which causes decision-makers to sit with incomplete information. The incomplete information can bake for days or weeks into an uninformed perspective or decision, derailing hopes of proposal acceptance.

• Know where people stand. You can use 1:1s to shop around a proposal and get thoughts before presenting to a larger group. This helps you incorporate new perspectives, address objections, and find weaknesses in the proposal early. Just don’t ask for a decision - make it clear it is a work in progress.

1:1s

1:1s are a great avenue for shopping a proposal around. People typically are more open about their thoughts than they are in group settings, and you can really dive deeply and openly into the thoughts around the proposal.

Keep in mind:

• At executive leadership levels, some 1:1s don’t stay 1:1.
  
  At individual contributor and manager levels, people can generally correctly assume 1:1s are 1:1s - nobody else will ever know. At leadership levels, things discussed in 1:1s are not automatically restricted to just those two people.
  
  It may surprise those not used to it, but it makes sense if you take a step back and think about it. When you’re talking to an executive and proposing an idea that impacts the company, you’re talking to a representative of the company and other leaders. If you propose something related to the company or is relevant to other executives, it’ll naturally get discussed with other executives. Decisions don’t happen in isolation - if you bring up something affecting a function, it’ll likely get brought up to that functional leader to address.
  
  This is pretty easy to deal with - be explicit if you want something to remain private. The strength of your interpersonal relationship with that person helps keep things private when you want them to be.

• What people say in a 1:1 may differ from a group.
  
  I once secured “buy-in” on a proposal to change the organization structure from every individual decision-maker, only to have all the individual decision-makers disagree with the proposal when I presented it to them in a group - despite them all individually agreeing to it!
  
  It wasn’t that they were lying - it’s just that the dynamics of group decision-making can’t be avoided. There’s external pressure, perception management, personal factors all interplaying in real-time during a group discussion. How one person personally feels and thinks may be completely different when in a group.
  
  In the case above, I pointed out that they all actually agreed with the proposal individually, which helped reset the decision in the group.

• Interpersonal relationships really matter to the honesty of thoughts.
  
  Honesty requires trust from both parties. Trust is a sensitive thing where history, competency, integrity, perception all play a key role in determining how open, truthful, and direct you can expect a relationship to be.
  
  It’s key to maintain good relationships with people you work with, and to not let ego, personal disagreements, or pettiness disrupt your working relationship. Work is work, and it really shouldn’t impact your perspective on someone as a person and human being. My advice? Always keep the other person’s best interests in mind, and support them when you can.

Instant messaging

Sometimes you don’t need a formal touchpoint to submit a proposal or get a decision.

You can just send an instant message, either directly to a single person or or in a group.

Some advice:

• Try not to write a wall of text. Your shortened summary statement actually help here an comprise the bulk of the message. You can link to additional details in another written document at the end of your message.

• Be cognizant of message visibility. It’s easy to accidentally include more people than needed in a decision, or to forget a key decision-maker when making a group chat. Always double check your list and adopt a ”just enough” approach to decision makers to avoid an awkward situation where you need to remove someone or include someone after a decision was made.

• Expect it to go into overtime. Some decisions may end up being larger an require deeper discussion. These tend to experience a medium change, such as being deferred to a breakout discussion or put on the schedule for the next committee meeting. Try not to push too hard after this point and wait for the time if you can.

• Tone gets lost. If you find that the conversation is going nowhere, it might be a matter of talking past each other. Defer to a breakout or other conversation where people can align and get a better sense of where they stand than what instant messaging provides.

• Keep a separate decision log if you’re dealing with a long-lived complex chain of decisions. Decisions tend to get lost amidst message an channels. If your proposal or decision involves a long-lived topic, it’s helpful to keep a decision log to track them over time, particularly if people forget what decisions were made in the past.

The amount of thinking that goes into a proposal does not need to be reflected in the actual delivery of the proposal itself.

I once wrote up a 10-page document on an organizational change. I articulated trade-offs, discussed alternate options, discussed failure modes, success criteria, and all manner of thinking into an extremely detailed, cohesive plan, complete with charts and data.

Once I did that thinking, I sent my CTO a two sentence instant message letting him know that I had a plan to adjust the organizational structure, and that we would not need more money. The CTO, satisfied, approved it.

Other advice for delivering your proposal

Be ready for a lot of questions.

Leaders, especially executives, will hone in on the stuff they care about. Some proposals might have zero questions, but others might have dozens.

Some questions might be very surface-level, others might drive extremely deeply even into areas you wish they didn’t go into. While you should do your best to preemptively think of and answer questions, it’s unlikely you’ll be able to address every single question before they are asked. Some questions are intended to poke holes, others are to help the leader build context. Some might just be intellectual curiosities for the asker. Some might be because there’s strong disagreement. Others might be because there’s strong agreement. You can’t assume the intent from the question alone.

Answer them factually and don’t get anxious or take offense. It doesn’t mean the leader is against the proposal - they just want to better understand it. I often see people answering questions with “justification” answers - trying to make themselves and their proposal look good vs. answering truthfully. Some end up blabbering in an effort to avoid answering the question. Neither builds confidence in the proposal.

An IT professional once gave me his proposal for securing our physical office network infrastructure to achieve compliance with PCI regulation. I asked a lot of questions. Questions about the tradeoffs, the cost, the firewall capabilities, the hardware maintenance costs, the setup and management time, personnel requirements, and more.

By the end of it, I was extremely convinced that the person had done their research and kept our company’s best interests aligned, and had considered the risks, benefits, and constraints thoroughly. While we had minor disagreements in approach, they were personal preferences or unimportant quibbles.

I approved his proposal in its entirety.

In a conversation afterwards, his boss said that I had scared him during my questioning. Because I was asking so many questions, the IT professional had believed that I was fully against the proposal and was trying to sink it. My questioning came across as intimidating.

Know when to stop talking

Whether it’s nerves presenting to an executive or just personality differences - some people just keep talking far beyond when their point has been effectively made and the proposal is ready to be decisioned.

Sometimes, this causes other areas of concern to open up, derailing a conversation or causing other factors to take precedence that change the decision.

It’s important to read the room and know when your point has been made. A useful mental model is to view your role in the delivery of a proposal as setting the stage for a show about making a decision. You’re not there to act in the show, so get off the stage before the show starts.

Useful phrases in your toolbox

Adapting to objections and changes in real-time can be difficult for some people, but it’s useful to have some phrases you can fall back on to help direct your thoughts.

Some of these phrases include:

• “I don’t recommend that, and here’s why...”

• “We did analyze that option and do not recommend it because…”

• “We can make that work, but our belief is that the more effective option is…”

• “I think that’s a great idea, and we can get started on it immediately/as soon as you want, provided…”

• “I defer to you all, but my personal opinion is…”

• “That’s a fair point, where does it fall in the set of tradeoffs we need to make?”

and so on.

When you adapt or address an objection, counter-proposal, or other statement during delivery of your proposal, make sure you:

• Make it clear you understand the objection or counter-proposal

• Make it clear you’ll commit to any decision that does get made

• Make your own position / recommendation clear

• Make it clear you are flexible when you are, and not flexible when you aren’t

Don’t worry about the credit.

You might not get credit or recognition.

Proposals can sometimes change form in tiny or large ways. This may muddy the waters as to who is responsible for a brilliant idea. Sometimes it’s the last person who spoke and had their idea incorporated. Other times it’s the most authoritative person in the room. I’ve had reports take full credit for something I explicitly prepared and directed them to do as if they came up with the idea themselves.

At the end of the day - it doesn’t matter. Trying to get credit might mean you reject otherwise good improvements to your idea, or lose someone who could’ve successfully drove it forward. It might mean you focus too much on optics instead of substance.

Remember - your goal is to affect organizational change, not get credit. Don’t worry about recognition - it doesn’t matter.

Focus on the goal: improving the company.

Having a great idea is unfortunately not enough to get it approved. The delivery of your proposal highly impacts the odds that proposal is approved. Stack the deck in your favor by avoiding common mistakes and making it as easy as possible for decision-makers to decide.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

Objections

When you deliver your proposal, you will get a response of some kind from the stakeholders and decision-makers.

While we all hope it is full-throated acceptance and a round of applause, it is extremely unlikely that will happen all the time.

Instead, you must be prepared to handle objections and the various responses you will receive. Handling might mean redirecting, debating, incorporating, or even ignoring, depending on the context.

Having a strategy helps you navigate the response in the heat of the moment improving the odds of successfully driving forward your change.

Categorizing responses

If we use a categorization model, you can expect 3 different kinds of responses when you propose something:

• A disagreement on outcome. There is a fundamental disagreement between you and the other person on the end desire or goal that you want to achieve.

• A disagreement on mechanism. While your goal may be shared by the other person, there is disagreement on the proposed solution to reach that goal.

• An agreement and alignment. There is both agreement on outcome as well as the mechanism to achieve that outcome.

Each of these requires a different approach to address objections or challenges.

Dealing with disagreements on outcome

There’s several ways that disagreements on outcome manifest:

• Rejecting

• Denying

• Diminishing

• Nitpicking

• Obstructing

Rejecting

aka. “Nope.”

• “I’m gonna have to say no.”

• “We have rejected your proposal.“

• “I disagree.“

A rejection is exactly what it sounds like. Your proposal is rejected, with no explanation why.

In this case - ask for specific reasons why. One you know the reason, you can address it.

Denying

aka. “This isn’t a problem”

• “The user activation rate isn’t a problem - our rates are fine.”

• “The team is happy, why do we need to increase the party budget?“

• “Leaders take time to onboard - it’s too soon to determine his performance.“

Denial occurs when people don’t agree there is a problem. Since they don’t agree the problem exists in the first place, they are unlikely to want to invest their energy or resources in resolving the problem you propose to solve.

There’s a few techniques you can use to address these:

• Paint a picture of the problem. If you can illustrate the problem truly exists in terms they understand, you can convince them to move beyond this objection. Consider your narrative and what is important to that stakeholder.

• Get feedback from those suffering from the problem. Sometimes, the denial comes because you lack credibility in representing the problem. Getting direct feedback from those suffering the problem may be enough to move past denial. Anecdotal but personal evidence can craft compelling reason from an empathy and sympathy standpoint to recognize the problem exists.

• Reduce their cost and energy. If the person doesn’t actually have to invest any resources or energy of their own, you could theoretically minimize their concern or involvement to bypass their denial. Emphasize how it won’t impact them or their organization at all, or even how negligble the cost is. They may move on to bigger and more important subjects and leave you to your devices.

Diminishing

aka. “This isn’t that big of a problem”

• “Retention rate is down, but only a few percent - it matches expected seasonality.”

• “Team churn isn’t a huge deal - we can replace them pretty quickly.“

• “We’ll just pay the daily fine - it’s the cost of doing business.“

Diminishing is a form of denial. Instead of denying the problem exists, the stakeholder agrees the problem exists, but disagrees on the magnitude or importance. 

Techniques to resolve:

• Illustrate the magnitude. This is where your research is important. Get data, quantify costs and impacts in a way the stakeholder cares about.

• Paint the long-term picture. A lot of diminishment comes from problems that are minor embers now, but can turn into massive fires later. If you’re doing your job right, you’re trying to avoid a fire before it starts. Paint a picture of what this catastrophic end state likely might be if the problem is left untreated.

• Compare it to other addressed problems. If you can show that the organization has approved or otherwise taken action on solving lower-magnitude or less important problems, you can make an argument that a higher-magnitude issue should certainly get traction. Otherwise, the other addressed problems should also be ignored.

• Ask the threshold at which they would start to consider it a problem. Sometimes the person just has a different level of pain tolerance or a different set of tradeoffs they are optimizing for. Understanding what that problem threshold would be is extremely useful for calibrating when it would start to be considered a problem for that person.

Nitpicking

aka. “Have we considered this, or this, or this?”

• “We haven’t done the research on React v14.2.1 vs. v14.2.2, so I can’t approve moving off of EmberJS.”

• “This is terrible - you used the secondary brand color here instead of the primary!“

• “Before I approve this $10,000,000 spend, why in the world is there a $500 line item for team snacks?“

Nitpicking is about resistance to the proposed solution, but the resistance is specifically not relevant to the actual outcome or success. Also known as “bike-shedding”, it’s over-discussion about details that are implementation related or don’t matter to actually proceeding or not with a proposal.

The classic example is when a committee is discussing whether to build a nuclear reactor or not, and the decision is being blocked on agreement. as to whether the bike-shed should be painted blue or green - a non-consequential detail to making the decision.

There’s typically a root cause for nitpicks you can address.

• Disagreement on outcome. The root cause of the nitpicks is sometimes related to the fact that the outcome doesn’t actually have buy-in. At which point, you can treat it as a denial or diminishment and act accordingly.

• Lack of perspective on problem or solution. Re-orient people back on the primary problem, and highlight the relative unimportance of whatever is being stuck on.

• Lack of other ability to contribute. Some people just want a path to contribute. Because there’s no other way, they instead contribute to minutiae, delaying. a decision. You can either provide other ways for them to contribute that don’t block the decision, or challenge their involvement in the decision-making process at all.

• Personal relationship issues. You may have just made someone mad. Perhaps they don’t like you, or they are just that kind of person who over-focuses on irrelevant details.

Obstructing

aka. “I’m gonna need you to do this and this and this. Why? Dunno.”

• “Sorry, you have to fill out Form 173 before I can even look at your Form 184.”

• “Can you get agreement from these 9 random people with no stake in this decision?“

• “Your team needs to do their daily log before I approve this new project.“

Obstructing is when a decision-maker or stakeholder introduces various hoops you must jump through to gain approval that are disproportionately difficult relative to the value they provide, or do not have any reasonable purpose relate to the proposal.

There’s a couple ways to deal with this:

• Do them. If the hoops are done, you can get approval. Yes, it means extra work, but it might be the fastest way. If later on even more hoops are added, you can point out the discrepancy and have a direct conversation about that. This is a useful method to deal with organizations that have layers of bureaucracies.

• Point out the hoops’ lack of purpose. You can directly address the fact that the hoops have no purpose or value. Depending on the organization, you may be able. to get the hoops removed.

There can be a deeper reason why someone might be obstructing your proposal:

• Lack of trust. If you lack credibility, or there’s some element of your performance that has caused deceased trust, this can cause opposition. Gently ask about ways you can build up or restore trust.

• Personal relationship issues. Once again, your personal relationship can plan in here. The best way to avoid this is to have good personal relationships with everyone.

• Horse trading. Stakeholders have their own needs. Perhaps they see this as the opportunity to get their item done.

One you understand why the hoops are being put up, you can work to go through them or remove them.

Dealing with disagreements on mechanism

When there’s a disagreement on mechanism, it means that the disagreement surrounds the specific context and constraints of your approach. While your goal may be shared by the other person, there is disagreement on the proposed solution to reach that goal.

There’s several ways that disagreements on mechanism manifest:

• Rejecting

• Criticizing

• Optioning

• Compromising

Rejecting

aka. “Nope.”

• “I’m gonna have to say no.”

• “We have rejected your proposal.“

• “I disagree.“

Same story - a rejection is exactly what it sounds like. Your proposal’s solution is rejected outright with no explanation why.

Same as before - ask for specific reasons why. One you know the reason, you can address it.

Criticizing

aka. “There’s quite a few challenges and issues here.”

• “Users are unlikely to even look at that page given the analytics information we have.”

• “This proposal relies on a key team member that’s going to be OOO for 3 months.”

• “The system doesn’t actually do what you’re saying it does.“

Criticizing is when stakeholders start to bring up relevant reasons why a proposed solution or change won’t work, discussion obstacles, challenges to execution, or even changes to the ROI, etc.

If you’re hearing about many of these things the first time - you probably should have done more research.

If you are addressing the challenges in your risk management, mitigating them, etc. then criticisms are generally overcome-able by talking through your plan to address each one.

Criticisms are extremely valuable as they tell you whether your idea has considered important factors or not.

Some criticisms have their root in a disagreement of outcome. Keep an eye out for when the criticisms start to talk about the why or the problem instead of the approach.

Generally, criticism can be addressed if you are prepared:

• You can accept it. A plan doesn’t need to be perfect to be effective. Having a weakness in the proposal can be accepted explicitly as a risk.

• You can reject it. If a criticism is unwarranted or doesn’t entirely apply due to some mitigating factor, you can reject it. You can explain why it shouldn’t be considered in the decision.

• You can address it. You can take that criticism, and modify your proposal to factor it in. Alternatively, you can explain how you’ve already addressed it in your plan.

Optioning

aka. “How about doing this instead?”

• “A much faster approach might be to send an email blast instead of calling everyone.”

• “We should move the budget from Product instead of Engineering to support Sales.“

• “What about implementing an unlimited leave policy instead of giving 30 days?”

When stakeholders agree with your outcome, but disagree with your mechanism, they may propose alternate approaches that help meet the same outcome.

If your solution is inherently unimportant, be open to the options they propose - if all roads lead to Rome, then does it matter what road you take?

If the specific form of the solution is important, then you can address the pros and cons of each approach and make a recommendation. You should be willing to walk away from your proposal if your solution is not approved.

Compromising

aka. “We can both get some of what we want.”

• “We’ll move Alice and Bob to the new team, but we’ll need to move Charlie off.”

• “We can move Project A to Q1, but we’ll need to stop work immediately on Project B.“

• “You can hire a new person, but you’ll need to terminate two under-performers by Q2.”

Compromising is when stakeholder ideas get merged together to water down the overall solution. It results in implementation of parts of the solution but not others that decrease overall effectiveness but still allows of the goal to be met.

Compromises are often unavoidable. Don’t be a ideologue, but keep the goal in mind and horse-trade as appropriate.

Agreement and Alignment

If you get agreement and alignment, you’re in generally good shape for getting your desired outcome and solution approved.

Responses you might get are:

• Accepting

• Reinforcing

• Testing

• De-risking

Accepting

aka. “Look good to me.”

• “Your approach is sound. Let me know what you need.”

• “Looks good.“

• “Good to go. -full steam ahead.”

Stakeholders fully agree with the outcome, as well as the mechanism you proposed, with no changes. This is full acceptance, and the easiest path forward for you.

Congratulations!

Reinforcing

aka. “Hey, it’d be even better if we did this, too.”

• “We could even add a banner to the page to upsell in addition to the ad you proposed.”

• “That’s great - maybe we can also do a secondary survey.“

• “If we have an offsite, we could probably throw in some fun events to build team camaraderie.“

When stakeholders start to suggesting improvements on top of the proposed solution that help reach the same or substantially the same goal, that is actually a great sign.

In order to move to a formal acceptance and avoid scope creep that could then make the proposal unwieldy and thus move it to rejection, explicitly get agreement that they agree to the outcome and the general solution, and propose further discussions to iterate on the solution together one the proposal is formally accepted.

Incorporate their feedback, consider the scope, cost, and other factors and generally move forward.

Testing

aka. “Look good to me, but let’s check in after a month.”

• “I think the plan makes sense, but let’s look at numbers in a month.“

• “Let’s roll out the A/B test and reconvene in a week.“

• “If the monetization rate stays above 20% next quarter, we’ll keep it.”

Testing is a conditional acceptance of your proposal.

Your proposal’s outcome and solution was accepted, but there’s a decision re-evaluation at some point in the future to determine whether the decision should be kept - ie. a trial run or a test. It means if it turns out to have issues, it might be reversed.

You’ll need to get agreement on the parameters of the test - if there are unreasonable expectations of early or immediate success, you’ll want to hash that out now before going forward and having the test fail. Your discussions will mostly revolve around managing the timing and scale of expectations rather than the outcome or solution.

After you all agree on the parameters, that’s it. Follow the test, report results accurately, and proceed with a permanent rollout if the results are positive. Make sure it goes as smoothly as possible.

De-risking

aka. “I have some concerns with the approach.”

• “Can we try this out on a subset of people? I’m afraid they’ll react quite negatively”

• “We should get some opinions from the team before committing to this.“

• “Let’s wait until after the busy season before making this change.“

De-risking is when stakeholders agree with your outcome and mechanism, but impose constraints or guardrails to address a perceived or real risk. The most common guardrail are typically around budget, timing, and audience.

If the guardrails are appropriate, incorporate them and move forward. If they are busy-work, you can try to argue out of it but it might be easier to just do the busy-work.

If the guardrails would cause undue burden to your solution, propose other mechanisms to address or mitigate whatever risk is being brought up.

Knowing how to address the various kinds of objections you will receive when you deliver a proposal is key in successfully driving forward the change you want to see.

People are complex with different motivations and perspectives - being able to easily and quickly factor in their perspectives to strengthen your proposal is a skill that can be learned.

A single objection doesn’t mean the end of your idea. Treat it as a beginning for further discussion and refinement.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

Crafting your proposal

An idea isn’t useful in and of itself. It requires execution and delivery. If you’re trying to drive a meaningful change, you’ll need to be able to formualte your idea and get buy-in from many stakeholders across an organization.

This requires you to create a compelling argument to convince others of the merits of your idea. Your proposal needs to be able to tell a story or narrative that relates to your stakeholders and decision-makers: the people who ultimately in charge of approving or rejecting your idea.

Your proposal should be well-researched, with data, sound arguments and clear, concise summary of the problem, the solutions, and the recommendation.

Do your research

The first rule of proposing something: know what you’re talking about. This obviously means doing your research.

• What exists today?

• What has been attempted or tried in the past?

• How aware are people of the problem/change/solution you are proposing?

• What are the risks?

• What are the important tradeoffs?

Every aspect a proposal where you are not aware of existing efforts, possible problems, or other issues undermines the credibility of your proposal.

Stakeholders expect you have done your homework. If you have too many unknown unknowns because you didn’t do your research, you harm your credibility. Unknown unknowns that should be known knowns is a signal to deciders that you didn’t really think that deeply about what you are suggesting. At some threshold, your proposal will be rejected outright on the grounds it was not as well thought out as it should.

The importance of knowing current state

I once worked with a senior engineer who proposed a scaling plan to avoid an outage during our busy season that he spent several weeks writing. In it, he proposed a massive re-architecture.

I read it and rejected it outright.

• He didn’t match the desired risk profile. His proposal was a big-bang change of a massive amount of infrastructure components and a complete rethinking of the data lifecycle. This would have taken on so much risk and required so many changes across the entire application that it was likely we would have broken our system ourselves a hundred different critical ways. At that point, I would have preferred to have an outage instead of the many data issues, defects, and other problems his approach would have caused.

• He proposed things we already had. It was clear he didn’t do his homework on what we were already using. He proposed large different implementations for capabilities we already had, such as asynchronous message passing or reading from replicas. His proposal was framed as if these did not already exist to strength his argument, when in reality much of what he was proposing was a re-creation of capabilities we already had. There would have been little to no benefit to change our implementation for the significantly added cost and risk.

• He proposed things we already had smaller, easier plans to do. It was clear he didn’t look at any of our existing documentation on our scaling plans or talked to any of the stakeholders. His proposal contained complex plans for things we already had simpler plans to do, such as vertically scaling or distributing load or leveraging caching. His plan increased the complexity of the effort and ignored many of the low-hanging opportunities that would have negated the need for many of his ideas.

It wasn’t that his plan was bad - it was, in theory, good. His issue was that he failed to account for existing work and the current context of our organization. This meant his proposal was, in practice bad, especially relative to our existing plans which were much simpler and more efficient with lower risk.

Form the right narrative

If you did your research and you have a great idea - it’s not enough. Unfortunately, convincing people requires more than facts. It requires a compelling story that helps people connect the dots to why you are proposing what you are proposing.

This is the big flaw I see with many people proposing changes and getting them rejected. They fail to clearly create a narrative structure. Instead, they dump a bunch of random statements and numbers on a page or deck, making it hard to follow. Or, they immediately jump into a solution without identifying why they’re even proposing it. By the end of it, the decision-maker doesn’t know what the problem is, let alone what the solution is, why it’s being asked for, or even what was being asked for.

They reject it out of sheer confusion.

Be structured

When you craft your proposal, you need to form a narrative that is well-structured an flows as expected. You’re telling a (hopefully true) story to decision-makers, taking them along on the journey.

You need to quickly orient them, answer their questions, and highlight the primary areas of importance, such as:

• Why is this being proposed?

• What is being proposed?

  • What are the pros?

  • What are the cons?

• What are other options?

• Who is involved?

• What’s the value of doing it the way it is proposed?

There are many narrative structures that can support you here:

• Pain point and solution. There’s a pain here. It’s causing <X> issues. Here’s a proposal to resolve that pain.

• Problem → Solution → Value. This problem exists. This is the proposal to solve it. Here’s the value of solving it.

• Simple math. This opportunity to capture or save <X> value exists. This is the <Y> cost to do it. <X> is greater than <Y>, so we should do it.

• Bets. Here is our goal. We have information that indicates this approach will lead to <Y> value. We are going to size a bet that costs <X> to capture this improvement.

• Intent. Here’s what I intend to do to solve this problem. Do you have any objections?

What narrative resonates depends on what you are proposing and to who, and the context.

Know what is important to the decision-makers

If you don’t know what is important to the decision-maker, you won’t be able to provide them with it. If you can’t provide what is important to the other person, they’ll either not care about your proposal, or they’ll reject it because you didn’t sell it from their perspective.

What does the person care about? The subjects are limitless: Cost? Risk? Impact? Numbers and data? Alignment with strategy? Impact to another project or effort? User benefit? Predictability? Impact to the team?

Ask yourself what the stakeholder cares about. Suppose you’re presenting an idea that has finance as a stakeholder, you’ll want to ask yourself:

• Does finance care about the cost of an initiative?

• Does finance care about the value of an initiative?

• Does finance care about predictability of expenses?

• Does finance care about the reliability of estimated expenses?

• Of these, does finance care about one in particular more?

If you can’t explain possible ways how or reasons why the stakeholder will reject your proposal, you don’t fully understand their perspective.

Once you do understand, bake that into your proposal. Show numbers to people who care about numbers. Talk about user benefit to people who care about user benefit. Show resource utilization to people who care about resource utilization.

The opposite of this is also true - don’t focus on something they don’t care about. If you know that a decision-maker doesn’t care about numbers an data, then don’t spend your whole proposal discussing numbers and data - it won’t resonate.

The importance of knowing your audience

Engineers often propose technology and practice changes in technology organizations that I lead. Proposals range from things as granular as new linting standards to as monumental as organization-wide technology stack.

Many engineers trying to introduce a new technology emphasize the positive resume/career impact on them personally, and the adoption of the technology by larger enterprise companies. They focus on things that they think are valuable, and not what I actually consider during a decision.

The problem is that whether there’s an impact on their career or that massive companies are using it aren’t factors in my decision. Instead, I care about things like:

• How long will it take to migrate?

• Do we have enough of “critical mass” of people in the organization that can sustain our usage and adoption of it?

• Across all of our innovation portfolio and organization, is this the most important technology to implement currently to slow down to learn?

• What are the benefits to speed, throughput, and quality?

• What classes of problems does this address, and are we experiencing these problems at the rate that I want to invest in resolving them?

• What do the next 3, 5, 7 years look like for this technology and its upgrades?

• Does the technology’s upgrade cycle match our ability to invest in upgrading?

• Does the technology’s market-wide trend enable effective hiring or training?

• Does the technology still provide benefits at the scale and size we operate at?

These questions matter significantly more than whether it’ll look good on a particular engineer’s resume or whether a big-name company that operates in a completely different context uses it.

I’ve often rejected weak proposals that didn’t factor in these interests. Engineers were ill-prepared for the kinds of questions I sought answers for, and the narrative and arguments they made up weren’t compelling.

Don’t hide from the weaknesses in your proposal

In an effort to get their point across, a lot of people hide the weak points of their argument or proposal. They do this because they aren’t confident in their proposal enough to overcome objections. By hiding it, they believe they’ll be able to hand-wave or gloss over it, skipping a potentially difficult discussion.

Don’t do this. When the proposal gets discussed under scrutiny, you will get caught off-guard and be unable to answer important questions, which undermines your credibility, or even worse, results in fatally flawed proposals being accepted, which isn’t good for the company.

It’s a mistake to ignore or hide the weaknesses of your proposal. Instead, be explicit about the drawbacks and try to figure out:

• Are they valid?

• Are they high impact?

• What is the risk of this weakness being encountered?

• Can this weakness be compensated?

• Is this an acceptable risk?

Once you identify the weaknesses, address it explicitly. Be up front about possible mitigations, or even solicit ideas for addressing the risk.

The more thoroughly researched, the better. Document potential objections, gauge their validity, and find counterarguments for them.

Remember - the point of a proposal is to swiss-cheese it and poke as many holes in it as possible. If it’s still standing after that, it’s more likely a good proposal.

The more you yourself poke holes in your proposal, the more prepared you will be to answer objections when decision-makers do it.

Be clear with you recommendation

When you’re proposing something, there are likely other alternatives to your approach to solve the same problem. When crafting your proposal and including possible solutions, you have to be careful to know what you don’t want.

Many people fail in this for some strange reason by leading with an option that’s the opposite of what they want actually want to do. Sometimes they’ll present multiple approaches as equivalent even when they have a strong recommendation - they fail to highlight what they are actually looking for. When decision-makers inevitably decide to do a thing they didn’t want, they are shocked.

It’s their fault, really. They didn’t make their desired outcome clear, instead providing the entire palette of options as equivalent.

Lead with your desired direction. Always make it clear what your recommendation actually is, and the strength of your recommendations.

You rarely want to give options you don’t want people to take. If you want to be comprehensive with the options, you can list them as rejected options due to various considerations, but you should always mark when an option is recommended or not recommended.

Polish your proposal up

Once you have created a proposal, take a step back and examine it. Be detail-oriented.

Use the right medium

There’s many ways a proposal can be articulated - verbal, a presentation, a short memo, a message.

You need to make sure you choose the right medium and approach.

Some of this depends on your audience - do they want to or have the time to read a giant document? Will a slack message be more effective? Do they need guidance through a presentation or an in-person discussion?

Whatever the case - match your proposal with the person and context. If you write a 10-page document for a simple, minor budget ask, you may just get rejected because of the length. If you put an ask to do a company-changing direction in a two-sentence direct-message, you’ll likely receive an immediate rejection followed by setting off a lot of alarms.

Ensure your story is cohesive

Cohesion is about removing unnecessary or irrelevant details and information.

Your proposal is about the believability of the story, not the comprehensiveness. That’s not to say you should hide or lie or remove important information. But you should be cognizant that not all details are relevant to the decision to approve or reject a proposal, and therefore these details should be removed to achieve a coherent flow.

You can save extraneous details for a deeper dive for actual implementation or as supplementary material for those interested.

The importance of removing the unnecessary

I once received a proposal to change our build pack technology from one of my engineers. Much of the document in particular was filled with code-level concerns and various line-by-line package changes, comparison points, and other examples.

I skipped almost the entire proposal because it wasn’t relevant to deciding whether we wanted to switch or not. Instead, I did my own research and approved the proposal. If I hadn’t had the time, I likely would have rejected it outright.

A single sentence that had said “Build definition files are 30% shorter and 3 minutes faster” would have been perfectly fine to illustrate the point, and saved me time.

Make it professional

I’ve seen many proposals littered with typos, work-in-progress sections, run-on sentences, incorrect data, or irrelevant fluff. These are all diminished my confidence in the actual thinking and preparation behind the proposal. It made me think the idea was half-baked, and I put less effort into trying to figure it out.

If you’re going to present something, make what you are presenting is polished. It doesn’t have to be aesthetically pretty, but put care into it.

Use headings and paragraph breaks. Use tables. Form complete sentences. Run auto-correct. Pay attention to the details.

Your proposal is your chance

You need to do your research, think through your proposal, carefully consider your audience, and be sure your ask is clear. When you put your thoughts in a structured format appropriate for the ask, it helps prepare the decision-makers to make a decision. The easier you make it to make the decision, the more likely it is the decision lands in your favor. Without the ability to craft effective proposals, you’ll be unable to drive organizational changes outside of your sphere of authority.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

Establish your credibility

Credibility = Proven Competence + Integrity + Relationships

- Chris Fussel, “One Mission “

Credibility is the trust your organization has in you. Trust is a key factor in driving organizational changes.

Organizational change requires participation across many people across a company. Each one has their own perception of you. For them to buy in and take the time to support your idea, they need to trust you.

If nobody trusts you, they’ll disregard what you say even if you are 100% correct. Even if you have authority, your authority has limits. You can’t just keep snapping your fingers and getting things done without breaking your organization.

Building credibility requires competency, relationship-building, and time.

Do your job well and build a track record

There’s no better way to prove your point than with overwhelming competence. If you’re excellent at what you do to the point where nobody can argue with the method or results, driving forward change becomes a lot easier. You have a history of credibility to fall back on, and people are willing to give you more leeway even if they aren’t fully sold on your idea because you’ve pulled through in the past.

People look to those who can deliver. If you don’t have a track record of delivering, you won’t have the credibility to ask for change. Start with quick wins. Don’t tackle a massive challenge day one. Find a small pain point and solve it. Then the next, and the next, and the next. Build up a track record before you need it.

You can’t rely on authority forever

I see a lot of new executives and leaders fall into this trap when they enter a new organization. They come in and demand changes to everything, not understanding or appreciating the context of the organization. They rely on their authority.

Initially, it works. These demands are followed because of the authority granted by their title, and not through merit of the idea or trust in the leader. People are willing to give the benefit of doubt. The new leader has the excuse of “being new” when they make mistakes.

However, it wears off quickly. As time goes on, competency and proven success at the organization becomes more important. If a leader keeps making mistakes and relying on authority to push things through, they’ll start to receive pushback. They don’t have excuses to fall back on for their bad decisions. When failure does happen, it marks the leader as a poor decision-maker, and the trust is lost with the team.

With enough trust lost, resentment starts to occur. It gets harder to rely on authority to push things through. People might actually be rooting for things to go wrong or put minimal effort into preventing failure, further driving poorer outcomes.

The loss of trust makes it harder for that leader to affect future changes successfully.

The importance of credibility

At a former company, our CEO hired his longtime friend to become the new Head of Development, without a single interview from anyone on the team.

My new boss came in and surprisingly fired several people in his first day. With the tone set, he started making demands left and right about changes he was making to practice, process, and technology.

It became evident over the weeks that this individual knew nothing about how to do the job. Basic concepts needed to be explained to him, and his orders consistently contained things that had no bearing on the actual problem, context, or solution space. He brute-forced his decisions through with his authority, causing significant issues and problems, which he then quickly blamed on the team.

He wasn’t just in the wrong ballpark, he wasn’t even playing the same sport. I attempted to guide him, privately giving him feedback on his decisions and doing my best to ensure successful execution. We had many perfectly implemented things with terrible organizational consequences. As he made more and more uninformed, indefensible decisions, he quickly lost credibility with the entire development organization he was leading.

With all of the problems occurring as a result of his poor decision-making, executive pressure started mounting. What was previously a well-run organization ground to a halt, and leadership wanted to know what the problem was. My boss tried to shift the blame on to me and claimed that I was not competent.

This was the straw that broke the camel’s back. At the organization, I had a significant amount of credibility built up with many, many, many wins - my track record was undeniable to even the uninformed. When his negative credibility challenged my positive credibility, most of the development organization threatened to quit - myself included.

The CEO, finally realizing his mistake, quickly transitioned that individual to a different role with no authority and little interaction with the development organization, and placed me in charge.

Build relationships with others

There’s an idea of a relationship "bank account”.

When you support others and help them achieve their outcomes, you make deposits into your “bank account” with that other person. When you detract from their efforts, ask for favors, or block their successes, you make withdrawals. If you try to withdraw more than you’ve deposited, it doesn’t work.

It’s a bit of a transactional mental model, but it’s a useful one: find out how you can support people before expecting them to do stuff for you.

If you haven’t built up any credibility, you can’t ask for large favors. Help others first.

Be careful to not start viewing everything as a transaction! Nobody likes a slimy politician.

There’s a lot of ways to support people:

• Do something for them

• Give them information they need

• Help them achieve their goal

• Help them build their own credibility

• Help them avoid a problem

• Give them a useful insight

It first starts with talking to that person and figuring out what they need and what they want.

Help others without creating problems for them

Helping others is a great way to support them and build trust. However - it is a double-edged sword. If done incorrectly, trying to help people can get you viewed as an interloper or someone who is overstepping their bounds.

If you want to support someone - ask if they want help. Be sure your help is actually desired.

It’s especially important to not seek credit when helping others. If you help someone, and then try to get credit for it, then it can be viewed extremely negatively and harm the relationship. Look at it from the perspective of others on that person you helped:

• Is that person not able to do their own job?

• Should I go to you now for this thing that this other person has owned in the past?

Many people want help, but few want to look bad to get it.

If you do help, stay in the shadows. Don’t draw attention to the fact you helped. It helps you help others when ego isn’t a consideration or factor.

True, genuine help builds trust. Selfish help does not.

Don’t engage in unhealthy office politics

Unhealthy office politics are things like:

• Gossiping about co-workers

• Telling people who don’t have any business to know things other people told you in confidence

• Complaining to people about things they reasonably have no authority or influence to effect

• Fostering bitterness, negative sentiment, or venting

These are all thing that are organizationally unhealthy. That is, it might feel good to do them, but they don’t help the organization improve or operate effectively. At their worst, they can feed into negative sentiment and cause churn and dysfunction.

If you’re trying to build credibility, you need to stay out of unhealthy office politics.

For one - people will eventually find out. Many people accidentally or intentionally leak will leak something. What you told them, even if it was a private opinion on something , may eventually makes its way back to the party involved— this may be accidental or intentional.

Imagine trying to get buy-in on a cross-functional idea from someone who later learns you’ve talked poorly about their competency to their report. Imagine you talk poorly about your boss to their boss while looking to get promoted. These situations can quickly degrade any credibility you have built.

Every organization has a grapevine of communication. People talk to each other. While you want to be aware of what the grapevine is saying, you never want to push unhealthy politics through it. Be aware it exists, but stay above it.

I once had a report complain about my decision-making to everyone who would listen, but never to myself.

In discussions with them, they agreed, nodded their head, and never raised issues. Others did bring up their own issues through various means, and they were factored in or incorporated when relevant. It was just this one individual who was clearly not bought in to anything I did.

Even in anonymous surveys, the feedback was never expressed. However, in their direct chats with others they pointed out what they thought were flaws in me left and right, including several leadership peers, my reports, and others completely unrelated to the initiatives in the organization. They even noted they were slow-rolling things I worked on, hoping I would fail so their approaches would be considered instead.

Obviously, this quickly made its way back to me. I asked them for feedback explicitly, and they continued to express positivity and full-throated support.

At that point, I terminated the individual. If they weren’t bought in, they didn’t want to give feedback, they didn’t want to help improve the situation, and they had no contribution other than complaining about things, then they didn’t need to be at a company under a leader they completely disagreed with.

An important distinction

Unhealthy gossiping about others or complaining is different than earnestly discussing problems or validly making comparisons. The difference is in the ability of the people involved in the conversation to resolve the issue, or the need-to-know of the information being discussed.

For example:

• Two managers talking about a report’s underperformance for the purposes of calibration or sharing ideas is perfectly fine (and should be promoted). The managers can support each other, both can be reasonably expected to have access to the information, and their conversation can help improve the situation.

• A manager discussing weaknesses about another manager to that manager’s report is not fine. The report has no need to discuss this, has no ability to improve it, and it decreases the authority of another manager over their own team.

• Two low-level people venting about the company’s decisions to each other is likely unhealthy. On the unhealthy side, it decreases the trust of both parties in the strategy, doesn’t send the information anywhere useful, and will likely not result in any meaningful change. However, what can make it healthy is if they share ideas for how to effectively navigate situations or improve their understanding of the tradeoffs and factors involved in the company’s decisions.

Establishing credibility is key to driving changes. Without it, you can’t even get to propose your ideas as they won’t be taken seriously.