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

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.

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.

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

Everyone knows how jarring a transition it is when moving from an individual contributor to a manager. Everything changes: the skillsets, the responsibilities, the scope, the tradeoffs. There’s been plenty written about supporting ICs through that.

Significantly less is available on the just-as-jarring transition from middle-management to executive. The stakes are higher, and the scope and responsibilities wider, and the possible impact exponentially larger.

Having been in the executive-level leadership seats multiple times now, I’ve learned a lot of lessons. I hope these lessons help former managers who may be new to the executive role, or managers who are thinking about entering the executive role.

What have I learned?

• People will be unforgiving.

• There’s little margin for error.

• You shouldn’t solve all the problems you see.

• The best solution might harm your team.

• Every decision you make will have someone who hates it.

• Executive discussions can be messy, intense, and unfiltered.

• You have to accept blame for things you didn’t want to do.

• You have to accept blame for things you had no control over.

People will be unforgiving.

As a leader, your actions and reactions create the environment your organization operates in. That shapes how they behave and think, whether they feel safe to act or not, and whether they are ultimately effective or ineffective.

You do your best to create an environment where people are nurtured, free to make mistakes while still being held accountable, and free to bring their best selves to work. You might call it creating “psychological safety” or allowing people to be their “authentic self”, and it’s your responsibility as a leader to make space for your team to do their best work.

Ironically, that benefit will not extend to you as an executive.

This surprises many middle managers who rise up the ranks under the protective environment their leader has developed, only to find that the protection stops at some point between Director and VP.

The truth is that the people in an organization don’t want their executives to be their authentic selves, with warts and flaws, even if they say they do.

When was the last time you heard an executive flaw spoken about as “they’re just being authentic?” If anything, any issue is highlighted as a sign of their unsuitability to leadership or indicators of incompetency. People derive judgements, not understanding, from flaws, mistakes, and foibles.

Most people want flawless leaders while simultaneously not wanting to be held to that standard themselves. People don’t want leaders who have a quick temper, or lose their cool in crises, or are unavailable because they are busy, or don’t know their work extremely deeply, or are late to meetings.

As an executive, when you fail to live up to the standard of perfection (which you will, often), you will hear complaints and criticisms from many different directions. In the rare situations you do manage to be perfect for a season, people will then hold you to account for being too perfect - intimidatingly unemulatable.

There’s no winning. There’s no perfect. You have to be willing to accept that, while still striving to be the best you can possibly be.

Although difficult, you have to not let this reality change how you view other people. Continue creating safe environments where people can grow and improve and bring their best selves to work. While you may not be covered by the umbrella, it doesn’t mean you can’t continue holding it for your team.

Once, after a round of lay-offs, I had to prioritize the survival of the company and push the team to release a set of capabilities that would stabilize the company and help it live to fight another day.

We released it successfully after several weekends, and while it was positive and impactful, the team was spent. I told the team to rest up, while simultaneously pushing back heavily against other leadership’s demands to do even more. Both were important: to give space to the team to rest but to also ensure the company continued operating.

To support the team, I personally worked nights and weekends to give the team a normal schedule for a few weeks. This was successful - the team was able to work standard hours, and we still managed to deliver additional key initiatives during a tough time for the company.

In my review that quarter, the team complained heavily about being forced to work after-hours to save the company. They also complained about my own after-hours work, noting that they felt it set an unrealistic expectation.

There’s very little margin for error.

If you’re working in a healthy organization as a manager, you’re not going to end your career over a mistake. They’re treated as learning opportunities that are necessary part of the improvement and growth that people experience. Sure, you might have to discuss the details with someone, or implement follow-ups or action-items to improve, but that’s not even a slap on the wrist - that’s just healthy retrospection and improvement.

Managers are often in for a shock when they become executives and realize they no longer get that benefit of doubt that has enabled them to learn and grow. There’s very little margin for error.

In some cases, mistakes are a “one-strike, you’re out” situation.

Why?

At the executive level, the impacts of mistakes are magnified - consistent excellence is the expectation.

This standard is correctly higher for executives. When you make a mistake as an executive, it has the potential to lose millions of dollars or cause an organization to collapse.

You need people in those seats consistently firing on all cylinders.

Minor things can set off a chain reaction that leads to a failing in the role. I’ve seen dozens of such moments across the companies I’ve worked with. First-time executives may expect forgiveness only to encounter a job-ending landmine.

Even in my own career, I’ve lost out on promotions or had teams pulled because of a mis-step I’ve made, and even in some occasions something one of my reports did against my explicit instruction.

Some of the reasons I’ve personally been penalized as a leader:

• One of my reports wrote a passive-aggressive message to their team

• One of my reports didn’t manage a new report on their team effectively

• Publicly favored a recommendation by the COO over the CTO.

• I made a joke about sunsetting a product that was close to the C-level’s heart

• I spoke up against an unnecessary multi-million dollar expenditure

Penalties at the executive level aren’t a simple talking to. Instead, they’re significantly more impactful: a harm to the company, a loss in team, a rejection of a promotion, or even an eventual replacement.

I’ve seen other leaders penalized over things like:

• Putting in the wrong number on a presentation

• Having a bad day and momentarily losing their temper in a single meeting

• Not matching the communicativeness of other leaders

• Disagreeing with someone in a public forum about a key issue

• Being surprised at news about one of their projects that they should have known

• Having a message’s tone misinterpreted by a key stakeholder, leading to conflict

• Having a highly visible but fairly minor project delayed

• Making the wrong hire

• Taking too long to hire

• Accidentally forgetting to do a task amongst the hundreds on their plate

• Their boss leaving

You typically don’t get a warning when people lose confidence in your leadership. It just happens.

In the hot-seat, first-time executives can get paranoid and more controlling, unintentionally inflicting further and further harm on their organizations. They eventually create a self-fulfilling prophecy where their desire to be perfect causes them to fail. It’s an unhealthy mindset that takes a huge perspective shift to combat.

The best way to deal with it? Take these hits on the chin and adapt for the best of the organization. Help support your organization, your team, and your reports. Accept that things will happen, and you’ll do your best for as long as you can, and you’ll leave the organization better than you found it.

That’s really all you can do.

You shouldn’t solve all the problems you see.

When you’re an executive, every single problem in the organization is visible to you across the entire organization. Personnel conflicts, failing processes, strategic mis-steps. Everything.

These problems are also rarely within your direct ability to solve. Some problems are intentionally left alone to help further another organizational goal. Others are problems, but they are a low priority relative to other problems the organization is solving.

Even trying to solve a problem can cause a whole host of issues that lead to significant waste and even more issues, especially if it crosses organizational boundaries. No executive likes it when someone else solves a problem in their organization that they were already handling, causing other unintended issues as a result.

Executives have to have the ability to view a problem, and accept that:

• It isn’t time to solve that problem

• Someone else is already solving that problem, and you should not be involved in any way

• The problem may not be one we want to solve

This, as it turns out, is extremely difficult for people who come up from management, where the whole role is about solving all of the problems within their view. As a result, they start to get overwhelmed at the amount of problems, or over-step in their desire to help, causing more issues than they solved.

The best solution might harm your team.

When a first-time executive solves a problem, they often apply manager-level thinking, optimizing for their function and near-term time horizon. This usually solves the immediate problem but negatively influences a farther-term outcome.

It’s often the cause of feedback of “not thinking strategically”.

Imagine a first-time executive who sees complaints from developers being frustrated with deployments, and fights to build a new team to handle those operations. They successfully argue for a million dollar budget and build the team. That leader might view that as a win in the short-term: they got the budget and they were able to hire and solve an immediate developer pain point. But at what cost? What else could the money have been used for in the organization? What happens if that budget was taken away from a new marketing initiative, or a struggling sales organization?

What about the mid-term? What if that new team takes on operations, causing disruptions to day-to-day activities as they onboard and make mistakes. Bottlenecks start to form. Batch size increase. Change failures and incidents occur more frequently.

What about the long-term? What happens when the rest of the organization loses their knowledge of how to set up operations, and as a result the organization’s ability to safely deliver changes rapidly to production decreases. Gate-keeping behaviors start to form, and hand-off cultures start to be developed between development and operations. Blame culture starts to develop when things go wrong.

Eventually, what seemed to be a huge win initially turns out to be a massive liability.

Why is this so different?

When you’re a manager, your problem space is your teams. Problems are immediately within your area of responsibility to solve. You see occasional challenges with your peer teams, but otherwise you don’t have to deal with fixing those problems - those teams’ managers can handle them, and other things can be escalated.

The problems in the managerial space are mostly tractable - they all have some sort of solution that you can discover and deliver that provides relatively immediate feedback on whether the problem has been solved or not. Trade-offs inform which solution is “better”, and these are typically articulated by the executive leadership.

When you’re an executive, problems have complex inter-relationships involving differing trade-offs, information asymmetry, and a web of complexities inherent in the organization.

Most problems you solve will not have clear or easy answers. Each one will have long lists of pros and cons with large, lasting impacts for getting it wrong. There’s typically no “right” decision at all. Just a bunch of decisions that’ll have positive impacts to some and negative impacts to others. Some are intractable - things that will never be solved, only mitigated.

Many solutions have different outcomes depending on whether you look at it across months, quarters, or years - a roller coaster of ups and downs far disconnected from the original decision. Optimizing a solution for the wrong time horizon may result in many downs later in the track.

It makes sense - if the decisions were easy or straightforward, anyone could make them and the executive wouldn’t be needed to make that decision. You’re only involved in that decision because of the implication and potential effects. Someone has to take ownership for that decision, and that’s the executive.

When you’re an executive, you have to think across multiple time horizons and scopes. Sometimes, you do what’s worst for your team or even yourself in the short-term to mid-term to ensure you do what’s best for your organization in the long-term.

Every decision you make will have someone who hates it.

Because of the scope of the problems you are trying to solve, and the pros and cons of them all, it means that every decision an executive makes will have detractors somewhere in the organization.

Managers are used to an environment where they can reliably keep most people happy and satisfied through their actions. They operate at a layer where they can build direct relationships with their immediate teams, and effective decisions are generally mostly aligned with team happiness. Good managers keep their teams morale high and often find solutions that optimize for their team’s happiness and the team’s effectiveness.

When managers become executives, the amount of people who might be unhappy at something they do can be shocking. Most decisions do not have an “everyone is happy” solution.

I have a rule of thumb that I follow with any decision I make:

• 30% of the org will be unhappy, and tell you

• 30% of the org will be happy, and won’t tell you

• 30% won’t care either way

• 10% will dislike it enough to complain to your boss

This means every decision, no matter the outcome, will be second-guessed by someone in the organization who has a less nuanced perspective. People will talk about how you made the wrong call, or should have done something completely different. They’ll bring up their issues to you, their peers, others in the organization, and yes - your boss as well.

As an executive, you (and your boss) will mostly be hearing negative feedback about what you do. It’s a tough transition for managers where in the past doing something successfully meant everyone in their sphere was happy. It’s hard for people who are used to calibrating via positive feedback.

If you have a good boss who listens to the negative feedback they get, nods their head, and doesn’t use it negatively against you - great: you’re in a perfect situation where you have your boss as a partner. They understand the realities of being an executive and have your back.

If you have a boss that takes any piece of negative feedback they get and immediately penalizes you and uses it against you: not so great, because you’re naturally in a role where everything you do will have some negative feedback around it.

The best way for managers-turned-executive to deal with this is to not stress about trying to make everyone happy. Instead, their goal should be to make the organization more effective. Calibration should be done on the desired outcomes and time horizon, not whether people are happy about it or not.

I once organized a change that involved spreading subject-matter-experts across each of the teams to support increasing their access to domain knowledge.

We were previously following a center-of-excellence model that simply was not working: bottlenecks were forming, there was a lack of incorporation of their expertise, and there was a lack of awareness of ongoing work.

Once I announced the change, there were significant complaints about it from various parts of the organization, some of who went above my head to the president to complain. They wrote pages and pages of how this was a terrible idea and how I was an ineffective leader and also demanded a meeting.

The president, luckily, was not a reactive leader. He met with me and I explained the reasoning, and he understood and disregarded all the negative feedback.

Three months later, the change had been extremely positive. As a result of having direct, dedicated access to experts, tams made significantly better decisions that were effectively de-conflicted and were no longer bottle-necked on a central committee.

Executive discussions can be messy, intense, and unfiltered.

Managers might envision an executive team as some sort of organized secretive group of wise experts sitting in a dark room with robes like Illuminati. They carefully and cunningly discuss problems and cast a secret vote on a solution that then gets imparted to the masses.

In my experience, executive discussions are a lot messier. Truly difficult decisions tend to be more like an all-out brawl where ideas quickly get presented, shot down, swiss-cheesed, and built back up. It’s a raw mess that can get quite intense. It’s often the opposite of most team-level manager-led discussions that are usually organized and more harmonious.

People who get a glimpse into how the sausage is made may come away with the sense that the executive team is chaos, or doesn’t know what they are doing.

That’s not an accurate perception.

When you are dealing with potentially intractable problems across a dozen different functions, the ability to rapidly hone in and really debate is key to arriving at a decision that weighs the tradeoffs in the manner best for the organization as a whole.

Managers may be used to softer, more harmonious approaches to discuss and debate ideas with their team, but these only work when the team is composed of mostly aligned individuals that are part of their function or peer function. Their first contact with an executive discussion might be extremely jarring: punches are not pulled, people say what they need to say, and ideas are shot down just as fast as they are brought up.

The lesson managers can draw? Don’t take things personally, and always be willing to speak up, dive deep into details, and make ideas better. Things left unsaid are misalignments that can later sink the success of an initiative.

You have to accept blame for things you didn’t want to do.

As an executive, you fight the good fight, make arguments, have vigorous debates, but at the end of the day the company may not do what you want. Maybe the other executives arrived at a different decision, and you got outvoted.

You then take that decision, fully align your organization, and deliver and execute on that decision as if it was your own. That also means fully taking all the flak from that negative feedback related to that decision.

People call it “towing the company line”, or “presenting a unified front”. It’s exceptionally important in an organization that leaders appear aligned - it causes significant dysfunction when there’s an appearance that they aren’t.

If you do this correctly as an executive - when your reports disagree about a decision, they will blame you.

You have to take that blame and accept it. You can’t pass the buck in any way - if you say “it wasn’t my call” or say “I disagreed, but…”, it creates cracks in alignment that harm the organization. No matter how much you disagree with a decision, or how unfair you believe it is, you have to keep these in private with other executives and not let it leak to others.

You have to accept blame for things had no control over.

While you might make decisions at the executive level, the actual implementation of that decision falls to people multiple levels below you.

When an individual contributor four levels below you does something incorrectly, you can’t just go and chain jump down and correct that contributor. If you did, you would undermine the delegated authority of your entire chain of command. Instead, you have to go through channels and hope that the message gets across.

Once issues comes up in the executive level, you can’t blame the individual contributor that did it. Every issue that occurs in your organization is your fault as an executive, since you created the environment for that failure to occur. You take the blame, and you tweak the environment to achieve better outcomes the next time, working indirectly through your leadership and management chain you implemented to affect the changes.

Becoming an executive can be a jarring transition for managers. Knowing what to expect and how to adjust your thinking to effectively deal with the new context will help you succeed in the role.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

After you craft a proposal, you need to effectively deliver it to the decision-makers and stakeholders. Knowing how to effectively tell your story and manage details can determine how successful your proposal is.

Concisely summarize

It’s really important to know how to summarize your proposal concisely. Leaders and executives typically don’t have a lot of time, and your item is likely on a long list of asks and problems they have to address.

Think about what your proposal - a summary structure will likely follow these patterns:

• “I’ve looked at this situation, and we should do this for these reasons.”

• “There’s a big problem here, and I have a path forward - here it is.”

• “Here’s a quick description of what’s happening. here’s what we’re doing next.”

• “Here’s what I need to achieve this result.”

• “I have additional information - I need guidance on directives based on this information.”

You need to be able to quickly:

• Make your ask clear

• Establish context of the problem

• Establish context of the ask

Remember: the value of the planning is in the plan. While you may not ever show anyone your proposal summary, crafting it allows you to think through it in a way that the major points are clearly laid out and addressed.

Make your ask clear

Most of the time, you are asking for something: a decision, a resource, information, etc. If you can’t articulate your ask and why you are asking in a single sentence, you aren’t being clear enough.

It’s not that you'll always present it in that short a format. It’s just that the skill of boiling it down is valuable for distilling the essence of whatever you want out of your proposal and drives attention to exactly what you need.

Once you understand what you’re trying to ask/recommend/conclude, start with that.

An example of a proposal summary to give raises:

