An oft-misapplied concept

Ben Horowitz has a piece called War-time CEO / Peace-time CEO. It’s an excellent read, with plenty of insights.

I’ve found though that many who read it come away with the over-simplified impression that it’s all or nothing - either you’re always directly involved in everything with no process during war-time or you’re always delegating everything into a perfect process during peace-time. That’s not what the piece says, yet the conclusion seems to be common.

The consequence of that simplification chain leads to people bucketing Operators into peace-time and bypassing operations completely once war-time rolls around.

In reality - there’s a messy middle where operators excel, helping companies navigate the uncomfortable period between the two extreme states of peace-time and war-time and ensuring war-time doesn’t break things that didn’t need to break.

When war-time hits, people at companies don’t just shift suddenly, ready to execute. Their operations don’t magically optimize themselves. The structure doesn’t remodel automatically. People often just stay stuck in peacetime operations, or start jumping ship, deteriorating the situation further.

Transitioning to war-time is a massively disruptive event, and the default mode is to break many things and keep them broken in the name of moving fast and breaking things.

In reality - moving fast and breaking things is irresponsible when your alternative option was to move fast and not break things.

After the break

Afterwards, it requires leadership and change to put back together - skills that are, by the time they are needed, gone from the organization.

Some companies brute-force their way through crisis. Few have people with the depth in putting the pieces back together. They do the best they can, but suffer losses that didn’t need to be lost, sacrifice gains that didn’t need to be sacrificed. They survive, but at a higher cost than they actually needed to pay.

Surviving is not thriving. It takes another skillset entirely to take a company in a crisis and thrive. That’s where effective wartime operators can help companies excel in times of turbulence, all while supporting providing a structure that can leverage the benefits founder-mode brings.

Thriving is thriving

What do wartime operators actually do?

• Understand the entire system and its influences and pulling the key levers - first, second, and third order effects providing leverage

  • Focus on the high leverage to maintain high effectiveness for effort, which critically matters in crisis.

• Make effective, rapid decisions and communications to prevent ambiguity and alignment drift

  • Don’t allow delays to fester for more than minutes - measure wait times in seconds.

• Supervise, and in some cases step into, execution to ensure sufficient quality and speed as context dictates

  • Be more attentive to specific key details - but spend your energy on the things that really matter.

• Improve efficiency of operations and execution, ensuring economy of limited resources and effort, including violating bypassing operations when needed

  • Maintain the minimum bar of operations necessary to keep things from creating new fires and adjust the rituals that don’t provide the ROI.

• Rally teams around challenges to maintain and increase morale through difficult times

  • People won’t be motivated because everything is calm, people will be motivated because the waters are choppy and they are showing their strength

• Change perspectives to see and capture opportunities, lifting team out of ruminating on failures

  • Doing better the next time should be baked in to the culture.

• Focus teams on the critical priorities, factoring in urgency, importance, risk, effort, and a dozen other tradeoffs rapidly

  • Instead of ‘everything is critical’, focus on what is actually critical

• Preserve and improve organizational knowledge for the post-crisis transition

  • The company needs to survive its survival.

This is different than peace-time operations. In a crisis context, you don’t get effective outcomes through taking actions that align with the traditional peace-time management that seems the default of much of the advice out there:

• “Get everyone’s opinions so they feel included and bought in”

• ”Give people stretch goals so they can grow”

• ”Get data and evidence on processes before acting to make good decisions”

• “Leave 20% time for self-directed education and training to support teams“

• “Let people define the ‘how’ so that you don’t micromanage and ruin autonomy“

• “Let the team run some experiments to see what happens”

This ‘sage advice’ just contributes to the spiral during wartime.

That’s not to say the outcomes they achieve aren’t important: buy-in is still important, growth is still important, good decisions are still important, leveraging individual skills is still important, understanding effects is still important. It’s just during a crisis, you have to achieve the same outcomes differently. The mechanism must change with the operating environment,

If you follow a peace-time playbook during war-time, you’ll feel good about your ideals but your organization will fail.

This is where a lot of leaders that step in during crisis fail to mitigate losses or recognize further gains - they ditch the peacetime practices without necessarily preserving the outcomes with wartime variants. As a result, people leave, morale suffers, costs increase, and it makes it that much harder to get through the tunnel, if they do at all.

I expect to see more crises

Company stabilization and transformation during existential stress has historically been a very, very small subset of lifecycle events.

Most of the time, it’s been limited to fairly predictable stages:

• Startups going through different lifecycle phases, from build to MVP to scale-up

• Companies getting disrupted by internal or external market shocks

• Already fragile organizations that suddenly become hit with the wrong combination of events simultaneously - key departures, client churn

With the advent of AI, I expect to see far more crises at companies.

External malicious actors can expose a company’s secrets more rapidly. The opportunity for internal mistakes increases ten-fold due to increased risk surface area and system connectivity with LLMs. People secretly burnt out from worry both due to macro-economic and industry trends suddenly encounter the straw that breaks their back. Acceleration of output and execution can overwhelm those downstream of the value chain. Deception and bypassing of traditional governance controls such as in hiring has become easier for even unsophisticated actors.

Everything is more flammable now - and there’s more and more people running around with flamethrowers. Unresilient organizations will burn.

Leaders would do well to apply their peacetime methods to help alleviate some of the potential risks, but also prepare their wartime toolkit before the inevitable crisis occurs.

What can leaders do to prepare?

That’s the magic question, isn’t it?

• Train your teams on wartime principles - adaptability, pro-activity, willingness to step across boundaries, initiative

• Train your teams on leveraging AI - a tool is less scary once people figure out how to leverage it

• Train your teams on a forward-looking mindset - AI isn’t coming to replace their jobs, it’ll help them expand their roles and opportunities

• Automate downstream for an increase in scale - whether that’s reviews, delivery artifacts, etc. - make sure your downstream processes can operate at the scale of an ever-increasing input while maintaining the bars you have

• Build in buffer - some organizations have done cuts to run leaner and more efficient, but some have overdone it to the point of creating systemic fragility - there’s no room to handle acute disruption in a perfectly efficient organization. A wrench in a gear will break the whole system without backup gears.

• Map your system - dependencies exist everywhere in an organization. You want to know what you need to do, how it needs to happen, and what their dependencies are. That way, you are aware of key risks - and can mitigate them pro-actively.

• Build resilience - your team needs to embrace adaptability, change, and direct intervention, not fight against it. Prepare their mindsets ahead of time, bake in collaboration vs. hand-offs.

