Empowerment vs. Entitlement

“Autonomy without accountability results in entitlement, not empowerment.”

Someone shared this quote in last week’s Tech Leader Chat where I spoke about empowering engineering teams, so I thought I’d unpack it here.

What does empowerment mean?

If you ask this question to a group of engineering leaders, you will probably get answers that are different, but aligned. Popular definitions are all some flavour of this: “Teams have the ability to choose their work, how it gets done, and they have resources they need to do it.” Some leaders will talk about speaking up with dissenting opinions, and some will emphasise control over roadmaps or technical choices.

In practice, your business constraints may only allow for empowerment to be visible in certain corners.

• Your teams can’t define the roadmap, but you want them to be empowered to control how they execute on each project.

• Your teams are required to use tools provided by a shared services team, but you want them to be empowered to adjust any workflows in order to fit their use cases or preference.

• Your teams need to deliver projects by non-negotiable deadlines, but you want them to be empowered to push back on scope.

These scenarios might fit neatly into your own definition of empowerment.

But if you ask a team of individual contributors, their definition of empowerment might be wildly different.

For some ICs, being able to determine what they work on, now just how it gets done, is critical for empowerment.

But what’s missing from all of the definitions above is any note about what happens after the work is delivered. Autonomy and empowerment need to be balanced with responsibility. Otherwise, you end up with entitlement.

What’s entitlement?

I don’t love this word and the connotations that come with it (“get off my lawn, you entitled brat!”) but it is a great way to express the opposite of empowerment.

Where empowered teams feel they have the space and support to advocate for what they believe is right, entitled teams believe they always are right. Empowered teams can understand organisational context and apply critical thinking to arrive at a solution — even if it’s not their first preference — whereas entitled teams struggle to consider outside constraints. And entitled teams often don’t close the loop on the results of their decisions, so they miss important feedback about the quality of their decisions.

In real life, it can look like this:

An entitled team wants to push a tech debt project ahead of other priorities. They get frustrated with their business partners because they believe that everyone should just trust them when it comes to whether the project is important or not. They know better, because they’re in the codebase every day.

An empowered team knows when to push back on priorities, and how to articulate the value of a maintenance or tech debt repayment project for their business partners. They also know that they know better because they’re in the codebase every day, but because they’re also responsible for results, they make sure that the tradeoffs are visible to everyone.

What empowerment isn’t

Empowering your team doesn’t mean ignoring results in the spirit of “letting them make their own mistakes.” It’s holding space for them to experiment within clearly defined parameters, acknowledging their responsibility to deliver, and making it okay for them to speak up with troubles, dissenting opinions, and to ask for help.

Many leaders fall into a trap of holding back too much information from their teams while trying to empower them. “I don’t want my opinions influencing them too much,” is what I often hear. This is a common pattern for leaders who want to avoid micromanagement, and advocate for empowered teams. Often, this pattern can lead them straight toward a path of micromangement — exactly the thing they were trying to avoid.

Micromanagement and empowerment

I call this the micromanagement spiral. It goes like this:

In the name of empowerment, you give loose direction to your team. You might hold back your preferences or a bit of context in order to create space for your team to figure it out by themselves. They go off to work on the project, and the results just aren’t what you were expecting. You didn’t catch it sooner because you didn’t want to micromanage by asking for frequent status updates. Instead, you wanted them to feel empowered to ask for help if they needed it, or share the updates that they thought were worthwhile.

But now the project is done and the results aren’t there. You might have lost a bit of trust within the org because of this, and now you need to revisit the work: “I was expecting us to select a vendor to provide this, not built it ourselves.” “This VP is not happy that you didn’t consult their teams when making this decision.” “The CEO is really expecting a UI update along with this.”

All of these do-overs could have been avoided if you had shared that context up front. Now, you’re finding yourself getting into the details — becoming the micromanager that you dreaded.

Empowerment is not about leaving your teams in the dark to figure it out by themselves, and it’s not about avoiding hard conversations about missing results for fear of hurting feelings or being perceived as a micromanager. You need to find the line where you equip your team with the vital information they need to be successful, while also holding space for them to bring you new ideas or push back on things that don’t make sense.