I need to redirect $1,000,000 previously earmarked for additional hires into increasing compensation for existing team members.

Due to our rapid growth and lagging compensation strategy adjustments, we currently have new junior developers making more than tenured senior high-performing contributors.

The recent accidental leakage of the company salary spreadsheet has caused significant morale issues in all of our high performers, with churn expected for over 30% of our team as a result of this issue. Losing our top performers will ensure we will not meet our funding goals for this year.

We must ensure we balance and achieve equitable compensation for our team to be able to move forward. Losing all of our top performers is not an option.

Establish context of the problem

You can’t just ask for something and expect to get it. You need to have a reason or “why” behind your ask. That’s the context you need to summarize and deliver.

Context requires:

• Explanation of a problem

• Explanation of the cost of the problem

• Explanation of the value of solving the problem

• Explanation of the stakeholders of the problem

Most importantly - you need to establish the magnitude of the problem. Revenue terms are often the most impactful, but other framing like reputation, risk, retention, etc. can all be effective depending on your audience.

An example of a proposal summary to change an incident response:

We’ve experienced a quarter-million dollar incident, folks, and we are on the verge of making it worse with our recovery plan - I need alignment on a different plan.

Due to our earlier decision of releasing our fund management dashboard before testing was fully completed, a severe defect was identified in our refund logic. The defect, now fixed, temporarily allowed users to issue repeated refunds for the same transaction, which pulled money directly from our bank accounts. Operations has identified our system automatically issued $230,000 in duplicative refunds that we are unable to claw back automatically. Their recovery plan involves pursuing legal action against our top customers to claw back the money.

This will greatly damage our reputation with customers far beyond the cost of the incident. I recommend instead that we eat the cost as the reputation damage will out-weigh the funds recovered.

Establish context of the ask

Chances are if you are making an ask or proposing something, you already have a solution or direction you’d prefer in mind.

This is your intent or recommended solution. Be sure this is extremely clear and show evidence you’ve done the thinking.

I’ve seen many a proposal sink because the proposer didn’t make it clear what they were specifically asking for and why, or that they didn’t prove they did the thinking to provide confidence in their proposal.

Context requires:

• Explanation of your ask/intent/solution/recommendation

• Explanation of why of this approach

• Explanation of tradeoffs and factors

An example of a proposal summary to change a technology:

I intend to transition our company from UJS and onto Vue.js.

We’ve experienced dozens of critical defects in just the past month and extremely delays in even simple front-end changes as a result of complicated UJS and lack of front-end or Javascript knowledge in our organization. If we wish to achieve our company’s development outcomes, we must address the root cause of the issue - our company’s increasing struggle using an outdated technology to achieve outcomes it wasn’t built to support. This requires a new front-end technology.

Vue.js, while new to me, is an extremely similar technology to Angular 1 that I am a deep expert in and can effectively train and educate a team around. I can, within three weeks, rapidly set up a front-end component and infrastructure system and conduct trainings to educate the team. I expect that even our back-end engineers can effectively make front-end changes within 2 weeks.

I evaluated other technologies like React and Angular 2 and found them quite difficult to use relative to the simplicity of Vue.js. The lack of in-house expertise also makes these challenging to build expertise for across the team.

Transitioning to Vue.js will greatly accelerate our product development efforts by a factor of 3x with higher quality, design fidelity, and lower defect rates.

Use the right proposal medium

One you have your proposal locked, you need to use the right proposal medium to communicate your proposal.

• Presentations

• Written documents

• Group discussions

• 1:1s

• Instant messaging

Presentation

A slide-deck presentation can be effective for asks to groups where the high-level details are enough to make a decision.

Some things to keep in mind:

• Presentations aren’t great at diving into things or explaining a narrative.

• If it requires deep thinking, it’s likely not the appropriate medium.

• Keep it short. Less than 10 slides should be plenty. If you need more, you may benefit from another medium.

• You’ll still likely need to prepare supplemental materials that dive into details.

Written document

A written document detailing your proposal can be extremely effective. You have tons of space to add details, explain thought processes, and dive deep.

Keep in mind:

• It has to be extremely well organized. Without an effective narrative structure people will get lost.

• Use the “newspaper approach”. Start with the headline, then summary, then go into details. Ensure you don’t start at the details or else people will get lost. Your conclusion should always be clear.

• People may not have time. If you’re talking with your leaders, you want to be cognizant of their time and effectively leverage their attention span. A dense, multi-page document may just not be read.

Group discussions

If you need decisions from multiple people at once, or there’s a lot of stakeholders that might have thoughts, it’s useful to have a group breakout discussion.

Keep in mind:

• It can easily derail. Try to redirect people back to the subject or topic at hand.

• Objections are highly visible. It can drag down decision-making or confidene in the proposal if people get stuck on the fact objections exist. It’s always useful to frame the objections and remind people of the magnitude or relevance to the decision at hand.

• Discussions may get uncomfortable. Handling public objection is a learned skill, especially on a proposal you may have crafted and have a vested interest in. Learn how to not take it personally or get nervous when conversations get deep and questions get extremely pointed.

• Ensure enough time on the agenda. Some people think a decision is going to be made quickly so they only reschedule a few minutes. When discussions run long, the context-setting or decision gets deferred for other matters, which causes decision-makers to sit with incomplete information. The incomplete information can bake for days or weeks into an uninformed perspective or decision, derailing hopes of proposal acceptance.

• Know where people stand. You can use 1:1s to shop around a proposal and get thoughts before presenting to a larger group. This helps you incorporate new perspectives, address objections, and find weaknesses in the proposal early. Just don’t ask for a decision - make it clear it is a work in progress.

1:1s

1:1s are a great avenue for shopping a proposal around. People typically are more open about their thoughts than they are in group settings, and you can really dive deeply and openly into the thoughts around the proposal.

Keep in mind:

• At executive leadership levels, some 1:1s don’t stay 1:1.
  
  At individual contributor and manager levels, people can generally correctly assume 1:1s are 1:1s - nobody else will ever know. At leadership levels, things discussed in 1:1s are not automatically restricted to just those two people.
  
  It may surprise those not used to it, but it makes sense if you take a step back and think about it. When you’re talking to an executive and proposing an idea that impacts the company, you’re talking to a representative of the company and other leaders. If you propose something related to the company or is relevant to other executives, it’ll naturally get discussed with other executives. Decisions don’t happen in isolation - if you bring up something affecting a function, it’ll likely get brought up to that functional leader to address.
  
  This is pretty easy to deal with - be explicit if you want something to remain private. The strength of your interpersonal relationship with that person helps keep things private when you want them to be.

• What people say in a 1:1 may differ from a group.
  
  I once secured “buy-in” on a proposal to change the organization structure from every individual decision-maker, only to have all the individual decision-makers disagree with the proposal when I presented it to them in a group - despite them all individually agreeing to it!
  
  It wasn’t that they were lying - it’s just that the dynamics of group decision-making can’t be avoided. There’s external pressure, perception management, personal factors all interplaying in real-time during a group discussion. How one person personally feels and thinks may be completely different when in a group.
  
  In the case above, I pointed out that they all actually agreed with the proposal individually, which helped reset the decision in the group.

• Interpersonal relationships really matter to the honesty of thoughts.
  
  Honesty requires trust from both parties. Trust is a sensitive thing where history, competency, integrity, perception all play a key role in determining how open, truthful, and direct you can expect a relationship to be.
  
  It’s key to maintain good relationships with people you work with, and to not let ego, personal disagreements, or pettiness disrupt your working relationship. Work is work, and it really shouldn’t impact your perspective on someone as a person and human being. My advice? Always keep the other person’s best interests in mind, and support them when you can.

Instant messaging

Sometimes you don’t need a formal touchpoint to submit a proposal or get a decision.

You can just send an instant message, either directly to a single person or or in a group.

Some advice:

• Try not to write a wall of text. Your shortened summary statement actually help here an comprise the bulk of the message. You can link to additional details in another written document at the end of your message.

• Be cognizant of message visibility. It’s easy to accidentally include more people than needed in a decision, or to forget a key decision-maker when making a group chat. Always double check your list and adopt a ”just enough” approach to decision makers to avoid an awkward situation where you need to remove someone or include someone after a decision was made.

• Expect it to go into overtime. Some decisions may end up being larger an require deeper discussion. These tend to experience a medium change, such as being deferred to a breakout discussion or put on the schedule for the next committee meeting. Try not to push too hard after this point and wait for the time if you can.

• Tone gets lost. If you find that the conversation is going nowhere, it might be a matter of talking past each other. Defer to a breakout or other conversation where people can align and get a better sense of where they stand than what instant messaging provides.

• Keep a separate decision log if you’re dealing with a long-lived complex chain of decisions. Decisions tend to get lost amidst message an channels. If your proposal or decision involves a long-lived topic, it’s helpful to keep a decision log to track them over time, particularly if people forget what decisions were made in the past.

The amount of thinking that goes into a proposal does not need to be reflected in the actual delivery of the proposal itself.

I once wrote up a 10-page document on an organizational change. I articulated trade-offs, discussed alternate options, discussed failure modes, success criteria, and all manner of thinking into an extremely detailed, cohesive plan, complete with charts and data.

Once I did that thinking, I sent my CTO a two sentence instant message letting him know that I had a plan to adjust the organizational structure, and that we would not need more money. The CTO, satisfied, approved it.

Other advice for delivering your proposal

Be ready for a lot of questions.

Leaders, especially executives, will hone in on the stuff they care about. Some proposals might have zero questions, but others might have dozens.

Some questions might be very surface-level, others might drive extremely deeply even into areas you wish they didn’t go into. While you should do your best to preemptively think of and answer questions, it’s unlikely you’ll be able to address every single question before they are asked. Some questions are intended to poke holes, others are to help the leader build context. Some might just be intellectual curiosities for the asker. Some might be because there’s strong disagreement. Others might be because there’s strong agreement. You can’t assume the intent from the question alone.

Answer them factually and don’t get anxious or take offense. It doesn’t mean the leader is against the proposal - they just want to better understand it. I often see people answering questions with “justification” answers - trying to make themselves and their proposal look good vs. answering truthfully. Some end up blabbering in an effort to avoid answering the question. Neither builds confidence in the proposal.

An IT professional once gave me his proposal for securing our physical office network infrastructure to achieve compliance with PCI regulation. I asked a lot of questions. Questions about the tradeoffs, the cost, the firewall capabilities, the hardware maintenance costs, the setup and management time, personnel requirements, and more.

By the end of it, I was extremely convinced that the person had done their research and kept our company’s best interests aligned, and had considered the risks, benefits, and constraints thoroughly. While we had minor disagreements in approach, they were personal preferences or unimportant quibbles.

I approved his proposal in its entirety.

In a conversation afterwards, his boss said that I had scared him during my questioning. Because I was asking so many questions, the IT professional had believed that I was fully against the proposal and was trying to sink it. My questioning came across as intimidating.

Know when to stop talking

Whether it’s nerves presenting to an executive or just personality differences - some people just keep talking far beyond when their point has been effectively made and the proposal is ready to be decisioned.

Sometimes, this causes other areas of concern to open up, derailing a conversation or causing other factors to take precedence that change the decision.

It’s important to read the room and know when your point has been made. A useful mental model is to view your role in the delivery of a proposal as setting the stage for a show about making a decision. You’re not there to act in the show, so get off the stage before the show starts.

Useful phrases in your toolbox

Adapting to objections and changes in real-time can be difficult for some people, but it’s useful to have some phrases you can fall back on to help direct your thoughts.

Some of these phrases include:

• “I don’t recommend that, and here’s why...”

• “We did analyze that option and do not recommend it because…”

• “We can make that work, but our belief is that the more effective option is…”

• “I think that’s a great idea, and we can get started on it immediately/as soon as you want, provided…”

• “I defer to you all, but my personal opinion is…”

• “That’s a fair point, where does it fall in the set of tradeoffs we need to make?”

and so on.

When you adapt or address an objection, counter-proposal, or other statement during delivery of your proposal, make sure you:

• Make it clear you understand the objection or counter-proposal

• Make it clear you’ll commit to any decision that does get made

• Make your own position / recommendation clear

• Make it clear you are flexible when you are, and not flexible when you aren’t

Don’t worry about the credit.

You might not get credit or recognition.

Proposals can sometimes change form in tiny or large ways. This may muddy the waters as to who is responsible for a brilliant idea. Sometimes it’s the last person who spoke and had their idea incorporated. Other times it’s the most authoritative person in the room. I’ve had reports take full credit for something I explicitly prepared and directed them to do as if they came up with the idea themselves.

At the end of the day - it doesn’t matter. Trying to get credit might mean you reject otherwise good improvements to your idea, or lose someone who could’ve successfully drove it forward. It might mean you focus too much on optics instead of substance.

Remember - your goal is to affect organizational change, not get credit. Don’t worry about recognition - it doesn’t matter.

Focus on the goal: improving the company.

Having a great idea is unfortunately not enough to get it approved. The delivery of your proposal highly impacts the odds that proposal is approved. Stack the deck in your favor by avoiding common mistakes and making it as easy as possible for decision-makers to decide.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

Objections

When you deliver your proposal, you will get a response of some kind from the stakeholders and decision-makers.

While we all hope it is full-throated acceptance and a round of applause, it is extremely unlikely that will happen all the time.

Instead, you must be prepared to handle objections and the various responses you will receive. Handling might mean redirecting, debating, incorporating, or even ignoring, depending on the context.

Having a strategy helps you navigate the response in the heat of the moment improving the odds of successfully driving forward your change.

Categorizing responses

If we use a categorization model, you can expect 3 different kinds of responses when you propose something:

• A disagreement on outcome. There is a fundamental disagreement between you and the other person on the end desire or goal that you want to achieve.

• A disagreement on mechanism. While your goal may be shared by the other person, there is disagreement on the proposed solution to reach that goal.

• An agreement and alignment. There is both agreement on outcome as well as the mechanism to achieve that outcome.

Each of these requires a different approach to address objections or challenges.

Dealing with disagreements on outcome

There’s several ways that disagreements on outcome manifest:

• Rejecting

• Denying

• Diminishing

• Nitpicking

• Obstructing

Rejecting

aka. “Nope.”

• “I’m gonna have to say no.”

• “We have rejected your proposal.“

• “I disagree.“

A rejection is exactly what it sounds like. Your proposal is rejected, with no explanation why.

In this case - ask for specific reasons why. One you know the reason, you can address it.

Denying

aka. “This isn’t a problem”

• “The user activation rate isn’t a problem - our rates are fine.”

• “The team is happy, why do we need to increase the party budget?“

• “Leaders take time to onboard - it’s too soon to determine his performance.“

Denial occurs when people don’t agree there is a problem. Since they don’t agree the problem exists in the first place, they are unlikely to want to invest their energy or resources in resolving the problem you propose to solve.

There’s a few techniques you can use to address these:

• Paint a picture of the problem. If you can illustrate the problem truly exists in terms they understand, you can convince them to move beyond this objection. Consider your narrative and what is important to that stakeholder.

• Get feedback from those suffering from the problem. Sometimes, the denial comes because you lack credibility in representing the problem. Getting direct feedback from those suffering the problem may be enough to move past denial. Anecdotal but personal evidence can craft compelling reason from an empathy and sympathy standpoint to recognize the problem exists.

• Reduce their cost and energy. If the person doesn’t actually have to invest any resources or energy of their own, you could theoretically minimize their concern or involvement to bypass their denial. Emphasize how it won’t impact them or their organization at all, or even how negligble the cost is. They may move on to bigger and more important subjects and leave you to your devices.

Diminishing

aka. “This isn’t that big of a problem”

• “Retention rate is down, but only a few percent - it matches expected seasonality.”

• “Team churn isn’t a huge deal - we can replace them pretty quickly.“

• “We’ll just pay the daily fine - it’s the cost of doing business.“

Diminishing is a form of denial. Instead of denying the problem exists, the stakeholder agrees the problem exists, but disagrees on the magnitude or importance. 

Techniques to resolve:

• Illustrate the magnitude. This is where your research is important. Get data, quantify costs and impacts in a way the stakeholder cares about.

• Paint the long-term picture. A lot of diminishment comes from problems that are minor embers now, but can turn into massive fires later. If you’re doing your job right, you’re trying to avoid a fire before it starts. Paint a picture of what this catastrophic end state likely might be if the problem is left untreated.

• Compare it to other addressed problems. If you can show that the organization has approved or otherwise taken action on solving lower-magnitude or less important problems, you can make an argument that a higher-magnitude issue should certainly get traction. Otherwise, the other addressed problems should also be ignored.