• Aim for efficiency - Teach people how they can do their jobs faster and more efficiently. The key: don’t be overly efficient. Build the capability but never fully saturate it.

Build teams that work well together but also can work independently and fully own end-to-end things by themselves, while keeping others in the loop.

Build up the capability to project out plans into the future, but with an understanding that no plan survives contact with reality and rapid changes may be required.

Build up rapid ways to collect feedback and input from the team, while still ensuring that decision-makers are clear and there’s an understanding that it’s not a vote.

Build up a tolerance for being told ‘how’ while providing space for improvements to occur after efficient execution achieves the goal.

What does this enable?

Turns out, effective war-time operations enables more effective founder-mode.

If effective war-time operations are set up, it enables a leader to apply their founder-mode to exactly where it is needed and provide leverage. Instead of throwing the entire organization into chaos, they can focus and push forward key leverage points while the rest of the company operates tightly, effectively, efficiently, and with stability - providing the structure necessary to direct and leverage founder-mode efforts in the places it is needed most.

Not all operators can do this

A thing that is true from that article - many, many operators established their careers solely in peace-time contexts.

The phrase “sweet summer child” comes to mind.

When hit with crisis, their operations break, and they fall into chaos. They can’t handle the stress, they don’t have the skills to execute, and they try to delegate in a time when it requires direct intervention and complete rework of the established processes.

These folks fall behind. Their organizations become almost useless as they attempt to preserve instead of transform. They are rightfully and more effectively replaced by war-time founder-mode leaders.

Like the piece said, it does require true understanding of management and leadership fundamentals, and a flip in mindset. At the same time - it doesn’t require throwing out the baby with the bathwater.

All other things held equal, in wartime, effectiveness can be stack-ranked for war-time:

Peace-time operation is less effective than founder-mode which is less effective than a war-time operations which is less effective than war-time operations supported by war-time operations.

Put another way - you go from ‘bad’ to ‘good’ to ‘great’ to ‘excellent’.

Wartime operators provide can help a company entering crisis to preserve the outcomes that matter while changing the mechanisms that achieve those outcomes to operate fast enough for the new environment. Effective war-time operations can reduce the friction and heavy costs of war-time and even leave the company better than it was in peace-time.

Gefroh is a product and engineering leader in Kirkland, Washington. He often writes about Leadership, Management, Operations, AI, and Product Engineering. He has never actually watched Game of Thrones.

Align, Empower, Execute. I call this the AEE Cycle - the fundamental cycle of any execution that occurs in an organization. Whether the work is being done by engineering teams, or even just basic projects - managing the cycle effectively a powerful management tool for achieving leverage and project success and operational efficiency.

AEE - The Cycle

AEE is simple conceptually:

• Your team needs to know what to do (Align)

• Your team needs resources to do it (Empower)

• Your team needs to go and do it (Execute)

It’s a cycle - once the team executes, something in the environment might change that invalidates assumptions, necessitates a change in the direction, or perhaps just to catch natural goal drift. The team then goes back to Align at some point in the future, going through the cycle again, and again, and again.

That helps keep the team on track, focused on execution, and ensures that projects don’t stall.

Align - Providing the team clarity

Alignment is the most important activity to start with. You want to point your team in the right direction so that their efforts can be put into productive ends. To do this, you align and provide the details.

I recommend creating a document that articulates all of this precisely, though you can also do this verbally.

What do you want to achieve?

One-sentence should be enough to describe this. If you need more, you probably don’t have the necessary clarity of thought.

Why do you want to achieve this?

While “because I want to” might be fine for you, it has to be understandable and acceptable to your team. The Why? matters a lot because it also shapes decisions.

“Because it’s a great side market with potential for 10x growth 5 years from now” causes the team to make very different decisions than “Because it’s an existential crisis for the company if we don’t get this done.”

Under what constraints?

• Time - Is there a deadline or schedule?

• Money - Is there a cost limit, or alternatively - a minimum investment?

• Effort - Is this a sole focus, or one of several projects? Where does it fall in prioritization?

• Quality - Is there a desire to make it great, or is it a ‘get it out the door’ to get speed to market?

• Scope - Is there need to be comprehensive solution, or would an MVP be acceptable?

Explain why each tradeoff is what it is. Why is the deadline there? Is it for alignment with GTM, something required by a customer, a made up number? Why do we want to invest this much money in it, and is there wiggle room?

What do you NOT want to achieve?

This is one a lot of leaders forget, which leads to an accrual of alignment failures during execution. People need to know what not to do and what not to worry about.

If you have a team full of high-initiative people, they may, in their efforts to be pro-active, go down a completely different path towards a completely different destination than you actually need.

It’s a common source of scope-creep. You need to give people boundaries and anti-goals: things you definitely do not want to do or happen.

An anti-goal might be something like:

For example, if the goal given to a growth team is “Increase signups by 5%”, an accompanying anti-goal might be: “We do NOT want to change the sequence of steps within the sign-up or user registration experience.”

A common trap

Just remember - explaining something is different than justifying something.

Explaining is providing reason behind decisions, which teams benefit from as they make decisions. Justifying is proving that your reasoning is legitimate for approval.

You’re the leader - the only person you have to justify your decisions to your is your boss. Your team has no approval authority.

Once explained, you should set the expectation that your team commits - even if they disagree. Make sure decision-rights are clear, otherwise you create opportunities for additional alignment problems through your attempts to align. It’s a common trap a lot of leaders fall into that creates execution friction later on.

Empower - Meeting team needs

Once your team understands what they need to do, under what constraints, and why, it’s now your job to empower them.

Empowerment is simple - conceptually:

• Give people the resources they need - money, time, focus, freedom, etc.

• Give people the knowledge they need - clarification, expectation, etc.

• Give people the capabilities they need - authority, skills, access, etc.

• Give people boundaries - ie. emphasize what they don’t need and won’t get

Give people the resources they need

This might look like authorizing and specifying a budget. It might mean deprioritizing other projects or work. It might mean getting stakeholders off their backs so they can focus.

Give people the knowledge they need

This might be providing a central place to find documentation like meeting notes, explainers, or links to other artifacts.

It at minimum means you’ve taken the alignment and written it down.

Give people the capabilities they need

Do they need access to a SaaS tool? Get them access. Do they need a connection with another team? Do the intro. Do they need borrowed authority to make decisions in a space? Connect the stakeholders and tell them who the deciders are. Do this ahead of time so that it doesn’t create wait time and delays during execution.

Give people boundaries