Empowerment and psychological safety

Psychological safety happens when your team members feel secure that mistakes, failed experiments, and dissenting opinions won’t result in negative consequences for them. It’s highly correlated with empowerment, because it is foundational to an environment where team members can speak up and push back. It also puts results front and centre, allowing teams to align and reflect on their failures.

If you are trying to increase empowerment on your teams, and specifically, you’re looking for more discussion, more debate about decisions, and more risk-taking, it’s possible that your team members don’t feel that they’re in an environment where it’s safe to do those things.

What to do tomorrow

If you’re trying to increase empowerment on your teams:

• Talk to your teams about what makes them feel empowered or disempowered. Their answers might be quite different from yours, or what you assumed. Help them understand what is possible within the constraints of your business.

• Don’t ignore results in the name of empowerment. Having high standards is a signal to your team that you care, and that you’re there to support them.

• Increase psychological safety through leading by example. Talk about your own mistakes and failures, and make space for your team to align and reflect on theirs.

Managing Former Peers

It’s tricky to navigate relationships after a move to management, or any situation where a former peer now reports to you. Can you still have lunch together? What if they earn a lot more than you? What’s going to happen when you disagree and have to overrule their decision? Are they going to resent you?

Here’s a guide to help you navigate this change.

Don’t pretend like nothing changed

There are plenty of situations that you can quietly ignore until they resolve themselves and everyone forgets about the tension in the first place. This is not one of them.

I’ve spoken with so many leaders who are having issues with a former peer. My first question is “how did you address the change when you moved in to management?” All but one have said, “oh, I guess we never directly addressed it.”

How did you get here?

The circumstances surrounding the change should influence the way you approach the situation.

• Was there one management spot open, and both you and your former peer were competing for it?

• Did you former manager depart the company, leaving a leadership gap, and you willingly stepped up?

• Are you managing a team with someone you worked with on a previous team, but continued to be friends with?

• Are you a new hire?

Your situation might be a mix of a few of these.

If there was just one management position available, and you won out over a group of peers or other applicants, expect some resentment and disappointment in the short term. It’s normal. But this period really sucks for you, because you’re probably going to mess up quite a few times as your transition into a new role. It’s probably going to be uncomfortable. You might also feel discouraged, like the hiring committee made a bad choice, or that your former peer is right in thinking that they could be doing a better job. This will all pass. Remember you’re there because someone else agreed that you were the right person. Balance that feeling with knowing it’s going to take you all a bit of time to settle in.

Address the awkwardness

“It’s a little weird that we used to be peers and now I’m your manager. How do you feel about it"?”

There’s no need to be subtle here. Just dive in. First, listen to them. Second, you can share some detail about the transition from your point of view.

But even if your former peers have absolutely 0 aspirations to move to management, it’s still weird.

Make sure to state clearly that this is a career change for you. You have a different job now than what you had before. There might be some habits that need to change between you and your direct report now that you’re a manager. 

It might be worth calling out that this doesn’t mean that you’re a better engineer than they are. This can often be a point of contention and a reason for resistance. “Well, I’m a much stronger programmer than she is, why is she managing our team?” This objection loses power when the other person understands that the role of a manager isn’t to code. It can be helpful to share your performance criteria or job description with your team so they know what to expect from you.

Reinforce your commitment

Reinforce that you’re there to support them and the rest of the team. This is also a good time to emphasize that their expertise is important for your team’s success.

They probably have a bunch of ideas for things that they want to change — and things that they want to remain the same. Hear them out, but avoid the temptation of changing too much at once.

Make a plan for when things get weird

Every human gets annoyed with their boss. You do, and your direct reports do. Except now, you’re the boss.

Make a plan for when things get awkward. It’s not a question of if, but when, things get tense because of mismatched expectations between you and a former peer.

• You can’t give them a raise they asked for

• You need them to work on a project you know they won’t enjoy

• You have to pull the plug on a project they’re really interested in

• You veto hiring someone that they’re really enthusiastic about