• Ask the threshold at which they would start to consider it a problem. Sometimes the person just has a different level of pain tolerance or a different set of tradeoffs they are optimizing for. Understanding what that problem threshold would be is extremely useful for calibrating when it would start to be considered a problem for that person.

Nitpicking

aka. “Have we considered this, or this, or this?”

• “We haven’t done the research on React v14.2.1 vs. v14.2.2, so I can’t approve moving off of EmberJS.”

• “This is terrible - you used the secondary brand color here instead of the primary!“

• “Before I approve this $10,000,000 spend, why in the world is there a $500 line item for team snacks?“

Nitpicking is about resistance to the proposed solution, but the resistance is specifically not relevant to the actual outcome or success. Also known as “bike-shedding”, it’s over-discussion about details that are implementation related or don’t matter to actually proceeding or not with a proposal.

The classic example is when a committee is discussing whether to build a nuclear reactor or not, and the decision is being blocked on agreement. as to whether the bike-shed should be painted blue or green - a non-consequential detail to making the decision.

There’s typically a root cause for nitpicks you can address.

• Disagreement on outcome. The root cause of the nitpicks is sometimes related to the fact that the outcome doesn’t actually have buy-in. At which point, you can treat it as a denial or diminishment and act accordingly.

• Lack of perspective on problem or solution. Re-orient people back on the primary problem, and highlight the relative unimportance of whatever is being stuck on.

• Lack of other ability to contribute. Some people just want a path to contribute. Because there’s no other way, they instead contribute to minutiae, delaying. a decision. You can either provide other ways for them to contribute that don’t block the decision, or challenge their involvement in the decision-making process at all.

• Personal relationship issues. You may have just made someone mad. Perhaps they don’t like you, or they are just that kind of person who over-focuses on irrelevant details.

Obstructing

aka. “I’m gonna need you to do this and this and this. Why? Dunno.”

• “Sorry, you have to fill out Form 173 before I can even look at your Form 184.”

• “Can you get agreement from these 9 random people with no stake in this decision?“

• “Your team needs to do their daily log before I approve this new project.“

Obstructing is when a decision-maker or stakeholder introduces various hoops you must jump through to gain approval that are disproportionately difficult relative to the value they provide, or do not have any reasonable purpose relate to the proposal.

There’s a couple ways to deal with this:

• Do them. If the hoops are done, you can get approval. Yes, it means extra work, but it might be the fastest way. If later on even more hoops are added, you can point out the discrepancy and have a direct conversation about that. This is a useful method to deal with organizations that have layers of bureaucracies.

• Point out the hoops’ lack of purpose. You can directly address the fact that the hoops have no purpose or value. Depending on the organization, you may be able. to get the hoops removed.

There can be a deeper reason why someone might be obstructing your proposal:

• Lack of trust. If you lack credibility, or there’s some element of your performance that has caused deceased trust, this can cause opposition. Gently ask about ways you can build up or restore trust.

• Personal relationship issues. Once again, your personal relationship can plan in here. The best way to avoid this is to have good personal relationships with everyone.

• Horse trading. Stakeholders have their own needs. Perhaps they see this as the opportunity to get their item done.

One you understand why the hoops are being put up, you can work to go through them or remove them.

Dealing with disagreements on mechanism

When there’s a disagreement on mechanism, it means that the disagreement surrounds the specific context and constraints of your approach. While your goal may be shared by the other person, there is disagreement on the proposed solution to reach that goal.

There’s several ways that disagreements on mechanism manifest:

• Rejecting

• Criticizing

• Optioning

• Compromising

Rejecting

aka. “Nope.”

• “I’m gonna have to say no.”

• “We have rejected your proposal.“

• “I disagree.“

Same story - a rejection is exactly what it sounds like. Your proposal’s solution is rejected outright with no explanation why.

Same as before - ask for specific reasons why. One you know the reason, you can address it.

Criticizing

aka. “There’s quite a few challenges and issues here.”

• “Users are unlikely to even look at that page given the analytics information we have.”

• “This proposal relies on a key team member that’s going to be OOO for 3 months.”

• “The system doesn’t actually do what you’re saying it does.“

Criticizing is when stakeholders start to bring up relevant reasons why a proposed solution or change won’t work, discussion obstacles, challenges to execution, or even changes to the ROI, etc.

If you’re hearing about many of these things the first time - you probably should have done more research.

If you are addressing the challenges in your risk management, mitigating them, etc. then criticisms are generally overcome-able by talking through your plan to address each one.

Criticisms are extremely valuable as they tell you whether your idea has considered important factors or not.

Some criticisms have their root in a disagreement of outcome. Keep an eye out for when the criticisms start to talk about the why or the problem instead of the approach.

Generally, criticism can be addressed if you are prepared:

• You can accept it. A plan doesn’t need to be perfect to be effective. Having a weakness in the proposal can be accepted explicitly as a risk.

• You can reject it. If a criticism is unwarranted or doesn’t entirely apply due to some mitigating factor, you can reject it. You can explain why it shouldn’t be considered in the decision.

• You can address it. You can take that criticism, and modify your proposal to factor it in. Alternatively, you can explain how you’ve already addressed it in your plan.

Optioning

aka. “How about doing this instead?”

• “A much faster approach might be to send an email blast instead of calling everyone.”

• “We should move the budget from Product instead of Engineering to support Sales.“

• “What about implementing an unlimited leave policy instead of giving 30 days?”

When stakeholders agree with your outcome, but disagree with your mechanism, they may propose alternate approaches that help meet the same outcome.

If your solution is inherently unimportant, be open to the options they propose - if all roads lead to Rome, then does it matter what road you take?

If the specific form of the solution is important, then you can address the pros and cons of each approach and make a recommendation. You should be willing to walk away from your proposal if your solution is not approved.

Compromising

aka. “We can both get some of what we want.”

• “We’ll move Alice and Bob to the new team, but we’ll need to move Charlie off.”

• “We can move Project A to Q1, but we’ll need to stop work immediately on Project B.“

• “You can hire a new person, but you’ll need to terminate two under-performers by Q2.”

Compromising is when stakeholder ideas get merged together to water down the overall solution. It results in implementation of parts of the solution but not others that decrease overall effectiveness but still allows of the goal to be met.

Compromises are often unavoidable. Don’t be a ideologue, but keep the goal in mind and horse-trade as appropriate.

Agreement and Alignment

If you get agreement and alignment, you’re in generally good shape for getting your desired outcome and solution approved.

Responses you might get are:

• Accepting

• Reinforcing

• Testing

• De-risking

Accepting

aka. “Look good to me.”

• “Your approach is sound. Let me know what you need.”

• “Looks good.“

• “Good to go. -full steam ahead.”

Stakeholders fully agree with the outcome, as well as the mechanism you proposed, with no changes. This is full acceptance, and the easiest path forward for you.

Congratulations!

Reinforcing

aka. “Hey, it’d be even better if we did this, too.”

• “We could even add a banner to the page to upsell in addition to the ad you proposed.”

• “That’s great - maybe we can also do a secondary survey.“

• “If we have an offsite, we could probably throw in some fun events to build team camaraderie.“

When stakeholders start to suggesting improvements on top of the proposed solution that help reach the same or substantially the same goal, that is actually a great sign.

In order to move to a formal acceptance and avoid scope creep that could then make the proposal unwieldy and thus move it to rejection, explicitly get agreement that they agree to the outcome and the general solution, and propose further discussions to iterate on the solution together one the proposal is formally accepted.

Incorporate their feedback, consider the scope, cost, and other factors and generally move forward.

Testing

aka. “Look good to me, but let’s check in after a month.”

• “I think the plan makes sense, but let’s look at numbers in a month.“

• “Let’s roll out the A/B test and reconvene in a week.“

• “If the monetization rate stays above 20% next quarter, we’ll keep it.”

Testing is a conditional acceptance of your proposal.

Your proposal’s outcome and solution was accepted, but there’s a decision re-evaluation at some point in the future to determine whether the decision should be kept - ie. a trial run or a test. It means if it turns out to have issues, it might be reversed.

You’ll need to get agreement on the parameters of the test - if there are unreasonable expectations of early or immediate success, you’ll want to hash that out now before going forward and having the test fail. Your discussions will mostly revolve around managing the timing and scale of expectations rather than the outcome or solution.

After you all agree on the parameters, that’s it. Follow the test, report results accurately, and proceed with a permanent rollout if the results are positive. Make sure it goes as smoothly as possible.

De-risking

aka. “I have some concerns with the approach.”

• “Can we try this out on a subset of people? I’m afraid they’ll react quite negatively”

• “We should get some opinions from the team before committing to this.“

• “Let’s wait until after the busy season before making this change.“

De-risking is when stakeholders agree with your outcome and mechanism, but impose constraints or guardrails to address a perceived or real risk. The most common guardrail are typically around budget, timing, and audience.

If the guardrails are appropriate, incorporate them and move forward. If they are busy-work, you can try to argue out of it but it might be easier to just do the busy-work.

If the guardrails would cause undue burden to your solution, propose other mechanisms to address or mitigate whatever risk is being brought up.

Knowing how to address the various kinds of objections you will receive when you deliver a proposal is key in successfully driving forward the change you want to see.

People are complex with different motivations and perspectives - being able to easily and quickly factor in their perspectives to strengthen your proposal is a skill that can be learned.

A single objection doesn’t mean the end of your idea. Treat it as a beginning for further discussion and refinement.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

Crafting your proposal

An idea isn’t useful in and of itself. It requires execution and delivery. If you’re trying to drive a meaningful change, you’ll need to be able to formualte your idea and get buy-in from many stakeholders across an organization.

This requires you to create a compelling argument to convince others of the merits of your idea. Your proposal needs to be able to tell a story or narrative that relates to your stakeholders and decision-makers: the people who ultimately in charge of approving or rejecting your idea.

Your proposal should be well-researched, with data, sound arguments and clear, concise summary of the problem, the solutions, and the recommendation.

Do your research

The first rule of proposing something: know what you’re talking about. This obviously means doing your research.

• What exists today?

• What has been attempted or tried in the past?

• How aware are people of the problem/change/solution you are proposing?

• What are the risks?

• What are the important tradeoffs?

Every aspect a proposal where you are not aware of existing efforts, possible problems, or other issues undermines the credibility of your proposal.

Stakeholders expect you have done your homework. If you have too many unknown unknowns because you didn’t do your research, you harm your credibility. Unknown unknowns that should be known knowns is a signal to deciders that you didn’t really think that deeply about what you are suggesting. At some threshold, your proposal will be rejected outright on the grounds it was not as well thought out as it should.

The importance of knowing current state

I once worked with a senior engineer who proposed a scaling plan to avoid an outage during our busy season that he spent several weeks writing. In it, he proposed a massive re-architecture.

I read it and rejected it outright.

• He didn’t match the desired risk profile. His proposal was a big-bang change of a massive amount of infrastructure components and a complete rethinking of the data lifecycle. This would have taken on so much risk and required so many changes across the entire application that it was likely we would have broken our system ourselves a hundred different critical ways. At that point, I would have preferred to have an outage instead of the many data issues, defects, and other problems his approach would have caused.

• He proposed things we already had. It was clear he didn’t do his homework on what we were already using. He proposed large different implementations for capabilities we already had, such as asynchronous message passing or reading from replicas. His proposal was framed as if these did not already exist to strength his argument, when in reality much of what he was proposing was a re-creation of capabilities we already had. There would have been little to no benefit to change our implementation for the significantly added cost and risk.

• He proposed things we already had smaller, easier plans to do. It was clear he didn’t look at any of our existing documentation on our scaling plans or talked to any of the stakeholders. His proposal contained complex plans for things we already had simpler plans to do, such as vertically scaling or distributing load or leveraging caching. His plan increased the complexity of the effort and ignored many of the low-hanging opportunities that would have negated the need for many of his ideas.

It wasn’t that his plan was bad - it was, in theory, good. His issue was that he failed to account for existing work and the current context of our organization. This meant his proposal was, in practice bad, especially relative to our existing plans which were much simpler and more efficient with lower risk.

Form the right narrative

If you did your research and you have a great idea - it’s not enough. Unfortunately, convincing people requires more than facts. It requires a compelling story that helps people connect the dots to why you are proposing what you are proposing.

This is the big flaw I see with many people proposing changes and getting them rejected. They fail to clearly create a narrative structure. Instead, they dump a bunch of random statements and numbers on a page or deck, making it hard to follow. Or, they immediately jump into a solution without identifying why they’re even proposing it. By the end of it, the decision-maker doesn’t know what the problem is, let alone what the solution is, why it’s being asked for, or even what was being asked for.

They reject it out of sheer confusion.

Be structured

When you craft your proposal, you need to form a narrative that is well-structured an flows as expected. You’re telling a (hopefully true) story to decision-makers, taking them along on the journey.

You need to quickly orient them, answer their questions, and highlight the primary areas of importance, such as:

• Why is this being proposed?

• What is being proposed?

  • What are the pros?

  • What are the cons?

• What are other options?

• Who is involved?

• What’s the value of doing it the way it is proposed?

There are many narrative structures that can support you here:

• Pain point and solution. There’s a pain here. It’s causing <X> issues. Here’s a proposal to resolve that pain.

• Problem → Solution → Value. This problem exists. This is the proposal to solve it. Here’s the value of solving it.

• Simple math. This opportunity to capture or save <X> value exists. This is the <Y> cost to do it. <X> is greater than <Y>, so we should do it.

• Bets. Here is our goal. We have information that indicates this approach will lead to <Y> value. We are going to size a bet that costs <X> to capture this improvement.

• Intent. Here’s what I intend to do to solve this problem. Do you have any objections?

What narrative resonates depends on what you are proposing and to who, and the context.

Know what is important to the decision-makers

If you don’t know what is important to the decision-maker, you won’t be able to provide them with it. If you can’t provide what is important to the other person, they’ll either not care about your proposal, or they’ll reject it because you didn’t sell it from their perspective.

What does the person care about? The subjects are limitless: Cost? Risk? Impact? Numbers and data? Alignment with strategy? Impact to another project or effort? User benefit? Predictability? Impact to the team?

Ask yourself what the stakeholder cares about. Suppose you’re presenting an idea that has finance as a stakeholder, you’ll want to ask yourself:

• Does finance care about the cost of an initiative?

• Does finance care about the value of an initiative?

• Does finance care about predictability of expenses?

• Does finance care about the reliability of estimated expenses?

• Of these, does finance care about one in particular more?

If you can’t explain possible ways how or reasons why the stakeholder will reject your proposal, you don’t fully understand their perspective.

Once you do understand, bake that into your proposal. Show numbers to people who care about numbers. Talk about user benefit to people who care about user benefit. Show resource utilization to people who care about resource utilization.

The opposite of this is also true - don’t focus on something they don’t care about. If you know that a decision-maker doesn’t care about numbers an data, then don’t spend your whole proposal discussing numbers and data - it won’t resonate.

The importance of knowing your audience

Engineers often propose technology and practice changes in technology organizations that I lead. Proposals range from things as granular as new linting standards to as monumental as organization-wide technology stack.

Many engineers trying to introduce a new technology emphasize the positive resume/career impact on them personally, and the adoption of the technology by larger enterprise companies. They focus on things that they think are valuable, and not what I actually consider during a decision.

The problem is that whether there’s an impact on their career or that massive companies are using it aren’t factors in my decision. Instead, I care about things like:

• How long will it take to migrate?

• Do we have enough of “critical mass” of people in the organization that can sustain our usage and adoption of it?

• Across all of our innovation portfolio and organization, is this the most important technology to implement currently to slow down to learn?

• What are the benefits to speed, throughput, and quality?

• What classes of problems does this address, and are we experiencing these problems at the rate that I want to invest in resolving them?

• What do the next 3, 5, 7 years look like for this technology and its upgrades?

• Does the technology’s upgrade cycle match our ability to invest in upgrading?

• Does the technology’s market-wide trend enable effective hiring or training?

• Does the technology still provide benefits at the scale and size we operate at?

These questions matter significantly more than whether it’ll look good on a particular engineer’s resume or whether a big-name company that operates in a completely different context uses it.

I’ve often rejected weak proposals that didn’t factor in these interests. Engineers were ill-prepared for the kinds of questions I sought answers for, and the narrative and arguments they made up weren’t compelling.

Don’t hide from the weaknesses in your proposal

In an effort to get their point across, a lot of people hide the weak points of their argument or proposal. They do this because they aren’t confident in their proposal enough to overcome objections. By hiding it, they believe they’ll be able to hand-wave or gloss over it, skipping a potentially difficult discussion.

Don’t do this. When the proposal gets discussed under scrutiny, you will get caught off-guard and be unable to answer important questions, which undermines your credibility, or even worse, results in fatally flawed proposals being accepted, which isn’t good for the company.