Once again - tell people what they won’t get. If they ask for a tool and you aren’t going to give it to them, don’t tell them “let me check”, tell them “You aren’t going to get that tool for this project.” It helps avoid wasted time from the team pursuing pathways that lead to dead-ends.

Execute - Letting your team work

After Align and Empower, it’s your time for you to step back.

• You’ve aligned and provided clarity, including expectations of behavior

• You’ve empowered the team, providing them what they need

Step back. Let the team cook.

Your active over-involvement here will likely cause more issues and misalign teams. They’ll read your interventions as reprioritization, changes to the boundaries and constraints, and it’ll create re-work, hesitancy, doubt, and sloppiness as implementations pivot back and forth.

To effectively let a team execute, you need to delegate. The rules of delegation are simple but difficult emotionally:

• Even the most highly competent team will take different paths to achieve the same result. You must judge the outcome and how it met the constraints, not the process by how it got there.

• Over nit-picking on implementation that ultimately doesn’t change the outcome will reduce empowerment and alignment, completely stalling a project’s execution.

• You must be available and responsive and provide direction, but not controlling.

These are hard things to do. You’ll see the team do things that you feel are a waste of time, or are not how you would do it. You, as the leader, need to step back and let them maneuver within the boundaries you have provided.

The only exception to this - key efforts during wartime mode, where the how matters as much as the what. In that case, you should have already set the expectation during alignment so the team is operating in the right posture and you retain direct control.

Keeping a close eye

If you’re working in an organization, chances are you can’t just leave teams alone for months at a time hoping they are doing their work. You have people to report to, other efforts to coordinate, risks to manage and mitigate, interventions to perform.

Once the team executes - you need to check their progress.

This is the beauty of the Align, Empower, Execute cycle: we’re back to Align!

Touchpoints

How? By establishing supervision touch-points. These are moments you bake in ahead of time where you can ensure that the work is being done in the manner it needs to be done, help address any uncertainties that have arisen, or respond and react to new discoveries.

Depending on the effort or its importance or its rate of change your supervision touch-points might range anywhere from monthly to hourly in extreme cases.

While I don’t recommend hourly except for crisis-related efforts, weekly is a good place to start - it’s enough time for work to get done but also enough time where something may have changed about the environment or work.

How frequently you have your touch-points is an entire science / art all on its own I’ve written about before - tempo.

Milestones

For more autonomous, experienced teams, you can switch from a time-based tempo to a Milestone-based tempo.

Instead of checking in and aligning on a set frequency, check in and align according to milestones. These might be specific project phases (eg. RFC, Beta Release, GTM) or key dates (eg. 2 weeks post-start, project mid-point).

This gives you the ability to track to the granularity you need without requiring wasted alignment effort.

Just note - you really need a pro-active, autonomous team for this approach to work. If a team spins its wheels and never gets to Beta Release, you run the risk of introducing wasted time or even a complete project failure if you don’t have enough time to get the project back on track. Choose your milestones carefully.

Milestones might look like phase gates:

• When the team starts discovery

• When the team develops an execution plan

• When the team starts implementation in earnest

• When the team has a working prototype

• When the team has a functional end-to-end flow

• When the team is ready for testing

• When the team is ready for GTM

or they might look like deliverables:

• When the team delivers the MVP

• When the team delivers the Search feature

• When the team delivers the Filter feature

or some combination - the milestones are theoretically infinite - you can have extreme granularity or high levels of abstraction.

Optimizing the cycle

Alignment, Empowerment, and Execution isn’t just a single, linear path. It’s a cycle. You Align, Empower, Execute, Align, Empower, Execute, Align, Empower, Execute until the project is done.

The key here is optimizing for the entire cycle.

Here’s a very difficult truth: the only value creation that occurs here is execution. Ideas are endless, it’s what happens with those ideas that turns it into reality that matters.

The trap is that many leaders attempt to achieve the above by ignoring Alignment and Empowerment and focusing on Execution, which paradoxically reduces time spent in Execution dramatically due to the confusion and chaos it creates. It breaks the cycle, leading to extra effort to align and empower and less time spent on executing.

If you’re leading a team, you actually want to have AEE cycles where you spend as minimal amount of time and effort necessary in Alignment and Empowerment and maximize your team in Execution, but to achieve that - you have to effectively Align and Empower.

Spend more to spend less

Shortening the alignment cycle is your primary goal, and you do that by focusing on the alignment cycle. Yes, it’s a paradox. To spend less time on alignment, you must spend more time on alignment.

The better you align initially and maintain that alignment, the less time you have to spend outside of Execution. The more Empowerment you provide the team, the less you have to spend struggling with Execution friction caused by a lack of Empowerment.

An hour spent on alignment upfront will literally save dozens of hours of waste in Execution. Getting your team what they need up front will save time during execution waiting for the things they need or working around it.

Are you over-aligning?

Weekly multi-hour meetings. Multiple daily check-ins. There are symptoms of an under-aligned team practicing alignment theater. You might need it for more complex, rapid change endeavors, but a single team or initiative under no duress should not require more than 30m a week to align on.

These are moments where you should step in - is there clarity missing? Is there ritualistic behavior that’s not leading to better execution? Don’t just leave teams sleepwalking - step in and intervene: cut out meetings, facilitate the outcomes yourself, adjust the process.

A useful tool - The Weekly Alignment

The weekly alignment is a very useful tool for team-level leaders to manage the AEE Cycle within their team without over-aligning. At the beginning of every week, share with your team and walk through a document that outlines:

• Goal - the clear, 1-sentence goal the team is moving towards

• Anti-goal - any outcomes the team doesn’t want to achieve

• Current context - any specific things for that week that might impact the work

• End state of this week - what a successful week would look like

At the team level, this can be very granular. For example:

Weekly Alignment - 10/30

Goal

• Complete the fundraising ‘add a tip’ feature by the 11/30 marketing deadline.

Anti-goals

• Lose the trust of users by miscalculating tips or lacking transparency

• Burn out the team through overwork or unreasonable expectations

• Launch without coordination with the GTM team

Current context

• Brent is going on vacation for 2 weeks starting 10/14.

• Consumer-facing design conceptual mocks have been approved by leadership, but details and workflows for admin side not yet completed.

End state of this week:

• Have completed conceptual designs of Admin workflows by Thursday.

• Have a recording of the MVP of the Consumer experience usable by internal testers by Friday.

  • This requires a PR built, reviewed, and deployed by Thursday EOD to Staging.

• Have a shared marketing calendar for the Add a Tip GTM events available to everyone by Friday.