• They give you feedback about something and you don’t implement their suggested change

• And honestly thousands more

Have a plan when those situations arise. Do you agree to talk about it face to face, send a Slack message as soon as you can, or save it for a 1-1 where you can give it more attention?

---

If you’re still an individual contributor preparing for the leap to management, one helpful thing you can do right now is to share your desire to be a manager with your team.

Then, when the time comes for you to lead a team of your own, it’s not surprising. It’s easier for people to support you when they know it’s what you’ve been working towards.

It might help you to keep in mind that tens of thousands of people have made this same transition, with success.

Some of them might even be at your company!

How To Think About Firing People (Kindly)

Here’s an uncomfortable truth: not everyone you hire is going to perform well in their role.

As a leader, this means that you’re going to have to fire people. It’s uncomfortable, but it’s necessary.

If you’re hiring 20 people today, you should expect that at least one of them is going to depart the company due to performance reasons within the first year. This isn’t a sign that your hiring processes are bad, or that you aren’t “raising the bar” in your assessments. Interviewing is an imperfect way to predict future success. And, companies change a lot within a year.

I’m always surprised when companies share stats like “we’ve never had to fire anyone!” or “we don’t have any developer turnover” in their interview processes. Some might take this to mean that the team has outstanding culture and very high performance. But working with dozens and dozens of companies, I know this just isn’t the case.

Teams that have no turnover are most likely dealing with unaddressed performance issues.

Performance management is a tough job, and it can be very difficult to address performance issues when a team is in a state of growth. You’re under pressure to hit hiring goals, so it’s a tough argument to remove someone from your team.

This is a paradox: when you hire more people, the likelihood that someone won’t perform well increases. It’s the time when you need performance management the most.

I often see companies make the mistake of thinking that a rigorous interview process leads to a high performing team. This is almost never the case. A challenging interview process is not a replacement for performance management, though some companies treat it as such.

Onboarding and probation periods

Many countries have probationary periods when a new employee begins a work contract. This is a period of several weeks or months where the employment contract may be terminated with minimal consequence. Sometimes things don’t work out, so the probationary period is an escape hatch. Unfortunately, short stints at a company or gaps in your resume are still stigmatised, so if you join a company and the role turns out to be something very different from what you were sold, there’s still a consequence for you as a job seeker.

In the USA, probationary periods are extremely uncommon because most US states are a “right to work” state. You can be fired at any reason, for any time, with little legal recourse. On the other hand, you theoretically have the right to quit your job with 0 notice period, but it will be next to impossible to get a recommendation from your colleagues if you did that.

If you are in a country where probationary periods are used, it’s a time to keep open communication with your new employee about expectations and performance. If you have to terminate employment in the probationary periods, the legal clauses provide you the ability to do it quickly, so both the employee and your team can move on.

Don’t fire for failure

How do you know when it’s time to fire someone? This usually doesn’t happen like it does on TV, where someone royally screws up and then gets marched into their boss’s office to get raked over the coals. Contrary to TV advice, firing someone for failing at a project is bad practice. It will lead to

• lack of experimentation

• unwillingness to take accountability

• fear-based culture

Instead, failure should be a part of growth. This kind of failure is different to a persistent failure to deliver on business results, despite having coaching and other support at their disposal.

• A skill gap that can’t be sufficiently be addressed with the resources and time available to the team or company

• Violation of core principles of respect

• Demonstrated lack of willingness or ability to change and adapt

• My own belief that they will not be successful

There’s no perfect formula here, but this is how I assess whether termination is the right choice.

If someone is struggling to perform, but has a high willingness and ability to change, I will continue to support them.

Conversely, if someone demonstrates neither a willingness nor an ability to change, the decision is very clear to terminate them.

There’s a big “it depends” area in here, where a team member might show a reasonable willingness to change, and they’ve started to show some results. Time is an important factor here. If their willingness to change after seeing results does not increase, I would err on the side of termination. Similarly — although I hate this situation - if they’re very willing to change but just lack the skills and capacity to do so, it’s also time for a difficult conversation.