It’s a mistake to ignore or hide the weaknesses of your proposal. Instead, be explicit about the drawbacks and try to figure out:

• Are they valid?

• Are they high impact?

• What is the risk of this weakness being encountered?

• Can this weakness be compensated?

• Is this an acceptable risk?

Once you identify the weaknesses, address it explicitly. Be up front about possible mitigations, or even solicit ideas for addressing the risk.

The more thoroughly researched, the better. Document potential objections, gauge their validity, and find counterarguments for them.

Remember - the point of a proposal is to swiss-cheese it and poke as many holes in it as possible. If it’s still standing after that, it’s more likely a good proposal.

The more you yourself poke holes in your proposal, the more prepared you will be to answer objections when decision-makers do it.

Be clear with you recommendation

When you’re proposing something, there are likely other alternatives to your approach to solve the same problem. When crafting your proposal and including possible solutions, you have to be careful to know what you don’t want.

Many people fail in this for some strange reason by leading with an option that’s the opposite of what they want actually want to do. Sometimes they’ll present multiple approaches as equivalent even when they have a strong recommendation - they fail to highlight what they are actually looking for. When decision-makers inevitably decide to do a thing they didn’t want, they are shocked.

It’s their fault, really. They didn’t make their desired outcome clear, instead providing the entire palette of options as equivalent.

Lead with your desired direction. Always make it clear what your recommendation actually is, and the strength of your recommendations.

You rarely want to give options you don’t want people to take. If you want to be comprehensive with the options, you can list them as rejected options due to various considerations, but you should always mark when an option is recommended or not recommended.

Polish your proposal up

Once you have created a proposal, take a step back and examine it. Be detail-oriented.

Use the right medium

There’s many ways a proposal can be articulated - verbal, a presentation, a short memo, a message.

You need to make sure you choose the right medium and approach.

Some of this depends on your audience - do they want to or have the time to read a giant document? Will a slack message be more effective? Do they need guidance through a presentation or an in-person discussion?

Whatever the case - match your proposal with the person and context. If you write a 10-page document for a simple, minor budget ask, you may just get rejected because of the length. If you put an ask to do a company-changing direction in a two-sentence direct-message, you’ll likely receive an immediate rejection followed by setting off a lot of alarms.

Ensure your story is cohesive

Cohesion is about removing unnecessary or irrelevant details and information.

Your proposal is about the believability of the story, not the comprehensiveness. That’s not to say you should hide or lie or remove important information. But you should be cognizant that not all details are relevant to the decision to approve or reject a proposal, and therefore these details should be removed to achieve a coherent flow.

You can save extraneous details for a deeper dive for actual implementation or as supplementary material for those interested.

The importance of removing the unnecessary

I once received a proposal to change our build pack technology from one of my engineers. Much of the document in particular was filled with code-level concerns and various line-by-line package changes, comparison points, and other examples.

I skipped almost the entire proposal because it wasn’t relevant to deciding whether we wanted to switch or not. Instead, I did my own research and approved the proposal. If I hadn’t had the time, I likely would have rejected it outright.

A single sentence that had said “Build definition files are 30% shorter and 3 minutes faster” would have been perfectly fine to illustrate the point, and saved me time.

Make it professional

I’ve seen many proposals littered with typos, work-in-progress sections, run-on sentences, incorrect data, or irrelevant fluff. These are all diminished my confidence in the actual thinking and preparation behind the proposal. It made me think the idea was half-baked, and I put less effort into trying to figure it out.

If you’re going to present something, make what you are presenting is polished. It doesn’t have to be aesthetically pretty, but put care into it.

Use headings and paragraph breaks. Use tables. Form complete sentences. Run auto-correct. Pay attention to the details.

Your proposal is your chance

You need to do your research, think through your proposal, carefully consider your audience, and be sure your ask is clear. When you put your thoughts in a structured format appropriate for the ask, it helps prepare the decision-makers to make a decision. The easier you make it to make the decision, the more likely it is the decision lands in your favor. Without the ability to craft effective proposals, you’ll be unable to drive organizational changes outside of your sphere of authority.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

Establish your credibility

Credibility = Proven Competence + Integrity + Relationships

- Chris Fussel, “One Mission “

Credibility is the trust your organization has in you. Trust is a key factor in driving organizational changes.

Organizational change requires participation across many people across a company. Each one has their own perception of you. For them to buy in and take the time to support your idea, they need to trust you.

If nobody trusts you, they’ll disregard what you say even if you are 100% correct. Even if you have authority, your authority has limits. You can’t just keep snapping your fingers and getting things done without breaking your organization.

Building credibility requires competency, relationship-building, and time.

Do your job well and build a track record

There’s no better way to prove your point than with overwhelming competence. If you’re excellent at what you do to the point where nobody can argue with the method or results, driving forward change becomes a lot easier. You have a history of credibility to fall back on, and people are willing to give you more leeway even if they aren’t fully sold on your idea because you’ve pulled through in the past.

People look to those who can deliver. If you don’t have a track record of delivering, you won’t have the credibility to ask for change. Start with quick wins. Don’t tackle a massive challenge day one. Find a small pain point and solve it. Then the next, and the next, and the next. Build up a track record before you need it.

You can’t rely on authority forever

I see a lot of new executives and leaders fall into this trap when they enter a new organization. They come in and demand changes to everything, not understanding or appreciating the context of the organization. They rely on their authority.

Initially, it works. These demands are followed because of the authority granted by their title, and not through merit of the idea or trust in the leader. People are willing to give the benefit of doubt. The new leader has the excuse of “being new” when they make mistakes.

However, it wears off quickly. As time goes on, competency and proven success at the organization becomes more important. If a leader keeps making mistakes and relying on authority to push things through, they’ll start to receive pushback. They don’t have excuses to fall back on for their bad decisions. When failure does happen, it marks the leader as a poor decision-maker, and the trust is lost with the team.

With enough trust lost, resentment starts to occur. It gets harder to rely on authority to push things through. People might actually be rooting for things to go wrong or put minimal effort into preventing failure, further driving poorer outcomes.

The loss of trust makes it harder for that leader to affect future changes successfully.

The importance of credibility

At a former company, our CEO hired his longtime friend to become the new Head of Development, without a single interview from anyone on the team.

My new boss came in and surprisingly fired several people in his first day. With the tone set, he started making demands left and right about changes he was making to practice, process, and technology.

It became evident over the weeks that this individual knew nothing about how to do the job. Basic concepts needed to be explained to him, and his orders consistently contained things that had no bearing on the actual problem, context, or solution space. He brute-forced his decisions through with his authority, causing significant issues and problems, which he then quickly blamed on the team.

He wasn’t just in the wrong ballpark, he wasn’t even playing the same sport. I attempted to guide him, privately giving him feedback on his decisions and doing my best to ensure successful execution. We had many perfectly implemented things with terrible organizational consequences. As he made more and more uninformed, indefensible decisions, he quickly lost credibility with the entire development organization he was leading.

With all of the problems occurring as a result of his poor decision-making, executive pressure started mounting. What was previously a well-run organization ground to a halt, and leadership wanted to know what the problem was. My boss tried to shift the blame on to me and claimed that I was not competent.

This was the straw that broke the camel’s back. At the organization, I had a significant amount of credibility built up with many, many, many wins - my track record was undeniable to even the uninformed. When his negative credibility challenged my positive credibility, most of the development organization threatened to quit - myself included.

The CEO, finally realizing his mistake, quickly transitioned that individual to a different role with no authority and little interaction with the development organization, and placed me in charge.

Build relationships with others

There’s an idea of a relationship "bank account”.

When you support others and help them achieve their outcomes, you make deposits into your “bank account” with that other person. When you detract from their efforts, ask for favors, or block their successes, you make withdrawals. If you try to withdraw more than you’ve deposited, it doesn’t work.

It’s a bit of a transactional mental model, but it’s a useful one: find out how you can support people before expecting them to do stuff for you.

If you haven’t built up any credibility, you can’t ask for large favors. Help others first.

Be careful to not start viewing everything as a transaction! Nobody likes a slimy politician.

There’s a lot of ways to support people:

• Do something for them

• Give them information they need

• Help them achieve their goal

• Help them build their own credibility

• Help them avoid a problem

• Give them a useful insight

It first starts with talking to that person and figuring out what they need and what they want.

Help others without creating problems for them

Helping others is a great way to support them and build trust. However - it is a double-edged sword. If done incorrectly, trying to help people can get you viewed as an interloper or someone who is overstepping their bounds.

If you want to support someone - ask if they want help. Be sure your help is actually desired.

It’s especially important to not seek credit when helping others. If you help someone, and then try to get credit for it, then it can be viewed extremely negatively and harm the relationship. Look at it from the perspective of others on that person you helped:

• Is that person not able to do their own job?

• Should I go to you now for this thing that this other person has owned in the past?

Many people want help, but few want to look bad to get it.

If you do help, stay in the shadows. Don’t draw attention to the fact you helped. It helps you help others when ego isn’t a consideration or factor.

True, genuine help builds trust. Selfish help does not.

Don’t engage in unhealthy office politics

Unhealthy office politics are things like:

• Gossiping about co-workers

• Telling people who don’t have any business to know things other people told you in confidence

• Complaining to people about things they reasonably have no authority or influence to effect

• Fostering bitterness, negative sentiment, or venting

These are all thing that are organizationally unhealthy. That is, it might feel good to do them, but they don’t help the organization improve or operate effectively. At their worst, they can feed into negative sentiment and cause churn and dysfunction.

If you’re trying to build credibility, you need to stay out of unhealthy office politics.

For one - people will eventually find out. Many people accidentally or intentionally leak will leak something. What you told them, even if it was a private opinion on something , may eventually makes its way back to the party involved— this may be accidental or intentional.

Imagine trying to get buy-in on a cross-functional idea from someone who later learns you’ve talked poorly about their competency to their report. Imagine you talk poorly about your boss to their boss while looking to get promoted. These situations can quickly degrade any credibility you have built.

Every organization has a grapevine of communication. People talk to each other. While you want to be aware of what the grapevine is saying, you never want to push unhealthy politics through it. Be aware it exists, but stay above it.

I once had a report complain about my decision-making to everyone who would listen, but never to myself.

In discussions with them, they agreed, nodded their head, and never raised issues. Others did bring up their own issues through various means, and they were factored in or incorporated when relevant. It was just this one individual who was clearly not bought in to anything I did.

Even in anonymous surveys, the feedback was never expressed. However, in their direct chats with others they pointed out what they thought were flaws in me left and right, including several leadership peers, my reports, and others completely unrelated to the initiatives in the organization. They even noted they were slow-rolling things I worked on, hoping I would fail so their approaches would be considered instead.

Obviously, this quickly made its way back to me. I asked them for feedback explicitly, and they continued to express positivity and full-throated support.

At that point, I terminated the individual. If they weren’t bought in, they didn’t want to give feedback, they didn’t want to help improve the situation, and they had no contribution other than complaining about things, then they didn’t need to be at a company under a leader they completely disagreed with.

An important distinction

Unhealthy gossiping about others or complaining is different than earnestly discussing problems or validly making comparisons. The difference is in the ability of the people involved in the conversation to resolve the issue, or the need-to-know of the information being discussed.

For example:

• Two managers talking about a report’s underperformance for the purposes of calibration or sharing ideas is perfectly fine (and should be promoted). The managers can support each other, both can be reasonably expected to have access to the information, and their conversation can help improve the situation.

• A manager discussing weaknesses about another manager to that manager’s report is not fine. The report has no need to discuss this, has no ability to improve it, and it decreases the authority of another manager over their own team.

• Two low-level people venting about the company’s decisions to each other is likely unhealthy. On the unhealthy side, it decreases the trust of both parties in the strategy, doesn’t send the information anywhere useful, and will likely not result in any meaningful change. However, what can make it healthy is if they share ideas for how to effectively navigate situations or improve their understanding of the tradeoffs and factors involved in the company’s decisions.

Establishing credibility is key to driving changes. Without it, you can’t even get to propose your ideas as they won’t be taken seriously.

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

This article is part of my series How to Drive Meaningful Change.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

It starts with improving your mindset

Because politics is about relationships, and relationships involve a connection between you and someone else, the very first place you should start at is yourself.

How you view the world, the interactions, and the opportunities colors your decision-making - for good or for ill. Your mindset needs to be aligned to achieve maximal benefit for the organization.

View politics as a positive

Office politics is basically just a fancy term for “human relationships and interaction.”

When many people think “politics”, they think of some slimy politician that takes bribes and enriches themselves at the expense of others. They might even envision lizard people wearing human skin suits slithering about as they pursue world domination.

This perspective may be accurate in some cases, but it’s just not necessarily true within the context of companies and organizations. Organizations that say they don’t have politics still have politics.

The only organization that doesn’t truly doesn’t have any politics is an organization with a single person.

Office politics is basically just a fancy term for “human relationships and interaction”.

Whenever people interact, they form judgements, share insights, and ultimately make decisions. They may agree, they may disagree, there might be conflict. Over a period of time, trust or distrust builds, alignment or misalignment is created. Given enough time, an interpersonal relationship forms.

If you view politics as just “human interaction”, it’s a lot less intimidating. It’s not something to be avoided, and is instead something that can be learned to the benefit of all.

More importantly - it’s not a negative thing. What people think of politics, they’re conflating unhealthy politics like gossiping or larger corporate “dog-eat-dog” behaviors. That’s also politics, sure, but only a subset. Politics can also be extremely healthy and valuable.

View interactions as an opportunity to help

Some people sometimes naturally shy away from meetings and having to talk to people. They’d rather focus on their work, headphones on and heads-down. While this might be useful for getting the day-to-day work done, it makes it harder to truly impact the upstream that heavily influences what the day-to-day work entails.

Instead - view conversations as opportunities. Every conversation you have is an opportunity to help the other person. It’s an opportunity to learn about the problems they are encountering within the organization. It’s an opportunity to swap ideas and discuss how to improve and strengthen the company. It’s an opportunity to raise awareness, to provide support, or even empathize.

Whether it’s a comment on a ticket, or a slack message - think about how you are helping the other person with your interaction. If you’re not - is there a way?

If still no - then why are you having that conversation? Talking in and of itself doesn’t create value. Are you actually wasting the person’s time? Is the most helpful thing you can do to not have that conversation?

View getting credit as meaningless

A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.

— Lao Tzu, philosopher

You can get a lot done if you don’t care who gets the credit.

If you truly want to drive change, it often means letting others take credit for your hard work — and being OK with it. It may mean nobody even knows you were involved!

This is a tough pull to swallow for most people, and it’s the one that gets in the way of their efforts to actually have an outsized impact. People naturally want to get credit. People naturally want to be rewarded for their efforts. There is a sense of inherent unfairness that bubbles up as a reaction when others get credit for work you’ve done.

Push down that reaction. Let it pass. Your goal is to make the change, not to get credit for it.

If you care too much about your own success, you start to make zero-sum decisions. You’ll shoot down ideas that are great just because you won’t get credit. You’ll start “protecting your turf” when great concepts in your area come from those outside your area. It very quickly devolves into an “us vs. them” mentality - damaging to organizations and the cause of many silos. You’ll start positioning yourself as the “go-to”, which harms your organization’s bench.

All the “big company” corporate behaviors start to come in:

• Siloing

• Resource and knowledge hoarding

• Non-collaboration

• Job security

• Self-aggrandizing

The list goes on.

You’ll hurt your own cause trying to ensure your name is attached to every win. People see this - your reports, your peers, your superiors.

If you’re trying to drive organizational change, it’s not about the credit — it’s about making positive impact. Don’t think about the credit. Focus on the outcome.

I once worked with a Product Manager that took credit for all of my ideas and successes. Sometimes it was implicit, like not mentioning my participation or contributions. Other times, it was explicit - framing himself as if he was the key contributor and decider. He didn’t do this just to me - he regularly took credit for his team’s ideas, as well.

I didn’t care because I was focused on the long-term: making our organization successful. Later on, that Product Manager got promoted and moved to another team, and we stopped interacting.

He floundered in his new role. He was unable to build the trust of his team because his reputation preceded him, and without having access to someone else who could actually do the job, he was unable to have an impact proportional to the higher expectations of his new role. He was later fired, having been peter-principled beyond his competency.

As for me - none of that mattered. I got the product to where I envisioned it should go.

View resistance as inevitable

There’s no. way around it - people will strongly object to an idea you propose at some point. You’ll face a lot of resistance, or you may not get your way.

Master the emotional reaction to opposition

There’s often a feeling of defeat when people shut down your idea or object to it happens. Perhaps you feel an anger that rises, like "how dare they disagree with me”. These sentiments can quickly lead to a a “you vs. them” combative mindset which can devolve into uselessness.