Combined with an asynchronous daily update, you can get a pulse without putting in over-bearing ritualistic behaviors. Better yet, this structure can be adapted to support higher-level efforts or lower frequency touchpoints.

Alignment is a key activity as a leader, but the purpose of it is not to align - the purpose of it is to increase relative time spent in execution.

Understanding the cycle fundamentals and how to provide clarity is a key component of efficient, effective, aligned teams.

Gefroh is an engineering and product executive in Kirkland, Washington. He frequently writes about Leadership, Management, Operations, AI, and Product Engineering on his blog.

“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.

Strategy in the everyday

As a director or manager, you may be waiting to be pulled into a ‘strategic conversation’.

That’s unlikely to happen. A senior leader isn’t thinking “I’m going to pull this manager in to help them become strategic.” They’re thinking “This person thinks strategically so I’m going to pull them in to help me think through this”.

You have to be pro-active about being strategic before you’re trusted to be strategic.

Don’t lose hope though - any situation can be analyzed for its strategic implications. Strategy isn’t just major company pivots. Strategy is also in day-to-day moments and as a manager or director, there’s an advantage because there are so many day-to-day moments where the skill can be exercised.

Here’s a few real examples I’ve been through to illustrate.

The meeting derailment

During a meeting, a Senior Product Manager gets asked a question by the data scientist - “did you validate that this isn’t a seasonal quirk?” Perfectly reasonable. She started rambling, talking over the data scientist with hints of aggression.

The lens

The tactical lens - stabilize the moment:

• Meeting facilitation - How do you get the meeting back on track?

• Cultural modeling - How do you ensure that observers of that meeting don’t view that as acceptable behavior?

• Corrective guidance - How do you ensure that the PM avoids a defensive reaction in the future for being asked a reasonable question?

The operational lens - diagnose if and why the system failed:

• Standards enforcement - why did the product manager ramble? Was it simply a communication issue, or did they actually not know? If not - why did a Senior Product Manager not know their own data? Is this a training opportunity?

• Consistency check - What other decisions are we making where we aren’t factoring in seasonality in our data assessments?

• Collaboration opportunity - Why did this happen during the meeting? Couldn’t it have happened before it was presented?

The strategic lens - evaluate the tradeoffs and determine if they are worth it:

• Decision tradeoffs - Are we making the right speed vs. rigor tradeoffs? Do we actually need or want data for this? For other things? Where’s the line, and what’s the impact of putting that line where it is?

• Center of authority - If data materially drives a decision, who should own decision-rights? The person closest to the data, or the person responsible for the product outcome? If data isn’t important, shouldn’t data be more of an advisory role? Who should own this decision and what tradeoffs are we stack ranking?

• Organizational capability - Do we want to drive more rigorous decision-making in this area as a de-facto standard, or is speed more important? What are our competitors doing? Is this a place where data moves the needle or does speed win out? Does it help us win, or does this just help us feel better about our losses?

What did I do?

I stepped into the conversation to redirect the meeting. “We’ll circle back to the data. Let’s stick to the agenda for now.” That kept the meeting on track.

I didn’t chew out the product manager in the meeting for not knowing their numbers - that would’ve led to more defensiveness, not less. I did talk with the product manager afterwards, specifically noting how that reaction wasn’t conducive to achieving the outcome of the meeting.

I also asked the Data Scientist how they felt afterwards to ensure they knew their contribution was appreciated.It led to a whole conversation about their perception of a lack of rigor they’ve been sitting uncomfortably with.

In my following 1:1s with product managers, I specifically requested deeper attention put into analysis and partnership with our data team before public presentations on work. I increased spot checks on analysis work and actively commented gaps, redirecting to data.

You get what you inspect. Afterwards, the team as a whole started ensuring that seasonality was a factor in their analysis. There were still some misses, but the rigor increased across the board.

Cross-functional mis-fire

A director of engineering posts an article to the company chat that is easily construed as villainizing and condemning a peer function, after a painful year of growing pains for that function. The director found it funny and enlightening, the function it villainized - not so much.

The lens

The tactical lens - contain the immediate damage:

• Protecting morale - How do you make sure the peer function still feels respected and appreciated for the progress they have made while at the same time not stifling legitimate critiques?

• Escalation control - How do you prevent this from rapidly turning into a public pile-on on a struggling function?

• Immediate repair - Does the director need to clarify, apologize, remove the post, or follow up directly with the affected function?

The operational lens - diagnose if and why the system failed:

• Director judgment assessment - Why did the director not anticipate how the message would be received? Was this a one-off lapse in judgment, or a pattern in how they communicate?

• Leadership standards - Do our directors understand that their words carry organizational weight, or does that require renewed guidance? Are our leaders clear on what belongs in public channels vs. private discussions?

• Cross-functional health - Is this incident exposing existing tension between Engineering and the peer function? How wide-spread is it, and does this need a relationship reset or repair?

The strategic lens - re-evaluate the tradeoffs and standards:

• Cultural interactions - Do we want functions to challenge each other publicly, privately, or through a more structured forum? What model creates the best outcomes given our culture? How sharp can an honest critique be before it becomes corrosive?

• Leadership bench depth - Is this director demonstrating the judgment required for increasing, broader influence, or is this a signal that they’re not suited? What does that imply for succession planning, promotion strategies, and future structural plans? Is this a sign of an underlying strength, and can it be directed productively?

• Functional expectations - Is the peer function actually improving at the rate it needs to, or does it require a reset? Are the expectations on the function from the top matching those of peers? What level of friction between functions is healthy?

What did I do?

I messaged the director privately, asking them to reflect on how a peer function would perceive one of the leaders of another function publicly posting an article condemning that function.

While the director made some justifications, in the end they removed the post. I noted this as a potential improvement opportunity for the director as there were several other sporadic instances in the past - correctable, but not allowable at their level.

I had some follow-up conversations with a couple of members of the peer function who saw the post, hearing them out and ensuring there was no lingering concerns.

In my managerial 1:1s with my management reports, I ensured to re-emphasize the importance of communication tact.

I also worked more closely with the peer function to address its gaps and shortcomings.

Given the tremendous damage a lack of tact can cause and how important cross-functional collaboration was at our company, I held managers accountable to higher communication standard. Trust is not free.

Dysfunction function