These are the hardest situations, but it’s important to think about the team that will stay. You’ve shown that you’ve given as much support as possible to the struggling team member, but they were still unable to get over the learning curve and perform well. Your team has been carrying the weight of their underperformance that whole time.

Hire fast, fire faster?

On May 31, I joined some spectacular engineering leaders at CTO Craft’s conference on the complete hiring arc. If you missed it, you can check out the recording here (my talk at 1h50m, Roy’s at 2h24m).

Roy Rapoport from Netflix spoke about “Hire fast, fire faster.” He shared that Netflix has ~3% termination rate within the first year. That’s reasonably low. He explained that “fire faster” is not about firing a lot of people. It means that the time between your decision to fire someone and the termination conversation should be as short as possible. It should also never be a surprise to them.

Conversations before firing

After you let someone go, your team will have questions. One of those will be “did the person know about the performance issues?” If you can’t answer this with an emphatic yes, you are doing your team a disservice.

When I have performance conversations with someone who is at risk of losing their job, I say very clearly “I will have to let you go if we are unable to address these performance issues.”

Roy mentioned that he will explicitly use the phrase “your job is at risk” in performance conversations with people who are at risk of losing their jobs.

Clarity is kindness. It’s unkind to be less direct, let the person guess where they stand, and then ultimately surprise them with a termination.

Firing is part of your job

It’s not anyone’s favorite part. But managing your team’s performance is a critical component of your job.

Be kind, be clear, and ask for help when you need it.

Unplannable Work and Queueing Theory

Here’s a question I’m asked often:

What’s the best way to deal with bugs and unplanned work? We’re under a lot of pressure to deliver, so our sprints are pretty maxed out. Bugs and customer requests just add to the load and delay the other work. Is there a better way to plan our sprints?

This is a pretty universal and evergreen question. The current hiring landscape just amplifies the pain. So many teams have growing backlogs and roles that have been siting vacant, maybe for months.

You might feel like you’re constantly reacting to everything, without having time to catch your breath and make a plan for how you’re going to be proactive.

And based on this Twitter thread, a lot of you feel like work just keeps piling up.

Scheduling your team at 100% capacity is a great way to ensure that nothing will be delivered on time.

— Laura Tacho 🌮 (@rhein_wein) May 16, 2022

Queueing Theory and Slack Time

First, some math.

Let’s say you have a bank with just one teller. Each customer takes an average of 10 minutes to be served, and they arrive at the bank at an average rate of 5.8 per hour, or about once every 10 minutes.

When you look at the average values, this shapes up to be a pretty efficient system. A customer arrives, and just when they’re wrapping up, someone else shows up.

But there are ebbs and flows to foot traffic, and the average service time of around 10 minutes is just an average. There might be a customer that takes 35 minutes. Then what?

In the bank I described above, the average wait time is close to 5 hours. That’s because as a system nears 100% utilization, the queuing time grows exponentially.

From Practical Insights From Queueing Theory

We think about this often when it comes to servers working on jobs from a queue, but the same applies for systems of people, too.

Adding another bank teller reduces the wait time from 5 hours to about 3 minutes. It sounds unbelievable, but the math checks out.

When your team plans sprints at close to 100% capacity, you are increasing response time exponentially for any unplanned work that comes in.

A system with no slack is just going to snap.

Unplanned work vs. unplannable work

A lot of what we consider unplanned work is actually plannable. There will be bugs. There will be customer requests. You can plan for these, even if you don’t know the specifics.

And after enough sprints, you’ll likely have some decent data to show trends about how much and how long these types of unplanned work can soak away from your core projects.

If you don’t have this insight yet, a good first step is to write a ticket for everything. Fight the urge to grumble about the administrative overhead.

If you don't find a way to visualize your toil (maintenance tasks, bugs, etc KTLO) it won't be prioritized accordingly.

— Félix López (@flopezluis) May 7, 2022

Not only will tracking this type of work give you insight into how much slack you should build in to each sprint, but it will also make sure that you have a record of why you made all of those changes.

Customers are great at finding edge cases, so make it easy for your future self to remember why you made this one weird change.