It is your responsibility to control your reaction and tamp it down. You must avoid getting defensive, combative, or reactionary. Your mindset on receiving resistance should be one of openness and comfort.

In fact - you should expect opposition and want it to occur. This is an opportunity to learn more and strengthen your idea. “Swiss cheesing” is a technique where you ask people to poke holes into your idea so that you can address weaknesses and make it stronger.

Dig deep into objections to learn from them

People’s objections to your idea are a gift. If there’s an objection to your idea, you’ve learned something that’s beneficial.

Dig deeper. Ask questions. Understand the “why”:

• Why the opposition?

• Are there other factors not being considered?

• Are there other prioritizations occurring that you should be aware of?

• Are there different tradeoffs at play?

• Is there some unexpected conclusion that was arrived at?

• Is there clarity or lack of clarity?

Remember - it’s rarely, if ever, a personal attack against you or your character, and thus it is important to not take it personally. Even if the resistance is personal, it’s important to consider it as if it wasn’t personal.

Viewed from that perspective, objections are constructive in nature.

I once proposed an idea to the executive team that would improve percetion from users in our organization, but had the risk of greatly harming the company’s bottom line by reducing processing volume. I knew the risk existed, and knew the objection would be there, but proposed it anyways for discussion.

The initial reaction was strongly negative: absolutely not - it would kill our company.

The discussion could have easily stopped there. We could have moved on to a different topic. I could’ve tried to save my reputation somehow, argued, and tried to look smarter. Instead, we acknowledged the flaws involved, and then dug deeper into the idea.

What risks were involved? What controls could we implement to mitigate the risks? What elements of the idea could be removed, supplemented, delayed, accelerated, reinforced?What would need to change or be implemented first for the idea to be effective? What small experiments could be done to validate some of these concerns?

From that discussion rose a much stronger, much improved idea that incorporated elements of the original idea, layered with expertise from others. This wouldn’t have been possible without the initial, less ideal idea being proposed and honestly discussed.

Always look forward

Always keep your mindset and conversations constructive and forward-looking.

If you do face a setback, realize it is not necessarily permanent. A “no” or “not yet” is an opportunity to figure out the “why” behind the “no”. Once you know the “why” you can work to resolve the reason for the opposition. It may even be a perfectly legitimate reason that you should factor in.

Every problem you encounter is an opportunity to solve it. It might truly be that your approach or idea is fundamentally flawed — that’s OK: it’s an important learning!

A lot of people would love to change some aspect of their job.

Perhaps it’s getting to work on a new project, or introducing something you think will be valuable to users. Maybe it’s more consequential, like increasing headcount or budget. Whether it’s as small as implementing Kanban instead of Scrum, or as large as defining the strategic direction of the company, all of these changes require skill to drive forward.

You may have tried a couple of times and failed to make the change. You may have thrown up your hands and embraced the motto “it is what it is”. 

It’s not what it is

Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.

Much of it relies on learning and understanding the soft skill of navigating organizational politics. 

It’s uncomfortable for a lot of people. They would rather rely on the results of their work to speak for itself. 

It’s a nice sentiment, but that’s not how societies work. Case in point — marketing or public relations experts exist and thrive. Clearly, there’s an element to influence beyond being the best, being the authority, or being right. 

We can either not be able to drive any meaningful change or embrace this reality and learn how to operate in it. 

A series

In this article series I’ll go over organizational politics and how to be a catalyst for good.

• Improve your mindset

• Establishing credibility

• Crafting a proposal

• Delivering your proposal

• Handling objections to your proposal

Startups survive because of their agility and speed — their ability to pivot and move quickly. They measure their execution tempo in hours, days, and weeks. This allows them to maneuver around larger lumbering organizations that operate in tempos of months, quarters, and even years.

In environments like this, speed is king. Rapid time-to-market is the startup’s competitive advantage. Without it, you can’t get the tight feedback cycles that make iteration possible.

Achieving these speeds isn’t easy — it requires startup engineers to make a lot of sacrifices (both personal and technical) and take plenty of shortcuts. These actions have pros and cons that impact the organization’s ability to sustain and maximize its speeds over the short and long-term.

Two kinds of shortcuts

There are two kinds of shortcuts engineers at startups make in the pursuit of speed:

• They reduce Quality

• They reduce Scope

Reducing quality

Reducing quality means writing code quickly, without regard to the general hallmarks of maintainability including:

• Correctness

• Cleanliness

• Understandability

Engineers taking this shortcut choose not to do things that would otherwise ensure these attributes, such as:

• Writing automated tests

• Refactoring

• Creating abstractions and thoughtful system designs

• Generalizing repeated functionality into reusable libraries and frameworks

Not doing these things saves engineers time in the short-term. They prioritize the speed-to-create, which allows for faster short-term releases at the expense of speed-to-change, which slows down future changes such as integration, debugging, and iteration.

Reducing scope

Reducing scope is a shortcut engineers can take regarding completeness and comprehensiveness. Activities that fall into this are often product-related, which requires negotiation with product owners or thoughtful execution management on the part of engineers.

They include:

• Not building all of the capabilities that are envisioned

• Not building everything at once

• Not integrating with existing process or technology

• Not addresses all of the concerns (eg. scalability, measurability, security)

• Not involving engineering at all (eg. doing things manually)

• Not automating or operationalizing (aka. doing things that don’t scale)

• Not handling less common use-cases

While many of these aren’t entirely up to the engineer to decide, engineers can influence these decisions. At early-stage startups, the order in which to actually execute is often up to the engineer to figure out, as they have to lay the track needed to get to the eventual goal. It is here they can influence the build by developing smaller, complete, fully-functional verticals instead of building the entire feature all at once.

Which one to pursue

While both of these practices can result in speed, only one results in speed over the long-term.

Sacrificing quality can be a massive initial speed gain during the first creation of the product, but these speeds rarely sustain themselves once iteration starts to occur — and iteration will occur.

Maintaining is harder than creating

Teams that sacrifice quality slow down over time, becoming overburdened by bugs, untraceable issues, and difficult-to-change systems. Because they optimized for creation instead of maintenance, which makes up the bulk of software development activities, the team’s output slows down to a crawl after the initial build-out.

The only solution for teams following this strategy is to approach everything as net-new — building things separate so they don’t have to deal with the debt they’ve created.

This means that products end up as shallow and unintegrated silos, regardless of whether they’ve been built before. Teams that operate in this model can’t take advantage of development momentum because they’re creating net-new on everything each time.

This works in contexts where exploration and experimentation is still the name of the game, but not in situations where product-market fit has been discovered and needs to be capitalized on.

Fixing quality shortcuts costs money

Resolving issues caused by quality shortcuts costs the startup a lot of money. More engineering headcount is required to push through the issues, or higher engineering salaries are required to get the skill needed to resolve the issues. An engineering team of 4 can perform incredibly well in a high-quality environment, but you’d need a team of 12 to reach the same amount of effectiveness in a low-quality one.

The alternative to throwing money at the problem is not something many startups can bear: pausing feature development to spend time fixing issues or paying down technical debt is the last thing founders want to do.

Either way, there’s a significant cost to quality shortcuts and they have to be meticulously measured and applied.

This strategy can be appropriate if your organization is aiming to receive a massive investment round to push through the problems, but if that’s not in the cards you’re better served to take the other kinds of shortcut.

Where possible, reduce scope instead of quality

Prefer reducing scope instead of quality. This will help ensure speed across a longer time-frame. Yes, it does mean that you’ll need more skilled engineers initially, but the payoff is massive.

One secret benefit to prioritizing quality — if you sustain a certain level of quality over a long enough period, you’ll eventually reach a point where development starts to speed up, not slow down. This is because higher quality code leads to higher confidence in development and maintenance, which results in faster changes.

Change = Risk

Lack of confidence is the number one speed killer. If a developer is not confident that their code will work, that they covered all the edge cases, that they fully understand what is happening, or that they won’t break anything, they will move slower to compensate.

This is because risk increases as change increases. While a static system only has to deal with environmental risk (risks that occur from not changing), a system under active development has to deal with much more risk — risk of bugs, risk of failure, risk of edge cases, risk of losing customers, etc.

You combat risk by minimizing the negative impact of failures and improving quality so that developers have increased confidence that the changes they are making are correct and have no unintended consequences.

The more confident a developer is in the change they are making, the faster they move. By keeping quality higher, you improve developer confidence and thus improve speed.

Advice for the real world

Of course, we live in the real world where things get messy and the lines are easily blurred. Sometimes the barometer of when to sacrifice quality and when to sacrifice scope is hard to read. You need to know how to best deal with both strategies instead of being told that you should avoid one entirely.

To benefit the most from reducing Quality…

Track it

Know when, where, and why shortcuts were taken, and track the speed of your team to ensure that these issues aren’t leading to a team-wide slowdown.

Tracking is an incredibly important aspect of quality reduction, because of two insidious aspects of technical debt

• Technical debt builds one line at a time

• Technical debt can be both incredibly easy and impossible to payback

Technical debt builds one line at a time.
That means it’s difficult to realize when you’ve accrued too much of it because every small change, taken in isolation, is often acceptable. It’s only by looking at the total amount that you realize the magnitude of debt you’ve taken on in the technology.

Technical debt can be both incredibly easy and impossible to pay back.
Once you’ve amassed a certain amount of technical debt, it becomes nearly impossible to pay back and maintain speed without exponential cost increases (often in the form of salaries, unhappy customers, and lost opportunities).

However, other times, you never have to pay back technical debt because of some change in the environment (eg. the feature is no longer needed).

Which one is which is difficult to determine at the time you accrue it and requires forethought and experience.

If you aren’t tracking the speed of delivery on your team in the form of an empirical metric, such as cycle time, deployment frequency, or lead time, you are driving blind and relying on luck. Don’t rely on luck to succeed — make your own luck.

Don’t take Quality shortcuts in your core

Set higher quality bars for things that are core parts of your technology or business, functionality that is used in many places, or parts of your system that you can’t afford to get wrong (eg. security, financials).

These are the parts that will experience the most change and iteration and form the foundation of the rest of your product. Other ideas you have will branch off of or integrate with these core pieces, and it’s important to get these areas right in order to keep as many options open as possible and to sustain speed.

This means if you’re a payments company, don’t skimp on testing or maintainability of your payments infrastructure. If you’re a workflow company, make sure you really think through your workflow architecture.

If you don’t, you might end up with a fragile tower of cards that you can’t easily add to, integrate with, or change.

Do take Quality shortcuts in your peripheral

Got a script that only needs to be run once? How about a minor feature that only 1% of your customer base is going to use? Up against an RFP deadline and need a tick-off-the-box feature?

In these cases, it’s OK to take quality shortcuts to get it out the door faster. The benefits of doing so can outweigh the long-term costs, and buy more time to fix it.

To benefit the most from reducing Scope…

Don’t cut to nothing

Minimum viable products often experience so many scope cuts in the drive to get them to market that teams accidentally turn them into minimal valueless products.

Because they lack any value, these projects fail to get traction with the users or customer base, and a potentially promising route gets cut short because it didn’t solve the core problem of the customers.

Avoid this trap — make sure you actually include the parts that do provide value. Don’t dismiss an idea outright just because it didn’t work the first time, especially if the execution was sloppy or incomplete or interrupted. Solve the core problem.

Ensure you prioritize iteration

One of the biggest issues I see with startups is a lack of focus. They bounce around from idea to idea, never really seeing the success they could have had they focused on any handful of them.

They deliver minimum viable products (if that) and then move on to the next big thing instead of building on their initial attempt with market feedback and iterating.

Because they fail to iterate on their MVPs, these startups quickly get overshadowed by competitors who do, losing what advantage they gained by getting to market quickly.

Competitor advantages deepen as time goes on because while the startup floats from product idea to product idea, the competitor focuses, iterates, hones, and refines their MVP into a leading, world-class solution.

Part of this behavior is driven by inexperienced product leaders. If you’ve ever seen a startup investment pitch deck or an idea presentation from a junior product manager, you’ll know what I mean. They are filled with charts that indicate hockey-stick growth and completely unrealistic projections that somehow magically include some inflection point that explodes into exponential growth.

How can any iteration compete against that? How can an idea that leads to a 1% revenue improvement compete against a 10,000% revenue improvement? They can’t — iteration and small improvements will always lose the prioritization argument against the next big idea, every single time.

It’s a rigged comparison with lies for numbers. Everyone is almost invariably over-optimistic of the potential of their next big product idea.

This is why it’s important to ensure that you dedicate time and resources to iterating on what you’ve already built, regardless of whatever is on your roadmap. If you don’t, your product will just float from idea to idea without any purpose or direction, and you’ll lose the momentum you build.

Those scope shortcuts you took will quickly turn into dead ends and wasted effort without iteration.

Never scope out company-destroying aspects

There are just certain things you shouldn’t scope out — security in payments, legal requirements, and consumer safety are just a few for starters. By scoping them out, you might move faster but you play fast and lose with a company-destroying level of risk. You want to take risks judiciously, not take on risks like a gambler.

Use this as a guide — how would you feel if the fact you scoped it out of your product was on the front page of a newspaper tomorrow? Don’t care at all? Go ahead and scope it out. Slightly embarrassed? Think about it first. Shaking in your boots and looking for plane tickets out of the country? Don’t scope it out.

Build reusable libraries to avoid having to scope out aspects

An aspect only has to be scoped out if there is a cost associated with keeping it within the scope. However, if there is no cost associated with it, scoping it out is unnecessary as the shortcut would not decrease costs in any meaningful way.

Developers can achieve a near-zero cost scope addition by creating or using reusable libraries and frameworks that have been proven to work, and by establishing patterns so that problems solved in the past do not have to be solved again. These can be anything — audit libraries, feature flags, image uploading subsystems, or maybe payments APIs.

Creating and using reusable code enables engineers to easily and quickly include things that would have otherwise been scoped out, leading to a better overall product.

Startups deliver rapidly through the proper application of shortcuts. These shortcuts to both quality and scope determine the speed you move during the short-term and long-term. Balance these judiciously to ensure your startup has the technology it needs to succeed and thrive now and in the future.

It is everywhere. Not a day goes by where I don’t run into a blog article espousing a new framework or library, encounter some massively upvoted Hacker News post on yet another data management technique for the current flavor-of-the-month javascript framework, or a meet-up talk about a brand new technique implemented at some company that saved them tons of time or money.

It seems as if the entire tech ecosystem is yelling in unified consensus about the latest and shiniest new thing.

Sometimes, it makes me feel like an idiot because I’m just not using it.

What do junior developers do?

When a junior developer encounters that kind of community consensus, what are they most likely to do? They’ll adopt whatever it is the community has “achieved consensus” on, often without regard to whether it is appropriate for the context.

They’ll start adding the new technology to their company’s projects or implementing the new technique in the codebase.

As they do, they’ll gain experience and expertise in using it, and then start convincing others on their team to do the same. They’ll link to a multitude of very convincing articles and references that simply can’t be argued against — an appeal to the ambiguous authority of the community.

What’s the problem?

The problem is that not all of these ideas are good ideas for all situations, and junior developers haven’t built up the experience and knowledge to determine appropriateness.

By definition, they don’t have the knowledge or experience to filter the good from the bad. Without guidance and appropriate direction from senior engineers, they are likely to cause insidious long-term damage for a small boost in short-term gains, or struggle needlessly to adopt something that just won’t work in their situation.

The reality of it — there’s way more junior developers than senior developers in our industry. It may not be the case in your company, but realize what this means:

There are products out there being built entirely by teams solely composed of junior developers, without any guidance from senior engineers, and with only the community to guide them. This is the case in every single industry, including defense, finance, medical, etc. To achieve success even with the odds stacked against them is impressive, but there’s always a cost.

These products and technologies might work well on the surface, but have hidden issues lurking beneath the functioning veneer. Do you want data leaks in your financial systems? How about dosage miscalculations in your medical dispensing?

It’s a scary thought.

I’ve made these mistakes, too.

I’ve been bitten by the very behavior I’m writing about here. I used to be that developer, blindly listening to the community.

Back in the days of Google Web Toolkit, a pattern called Model-View-Presenter was all the rage. It called for abstractions upon abstractions in order to decouple data, the views, and the wiring in-between.

As a new developer, I didn’t have a senior developer to guide me. I did a lot of research. I judiciously studied and followed the advice of the community. I understood the theoretical reasons for why it was being done and how to do it, but since I was a junior developer, I didn’t have the experience or knowledge to decide whether I should do it or whether the issues it was addressing were even present.