The product organization has not been able to turn customer insights into direction at a pace that the company requires. You’re the engineering leader and have been working on providing feedback, support but more and more the responsibilities are falling on you and other non-product people to keep the company running. The company needs its product organization to get back on track - they’ve been delayed and halted from improving the product for over a year now thanks to poor processes, analysis paralysis, and low hiring bar. Product continually asks for more time, but progress and change is stalled. You’ve been working closely with the new VP of Product, and she has some good ideas but seems to conflict with the CPO on how it should be implemented or communicated. In the mean time, the product organization is blaming engineering for low quality and delivery speed, and market conditions for recent hits. The Engineering organization’s morale is at an all-time low and your own outcomes have started to suffer. The company’s largest spend has delivered nothing in a year.

The lens

The tactical lens - stabilize execution and morale

• Execution containment - What needs to happen immediately to keep critical company work moving without permanently informally absorbing Product’s responsibilities?

• Narrative control - How do you prevent Engineering from becoming the convenient explanation for Product’s misses while avoiding a public cross-functional blame war?

• Morale protection - How do you keep Engineering from disengaging when they believe they are being blamed for problems they did not create and asked to compensate for failures they do not own?

The operational lens - diagnose where the operating model is breaking

• Ownership clarity - Which Product responsibilities are being absorbed by Engineering? Which of those need to be returned, reassigned, or explicitly redesigned, and can they without losing productivity?

• Leadership alignment - Where are the VP of Product and CPO misaligned? Does anyone else in leadership see a problem? What is their timetable for solving it?

• Systemic failures - Are the delays caused by poor process, weak talent, unclear authority, analysis paralysis, executive disagreement, or something else? Who is accountable for solving them, and what authority do they actually have?

The strategic lens - decide what the company can no longer afford to tolerate

• Functional accountability - How long should the company continue absorbing Product dysfunction before resetting? What is the cost of waiting another quarter? If a reset is conducted, what does that look like structurally and who’s best suited to pick up the pieces? Does Engineering and Product have the right current responsibilities, and is there alignment in leadership?

• Company operating model - Should Engineering continue compensating for Product’s gaps to protect near-term outcomes? Can you fix the Product gaps if they are being compensated, or does it require the plate to drop?

• Strategic capacity - What company opportunities are being lost because Product cannot effectively develop and execute a coherent product strategy? Is the current Product organization actually capable of supporting the company, or has it become a constraint? What value is the Product organization delivering today, and what do they need to deliver by next year? Are they on track, and if not - what’s going to fix that?

What did I do?

I kept the trains running. I ensured that the execution still continued and didn’t get stopped because of role boundaries. I coached our team on the importance of adaptability and initiative, promoting gap filling if it existed while ensuring we were deferring to our product peers - we were a startup, and sometimes we had to flex to get things done. We could make it easier for product partners by doing more of the heavy lift and proposing recommendations - at least in the short-term. I framed it as a growth opportunity and the way the industry was headed - engineers weren’t purely going to remain ‘tech’.

I worked as closely as I could in partnership with the Product leadership, noting issues, proposing solutions, and facilitating the implementation of their operational ideas to the extent I could without jeopardizing hard role boundaries. There was definitely a recognition there was a problem, but there was disagreement amongst the product leaders on the solution. I kept track of metrics and delivery, sharing with the product leaders so they could make better informed decisions.

Eventually, the organization reached a point where the cost-benefit of waiting for improvement no longer made sense. The product leaders departed, and I ultimately stepped in to redirect efforts - but that’s a war story for another time.

Situations are not ‘strategic’ or ‘not strategic’ by default. Moments and decisions can become strategic when you use them to change or reinforce direction. Every situation can be examined for signals and opportunities to influence future capabilities, manage organizational risks, improve systemic decisions, raise standards, or adjust other tradeoffs.

If you’re waiting to be invited into a room to ‘decide strategy’, you’ll never stop waiting. Strategy is all around you - you just need to use the right lens.

Get invited into the room by already being strategic.

Gefroh is the SVP of Product and Engineering at a technology startup in the health insurance domain. He writes extensively about Leadership, Strategy, and AI on his blog.

Feel free to reach out and ask any questions!

If you’re vibe-coding, you’ve probably reached a point where the AI is just terrible at progressing: making tons of mistakes, creating bugs with every change. It really stalls your progress.

What if I told you that with some simple questions, you can slow down getting to that point?

You don’t need to be an engineer to guide the AI (though, I’d recommend it). You can just ask the question and make sure the AI answers.

The key questions:

• Why is this named the way it is?

• Should this live here?

• What if there’s more than one?

• Is this the one place this ‘fact’ exists?

• Should this know about that?

Why is this named the way it is?

This is the most important thing.

• What is something called?

• Why is it called that?

The name of the file should impart what it does, scoped exactly to what it does. It should be consistent across the application and be both exactly precise and generic enough.

If you find yourself unable to describe what it does without using the word “and”, it probably does too much and should be in a separate file.

For example:

• Sidebar - shows the sidebar navigation links and handles login state

  • You probably need to move login state somewhere else.

• Sidebar - shows the sidebar navigation for admins

  • You probably need to name this AdminSidebar for precision.

• TransactionChart - a bar chart

  • You probably need to name this BarChart or at least TransactionBarChart.

• OverviewPage - shows a set of charts and contains help navigation

  • You probably need to move the help navigation into its own component

Naming is so critical that I never allow the LLM to name things. I always pick the name.

Ask the LLM:

• Why did you name it that, and can you think of a more consistent / cohesive name?

What if there’s more than one?

Suppose you’re making a chart. You prompt your LLM:

“make me a bar chart that shows transaction amounts”

Your LLM dutifully creates you a TransactionBarChart.js.

This is a use-case tied to a specific mechanism: the use case of ‘transactions’ tied to the mechanism of ‘show a bar chart’.

This is a key moment to ask:

• What if there’s more than one?

• What if you want another bar chart in the future?

This is a signal - you should extract the concept of a bar chart so that one file can serve multiple use cases.

Instead of having TransactionBarChart, UserCountBarChart, all with their own independent logic, you should have a BarChart that you pass in parameters to:

<BarChart title="User counts" data="{seriesLabels: ['Account A', 'Account B', 'Account C'], seriesData: [21,24,31]}" />
<BarChart title="Payments" data="{seriesLabels: ['2024/01/01', '2024/01/02', '2024/01/03'], seriesData: [1000,2333,1284]}" />

Pros:

• You reduce variability - if you fix a bug in BarChart or add a feature, it’s available for every place that BarChart is used.

• You have a consistent interface that you can use for any bar chart - you (and the LLM) does not need to re-create it.

• These are called re-usable components. The more you have, the easier it is to maintain your system.

Prompt your LLM:

• “What if I need to have another of this in a different use case?”

Should this live here?

You want to achieve cohesion - files should be located close to the things it works with.

eg. a PaymentBarChart should show a chart for payments. It should live a folder called /payments so you can easily find it.

If you had a BarChart, it should live in a /shared/charts folder alongside PieChart and LineChart.

Ask the LLM:

• Why did you place this logic in this folder/file?

Is this the one place this ‘fact’ exists?

A big cause of bugs is duplication of facts in a codebase - parts of the code that assert how something behaves, but in different places.

Suppose you had a “Delete note'“ button on a NoteShowPage.js that contains the logic to call an endpoint to delete a note.

Let’s suppose you also add a “Delete note” button on NoteListPage.js that contains the logic to call an endpoint to delete a note.

These are two duplicative sources of truth for the front-end logic of deleting notes. What if the endpoint changes? What if you want to add a confirmation modal to delete a note? What if you add front-end visibility adjustments so only certain users can delete a note? Now, you might have a missed spot. Worse yet - LLMs are prone to repeating the back-end logic too! Now you have four duplications for the same exact logic.

It’s better to have a single “Delete note” button file (eg. DeleteNoteButton.js) that contains the logic, or at least a single “Delete note” service that makes a request to the server.

Ask the LLM:

• Is this the only place this kind of logic exists, and should it be centralized?

Should this know about that?

LLMs often optimize for getting the thing done, not for overall system maintainability. That means it takes shortcuts.

As a practical example - an LLM will tie your toilet water plumbing to your kitchen sink because it’s faster than creating a separate set of pipes. The end result - your toilet will flush and your sink will have water - but you probably want them separate.

Likewise, in code, there’s certain things that should just never interact or know about each other. You want to ensure that your code knows the bare minimum about any other code in the system.

If you have an Export record, you don’t want it knowing about Payment records - it’s irrelevant. If you have a BarChart, why should it know about Navigation?

The more you can carve out, the more maintainable your system will be.

Ask the LLM:

• Does this really need to be aware of that?

Just five questions will dramatically improve your vibe coding longevity. It’ll also help you sniff out the issues that your AI is creating, long before they start to block progress.

I see far too much mis-use of metrics in the industry. From people using Story Points as a functional evaluation tool to lines of code as a productivity metric. Much of it is innocent mis-use by misinformed people who follow frameworks like Scrum or DORA without taking the additional steps of understanding their root principles. Others use it with a bit more of a unethical tilt to trick others.

If you’re an engineering leader, you owe it to your team to have a framework for the metrics you are tracking.

Start with why

The first thing to look at isn’t the metric itself, but why you are looking at them. It generally boils down to a few things:

• To follow a leadership or management directive

• To inform a narrative or decision

• To evaluate and judge

• To satisfy a curiosity

• To improve over time

What metrics you look at and how you use them depends on why you’re looking at them.

If you’re following a leadership or management directive, you ought to follow the rules of your leadership first. Then, dig in to why they are asking and how they are using them. The reason is likely one of the below.

If you’re collecting metrics to inform a narrative or decision, first ask yourself - do the deciders actually care about the metrics? There’s a lot of lip service to “data-driven” decisions, but the fact is data doesn’t matter in many decisions at many companies. Don’t waste your time if the deciders don’t care - find out what they do care about and do that instead.

If you’re using them to evaluate and judge - you’re probably using metrics incorrectly. You can use them to inform decisions, but engineering is often highly dependent on context, and it’s quite inaccurate to judge an individual engineer or even a team’s performance purely using metrics.

If you’re just trying to satisfy a curiosity, I’d say metrics are a waste of your time. Only collect metrics if you’re actually intending on doing something with them - otherwise it’s just a waste of attention and busy-work from people collecting them. It’s nice to be able to say you have data backing up your decisions, but if the data wasn’t a true factor you’re just playing data-theater.

Finally, if you’re using metrics to inform improvements over time, then that’s pretty much exactly what you should be using metrics for - read on.

What are you trying to improve?

Metrics indicate things - attributes about the thing they are measuring. If you’re an engineering leader, you probably care about the following:

• Delivery - speed, quality, quantity, efficiency, predictability

• Service - uptime, quality

• Capability - resourcing needs, tech capability, team capability

• People - happiness, growth, retention

• Impact - operational cost

If you’re trying to improve Delivery, you’ll look at a different set of metrics than if you were trying to improve Service. At some point, after the low-hanger are gone, metrics start becoming tradeoffs - improving one decreases the other. For example, you might increase speed, only to start suffering quality issues, or you might increase uptime only to suffer morale issues from longer on-calls.

Tradeoffs are real - and it’s your job to articulate them while creating new capabilities that reduce or remove the trade-offs.

Where to begin with metrics?

The easiest things first:

• How healthy is your delivery pipeline?

• How sustainable is your system operations?

• How observable is your product?

How healthy is your delivery pipeline?

The initial view of engineers is - they build things. To build things, you need to have a pipeline from Idea to Production. That pipeline has stages that ultimately can be measured, each with nuanced areas that can become bottlenecks.

A delivery pipeline should be able to sustainably take a code change to production.

Sustainably means:

• It can be repeated indefinitely.

• It processes changes at the rate those changes are being made.

• It completes successfully within an acceptable failure rate.

The metrics that indicate the health of the delivery pipeline are:

• Deployment Frequency

• Deploy Failure Rate

• Change Volume Rate

• Change Failure Rate

• Cycle Time

Deployment Frequency is the number of deploys the team makes per day.

Deploy Failure Rate is the number of deploys the team made that had an issue.

Change Volume Rate is the number of changes delivered per deploy, on average - often a Pull Request.

Change Failure Rate is the number of changes that had an issue (eg. defect).

Cycle Time is the amount of time a change spent in an engineering phase, end-to-end.

Balancing the metrics

You might think “Oh, we should just work to increase deployment frequency and change volume rate” but that’s not necessarily the case. While higher numbers are better and generally indicate a healthier pipeline, they aren’t the goal.

The goal is sustainable delivery. Your pipeline should be able to deploy changes at the frequency and rate at which they are needed. That’s your target. You should aim to have a ceiling on Change Failure Rate and a floor on Deployment Frequency that is proportional to your Change Volume.

Put another way - you need to deploy changes as often and in as small increments as needed to deliver all your changes while within your target change failure rate. Any more and it’s waste. Any less and it’s a bottleneck.

Indicators

You’ll have a baseline. Most companies without metrics are shocked when they first calculate them and see change failure rates of 20%+.