Unplannable work isn’t a bug or a customer support ticket. These are emergencies: a flooded data center, us-east-1 having issues, a bad deploy, or a db migration that went sideways. It’s the truly unplannable stuff that is also drop-everything-and-get-to-work urgent.

If you don’t have any slack time, there is absolutely no way you’ll be able to stick to your initial timelines on your in-progress projects. A 5-hour emergency shouldn’t delay a project by a week, but that can very much happen when your system is oversubscribed.

Two things to do tomorrow

• Make sure your team is tracking all the different kinds of unplanned work to make it easier for you to understand the strain it puts on them. No more quick PRs after someone Slacks a request.

• Adjust your own expectations for what an “ambitious sprint” looks like on your team. You might see a reduction of story points, but you’ll see cycle time decrease. Story points alone are not a great metric of performance and productivity.

Finding Untapped Engineering Talent on LinkedIn

Are you hiring engineers right now?

I’m guessing the answer is yes, and I’m guessing it’s taking up anywhere between 25% and 75% of your time.

Someone asked me recently how they could make hiring go faster.

Here are a few of my go-to tricks when sourcing candidates on LinkedIn.

We all complain that LinkedIn is a steaming pile of recruiter spam. It’s rooted in truth though, because so many people are contacting the same candidates who are easily searchable. You aren’t going to get anywhere competing against 100s of other low-quality messages.

Instead, you need to find pockets of talent that often fly under the radar on LinkedIn. These are untapped groups who aren’t getting the recruiter spam, so you’re more likely to get a response:

• The Lurkers: People with light profiles but recent activity, so you know they’re still checking the platform. Candidates on LinkedIn are passive. They have no reason to keep their profile up to date unless they are a) looking for a job or b) selling something. Most recruiters will pass on reaching out to them because there isn’t enough info in their profile. Don’t make that mistake. High-performing individuals don’t need to market themselves in LinkedIn.

• The Flyovers: Target a region that’s not often associated with lots of tech talent. A personal example: I grew up in Wisconsin. I know that talented folks who graduated from college probably landed in Madison, Milwaukee, or Chicago for at least a few years in their early careers. They might have moved back to Wisconsin to be closer to family once they got a bit older. Most companies there can’t or won’t compete on salary, so there’s a huge opportunity to get amazing talent to join your team. This is especially true if you’re offering location-agnostic salary bands like Airbnb just announced. On LinkedIn, I’m going to search for a specific job title (level + language + “developer” or “engineer”), then set a location filter for Wisconsin, and then probably filter on previous employer if I have some reputable local companies in mind.

• The Bootcamp Grad: Bootcamps have been around for a while now. There are people who graduated from bootcamps who have now been engineers for 10+ years but will get passed over because they don’t have a CS degree (mistake) or because recruiters have been instructed not to reach out to people from a bootcamp (also mistake), regardless of their years of experience.

Get More Feedback This Week

“Do you have any feedback for me?” I’ve been asked this question probably a hundred times, and have asked it the same amount. I didn’t know what I was doing wrong."

“Uh…. Nothing that I can think of right now!”

There’s a lot of focus on giving more feedback. But feedback is like currency; it needs to circulate.

So what’s the secret to getting more feedback from your peers and your boss?

Asking an open ended question at the end of a meeting isn’t the way to do it.

Here are 3 things that will help you get more feedback this week:

1. Be specific. “Let me know if you have any feedback” is not going to help you. It’s not specific, and your conversation partner will be overwhelmed with choice. Make it easy for them to give you what you want. A request like “Could you tell that I was really nervous when I demoed that new feature in All-Hands?” will get you the feedback you are looking for.

2. Be timely. Ask for feedback beforehand, so people know what to look out for. Send out a quick Slack message ahead of a meeting or mention it in a 1-1. “I’m going to share an architectural proposal later today. When you read it, can you point out any areas where my logic is hard to follow?”