As a result, I applied it everywhere. That’s what the community told me to do. I added it even on pages where it would never have a variant or take advantage of the benefits of the pattern. I perfectly followed the pattern in all situations, as instructed. I convinced others to do the same with links to articles and podcasts and videos and lectures.

I used to be that developer, blindly listening to the community.

After a while, the system became an unmaintainable mess. I would have been better off hard-coding everything. The layers of unnecessary abstraction it created would later make even changing text a significant burden to whatever unfortunate soul had to maintain the system.

I was lucky because that developer who had to later make changes years down the line was still me. Having to struggle through fixing my earlier mistakes helped me learn a lot of lessons early on. While the MVP pattern was useful in many situations, the one I applied it in was not that situation. As a result, it caused significant friction in implementing later changes.

It taught me what might have been my most valuable lesson of my career so far: context is king.

Context is king

Of the good advice out there, much of it is written for a specific context or situation. However, many developers encountering this advice forget that what works for one company might not work for another. What makes one team highly effective might bring another team to a dead halt. A technology that works for one situation might not be a good fit for another.

Look at what happened when the NoSQL hype train arrived. Articles confidently declared that document storage was going to be the wave of the future and that structured data was dead. Technologies like MongoDB made it easy to set up, easy to run, and easy to build on. Coding bootcamps around the world taught it to hordes of new developers, without teaching them when to use it.

Who needed schemas anymore? As far as the tech community was concerned, nobody.

Well, it turned out that people who needed schemas needed schemas, and that ended up being most software that did anything even remotely interesting.

Now, these trendy schema-less, free-form data stores that everyone implemented were liabilities that caused security, performance, and integrity issues in many software systems.

By then, the community had moved on to the shiny new resume-builder.

Trying to lift a technology, strategy, or technique wholesale just because some internet articles tell you to do so is like buying the world’s top rated stroller when you don’t have a baby. It might be a fantastic stroller, but it’s a waste of resources for you specifically.

What makes one team highly effective might bring another team to a dead halt. A technology that works for one situation might not be a good fit for another.

Blind leading the blind

If the “tech community” has a significant number of junior developers consuming and creating material, it means two things:

• A lot of the articles and talks will be from junior developers who are unqualified to be giving advice

• The articles and posts from experienced developers will get misinterpreted, misapplied, and written about as a success story, which will lack the nuances present in the original messaging.

Talks with titles like “Monoliths are bad” or articles calling GraphQL the “REST killer” pop up, promising a new silver bullet. These talks are then attended by many other junior developers who happily and eagerly consume the information and go off and do it themselves.

Now, don’t get me wrong —it takes courage to publish a piece of content and open yourself up to criticism and judgement with the intention to better their community and help others. I applaud that tremendously.

Nor am I knocking the drive to learn and desire for improvement — these are things I and many others look for in developers. A developer that doesn’t learn is stagnating, especially in an industry that is constantly changing.

However, many developers who read or consume these pieces of content don’t look past the advice itself. If they did, they’d realize that a lot of advice comes from people who haven’t built very much, if anything at all.

Being a part of a large or well-known company doesn’t automatically make a developer qualified to tell you how to structure your teams. Nor does releasing a library make someone an expert in how to architect your software. It might be an indicator, but it’s not assured and certainly shouldn’t be assumed.

a lot of the advice comes from people who haven’t built very much, if anything at all.

Most developers are not experts

The uncomfortable truth is that most developers are, at best, mediocre.

It makes sense — most businesses don’t need expert developers to succeed. A vast majority of problems encountered by businesses that technology solves are not complicated. How many developers out there are working on the world’s umpteenth CMS, or building yet another bar chart? Probably a lot, and maybe most of them.

This might make some founders and engineers bristle. Every company likes to think they are unique and game-changing — special snowflakes. However, at the end of the day, a lot of the technology out there is just a rehash of stuff that has existed before, slapped with a new label, facade, and re-organized in a way that provides distinct value. CRUD apps are CRUD apps.

Even in organizations with more complex challenges, I’d wager many have a handful of senior developers making the complicated decisions, which are then executed on by more junior developers.

It’s how companies work: few have teams that consist solely of experts.

In reality, the skill distribution of developers is not a bell curve. It’s a cliff with a very long tail representing the truly skilled, following a power law.

Most of the developers in the industry have less than 5 years of experience. Of the ones that have more, there’s many that have simply coasted: we’ve all run into senior engineers that didn’t know how to build anything, or haven’t advanced their skillsets.

There’s only a small percentage of software engineers who are experts, and consistently do it well.

Consequently, most of the articles out in the community are not written or read by experts. While senior developers can discern and apply the advice appropriately, most junior developers cannot tell apart what is baloney from what is not.

These junior developers are incentivized to parrot the information and follow the advice, to destructive results. When a developer’s only argument for doing something boils down to “this company does it” or “the community does it this way”, it’s a signal that it is being applied without proper consideration.

Systematic issues

There is a perverse incentive system within the tech community that greatly amplifies the effects and reach of terrible advice.

• Open source contribution is associated with notoriety and is a marker for success

• Fierce competition amongst junior (and senior) developers causes self-promotion to be a viable ways to compete

• Developers self-promote and produce content to help them stand out and get a job

• Other developers consume and implement this content in their companies to ensure that they are doing “the right thing” and that they don’t fall behind

• These inappropriately implemented tools and techniques end up crippling long-term viability of systems, damaging organizations and increasing costs

Open source = skilled developer?

Our industry generally regards open source contributions as a bragging right.

There’s an entire incentive system out there that rewards developing something that is widely used. Creating a successful, widely used library is (correctly) a noteworthy resume-maker. Having a repository with thousands of Github stars is used as a mark of success. These are credentials that says “hire me”. Who wouldn’t want to hire the creator of Redux, a maintainer of Ruby on Rails?

The fame is a huge allure for many developers of all skill levels. It incentivizes them to create libraries, promote them, and get them used by as many people as possible, regardless of whether it will actually benefit them or not in the long run. Developers hop on to this bandwagon by creating content for the new technologies, writing articles and promoting it.

The problem is that there’s a larger reward in creating new things over creating valuable things.

The lowest hanging fruit to build are libraries that do the same thing as other popular libraries, but only better. Look at how many ways there are to upload an image on Rails — Paperclip, Shrine, Refile, Carrierwave. How about the number of ways you can do state management— Redux, Mobx, Recoil, context, etc. The options are numerous, and ever-increasing.

When everyone will praise you for creating something new, people are incentivized to reinvent the wheel and talk about how awesome their new wheel is, which drives usage.

Within this ecosystem exist junior developers

Junior developers have to operate in this ecosystem we have to succeed, so that’s what they do.

It’s easy to forget, but the competition at the junior level is fierce. The junior developers most likely to be hired are the ones that stand out. They’re told by everyone from their community to mentors to teachers that the best way to stand out from the hordes of other junior developers is to show passion and knowledge.

They show knowledge by working on side projects, studying data structures and algorithms, and demonstrating they can use these new hot, in-demand technologies. They demonstrate their passion by writing blog articles, giving talks, and engaging with the community as a whole. It’s what helps give them an edge in their job hunt.

In their studying, they consume a plethora of content that talks about things on a surface level with an air of authority. Much of this content is essentially marketing spiel that heaps high praise on a specific technique or technology and recommends it without limit.

Just look at articles on Redux, GraphQL, or MongoDB. These tools are absolutely useful and appropriate in the right contexts, but it’s rare to see a nuanced recommendation or one that adequately explains the context behind the decisions.

When everyone will praise you for creating something new, people are incentivized to reinvent the wheel and talk about how awesome their new wheel is, which drives usage.

Lowering the bar

A lot of the new content is designed to lower the barrier to entry so that it is easy to adopt. Code samples show you the exact code you need to copy-paste to get up and running. FAQs show basic errors you run in to. They often invest significantly in the ease of setup.

Unfortunately, much of the guidance after that stops there. Rarely do I see examples that show you what not to do, or how doing something as shown will create an integration challenge in the future.

That’s to be expected — integration is not the library’s job.

However, this lowered bar and lack of context does cause people who don’t know better to follow these patterns blindly. Eventually, through experience they realize that they need to make changes, but by then it is often too late — the damage has been done.

It’s easy to understand how this happens: most articles rave about how you should use whatever they are talking about starting today because it is just so easy to use and set up, and light years above the current status quo. It deceptively leads people who don’t know better down the wrong path. They then repeat this misinformation in their own presentations, articles, and conversations until it becomes solidified as truth in the community.

People then chase shiny things despite marginally better value. Systems end up having to get rewritten, or start incorporating a dozen different ways to do the same thing, costing companies significant time and money.

How do you avoid it?

How are you, as a developer who is rightfully consuming as much literature as possible, going to distinguish between content that is written from a tried-and-true perspective or content written as a puff piece with no experience beyond one or two sample projects?

Get background information

A right solution applied to the wrong problem can be like throwing water onto an oil fire.

The best way to avoid incorrectly applying the wrong solution to the problem is to understand the principles and context under which that solution is being implemented

If you’re lucky, the creator of the piece of content has explained their context to you. Perhaps they work in a massive company on a R&D focused team. Maybe they work on the sole infrastructure team responsible for keeping systems running. Perhaps they are the only developer in their company and need to crank out features as fast as possible. Maybe they are in a product organization that has to balance the needs of dozens of stakeholders. If there’s a significant mismatch between their problem space and your’s, that should raise a yellow flag.

If you’re not lucky, you’ll have to suss out clues. Don’t blindly trust advice from a faceless developer — dive into their background and experience. Look up the author’s employment history. See what kinds of companies or systems they have worked on or are currently worked on. For example, a developer with significant agency experience may be good at starting projects, but I would look further for evidence of an ability to maintain them. Likewise, a developer who spent a decade at a Fortune 500 company may give advice that is inappropriate for a startup. Weight advice accordingly (but don’t dismiss good advice just because a junior developer gave it).

Whoever it is, make sure you understand in what situation the solution is being applied. A right solution applied to the wrong problem can be like throwing water onto an oil fire. Be diligent and judicious.

Adapt the solution

Solutions need adapting and molding to be implemented in your company, even if it is the right solution for the right problem.

Maybe MongoDB is the right solution, but your department’s budget doesn’t allow for another vendor license. While writing everything as a micro-service is truly the answer for an organization with a dozen teams, but your team of 4 developers doesn’t quite need it right now, and a service-oriented approach will be more valuable instead.

Whatever it is, check to see how you can adjust the solution to fit your context.

Avoid inconsistencies

I’ve written about the challenges of adopting new shiny things. From consistency issues to wasted effort, adopting a new technology causes business and technology issues that can last the lifetime of the software you are incorporating it into.

Here’s the deal — if you’re a professional software developer, you have a responsibility to not do things that will screw up your business’ future. This means doing what you can to minimize risk. For most developers, that means experiment on your own time and in your own space. Don’t bet the business’ future on something unproven unless it is your job to do so. If you have to experiment, do it on a side project or in an isolated, unimportant area.

This advice generally applies to organizations that have limited resources. If you’re in a larger company where moving fast and breaking things is par for the course, you can afford to do things differently because innovation risks are supported by the rest of the business. However, if you’re in a small startup with only a year of runway, it is likely that major mistakes you make can ultimately sink the company’s chances of success.

Hopefully, there will be effective senior leadership keeping an eye out for you. But, as we all know, many companies have no such leadership. In these situations, it’s your responsibility to weigh things carefully and with due consideration.

you have a responsibility to not do things that will screw up your business’ future

To writers

Finally, if you are writing an article — provide context and disclaimers. The solution you are proposing or writing about is likely not applicable in every situation. Even mentioning that explicitly is a gentle reminder to use thought before applying it.

Even better, go in depth as to why this solution worked in this particular case, and in what situations it would fail — this would help others build context and determine whether it is appropriate for their environment or not.

I know I’ve forgotten to do this many times, and who knows how many I’ve led astray.

Now that you’ve reached the end of this post/rant, what’s the first thing you should do? That’s right — make sure I’m not just spoon-feeding you a bunch of crap, because I totally could be. Odds are, I’m one of the mediocre developers, so take my advice with a grain of salt, and weigh it accordingly.

Many leaders struggle and eventually throw in the towel when being placed in charge of a team full of inexperienced members. They often become overwhelmed by the lack of skill available to their team. Like pushing against a rope, they make no progress towards goals and may even may even make negative progress.

Leaders stuck in this situation may blame their team, forgetting the mantra that “there are no bad teams, only bad leaders.” Though often well-intentioned and otherwise talented, these leaders end up flailing in their role.

Eventually they either burn out or are replaced due to their poor performance.

It doesn’t have to be this way.

Inexperienced teams can perform incredibly well when guided by the right leadership. They can even perform better than a team full of experienced members under poor leadership.

Good leadership requires good planning

A lot of leads simply go with the flow, performing ad-hoc interventions on an as-needed basis to lead their team. They call out mistakes as they see them, give pats on the back here and there, and otherwise wonder why their teams fail.

Their freewheeling attempts to tackle problem as they come results in a lack of focus, reducing the effectiveness of the team as they work on efforts that don’t synergistically build on each other.

A failure to plan is a plan to fail. Good leadership requires planning and follow-through, while understanding that no plan survives contact with reality. As a leader it’s your responsibility to create a solid plan and be prepared for any contingencies, adapting accordingly to changing conditions.

The plan below should help you.

Figure out what kind of team you have

The terms “inexperienced” and “junior” can be incredibly broads labels.

A person can be great at one thing but junior in another. Identifying where your team’s individual strengths and weaknesses lie is therefore the key first step in leading them.

Make a skills matrix, listing the various skills an individual would need to succeed in your endeavor. Be sure to list soft-skills like communication, the ability to work with others, and whether they encompass the values and traits of your organization. These are just as important as hard, technical skills.

After you rate them, you’ll notice that the juniors can fall into certain categories.

Some juniors encompass all of the categories, while others may only need work in one or two areas. These categories aren’t mutually exclusive, and it’s important to understand what kind of junior you are dealing with so you can appropriately alter your approach.

The technical junior

The technical junior is a person that lacks the hard skillsets of the industry or role. It’s a fresh college graduate starting their first job, or someone making a mid-life career change.

Technical juniors do not have familiarity with the tools, techniques, and skills needed to perform competently. They require very conscious effort to do things that may otherwise be simple or subconsciously perform by more technically experienced members. They’re unable to make tradeoffs and good decisions because they don’t know what they don’t know.

The process junior

The process junior lacks the experience and skills working within a team. They may not understand the team culture, structure, dynamics. They lack context into the history of the team and how the team collaborates, coordinates, and communicates. Working with them is an act of friction.

The end result is chaos for the team.

The behavioral junior

The behavioral junior has personal character or behavioral deficits that keep them junior, despite how good they may otherwise be.

They may lack the initiative to take on work after they are done with their current work. They may not care to learn, only doing the barest minimum needed to complete their task. They may lack follow-through or have issues communicating. They may not have attention-to-detail. They may be unable to take constructive criticism. They may lack drive, initiative, or good judgement.

Whatever the issue is, it prevents them from operating at the level they need to operate at.

Develop your team

Once you’ve conducted an honest assessment of your team’s individual strengths and weaknesses, you can make plans that take their strengths and weaknesses into account as individuals and as a team.

Developing technical juniors

Developing technical juniors is a matter of focused, targeted training. The goal is to build up their knowledge and experience of the fundamentals until it becomes unconsciously known.

Develop a training program that conducts focused, targeted instruction on the various technical aspects of the role. Provide real-life examples when possible. Conduct drills, leverage the power of repetition, and ensure the fundamentals are mastered.

Developing process juniors

Developing process juniors is a matter of ensuring two things are understood:

• The process itself

• The reason why the process exists

Some process juniors simply don’t know a better way, and once exposed to it are eager to follow the process.

Other process juniors may have a difficult time following any process, seeing them as unnecessary friction to accomplishing their goals. So-called “cowboy coders”, they likely haven’t experienced the pain the process prevents.

Describing why the process exists and the consequences of not following the process in detail can help align their behaviors. If they still fail to follow the process, establishing checkpoints, boundaries, and penalties can help align behavior.

Process juniors are often a source of tremendous initiative. With a fresh pair of eyes, they can bring in new efficiencies that challenge the status quo. However, their idealism must be balaned by the reality of the situation. Ensure they can follow the existing process first and appreciate why it exists before allowing them to introduce new processes and refinements.

Developing behavioral juniors

Developing behavioral juniors is the most challenging. Change comes from within, and asking someone to change their behavior can be a fool’s errand.

The behavioral junior can lack the self-awareness to recognize their flaws, exhibits defensiveness when criticized, or allows pride or ego to prevent them from making progress.