Over time, you can use changes to the baseline as indicators of whether a particular process or change has helped or not. Implement a QA process? You can see how that affects your cycle time. Increase automated test coverage? See how your change failure rate is impacted.

General rules of thumb

Increase the number of deploys to reduce your change volume rate. The more deploys you do, the fewer changes you need per deployment, which also decreases your change failure rate and makes it easier to identify the source of issues due to the smaller batch size.

If your change failure rate significantly increases - slow down your deployment frequency and change volume. You need to fix the problem upstream.

Ensure you benefit from extra effort. Going from 3 deploys per day to 4 deploys per day may mean absolutely nothing if you only create 3 change units (eg. a Pull Request) per day. That extra deploy is actually meaningless. Whereas, going from 3 deploys to 4 per day means the difference between a bottlenecked process or smooth delivery if you create 4 changes per day.

Larger batch sizes have higher levels of risk. They’re harder to debug if there’s issues, they often have to roll back in a single unit, and it increases the monitoring surface area post-deploy.

How do you measure it? Tools like Jellyfish are excellent for this, but you can also be scrappy about it. Use basic Github PR counts, or have an LLM write a script to count merges and cycle times from your git history. Create a simple webhook for deployments that stores the data in a table that your deployment script calls.

Lines of code isn’t a delivery metric. Your most impactful engineers might write 10 lines of code. Your worst engineers might write 100,000. Lines of code mean nothing.

How sustainable are your system operations?

Uptime

In most cases, the goal is not 100% uptime.

• 99% uptime is ~7 hours of monthly downtime.

• 99.9% uptime is is ~43 minutes of monthly downtime.

• 99.99% uptime is ~4 minutes of monthly downtime.

• 99.999% uptime is ~26 seconds of monthly downtime.

If your application is used only in a specific region during the 9-5, then you can have a completely successful operations with abysmal uptime.

Time ranges of the downtime matter. 99% uptime can be sufficient as long as you have 100% uptime during business hours.

Securing that fifth 9 is actually quite difficult, requiring an exponential increases in cost through investments in system resilience - whether that’s additional availability zones, replicas, failovers, etc. For many companies, that fifth nine is not worth it.

How do you measure it? Set up a tool like Pingdom - just a few bucks a month. Point it at your system, make it run once a minute.

Mean Time to Restore

A lot of leaders optimize for not having incidents, but it’s more effective to optimize for fast recovery from incidents.

Not having incidents can ultimately be luck and over-caution: incidents are actually fine for many business cases, provided they don’t cause lasting damage. The cost of having no incidents can outweigh the benefit (unless you’re working on mission-critical or life-critical projects).

Your time to restore is dependent on:

• How fast you detect an issue

• How fast your team or systems responds

• How fast that response can restore service

These are impacted by:

• Your level of observability and alerting

• Your level of standard practice and process

• Your level of team education and training

• Your level of technical controls and capabilities

Your goal as an engineering leader should be:

• Quickly detect an incident is occurring using automations, and not people.

• Have robust damage mitigation (eg. backups, staged releases) and rollback levers (eg. feature flags).

• Educate your team on incident response, including playbooks, runbooks, and tools.

How do you measure it? Ensure every single incident has a postmortem report written that has exact timestamps of incident start and resolution. Then, add the numbers up. Categorize the incidents - outage, workflow breaks, data loss, etc. A manual process can go a long way.

How observable is your product?

If you’re company makes money through a business event, you need to track that business event. For example, if you’re an eCommerce company, your event might be a Sale of an Item.

You should be able to tell, in real-time:

• How many of those business events have occurred in the past minutes, hours, days, and weeks.

• How that trend has changed over a period of time, including the past 5 minutes.

From there, you can add properties to those events to identify more granular segments, such as:

• What specific user types are performing those events

• Where are those users located

• How valuable are those events over time

This doesn’t have to be complicated. You can attach a product analytics tool, you can write a record into your database, or you can log it an create a dashboard off of your log stream.

From there, you can then monitor user interaction events - clicks, views, etc. to see what specific funnels are performing well, etc. You can add events for user signups, acquisition, churn - all things you can track day-to-day to get a heartbeat for your product.

Ultimately, the important part is to know it’s happening and watch it for changes. If your success rate suddenly drops - that’s an incident you should look into. You system might be running fine, but there’s an outcome issue that needs to be resolved.

Moving forward

Once you have the basics, you can start tracking other important metrics:

• Team morale - you can use surveys, retention rate, etc.

• Costs - $ spent on vendors, headcount, etc.

Just remember: metrics are indicators. They tell you something has happened, but not why it happened or whether it’s good or bad. The goal is not ‘numbers go up’ - the goal is ‘understand what has changed, and why’.

It might be a perfectly acceptable outcome to see a doubling in change failure if it results in a tripling in delivery throughput. It might be perfectly reasonable to see a halving on delivery throughput if half the team was at an offsite.

Don’t judge purely off of numbers - use them to indicate.

I’m constantly looking for potential leaders in an organization to uplift and empower. It helps the company, and selfishly it make my job 100x easier to have effective leaders running the show.

I find, however, that while many people want to be leaders, they often disqualify themselves or raise flags at their suitability. These issues are subtle - people often do not realize they are sending the signal, but once the signal is seen clearly, it can be hard to unsee. Leadership requires trust, and many of these behaviors quietly erode that trust before a person ever gets the title.

It’s correctable, but often need someone else to point out.

Mistakes that impact perception

Some people demonstrate a lack of self-awareness that damages perception, even if they are technically competent.

Not knowing how to follow before positioning to lead

Some people focus so much on obtaining leadership authority while they simultaneously failing to effectively follow instructions or align with the organization.

They resist instructions, constantly derail efforts by following their own ideas, causing disruptions. In the same moment as I’m cleaning up their messes, they ask for authority, title, decision-making rights.

Good leaders know how to follow orders.

Being overly compensation-focused

Everyone needs to eat, but some people exude a view of leadership that boils down to “you get paid more”. They forget the other half of that - if a company is paying more, what are you doing more to help the company succeed?

Folks who focus exclusively or primarily on the benefits to themselves unknowingly disqualify themselves.

Compensation is important, and you should be paid fairly for your contributions, but if all you can talk about is your compensation without any idea of what you’re doing to earn it, why would a company ever give you the responsibility of leadership?

Good leaders find leverage.

Demanding authority when you can’t wield influence

People often state “need the title” to get things done. Reality check - if you don’t have the influence, your authority doesn’t matter: people will just leave eventually.