3. Be gracious. If someone gives you feedback and then you immediately dismiss it, explain it away, or share that you’ve already thought about it, you can bet that will be the last time they go through the trouble. “I hadn’t considered it that way. Thanks for pointing that out!” will get you a long way. No one wants to go through the effort of putting together some thoughtful feedback only to be dismissed right after delivery.

Is Your Engineering Roadmap Destined to Fail?

Maybe you’ve been there:

You’re in a meeting with your engineering team. You’re discussing the projects you’d like to finish in order to improve the codebase. Maybe this includes refactoring, security stuff, replacing dependencies, or adding redundancy for when us-east-1 inevitably goes down again (but the status page: ✅). You prioritize these projects and everyone agrees they’re important.

Months pass. Nothing gets done.

Here’s the secret: these roadmaps are doomed to fail. Not because your team is bad, or your PM is bad, or that the projects were bad. But the system is designed to pit one set of priorities against another — disregarding their relative importance — and the new shiny things always win.

In theory, engineering roadmaps are a tool of great empowerment for your engineering teams. It’s a curated list of the projects that matter most, made by the people who know best.

But in practice, engineering roadmap projects are almost always deprioritized when they go up against product roadmap items, meaning new features and enhancements that come through your product management or sales teams. Engineers are left fighting for scraps of time to get critical work done.

Where things go wrong

Classifying priorities as either product or engineering creates an artificial world where they don’t align to the same goal. All projects - whether coming from a PM or an engineer - need to have clearly articulated business impact. This impact can be measured in user satisfaction, revenue, or whatever other metrics show up on your dashboards. Once you have clear measurements of predicted outcomes, it’s a matter of prioritization.

Here’s what I mean:

It could be the case that the first 3 projects on your engineering roadmap will have more positive impact on user experience and revenue than the first 3 on the product roadmap. So if you’re working from two lists, and bargaining to say “let’s do two new features, and then we’ll make time for an engineering product”, everyone loses, including your customers.

Here are roadmaps for my fake documentation app.

Product

• Custom notifications

• Editor role type

• Add toggle options to headers in text editor

• Keyboard shortcut to add a new post

• Trello integration

• Support for payments via invoice

Engineering

• Optimize image compression

• Migrate last test suite

• Spike - Feature flags

• Untangle and remove dead code

• Fix memory leak in text editor service
  

In this case, it’s so critical that the memory leak in the editor is fixed before adding toggle options to headers, or bringing more people to editor by creating a new role type. If the memory leak stays hidden in the engineering roadmap, the risk is high that the increased usage of the product will actually result in poor satisfaction instead of the upward momentum the business needs.

This isn’t about giving your product manager unilateral authority over what gets built. They don’t want that. Instead, elevate engineering to have an equal stake and ownership over the product and the outcomes. Product teams have a high sense of ownership, and with that ownership comes accountability for outcomes.

Better measurements always win

I said above that “the new shiny things always win”. The shiny new thing almost always has better measurements. It’s a lot easier to count the number of new logos, or the increase in average deal size, that results from launching a new feature.

It’s much more difficult to measure the absence of something. For example, how do you measure the absence of an incident because you took a week to add some fallbacks for a 3rd party dependency that’s been a bit flaky lately?

Contributing to this is the tendency of some engineering teams to skip a mini-discovery or validation step before pitching projects. Using data to inform decision making is a key skill for engineers, so don’t skip it. You should be able to make a case for your projects that goes beyond just “we know this needs to be done.”

To be extremely direct about the point above: it is the responsibility of engineering teams to articulate the business value of projects to their cross-functional partners. It’s sometimes the case that your PM doesn’t have the subject matter expertise to know the value of a project pitched by engineering, which makes prioritization very difficult. It’s your job to communicate with data so everyone has the same information.

Money is a language everyone speaks. How much does an outage cost when you need to refund monthly subscription fees per your SLAs? How much risk and cost is associated with a security breach? How many enterprise customers would be likely to increase their investment if you had an executive report from an external pentest?

In the absence of money, think about UX and customer satisfaction. Dig up support tickets that mention latency or perceived lack of product quality. Look at churn rates and exit surveys from former customers.

Where do internal engineering projects get tracked?