Pointing out behavioral flaws is also one of the hardest subjects for most leads to broach. People have a natural aversion to directly criticizing others, and a lack of control over emotions can turn a potential teaching moment into a heated argument.

Developing junior developers with behavioral traits you’d like to change comes down:

• Clarifying which specific behavioral traits you’d like to see and why

• Demonstrating those traits yourself

• Explicitly pointing out when those traits were or were not demonstrated

• Monitoring and holding juniors accountable for their progress

Changing behavior is a long-term game even in the best scenarios. Sometimes you won’t have the runway to wait for that change to occur. In these cases, it’s best to cut your losses.

Execution

While the best executing teams have clarity, competency, and control, providing a team of junior developers full autonomy is a recipe for disaster. It leads to poor decisions, which leads to broken systems and negative effectiveness as you work to undo the damage and pay down the tremendous amount of technical debt they generate.

As a leader it is your responsibility to give junior developers room to grow and potentially fail, but not room to sink the ship. It requires careful calibration between freedom and restriction. While learning can’t happen without mistakes and failure, it’s your job to ensure the mistakes junior developers make are survivable.

Front-load decision-making

Junior developers by definition don’t have the clarity or competency to utilize good judgement when they make decisions. It’s important to ensure that major decisions, such as architecture, technologies, and patterns, are not initially in their purview.

This means that when starting a new feature or module, make the major decisions ahead of time. They should be working within a framework of established patterns, practices, architectures, technologies, and procedures. If this doctrine doesn’t exist, create it.

Ensure this framework exists before they reach the point where they have to make these decisions themselves. Train them on the patterns and practices. Create component libraries. Demonstrate the way you want the system built.

Front-loading major decisions has the added benefit of helping junior developers avoid decision fatigue. They avoid making decisions they don’t have the competency or clarity to make, and focus their decision-making at the micro-level that they are gaining mastery over: naming, variables, etc.

Making the major decisions doesn’t mean completely shutting off a junior developer’s viewpoint or voice. Junior developers can introduce new ideas and help keep your organization from becoming an antiquated dinosaur. However, balance their new ideas with the risks and realities of your organization.

Give them visibility into the thought processes behind your decisions so they can build up their own ability to judge trade-offs. Ask for their input, but ensure that the final decision itself remains with you.

By front-loading the decisions before they reach the decision-point, it helps focus junior developers during execution.

Break it down, barney style

Junior developers may have knowledge of individual pieces, but lack the intuition and experience that allows them to apply their pattern-recognition skills to other situations. As a result, they’re unable to rapidly move outside their areas of comfort and knowledge, even if the work is very similar.

Junior developers won’t recognize a rose by any other name, even if it looks as pretty or smells just as sweet.

Turn knowledge work into mechanical work

For junior developers who haven’t mastered the fundamentals and basics, it’s imperative to break down their work and provide step-by-step instructions. They need to learn to crawl before they learn to run.

Be as explicit as possible. Perform drills, going step by step over setting up a class or calling a method. Ensure they achieve mastery over the building blocks and fundamentals before having them attempt anything else.

Once they begin achieving competency with their tools, you can move on to working with them on integrating their fundamentals into the larger effort.

Teach them principles and rules of thumb

As junior developers learn the basics, you can start explaining the “why” behind the techniques.

Explain the principles that form the foundation and reasoning behind what they are doing. Give them rules of thumb they can generally reliably follow. As they execute their day-to-day work, provide course-correction on where the principles are violated and how they can change their work to remediate the defects.

Over time, they will learn to apply these principles themselves without being told to. They’ll come to develop their own heuristics, which are critical to being able to apply what they are doing to other similar situations.

Teach them when to violate the principles and rules of thumb

Software engineering is a context-based profession. Decisions that may be terrible in one circumstance can be the right thing to do in another. It’s important that you teach junior developers the various decision-making tradeoffs and how to make the tradeoffs themselves.

This will help avoid turning them into dogmatic engineers who are incapable of adapting when needed.

Provide clarity on direction and where they fit

If you isolate junior developers and treat them as cogs in a machine, you prevent them from understanding their ultimate role in the project.

Without understanding their place in the bigger picture, they will become perpetual juniors, merely carrying out tasks and incapable of executing anything beyond simple, explicit instructions.

This may have been the end goal of Taylorist management, but the world has evolved in complexity since the philosophy’s heyday. Today, the best teams have the ability to adapt to a constantly changing environment.

The only way a team can adapt is if its members have a holistic view of the situation.

You don’t want junior developers staying junior forever.

Teach them their role

Explain to them the other moving parts in terms they can understand. Paint a picture of how their contribution (or lack thereof) impacts the overall goals and initiatives of the project and organization.

As junior developers improve, their understanding of their role will help guide them as they take on increasing amounts of responsibility. These guide-rails will focus their efforts on the things that matter and help ensure they execute within the constraints that makes sense for the team and organization.

Set goals

Focus and effective execution requires a goal or objective to work towards.

Work with your team to set attainable goals at regular intervals. These goals should be larger goals your team works towards, as well as individual goals that contribute to the main effort. By having your team work with you on deciding these goals, it improves their buy-in and motivation, increasing engagement.

Ensure you also establish milestones and interim goals that can serve as progress markers and checkpoints to determine whether the entire effort is on track and where attention may be needed.

These act as yellow flags and early warning signs of potential issues that need to be addressed.

Set boundaries

It’s not enough to set goals — goals can be achieved in many ways, some highly negative and damaging, especially if the junior developer hasn’t yet developed proper judgement. It’s important to ensure that boundaries are explicitly clarified and understood by the entire team.

Boundaries can be situation-specific things like “never use single-letter variables” to generalized value-based boundaries like “never make a customer feel bad”.

These boundaries act as anti-goals, things that should not be done, and are important in establishing what is accepted and not accepted behavior. Norm-setting is important in creating alignment and clarity, and without it you can end up with a team that achieves its goals, but in a chaotic and destructive way.

As your junior developers improve their judgement and prove credibility, you can start lifting boundaries and widening their area of operation.

Supervise

It’s not enough to set the pieces and press “play”. Good execution requires supervision. Course-correction and pointing out just-in-time lessons are valuable learning opportunities that leaders need to provide to junior developers.

Frequently check-in

Monitor progress and check in frequently with your junior developers on their growth. Constantly assess where they are and ensure they are making progress. Check progress against goals and milestones.

Provide them resources they need to learn — whether that be training materials, larger challenges, or your own time.

Ensure they know where they stand and where they are expected to be, and have the roadmap to get there.

Ensure there’s a process

Junior developers don’t do well when given an infinite amount of possibilities, and a tremendous amount of damage can be done over time if you leave them to their own devices.

Limit potential damage by ensuring that there’s a gated process where you have final authority. Ensure that there’s a code review process in place. Only allow deployments that you approve.

If your developers have trouble following the process, enforce it with technical solutions or management penalties.

These processes can be lifted as your junior developers grow and improve, but until then they act as safety nets that prevent harm to themselves and the business.

Give feedback often

Junior developers thrive when given feedback. They need this constant course correction, both to ensure they don’t sink the ship and to ensure they are learning the right things. Over time, they can begin giving themselves this feedback, providing them the ability to self-regulate once they are capable of doing so. This will ultimately ease the burden on you as a manager or lead.

Use 1:1 meetings with them effectively, ensuring that they know exactly where they stand in their professional development and performance. Point out areas in conversations where they can improve and where they are making good progress.

Be patient

No learning can be done without the possibility of failure. Accept that your junior developers will fail, or seemingly backslide on progress.

Act as necessary, but understand that punishing failures doesn’t stop them, it simply hides them. Sometimes you’ll have to let certain areas fail while you focus growth and attention on a more important area.

Failure is a part of the process of growing and learning. Be patient.

Know when to loosen the reins

Over time, junior developers will get better. The sort of managing that helped them initially will start to feel more constraining, dampening effectiveness and morale. It’s important as a lead to know when to loosen the reins and provide more autonomy and less supervision.

Keep a pulse of how junior developers grow and make progress. You can’t track what you don’t measure, so maintain a checklist of the traits, skills, knowledge you want them to demonstrate. Reward progress with more autonomy and trust.

Leading a team of junior developers is difficult but rewarding. As they learn and grow, the team will gel over the shared challenge and become more and more effective over time.

Many first-time leaders see their teams devolve into chaos and their effectiveness reduced by unnecessary friction.

Because of their lack of experience, they resort to large, sweeping changes in their attempts to improve the effectiveness of their organizations and fulfill their vision.

These herculean efforts fail over and over, while the real solution sits ignored in front of them: communicate better.

Blindspots

Why are so many otherwise educated, talented people oblivious to this?

It’s simple — leaders don’t see bad communication so they simply conclude it isn’t happening.

A leader’s position enables them to see a longer-term vision and the high-level workings of their organization. By virtue of being a leader, they have a tremendous amount of visibility into the rest of the organization.

Leaders forget that this visibility is a privilege of their position, and that their advantageous viewpoint simply isn’t shared by others in the organization. They incorrectly assume those at levels lower than they are have the same vantage pointthey do.

The more they see the more they don’t see. It’s an ironic blindspot caused by their position.

The more they see the more they don’t see.

Think about all the times you’ve heard people describe their leaders as being “out of touch” with their teams, not aware of the “ground truth”, or being described as “delusional”. It’s a sentiment shared across many teams and organizations throughout many industries.

How does it happen?

Leaders don’t intentionally become unaware of the inner-workings of their teams. They don’t just wake up one day and tell themselves “I’m going to be out of touch with the team I lead.” It creeps up on them, unrecognized.

It takes truly pro-active leadership to recognize and avoid this blindspot.

You’re here because you recognize there’s a problem

It’s not all doom and gloom — you’ve overcome the first hurdle: recognizing there’s a problem. Luckily, as a leader you are in an excellent position to resolve the communication issues that plague your organization.

Understand the realities of communication

You’re always delivering a message

Like I’ve said in the past, leaders are always on stage. Every word you say, every interaction you have, every facial expression you make is going to be scrutinized and replayed in people’s minds.

People look to their leaders for their reactions — their approval and disapproval — and modify their behavior based on these reactions.

Be cognizant of this fact and ensure that you are always delivering the message you want to deliver. You are never off-air.

You can leverage differences in how you normally communicate to emphasize a specific message. For example, if you are known to always be soft-spoken, people will definitely remember if you yell and get angry one day.

Volatile leaders with inconsistent behaviors will deliver inconsistent messages — adding to unneeded friction and chaos. Stable leaders reinforce their teams by delivering consistent messaging through every action, only deviating on rare occasions to emphasize a point.

Your communication gets distorted, fast.

It doesn’t matter what medium you use — any communication you send will be distorted, almost immediately.

Whether it be Slack, in-person, email, memos, or posters on a wall, your message will not be received with 100% accuracy.

There’s just too many factors in play — your tone of voice, the moods of the people communicating, the words you used, your facial expressions, body language, your history with the person you’re communicating with, etc.

That’s just communicating with one person — imagine the thousands of communications that happen between just as many people every day.

As your communication slowly makes its way through your organization, various factors will cause it to become muddied down until it no longer even resembles the original intent or message.

Like a large game of telephone, the meaning of any message becomes distorted for various reasons, whether through well-intentioned mistakes or malicious actors driven by self-interest.

By the time it reaches the people that really need to hear the truth, it may be the complete opposite of what you intended.

Understanding and acknowledging this dilution of communication is critical.

Avoid the dilution

How do you prevent your message from being diluted? Repeat it, repeat it repeat it, over and over and over.

Repeating yourself is important

It’s the most effective way to cut through the noise-to-signal ratio.

People receive a lot of communications throughout the day. Just imagine all of the emails, chat messages, advertisements, in-person chats, etc. that go on in any given work day. There’s too much to focus on, so messages get lost in the shuffle of the day-to-day.

The only messages that will get through are communications that the receivers deem important — the ones they can’t ignore. A leader repeating themselves will act as an amplifier- a signal that this communication is worth paying more attention to.

People need reminders. If they see a message come up time and time again, they’ll take notice of it. They’re more likely to remember repeated messages.

Repeating messages may seem like over-communication, but it helps clarify things and reduce mismatched assumptions.

Develop memorable phrases and memes

They may seem like dopey or insincere platitudes at first, but you’ll be surprised how quickly they become adopted as mantras and guiding principles.

These phrases will become adopted by your team and others and become a part of their everyday vocabulary. The repetition then begins to occur from other sources, further strengthening the message.

Use multiple mediums

If you talk about something in-person to someone else, enforce the idea in a follow-up email repeating the same information.

Have other people repeat their understanding of a message you sent them, explicitly asking them to rephrase or explain it to someone else. If they don’t align, you’ve found an opportunity to clarify a misunderstanding.

Be precise

Misunderstandings often arise due to mismatched assumptions between the the sender of a message and the recipient. When there’s a lack of information, people will fill in the blanks with their own interpretation, experience, and biases. Since everyone is different, it’s a quick path to miscommunication.

You can do a lot to avoid this by being specific in the language and words you use. Be specific. General language opens up too much room for possibility and assumptions.

For example, don’t just say a poor purchasing decision was a “bad call”. Say “it was an unwise decision to purchase this because it didn’t factor in our available budget”.

The first phrasing opens up many interpretations on why it was a bad call, whereas the second narrows down to a very specific reason that can be avoided in the future due to its actionable nature.

Constant positivity is not a positive

Don’t be afraid to give bad news

Sometimes the message you are delivering is going to disappoint people. Sometimes it’s difficult for you to even broach the subject.

Weak leaders avoid these difficulties by shying away from the topics, hoping the issue resolves itself. They try their best to avoid the problem, believing that any negative thinking or thought will harm the company.

Instead of delivering the bad news directly, leaders may try to be a people-pleaser, downplaying the negative aspects of the message and ultimately failing to deliver it outright.

That’s a mistake: a problem doesn’t go away just because you don’t address it. Sometimes the most positive thing you can do is addressing the negative directly.

Silence is not golden

Silence is a message in and of itself, and leads to miscommunication because people will fill in the gaps and play telephone. I’m sure you’ve been a part of the rumor mill, wondering what potential changes could mean — a layoff? A re-org? These rumor mills are damaging to organizational effectiveness.

An absence of explicit, clear messages is a breeding ground for dysfunctional communication.

You can’t stop the rumor mill by forbidding people to speak about it. You stop it by addressing the issues being discussed head on as quickly as possible.

Explicitly and repetitively communicate what you intend to communicate. If something happens, address it as immediately as possible before the rumor mill starts.

The more time passes, the more the dysfunction festers and has a chance to grow.

Don’t make sandwiches

A common technique to deliver criticism that is promoted by many management blogs and other sources is known as the “sandwich technique”.

In this technique, you couch negative feedback by first providing positive feedback, delivering the negative feedback, and then ending with the positive feedback. This is intended to soften the blow and make the negative feedback pill easier to swallow.

Don’t do this.

Contradictory messages will be misinterpreted. It divides the focus of the receiver and distracts from the ultimate intent message.

Contradictory messages will be misinterpreted. It divides the focus of the receiver and distracts from the ultimate intent message.

I can’t count the number of times I’ve seen people surprised that they were being fired — if only they had known about their poor performance earlier!

The problem was that many times they were told about their poor performance, but from inexperienced managers using the sandwich technique. What they thought wasn’t that big of a deal turned out to be the final nail in the coffin.

People will focus on the positive. After all, the negative feedback must not be that important since there was more positive feedback!

The sandwich technique also misuses an important aspect of people’s memory — they’re more likely to remember the first message as well as the most recent message they’ve received. Since the negative feedback is in the middle, people are psychologically prone to not remember it as much as the complimentary messages. It’s just how our brains are wired.

Be direct, clear, concise, and consistent. Don’t make sandwiches.

Breaking down communication barriers

Even if you think you have great rapport with someone, you’ll always be receiving some form of filtered viewpoint designed with your authority in mind.

It’s hard enough talking to leaders and people in positions of authority. Don’t make it harder artificially.

Here’s some things you can do to reduce the friction others may feel when communicating with you.

Institute an open door policy

Publicly and privately state that you want people approaching you and giving you unsolicited feedback or dropping in for a chat.

Make sure you are approachable. Any barrier you put is just one more roadblock to communicating with you.

Recognize your open door policy is ineffective

Already instituted an open door policy? Great — it probably won’t work.

Many people simply won’t come up to you for various reasons — shyness, busyness, etc. Arrange a specific time yourself to hear people’s thoughts and opinions in addition to your open-door policy.

You can’t be passive about promoting communication — open door policies are literally the least you can do.

Remove physical barriers

Your office desk is the second biggest barrier to effective communication next to a closed door.