Instead, you need to demonstrate you can be effective without authority. It’s only then when authority is best leveraged - when you don’t need it at all.

Good leaders can be effective without authority.

Expecting a transition to leadership to pull you out of the weeds

Some people gleefully look forward to the day that going to leadership means they don’t have to deal with what they consider the “grunt work”. They expect they can just focus entirely on “big picture” stuff, not realizing that the big picture is comprised of many details that have impacts in sometimes very nuanced ways.

These folks tend to become the most disconnected leaders who can’t do anything without an army of support staff around them.

Good leaders should be able to roll up their sleeves to get the job done.

Not thinking company-first

If I’m looking for leadership, I look for people who make decisions in the best interest of the company. Yet, many people seem to err on the side of making their own lives easier, making locally optimal decisions instead of systemically effective ones.

A leader that makes their lives easier is a leader that will:

• tolerate underperformance because they want to preserve the relationship

• take shortcuts to make their job easier instead of doing the most effective thing

• optimize for looking good instead of owning and fixing problems

In short - effectively someone you wouldn’t want to have in a leadership position.

Good leaders think about the broader outcome.

Mistakes that indicate lack of awareness of organizational dynamics

Not keeping your own boss in the loop

Fun fact - your boss hates surprises.

If something happens if your organization that they find out from someone else, it makes them look like out-of-touch at best and at worst makes the company think the organization they are responsible for is dysfunctional.

If you’re constantly forgetting to loop in your boss, you’re demonstrating unsuitability for leadership by not respecting the extreme coordination required at the leadership level for the organization to be effective, where the stakes are even higher.

If you can’t keep people updated on the small-scale stuff you’re responsible for now, imagine if you forgot to tell the CEO of something important worth tens of millions!

Good leaders keep others in the loop.

Signaling you can’t work with others

If you’re in an organization, chances are you’re working with other people. Other people may irritate you, annoy you, make you want to tear your hair out, but you still have to work with them successfully.

The more and more people you signal that you can’t work with, the less portability there is in personnel decisions and the less opportunity you can get.

I’ve had to make decisions in the past of not pairing two people together because they couldn’t work with each other. It was fine for the company, but removed an opportunity from them both.

At the leadership level - the effect is even more pronounced - I’m not going to promote anyone to the head of a function if they can’t put their ego aside to work effectively with half the org.

Good leaders can swallow their pride and work with anyone.

Putting your foot in your mouth

Some people repeatedly say and make public statements that make my mind boggle at the lack of good judgement.

I’ve had people insult entire functions, question the competency of others, and even highlight their unwillingness to work with the entire company. Worse yet, these remarks are rarely explicit - they’re just poorly phrased or even unintended.

Things like:

• “Yeah I guess I can do your job” when provided an opportunity to do something above their scope. Guess who never got another stretch assignment after that?

• “We could probably replace CEOs with AIs“ in a channel the CEO participates in regularly.

• “This is 101 level stuff” after a public presentation from a function on the work they did.

• “What if we got rid of all of the product people” during a brainstorm filled with product people.

Even if it’s all with good intentions, these moments diminish leadership suitability.

What you say matters a lot when you represent the company with every statement and everyone hangs off of every word you write.

Good leaders have tact.

Not having opinions.

Leadership requires setting a direction and then figuring out how to get there. If you have no opinions on direction, and no opinions on how to get there, then why are you a in a leadership role? That’s not leadership, that’s just coordination. It’s much less of a hassle for the organization to get a project manager at that point.

Good leaders do more than just glue.

Always having weak opinions.

Being a leader requires having an opinion and conviction behind it, and defending it.

A lot of people vying for leadership start by sharing their opinions (which is good), but then they do themselves a disservice by being unable or unwilling to defend their opinion.

I can’t count the number of times I’ve heard an opinion from a report, only to have them back-track and change their mind as soon a I ask a simple questions about it to learn more - almost as if they were waiting for the chance to second-guess themselves.

If your conviction always crumbles like a biscuit at the first sign of opposition or interrogation, other leaders see that and have less faith in your opinions.

When you share an opinion, make a recommendation - you need to stand by it. Have evidence and conviction. You can and should change your mind as you learn context and information, but leadership requires you to be able to talk an idea through its paces without immediately changing your mind.

Good leaders have conviction.

Always having strong opinions.

The other extreme of this is always having strong opinions that aren’t open to challenge, discussion, or change.

The hardest leaders to work with are the leaders that just always have to have their way. Nobody wants to work with them. When you’re part of an executive team (emphasis on the team), you need to be able to work with people who are diametrically opposed to your ideas.

This requires to pick and choose what battles you fight and what areas to push for, all in service of making the company better. If everyone on the executive team does that, then you’re golden as a company. If not, the whole thing starts to fall apart.

Good leaders can compromise.

Creating issues for your boss

We’ve all worked with people who lack tact. These folks throw fuel into fires, act like a “bull in a china shop” in communications and conversations, creating more problems as they try to address other ones.

If your boss has to bat cleanup and damage control for your actions all the time, it’s unlikely you’re going to end up on the leadership track. Some bosses have only a little patience, others have more, but everyone has a point where they will decide you’re not worth the trouble.

Good leaders solve more problems than they create.

Not understand what a promotion is

A promotion is either you performing at the level of your boss and supporting the organization in another vertical, or you replacing a slice of decision-making your boss previously owned that is now being entrusted to you.

The organization is demonstrating it trusts you to make decisions and own it. The organization - including your boss.

You have to realize it’s really difficult for your boss to give up their authority to you to give you an opportunity.

• One - they are still accountable for the results, no matter what you do. If you mess up, it’s on them, not you.

• Two - they know you’re going to mess up at times and are willing to work to mitigate damage and fallout from your mess-ups. They’re taking on risk and investing in you to hopefully ensure the longer-term success of the company.

It’s much easier for the boss to just remain the authority. When you get promoted, it’s your boss saying “you have demonstrated you can handle the basics of the job and can grow into the areas you need to grow in”.

• You don’t get to stop growing - you start the role with training wheels, but there’s an expectation the wheels come off

• The work gets harder, not easier - don’t mistake becoming a leader as “I made it”: it’s a heavy responsibility that marks the start, not the end, of the journey.

• You don’t get to demand the job without proving you can do it first - you have to have a track record.

Good leaders prove themselves every day.

These aren’t all of the things that make a good leader, but these are common, easily addressable issues that causes people to filter out people for leadership. Awareness is the first step to solving them!

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.