Buy My Book, "The Manager's Path," Available March 2017!

Sunday, May 12, 2019

OPP (Other People's Problems)

A hard lesson for me over the past several years of my career has been figuring out how to pick my battles. I’ve seen many friends and colleagues struggle with this as well: how do you know when to involve yourself in something, and how do you know when to stay out of it? How do you figure out where the line is?

The setup

If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. Your care may be focused on software and systems, or on people and organizations, or on processes and policies, or all of the above.

This attitude has probably served you well in your career, especially those of you who have been working for a number of years. You’ve been described as having a “strong sense of ownership,” and people admire your ability to think broadly about problems. You try to think about the whole system around a problem, and that helps you come up with robust solutions that address the real challenges and not just the symptoms.

And yet, despite these strengths, you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad. They don’t take your feedback well. They don’t want to let you help fix the situation. Your peers rebuff you, your manager doesn’t listen to you, your manager’s manager nods sympathetically and then proceeds to do nothing about it.

That kind of grinding frustration can wear you down over time. I know, because I’ve been there. I left a cushy big company job because I saw too many things I felt powerless to fix. When I got into management, I figured that I would have the power to make things right. Then I thought that when I became the leader of all of engineering I could do it. Then I thought that when I became an executive I would be able to do it. Chasing that dream of being able to fix all the things contributed to me feeling exhausted, and dare I say a bit burned out, when I finally decided to leave my CTO gig.


Escaping the Trap

I’ve come to realize that there isn’t a job where you can fix all the things. It is true that founders have immense ability to set direction and culture, but trying to control everything happening in a company causes many other problems that are outside of the scope of this essay. Assuming that you are not a founder, you should just take a minute to really let it sink in: there is no place you can go where you can control everything and fix all the problems, no matter how much you get promoted. There’s always going to be something you can’t fix.

So how do you decide where to exert your energy?

Step one: Figure out who owns this problem

If it’s your job (or the job of someone who reports to you), great. Go to it! Tend your own garden first. Make systems that are as robust as you believe systems should be. Follow processes that you believe are effective and efficient. If you are not leading by example, you have to start there. Stop reading now and go fix the things!

If there’s no clear owner, do you know why? Is it just because no one has gotten around to doing it, or has the organization specifically decided not to do it? If no one’s gotten around to doing it, can you do it yourself? Can your org do it, just within your org?

If it’s someone else’s job, how much does it affect your day to day life? Does it bother you because they’re doing it wrong, or does it actually, really, significantly make it harder for you to do your job? Really? That significantly? There’s no work around at all? If it is not directly affecting your job, drop it!

Step two: Talk to all the people

If you don’t clearly own the problem, you need to talk to people. If you feel tired by the idea of talking to all people, stop! This is a sign that you should not pick this battle! It’s already draining you and you haven’t even started on the path to addressing it. It is probably a good idea to just try to let it go, or at best, tell your manager that you worried about whatever it is, and then let it go.

If you’re ok with talking to all the people, then get out there and get a sense of the problem beyond you and your team. You can do this formally, with a document that you prepare addressing the problem as you see it, or informally, as a series of user interviews. You will need this information to make a case to fix it, and to make a plan for how to fix it. Does the information you’ve gathered from others make you think that perhaps this problem really isn’t as important as you first thought it was? Is someone else already solving this problem? Great! Let it go!

If you know who should own this, you need to give them a chance to fix it. Which means you need to come with examples of how the problem is impacting you or your team. Missing those examples? Stop! This is not your problem to fix! Don’t go bringing problems based on people from other teams complaining to you. Those teams need to bring up the problems themselves. If you must, tell their manager that you’re hearing these complaints, and let that manager decide whether to deal with it.

Step three: Plan the fix

Ok so you talked to all the people and the problem is still not fixed. Assuming no one owns the problem and you really still want to own it and fix it, great. Make a concrete plan for how you will fix it, and share that plan with the people who need to know about it. You should expect that you will need to get feedback and revise your plan, and the amount of feedback and revision required will be directly related to how big the problem is, how many people it impacts, and how controversial the fix you’re proposing is. Expect this feedback, buy-in, and revision process to take a while. You’ll need feedback from all corners, friends are good to start with but be sure to include your skeptics too. Your goal is to convince everyone that they want you to solve the problem. Yes, that means a lot more talking. If you’re tired now, maybe this isn’t your problem to solve!

If this problem is with another team, and you talked to that team, brought them clear examples of why it is truly a big deal, and they haven’t answered your concerns to your satisfaction, you have a choice. Do you escalate to your manager? If you have clear examples of why it’s a problem, and your peer hasn’t been able to do anything, this is a perfectly fine time to escalate! Consider though whether you can negotiate a fix with the other team, or work around the other team. And, especially when the problem is cultural, consider whether you really need to make this problem into a big deal, or whether you can just let it go.

Step four: Enact the plan

And now we get to the tricky part. You saw this problem, you complained about it, you made it your own, and now you have to fix it! This is what you wanted, right?

Unfortunately, the fix will almost certainly take a lot longer than you’re thinking it will take, and it will probably be a lot of work on your part to see it all the way through. And by the way, it’s unlikely that you get to give up any of your other problems to take this one on. But this is something you feel passionately about, and that should make the extra work worth it to you.

Step five: Think about how many of these you can actually do

Good job! You fixed the problem! It was probably a little bit harder to fix than you expected huh? Especially if it was a cultural thing that you needed to change. But it should feel good to have it fixed. You can see the improvement you were aiming for, and you’ve got a great story to tell.

Take a moment to reflect on whether it was worth the effort to you, and think about how many more things like this you see at the company you’re in that you really want to change just as much as that one.

Think about what else you could be doing with that extra energy. Finishing a critical project sooner? Hiring a few people who are more in tune with your way of doing things, who might be able to fix things for you? Writing a novel? Getting a personal best on your deadlift?


Pick Your Culture First and Foremost

Learning how to pick your battles is also about learning how to pick your company and pick your boss, because your job really shouldn’t be all or even mostly about battles. Going through this exercise of solving an unowned problem is fun once in a while, but it’s a real drag when you feel like you’re surrounded by such problems, you can’t ignore them, and you’re powerless to fix them. That is a good sign that it’s time to find a new job, preferably somewhere that is more in tune with your way of doing things. Life is so much more fun when you have people around you that you trust to solve problems, even the problems you have a lot of opinions about.

Flowchart courtesy twitter user https://twitter.com/felidelg
Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!

Friday, November 23, 2018

I hate manager READMEs


I got feisty on twitter this week and wrote up some tweets on manager READMEs, a recent hot trend in management. Let’s break them down:
Dropping f-bombs is one of my "quirks"



Well, what can I say, I’m sick of this trend. I’ve been a skeptic from day one, but what pushed me over the edge was watching one of my senior engineer friends react to this article on the concept. It mirrored the loathing I’ve heard from several senior engineers as well as the general negative reaction most managers in my trusted circle have about the concept. But we’ve got a lot of people trying to popularize the idea, so enough’s enough, and today I’m willing to be the critic to this well-intended exercise.
I will always tell it to you straight whether you like it or not, except when doing so will open me up to excessive criticism or otherwise rock the boat too much, and then I’ll probably just roll my eyes behind your back



Look, fellow managers: there is no way to write these and not be self-serving. You are writing them presumably to shortcut problems that arise when people misunderstand your behavior or when they act in a way you don’t like or otherwise violate some expectations that you believe are within your rights to set. And hey, I’m a boss too, I get it. You want people to respond to your emails within a certain timeframe, fine, that’s (maybe) a reasonable expectation. If most of the manager READMEs were essentially descriptions of what behaviors you expect from your direct reports in the performance of their job, I might not mind so much. It’s a bit crass (sounds more appropriate for a manager of a factory floor than a manager of “knowledge workers”), but could be effective.
But then there’s this idea that you can build trust with this exercise, and you do that by being brutally honest about your own flaws, your values, and the behaviors they should expect from you. That is where I really take issue with this process.

First of all, be real: you probably do not know yourself as well as you think you know yourself. It’s the Dunning-Kruger of self-awareness. If you’ve gone through any deep coaching, self-awareness practice, or therapy, what you learn over time is how hard it is to be 100% honest about yourself and your motivations. If you’ve gone through very little of that, well, you are almost certainly in deep denial about your behaviors and how well they actually reflect your conscious beliefs. I know myself well enough to know that I might usually behave in alignment with certain personal values and expectations, but I will break that alignment at the worst possible times (you’re most likely to break with your best intentions in times of high stress).

What happens when you put out this declaration of vulnerability and earnestness and self-awareness and then you behave in such a way as to completely contradict the thing you claimed to be? You damage your credibility, hard. You damage the trust you might otherwise have built with your team. And you make it harder for people to call you on your hypocrisy, because they know that you don’t actually see yourself this way. It is incredibly difficult to tell someone that the thing they believe about themselves enough to publicly declare is, in fact, not true. It’s hard to tell your partner that, it’s hard to tell your friends that, and it’s basically impossible to tell your boss.

Yes, of course, you said that you want feedback, that you respond well to feedback. That does not actually change the fact that you have a huge power differential to the person who reports to you. I like to think that I respond well to feedback, and I ask for it from people throughout my tree. I don’t actually expect them to believe me about that, because I’ve had too many managers who claimed they wanted feedback and then reacted to my honest feedback by shutting me down, blaming me or others, or otherwise making it clear that maybe they do want some feedback, sometimes, but not this feedback, not at this time, not in this way.

If you want to build trust, you do that by showing up, talking to your team both individually and as a team, and behaving in an ethical, reliable manner. Over, and over, and over again. You don’t get it from writing a doc about how you deserve their trust.

One of the worst parts of these docs is the airing of your own perceived personality faults. I suck at niceties. I get heated sometimes in discussions. I don’t give praise very much. If you know you have foibles/quirks that you in fact want to change about yourself, do the work. Don’t put them out there for your team to praise you for the intention to do the work, just do it. And while you get to decide which of your foibles/quirks/challenges you will or will not change about yourself, as the manager, it is on you to make your team effective and that may in fact mean changing some things about yourself that you don’t want to change. Writing them down feels good, like you’ve been honest and vulnerable and no one can be surprised when you behave badly, after all you warned them! But it does not excuse these bad behaviors, and it certainly does not take the sting away when someone feels shut down by your rudeness or unhappy from a lack of positive feedback. If you must write a README, please skip this section. Keep your bad behaviors to yourself, and hold yourself accountable for their impact.
I care about you and want you to feel seen but also I want to not come off as a total opinionated bitch when someone inevitably disagrees with me




I believe many people who are doing this are really trying to do the right thing. I see your good intentions. But good intentions don’t just magically make bad ideas turn good. Everyone writing one of these is trying to make it easier for their teams to work for them. But the unintended consequences of these docs given the power differential between you and the people on your team are real and serious. Recognizing that you are human and have flaws and preferences is great! But trying to codify them into a README is folly because for everything you know about yourself there’s another thing you don’t know, and your documentation is out of date the minute you write it down. You’re not a computer.

I've gotten a LOT of coaching


You know where these kinds of docs are useful? As a coaching, therapy, or personal introspection exercise! I love doing stuff like this for myself. It’s great to spend time writing down things that you believe about yourself. But the thing is, to make that process really useful, you then need someone who helps you dig into which of the things you believe about yourself are really true, and which are stories you’re telling yourself. You need a person who is in a position to hold you accountable when you stray from those stated values, or who can help you refine them better as you learn more about yourself. And that person is not someone who reports to you. That person may only be yourself, or maybe it’s a coach, or a therapist. I wouldn’t even really recommend trying to make your own manager do this job, because it’s probably not something they’re trained to do.



So maybe I’ve convinced you, and maybe I haven’t. If none of my arguments so far have convinced you not to write these for the purpose of sharing with your team, perhaps my final words will:

You’re probably just wasting your time, because no one reads the docs anyway!


If you’d rather read something funny, check out Tim’s parody, “A User Guide from My 5-year-old”

Enjoy this post (or hate it)? You (still) might like my book, The Manager’s Path, available on Amazon and Safari Online!

Saturday, November 17, 2018

When is someone ready to manage managers?

When I wrote “The Manager’s Path” I talked about what it means to work at the various levels of leadership, but I didn’t really talk as much about how you actually climb to those levels. For some people, it just happens as a consequence of being in a growing organization, and succeeding at growing with that organization. But how does that work, really? And how can you show that you are ready to take on bigger things when the opportunity comes along?

First, look at the role you are currently playing. If you are still spending most of your time deep in the technical details of the projects, you are probably not really working on the skills needed to manage managers. You need to develop the ability to leverage your attention and time through more people and projects, and that generally requires that you start looking outward (at people, teams, and related projects) and forward (to identifying opportunities, strategies, and potential pitfalls), rather than deeply down into the technical details. Be honest with yourself: Are you ready to spend less time in the technical details? If not, you are probably not going to enjoy managing managers. Is your team set up for you to spend less time in the details? If not, you need to fix that problem by developing new technical leaders, before you are likely to be tapped to manage more people and eventually managers.

Once you’ve started to scale yourself beyond a tech lead who manages a few people, you’re ready to be considered for the next level.

How to go from line manager to managing managers

The promotion path forward generally depends on a few things.

Can you scale your team effectively? If the team is 5 people growing to 20, it’s easy to argue that there is a need to create sub-teams. If you are seen as instrumental to leading the growth, hiring the new people, making sure the new hires are on-boarding successfully, and helping the team scale effectively, it might be you who gets called upon to manage the new team!

However, this only works when you are scaling successfully as a manger. Most of us want to promote from within, but when your team isn’t running effectively, it doesn’t make us want to give you more. This is usually what’s happening when a division grows quickly and the original manager does not get tapped to run the division. There’s a lack of confidence in the original manager to lead the larger team. If those new hires aren’t effectively working, if people are complaining to your manager that they feel unhappy with the work, if your projects aren’t shipping, if you have a lot of quality problems, or even if you just can’t effectively juggle all of the work of managing people and projects, you’re probably seen as unable to succeed at the next level of management.

Would other managers want to work for you? You need to be able to balance people and projects and getting things done, but that’s not all. The second question that arises is: would other managers want to work for you? Managers want a boss who can teach us things. We want coaching on how to be better, without being micromanaged. We want room to make our own decisions and our own mistakes. And we want to work for people who we trust and respect.

Look at the way you are managing your team right now for clues. Your team wants to learn things, and they should be making some of their own technical decisions. To make good decisions, they need to have context for their work (the customer feedback, product goals, and technical challenges). If you’re currently providing them with only a limited view of outstanding tickets or work to be implemented, you should broaden their access to context and give them a voice in the direction their work might take. If you haven’t yet, look to develop new leaders on your team. If you’re tempted to say they’re all “too junior” to be leaders it’s likely that you haven’t developed the coaching skills yet that you will need to manage another manager successfully.

Look at the teams around you, and your relationships with those teams. Developing strong peer relationships is critical to leading an organization effectively. If you are regularly at odds with the managers or the tech leads of other teams, spend some time repairing those relationships. Ideally you can develop enough trust that they will come to you for advice. You might need to start by asking them for advice or doing favors for them without any expectation of immediate return. You want to be seen as a leader beyond your team, and that starts by acting as a collaborative partner.

Does your manager want you reporting to her? The third question, beyond basic scaling and the ability to convince other managers that they might do well working for you, is the question of whether a more senior manager wants you reporting directly to her.

This depends on you, your manager, and the options that your manager has available. If your manager has to decide between someone who needs a ton of coaching and someone who already knows how to do the job, it’s unlikely she’s going to choose the person who needs a lot of coaching to run the team. Especially if she is already stretched thin. In general, if you’re managing managers, your boss wants you to be able to operate independently. She wants someone capable of dealing with most people problems without escalating them, smoothing over conflicts within their team and with peer teams, and who can represent the team well to third parties within the company.

That being said, if you lack the experience but have shown yourself to be open to feedback and coachable, you are much more likely to be chosen than a random outsider. Many people people get tripped up here without realizing it. So many line managers think that they are temporarily embarrassed CTOs, and don’t realize that they are lacking in many critical skills. If you bristle at every bit of corrective feedback, if you have an outsized ego that everyone can see, or even if you simply never actually act on the feedback that you get, you’re not going to be top of the list when the opportunities come about.

But how am I supposed to learn these skills if I don’t have a team to practice on!

Don’t despair. Just because you are only managing a single, smaller team doesn’t mean you can’t develop the skills and show that you can add more to the overall org. Here are some ideas for areas to focus on, in no particular order:
  1. Is your team a well-oiled machine, delivering clean code regularly and partnering well with other teams in the org? If not, perhaps you need to make sure your local house is in great working order, because it’s hard to get promoted if you aren’t seen as effective with your current scope.
  2. Look into how you can help your larger organization. This could be volunteering for organizational tasks such as: helping develop the interview process, running hackweek, organizing open source initiatives, etc. It could mean identifying processes within your organization that are less than ideal, and working to put in place concrete improvements. These will give you practice managing via influence, a valuable skill for most senior managers.
  3. How are your relationships with other managers and tech leads in your organization? Are you friendly and collaborative? Do you sometimes do things for their teams without expecting something in return? Building partner relationships with other teams nearby can help make you a possible candidate for leading those teams when there is an opening for a leadership change. But resist the urge to provide unsolicited advice to your peers! Your well-meaning advice will come across as a signal that you think you could do their job better, and that rarely goes over well.
  4. Are you presenting a professional face to the team? Are your working hours reliable? Do you respond to email in a reasonable timeframe? Are you thoughtful in your communication style? Do you come prepared to meetings or do you always look like you’re about to fall asleep at the table? In other words, is your boss going to worry that you’ll make her look bad? If so, work on that. Otherwise you’ll be fighting an uphill battle.
If all else fails, you can certainly try to jumpstart your career by moving to another part of your organization or another company entirely. But my advice, especially if you like the company you’re working for, is to start by making sure you’re not holding yourself back.

Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!

Saturday, September 22, 2018

Engineering Productivity

I’m often asked about the characteristics of great engineering managers. This is a question that almost always has a long answer that involves “well, she’s good at X, and he’s good at Y, and then there’s Z…” Every management role is slightly different, and a great engineering team will have managers who reflect a set of complimentary skill sets (such as operations, people management and coaching, product-focus) that are aligned with what their subgroup most needs.

However, for most of us, there is one characteristic that is not optional or debatable, which is that a great engineering manager is capable of creating a highly productive engineering team. This is one of the distinguishing characteristics of the management side of engineering. Call it what you will — drive for results, goal-oriented — if you are not great at getting your team to be productive, this is a critical growth opportunity.

How do I know this is important? Ask any engineering manager at a startup what one of their most dreaded questions is, and they will almost certainly mention “why isn’t it done yet?” Engineering productivity is a hard thing to measure, but most of us know intuitively what it feels like to be on a productive team. We’re shipping things, we’re focused, we feel like we know what we’re doing and why it is important.

So what are the management skills that are needed to achieve this result? At the first level of management, they look like:
  1. Breaking down the scope of projects to help your team ship frequently. An eye for the MVP, for sequencing work and for predicting likely risks and bottlenecks for project completion are the skills here. This is why I think project management is such an important part of engineering leadership development, and why I hate to hand it off to professional project managers for work that doesn’t cross teams or organizations.
  2. Balancing that product delivery with sustaining engineering so that you don’t end up with code that can’t be maintained in the future. The amount you will invest here depends on the future certainty (baby startup? Probably not so much!), but there’s a reason we call it “technical debt” and that is because it inevitably comes due, unless you declare bankruptcy.
  3. Prioritizing, prioritizing, prioritizing. Implicit in the first two skills is the ability to figure out what is important, and prioritize it. If you overprioritize shipping, you might get a lot done for a while, and then slow down as the debt you’ve accumulated comes due. Overprioritize sustaining engineering and you don’t ship product. You may not start out with these instincts, but they can be developed, so don’t be afraid to start making judgment calls now and learning from the results.
Managers who fail in these three areas quickly show why this is such an important skillset. Teams who don’t ship are usually disengaged and rarely get the positive feedback of seeing their work come to fruition. Teams who don’t ever clean up their tech debt end up burning out on the difficulty for supporting their software and the challenges building new features. And when teams don’t prioritize effectively, they end up burning cycles on things that are ultimately not that important which often contributes to a sense of purposelessness.

This is not the only thing that is important in engineering management, but without a focus on delivery, you are letting your team down in a critical way. So while you’re learning how to have good 1–1s, listen to people, create psychologically safe teams, and think about people’s careers, don’t forget that if your team isn’t shipping, you’re not doing your job. Nurturing a safe and healthy team helps your team do their best work, and helping them identify and deliver that best work is a key part of keeping them healthy.

Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!

Sunday, July 29, 2018

Delegation: When being helpful is actually hurting

Effective delegation is one of the most critical skills a manager can learn. Without effective delegation, you fall victim to micromanaging your team, losing control of your time, and eventually failing to put yourself in a position where you can take on more and lead bigger things. There are many facets of effective delegation, and in this post I’m going to talk about one that tends to come from an otherwise good instinct: The failure to delegate because you are trying to be helpful.
Be Like Rep. Maxine Waters, and Reclaim Your Time!


“How can I help?”

I want my team to be happy and successful, and I want to feel useful and needed. So it’s not surprising that, when people bring me problems, my first instinct is to think of ways I can help them with these problems. Can I escalate it to one of my peers or my boss? Can I talk to the difficult employee for them, and try to improve the situation? Can I review the project plan and find the areas that are lacking detail and likely to cause the timeline to slip?
As I’ve managed people with a lot of management experience themselves, I’ve noticed that they very rarely take me up on these offers. Instead, they tell me exactly how they are thinking about tackling the situation, perhaps listen to a few bits of advice from me, and then only ask for my direct intervention when their efforts have failed. It’s totally awesome! And it has taught me a lot indirectly about effectively managing my own time, and what good delegation looks like.


Not My Monkeys, Not My Circus

So, what did their previous managers teach them that I need to learn how to do? Well, it turns out, their previous managers were probably pretty sensitive to something called “subordinate-imposed time.” I was introduced to this recently reading an old HBR article, “Management Time: Who’s Got the Monkey?” Published originally in the 70s, this article took me a few read-throughs to really understand. Its focus is on controlling your time as a manager, and in particular, making sure you don’t take on too many tasks that are really the job of your subordinates.
The article uses a confusing-to-me analogy of monkeys riding on your back to describe these tasks. In simpler language, these are often the tasks that you take on when you are trying to be helpful to the people who work for you. Examples include:
  • One of your directs asks for your input on a complex decision, and you take ownership of studying the factors and making that decision
  • Telling someone on your team that you want to review a proposal before they send it out. 
  • Volunteering to provide the first draft of goals for a project that a member of your team owns. 
These are all examples of reasonable things that someone might ask for your help on (and all things I’m sure I have done!). However, the way you choose to provide that help is key. In each of the cases above, you’ve taken over a piece of work from someone that works for you. You’re making the decision, insisting on final review of the proposal, and starting the project work. 
How would you approach these situations if you were instead determined to leave the delegation on your team member, and make sure that you didn’t use a lot of your time doing their work? Well, you might:
  • Talk over the decision in your 1–1, provide them with suggestions, but let them make the final call and justify it to the stakeholders
  • Review the doc in your 1–1 or another meeting specifically set up for this purpose (if they requested your review or if this is something they’re still learning how to do), but otherwise provide feedback at the same time that other stakeholders are given the doc
  • Let them set up the first draft of the goals, and again in the context of your 1–1 or a review set up for this purpose, review the goals that they have drafted and provide your feedback
You might object, all these meetings! But most of these touch bases can be done in the context of your weekly 1–1 (and in my experience doing this, most of them are). This frees you up outside of these scheduled, planned meeting times to focus on other important tasks that come from your own boss, the company and your peers, and things you want to get done for yourself. And most importantly, it puts the initiative squarely on the shoulders of your team, which is almost always where it belongs. They aren’t going to learn how to make good decisions, set good goals, or write effective docs, if you are always there providing a safety net or taking over the hard work from them. 


Reclaiming My Time

So the next time you find yourself tempted to volunteer to take over responsibility for something from someone who reports to you, pause. Instead of taking it over, ask them what they think the next steps should be. Give your feedback, and let them bring the follow-ups to you in the next appropriate touch base. You owe it to them to stop taking over their work in the name of helpfulness.

For further reading, the classic HBR Article linked above, “Management Time: Who’s Got the Monkey” has much more detail, including a very useful scoping of how much initiative someone is showing on a scale from “waiting to be told what to do” to “acting on their own, then routinely reporting.” And of course, you can always read my book, The Manager’s Path.

Tuesday, March 6, 2018

Are you out of alignment?

Alignment, in the teamwork sense, means “a position of agreement or alliance.” It is one of the critical qualities that determines success in an organization, particularly at higher levels.

Many individual contributors (ICs) get stuck at a certain point in their career because they can’t see that they are out of alignment with their company, and they don’t realize that the way alignment is achieved has changed for them. In the earlier part of your career, you can be relatively well-aligned just by doing a pretty good job on the things you are asked to do. You get an assignment, presumably from someone who knows what is important to do, and you do it well. As you grow as an engineer, maybe the technical implementation details of those assignments get more challenging, the tasks get bigger, but as long as you keep conquering them, you are fine.

That is until some point you realize that you’re still good at conquering the tasks, getting those hard problems solved, but you aren’t really getting promoted any more.

Sometimes this comes on slowly, and it looks like boredom. There are fewer and fewer of those meaty big technical problems for you to work on. You assume that they don’t need your skills. You get jealous that people aren’t asking for your advice before they build things, because clearly you know better!

Or it comes on all at once. You are told explicitly that you should find the next thing you want to work on, and you look around and don’t know what to look for. There’s no obvious problem that breaks down into what you know how to do. Or you find something, and you dig in. You get a prototype finished, and everyone yawns. Maybe it gets used for something small, but instead of changing the world for your team, people don’t seem all that impressed, and the things they are impressed by seem so trivial, boring, and technically easy by comparison!

My friend, you have discovered that you are out of alignment.

There are a lot of obvious ways people are misaligned to their companies. The classic “not a cultural fit” is one. If you fight against every process, decision, person around you, even if you’re right, that alignment mismatch will hurt you.

The more subtle way that most of us get out of alignment is by being unwilling to admit that we don’t understand what’s important to the company. We maybe don’t want to understand. We want to do things that are fun and challenging and interesting to us and have that work out to be the important thing. But for the fun things to be the important thing effortlessly is pretty rare. At a certain level, creating the alignment between projects that are interesting for you and what is needed by the company is a big part of your job.

Getting into alignment with the company is often a challenge for senior ICs because it requires a major change in focus. The hardest part is now identifying the right problem to solve, instead of solving the hardest problem. If you want to be able to find interesting work and also work on important things, you generally have to go find the interesting important things yourself. This requires that you to talk to a lot of people and listen to their problems, and then place a bet on a solution to one of these problems that will actually both be feasible but will also be seen as important. Your manager might help identify people that you could talk to, but you must take responsibility for doing the legwork and making the final choice in problems to address.

The alternative way to resolve this alignment issue is to force yourself to address problems that you don’t want to solve, problems that are perhaps not as glamorous to you but are clearly important for the success of the company. Taking responsibility for cleaning up an area that feels intractably broken is not the job for every engineer, but for some people it is an easier and more obvious path to alignment and success. The risk you take here is that you either burn out fighting to fix a situation that is really about people and organizational issues that are beyond your scope, or you pick a broken area that no one really cares about fixing.

In both of these scenarios, you are taking more risk than you used to in the past, and that is where the second part of the quest for alignment comes in. It’s not just about being willing to find the work to do, it’s about finding the most important work that is right for you to do. The more attuned you are to the needs of the company, the kinds of work that is highly valued, the more likely you are to put your energy into something that will pay off well for you.

I often say that at more senior levels you get promoted for making wise bets, and really what that means is that you are smart enough to know the payout for what you’re pursing. Whether it’s knowing which fire to put out first, or having an idea for the thing to build to make your whole team more effective, the better-aligned you are to the needs and values of the organization, the more likely you are to be successful.

Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!

Saturday, January 13, 2018

Stop answering your own questions

I have a bad habit. I noticed it today as I was leaving a comment in a strategy document. I’d highlighted some text that I found unclear and commented:
“Do you mean X or Y? Because I don’t think it is reasonable for us to do Y”
This is one of my bad management habits. I jump to conclusions. I pretend to ask a question but then make it clear that only one answer can be right.
It is probably obvious why this is bad. While I do want to know more, in this framing, I am talking to hear myself speak, rather than genuinely asking for more information that would help me understand the plan and allow me to give better feedback. By stating my preference up-front I cut off discussion. What’s worse, I make the receiver unlikely to honestly answer my question; unless, that is, they feel up to the task of debating me.

Get Curious


In writing you can review what you have said and edit your phrasing to eliminate this kind of thing, but it’s significantly more difficult when you’re in verbal conversation. When you’re talking you don’t have a chance to see yourself poisoning the well and cutting off opinions before they can be explained. This is one of the many reasons I have tried to embrace the mantra get curious. I use this phrase to remind myself that I have to make room for people, that my first reaction is not always the right one, and that when I hear something that doesn’t sound right I need to listen more rather than jump all over it.
If you are (or were) a highly opinionated engineer, practicing making space for information rather than quickly jumping in and sharing your conclusions is a must for leadership growth. The more senior you become, the harder it is for people to feel comfortable disagreeing with you openly. That is not a sign of weakness on their part! Most people with any sense of self-preservation know that saying the wrong thing to the wrong person can have negative consequences. Lucky for you, as the manager, people are going to listen to what you have to say. Unlucky for you, as the manager, if you don’t make space for them to say things that you disagree with, you are unlikely to hear important details.
Making good decisions requires you to get as much information as possible, to understand the nuances of the scenario from all angles. It is very difficult to do that if people are afraid to contradict you. One of the less-obvious ways we make people afraid is by offering our opinions too early, without taking the time to get the rest of the information. So the next time you’re tempted to ask a question and answer it yourself, stop. Get curious. You already know there’s something you don’t totally understand, so hold on stating your opinions until you’re sure you’ve gotten as much information as possible.
Now, to go edit that comment…