Pushing toward one roadmap doesn’t mean that all engineering-proposed projects need to be a discussion with external stakeholders (no one wants that, even the stakeholders). A stronger partnership with your PM doesn’t mean that engineering loses all autonomy. There are some projects which don’t necessarily belong on your product roadmap, where engineering should have the final say. A rule of thumb here is that if you’re not going to write about it in your changelog or release notes, or if you sales and customer support teams don’t need to know about it, you can skip the overhead of adding a formal roadmap item. These projects are usually about research, internal efficiency, or velocity.

• Spikes or POCs of new technologies

• Improving development environments

• GitHub cleanup (stale PRs and projects)

• Adding new automated tooling (artifact scans, dependency scans)

You might call this is a roadmap, but it’s really just a backlog. These projects are important and your team needs to create capacity to accomplish them.

Some teams schedule only 75% of their available time with roadmap sprint work, leaving the rest of the time flexible for bugs, incidents, and internal-facing work. An alternative approach is to remove any sprint commitments from the on-call engineer. This protects your team from falling behind in case there is an incident, and if there isn’t, they can use their on-call week to work on internal projects.

And what if this isn’t your reality?

The organizational headwind working against you might be very strong. You may not have a PM that is routinely having conversations with your development team, you may be outsourcing a lot of work which leaves little room for internal work. In addition to factors like these, you might work in an organization with a very strong command-and-control culture and a focus on deadlines.

In these cases, change can be very slow. It might take you months to build relationships with external stakeholders that put you in a position to advocate for projects your team proposes. In the meantime, get creative with ways to carve out and protect 10% or 20% of your team’s time for the items on your internal roadmap. Do some internal debugging and try to understand where the pressure around deadlines come from. There are likely some projects that help you team execute faster, and if you’re armed with the right data, you can make a compelling case for those projects because they quickly pay for themselves.

Bad Management Advice

I spend a lot of time with engineering leaders dissecting different leadership challenges, and mentally mapping out the different outcomes that could result from different approaches to dealing with each challenge. We’re always looking to find the perfect union of fairness, consistency, and empathy.

I’m not often asked questions about the wrong way to do things, so I was surprised when someone asked me about the worst management advice I’ve gotten. It reminded me of a Twitter thread a couple weeks ago:

Q. What’s the worst leadership advice you’ve heard?

A. By far the worst is “Hire great people and get out of their way”.

— @jmwind

Two teams of smart people who are working hard on conflicting priorities will often result in minimal progress for your company. They might be executing at a swift pace, with measurable outcomes, but the lack of alignment can kill forward progress. Smaller teams that work less efficiently but are aligned to each other will end up having a bigger impact on the organization. And nothing is more frustrating to the great people you hired than lack of forward progress. Alignment is essential for the health and success of your business, especially if you hire great people.

A couple other hits from my list of bad management advice:

1. If you hire senior engineers, they can onboard themselves, and they won’t need management. There’s some truth to this - you should expect a senior engineer to be more comfortable with vague requirements and be resourceful and self-directed. But you can’t just throw them onto a team and expect them to be producing production-quality code immediately. You might also get away with less project management with experienced employees. They still need and deserve feedback, career growth, opportunities to learn new things, and for you to provide context so they can do their jobs.

2. Ignore questions from your team for a certain amount of time before answering them. You don’t want to set a precedent that you’re always around to help, and they’ll figure it out themselves because they need to. This might be my favorite bad management take because it’s just ridiculous. Trust that your team escalates important issues to you that need your input or expertise in order to unblock them. Being unavailable doesn’t empower your team to make decisions on their own. It causes them unnecessary stress, fear of punishment, and at worst, unsatisfactory results that you’ll need to deal with later because you didn’t want to be bothered to answer a question.

3. People who are interested in discussing salary early in the interview process are in it for the wrong reasons. We have jobs to make money. Would you do your current job for 1€? Probably not. It’s important to discuss salary expectations early in the interview process to ensure that you’re not wasting anyone’s time. If the salary expectations are really out of sync, it’s better to find out before investing hours in an interview process.