The typical office layout involves a desk in the middle of the office, with a chair close to the doorway for guests and the office owner’s chair in a seat of power between the wall and the desk.

The problem with this layout is that it creates a very real physical barrier between you and the person you are communicating with. This physical barrier is enhanced by any other item on your desk — typically a monitor.

Break down the barrier — position your desk against the wall so that any guest that enters your office to talk is sitting in front of you with no barriers in-between.

Remove those headphones, move that coffee mug to the side.

Get out of the office

Another person’s office is viewed as hostile territory. Human beings have a psychological aversion to crossing that door frame — the threshold between the outside of the office and the inside — the safe area and the lion’s den.

In an office the lines of authority are clearly defined and communication flows through that lens.

You’re unlikely to get effective communication within it.

The solution? Get out of your office. Talk to people in their office. Bring people to coffee shops. Grab lunch.

Reach out to people directly

If you want to hear from someone, ask them explicitly what their thoughts are.

Ask them regularly. Ask them through different mediums — in person, over chat, email, etc.

People have different comfort levels communicating through different mediums — find the one that works the best for the person you are communicating with.

Build rapport

You’re more likely to receive honest feedback and ensure solid communication if people feel comfortable and safe communicating with you. You can’t build that sense of safety or camaraderie with communication limited to work tasks.

Ask people about their day, how their work is going, or what they did that weekend. Build relationships with people, even if they aren’t even in your department.

Avoid silos

You can see these environments start to form — groups begin to silo themselves or cut off visibility and communication in the name of privacy, security, or some other reason.

Perhaps they begin to place certain information on a “need-to-know” basis, or suddenly make their meeting notes private. Maybe they stop inviting non-group members to lunch.

Many times there’s a valid reason to do so — especially in areas where a breach in privacy can be a massive issue (eg. HR, medical, defense, etc.) or a loss of focus can result in decreased productivity (eg. training, junior employees, highly complex endeavors, etc.).

However, many other times these silos are created with no other reason than to simply create an in-group, exercise authority, or develop miniature empires to stroke egos.

Over times, these silos being to operate independently, contributing to a dysfunctional communication environment that makes delivering accurate messages and operating effectively much more difficult.

Effective communication is hard, but not impossible. Leaders can make small changes in their behavior and the environment that lead to compound results down the road.

It’s a tough decision. Most early-stage startups aren’t flush with cash. Every dollar they spend on an “expensive” manager is one less dollar they can spend on a direct contributor to the codebase.

Furthermore, hiring the wrong manager can be incredibly damaging to the culture and organization. Tech leaders in first-time leadership positions have it doubly bad — they also have to wrestle with the fact that they have never hired a manager before, increasing their likelihood of hiring a bad one.

Faced with such uncertainty, many startup tech leaders put off the decision, falling back on what they know best: individual contribution.

Sometimes later is too late

Yes, a management hire too soon can become an unnecessary expense at a cash-strapped company. However, the flip-side is also true: a hire made too late can end up costing the company dearly. Cultural, technology, and process issues compound over time and even the world’s best managers can’t undo the damage overnight. Timing is incredibly important.

How do you determine when you need an engineering management layer?

I’m going to spoil the ending early — a blog post online can’t tell you when your company needs managers.

It’s a highly circumstantial decision only people at the company will have the context to make. The best an online article can do is to help arm you with knowledge — an understanding of the fundamental “Why?” behind managers so that you’ll be better informed to determine the “When?”.

Understanding the evolution of the engineering organization

To understand why one would even need an engineering manager, it’s important to understand the lifecycle of an engineering organization within a startup, which can take place over a period of years.

The beginnings

Startups typically begin life with a single in-house developer or a contractor. You couldn’t even call it a team at this point. This initial developer either either reports directly to the founder or is themselves the technical founder.

Bringing product to market

As the company sells their vision and what they’ve built so far, they have to increase their development speed to build all of the things the market demands. They reach the point where contractors are not enough or get too pricey.

To support the new demands on the development team, the hiring strategy shifts, and the focus starts to be on building an in-house team. The startup will eventually reach a point where there’s 6–8 engineers in a single team all working on the same product.

With a team this large, the founder is no longer in a position to directly manage these engineers, if they ever were in the first place. They’re too busy making deals, figuring out finances, business plans, and all of that stuff that business people do that engineers often take for granted.

Instead, the responsibility of ensuring the team still executes quickly falls to the initial developer or the senior-most developer. This developer, through acquisition of a vast amount of domain knowledge over several years, has become the de-facto Head of Engineering, in charge of all of the other engineers that are brought on.

Their title differs depending on the company — some companies use Director of Engineering, others CTO, still others Lead Software Engineer. The technicality doesn’t matter so much as the fact that they are the technical leader of the organization.

The burden of success

As the company grows and gains traction in the market, the tech demands increase. Cross-functional collaboration is more and more a key component of the job. Working with business stakeholders, potential customers, regulators all while keeping the product team rowing is a lot of work and a lot of communication.

At some point, it dawns on the Head of Engineering that their time is no longer their time. A mere glance at their calendar evidences this:

Somewhere along the line, their time went from coding 24/7 to meetings 24/7. It’s hard to pinpoint exactly when that was, but it was probably when the Org Chart started looking like this:

More people necessitates more communication. Projects get more complex, with more moving parts. Business demands increase as the company’s growth accelerates. Leadership desires the Head of Engineering to focus on the most important thing. With this many people, the Head of Engineering can barely focus on anything.

Bringing on senior talent

If the organization doesn’t have any senior engineers at this point, they often bring them in, with the rationale being that senior engineers require less management and can help pick up some of those responsibilities.

This is a coincidentally correct rationale. As these senior engineers become reliable executors, the Head of Engineering may start to delegate responsibility for completing certain projects or streams of work to them.

Splitting into teams

In many cases, the Head of Engineering implicitly knows when they’re reaching their limits.

They often try to save more of their own time by only syncing with the senior engineer that they put in charge of the project or workflow, avoiding having to sync with every individual engineer that is part of the same project.

This makes sense — part of the incentive of delegation is for the Head of Engineering to spend less time on certain things, which includes project and people oversight, and this activity reduces the number of communication channels the Head of Engineering needs to keep synchronized.

While formal reporting lines don’t change, the Engineering organization chart starts to implicitly look like below:

Formalizing the split

Eventually, the split gets formalized. As I wrote about in another post, there are a variety of ways you can split teams out, with pros and cons to each structure. There’s also hidden dangers of having skilled ICs suddenly jump into management roles without proper preparation, and methods with which to counter the drawbacks.

Regardless, the final end result is that there are different teams, with different individuals responsible for them:

Things under this structure become much more manageable for the Head of Engineering, and organizations can go a long way with this approach.

Why does this work?

There’s some fundamentals to organizational structures at play in this scenario that we need to understand..

As the organization grows, it becomes more and more difficult to ensure everyone is in-sync. This is because communication channel requirements scale exponentially with the size of the organization.

In early stages of a startup, say — when there’s just three people — it’s easy for those three people to talk to each other. There’s only three communication pathways to achieve shared consciousness and align. Everyone can communicate with everyone.

But if the organization gets bigger? That’s another story.

What we’ve got here is failure to communicate

As the number of people increases, the number of connections between them explodes dramatically. A synchronization strategy that used to keep 5 or 10 people in sync suddenly breaks down at 15. The problem gets even worse as the organization grows:

• 9 people? 36 connections.

• 15 people? 105 connections.

• 50 people? 1,225 connections.

• 100 people? 4,950 connections.

It’s impossible to keep that many people synchronized and on the same page by using a strategy that involves 1:1, direct communication.

This is a big reason why organizational structures exist: to create a flow of communication that can be managed effectively. Transitioning to a model where communication flows between specific individuals creates order.

There are some minor drawbacks, however. Because every individual member of now does not have access to the full consciousness of the organization, it has the tendency to create silos. These silos can easily become misaligned with the larger organization.

These drawbacks are countered with a focus on effective alignment, generated by — you guessed it — effective management activities. These management activities ensure information flows to where it is needed and individual silos are putting their efforts in a direction that aligns with the rest of the organization.

Why can’t the Head of Engineering do it?

A common question I get asked is — why can’t the Head of Engineering just manage people?

They could, if they have the skillset (which many do not), but it only delays the inevitable. There’s just too many other demands on their time for them to effectively do everything they are asked to do at a growing organization.

Companies recognize this, and most eventually split the responsibilities of the role of Head of Engineering.

Splitting the Role of Head of Engineering

The Head of Engineering at this point has (or doesn’t have) certain skills.

If we use a simplistic 4-quadrant model of a CTO skillset, we get the following:

• People management

• Execution management

• Coding and Technology

• Governance and Strategy

Few, if any, people are strong in ALL of these areas. Most engineering leaders have one or two of these areas they excel at, and have varying levels of performance and interest in the others.

By having someone that excels in the areas the Head of Engineering is only acceptable at, organizations can ensure key aspects of the role get the attention they deserve. It allows the Head of Engineering to focus on their strengths, and the organization as a whole gets stronger.

Sometimes, this is a tough pill to swallow, and some technical leaders push back against the idea of letting go of their authority and power. They cling to all of these areas regardless of their skills, weakening the organization to the benefit of their ego.

However, effective leaders recognize the importance of leaning into their strengths and welcome the ability to focus that comes with splitting their role.

Where do the responsibilities split?

This is highly context-dependent and really depends on the people involved and the organization.

A Head of Engineering with people management and execution management will likely want to be in a role that stays close to the day-to-day, and pass off strategy and governance to an incoming CTO. In cases like this, the Head of Engineering becomes the VP of Engineering.

A Head of Engineering who want to focus more on the coding, technology, and infrastructure aspects of the role essentially can take on the the role of Chief Technologist. In cases like this, they often remain an IC-focused CTO, with execution management falling to a new VP of Engineering.

Perhaps the Head of Engineering wants to be more external facing / governance / strategy-oriented. In this case, they remain a governance / strategic CTO, with management of execution falls to the VP of Engineering.

The organization should work with their Head of Engineering to find their strengths and ensure the role breakdown fits their interests.

What happens if the Head of Engineering isn’t ready at all?

Of course, there’s always a final option: the Head of Engineering simply doesn’t have the skillsets required to take the company through the next level.

There’s numerous reasons why this can happen.

Some engineers start their careers at a startup and grow with it. In the early stages where building is the priority, they can effectively perform the role, but later stages have significantly different skill requirements that they may not be ready for.

Some simply aren’t interested in the actual responsibilities that go along with the role once the organization gets larger, and it just wasn’t quite what they expected.

Organizational requirements change as a startup moves from stage to stage, and different skills are needed for different phases. Although many do, not everyone does adapt to these changes and keep their skills relevant. It’s not universally interesting to everyone, and people may have preferences for specific startup stages.

The solution here is straightforward: they either take on a lower role in the organization more suited to their skillsets so they can continue contributing maximally, or they part ways with the company.

The Manager of Managers

Of course, I assume you’re a lucky organization blessed with a fantastic technical leader.

Whatever the role split looks like, the VP of Engineering eventually takes over the management of the development teams, managing the managers who manage the teams. Sometimes they report to the CTO, other times they report to the CEO.

The management layer has been installed, and as the team grows it expands over time, including more Managers. For larger organizations, the Director of Engineering title often makes a comeback in a reduced, non-organizational scope, managing Managers that are part of a specific work group or department.

What do you need to ask yourself?

So, now that we’ve examined the evolution of this hypothetical startup, we come to the real question: how do you tell when it is time to get a management layer for YOUR startup?

Truthfully, a blog article online can’t tell you that. It’s context-dependent. However, by asking yourself the following questions, you’ll build up awareness of what specifically to look for:

Does your organizational culture appreciate management?

Some startup cultures are very IC (individual contributor) centric to the extreme. Early-stage startups survive because of the willingness of its members to do whatever it takes, wear as many hats as possible, and grind and hustle to get things done.

In these organizations, the concept of someone who sits around not actually doing anything themselves is anathema to the idea of the Heroic Contributor. It’s a misguided belief, to be sure, but one that I found to be prevalent in many early-stage startups.

If your organization doesn’t appreciate managers, it will place the expectations of an individual contributor on them and diminish the appreciation for the management aspects of the role, and that is a recipe for failure.

What do you do if your culture doesn’t appreciate managers?

If your culture doesn’t appreciate managers, it probably either:

• Has had bad examples of managers

• Don’t actually know what the value of a manager is

Managers exist for a reason and their actions can contribute greatly to even execution-oriented cultures— coordination, information pumping, alignment, are all activities that reduce execution friction across an entire team.

Managers can also ensure skills and career progression, providing valuable focus on training and growth. These aid in execution, and also retention of employees.

Finally, Managers can help ensure empiricism and improve processes over the long-term through the collection of metrics and optimization activities based on them. A focus on improving can help remove inefficiencies and ineffective behaviors — things that are hard to focus on if you’re also busy trying to do you part in the next project.

Management activities (done well) act as force multipliers, leading to the dreaded business word of synergy, the sum of the parts together becoming greater than what they could be individually.

Finally, remember: Google once tried to get rid of all of their managers. It went quite poorly.

Is your Head of Engineering overwhelmed?

Overwhelmed can be an overloaded term, so let’s specify what that means.

Does your Head of Engineering…

• …spend more time doing things they dislike than they do things that they love and excel at?

• …seem to be in meetings all day and have a massive backlog of code they need to write?

• …appear stressed, anxious, demotivated, burned out, depressed, hopeless?

• …keep asking for budget to hire senior engineers in hopes that they free up time?

If the answer is “yes”, you should look into it further.

Do projects frequently miss release targets?

Projects that get delayed repeatedly indicate some form of process, quality, or people issue. The fact that they frequently happen means that there’s something missing, whether that be better coordination, clarity on goals, or time to account for technical debt.

Managers can dive deep into these issues and help keep projects on track.

Are you getting a lot of bugs?

Here’s a secret: in well-engineered projects, bugs should happen LESS frequently over time, not more. If bugs happen more and more often, it can be indicative of severe quality issues caused by technical debt, unrealistic deadlines, lack of skill, or quality standards that are tending lower.

It’s easy to dismiss an increasing bug count as “the project is getting more complex” or “we’re moving fast and breaking things” but the truth of the matter is that if you have the option of “moving fast and not breaking things”, then “moving fast and breaking things” is irresponsible.

Do engineers feel out of sync, lacking clarity, or misaligned?

One of the key management and leadership activities is providing clarity to the team. Good managers can act as information pumps, ensuring people have the information they need to make effective decisions aligned with the goals of the company. They act as alignment generators that keep everyone on the team rowing in the same direction.

If your team doesn’t seem to know what’s happening, or seem confused as to the goals or current situation, it’s a sign that they’re not getting the information they need.

Employee surveys can help sniff this out, along with 1:1s and other tools.

Do engineers complain about a lack of skills or career progression?

A good manager can do wonders for the career progression of an engineer.

They have the time to provide resources, direction, coaching, training, and opportunities for the engineer to grow and improve. They can work 1:1 with the engineer to develop a personalized growth plan that helps the at a rate far more rapidly than they could themselves.

It’s a massive retention tool and competency booster long-term. However, it requires focus and attention, and is often the first thing that gets dropped when deadlines start getting missed.

Without a management layer dedicated to this, it’s often hit-or-miss whether the need gets fulfilled.

Do you have no visibility into engineering performance or trends?

Agile-istas often decry the use of metrics to measure performance of a development team, instead preferring to point to “working software” as the main measure of progress and success.

In an age where anyone and their dog can create working software, is that really a good standard to use?

While I agree metrics such as Story Points and Velocity have been abused by misinformed business leaders, proper use of metrics can be a powerful signal to indicate process issues or engineer capability growth over time.

Metrics like Cycle Time, Change Failure Rate, Deployment Frequency can help provide insight into whether your team over the long-term is getting better or worse, and you can target improvements to focus on areas that will benefit the most from them.

Do engineers feel powerless?

You can tell when you’re on an empowered engineering team. From the moment you start working with them, you feel this hum of work and this desire to excel and improve everything.

You can also tell when you’re on a disenfranchised engineering team. They don’t communicate. They don’t take the initiative. They do only what they are told to do — no more, no less. They don’t enjoy the work.

Effective engineering management can revitalize a team and help inspire and empower them. I’ve seen tenfold improvements in development effectiveness on teams that have been placed under an effective manager after languishing under a bad one or no manager at all.

Hiring a manager isn’t an easy decision, but it is a critical one for a startup. As startups grow and evolve, the collaboration burden gets too much for the Head of Engineering to exclusively bear.

An effective management layer often becomes a necessity to ensure the organization can continue to succeed and excel to the next level.