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

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…

Wednesday, September 6, 2017

How do managers* get stuck?

*May also apply to senior ICs

Earlier this year, I wrote a piece called “How do Individual Contributors Get Stuck?” This was an attempt to help ICs provide constructive feedback to their peers, by identifying common challenges that I have seen developers struggle to overcome. 

This piece is a little bit different. I want to answer the question that I often hear from first-line managers, that is, managers who manage only individual contributors: “How do I get promoted to the next level of management? How do I prove I’m ready to manage managers?” 

Managers often believe that if they are handling the demands of managing their team, they should naturally be promoted to manage more people, bigger teams, teams of teams, as quickly as such an opportunity comes about. And yet, just as often as those opportunities come about, someone else is chosen, a person is hired from outside the company, and the eager manager is passed over. You’re stuck. When you find yourself “stuck” in terms of management career progression, what might really be happening?

Usually, getting stuck as a manager falls into one or more of the key areas of management: Failing to manage down, failing to manage sideways, and failing to manage up.

Scenario One: You aren’t actually scaling yourself effectively, aka, failing to manage down

You may think that you’re handling your team well, but when you look at your schedule, you’re working nights and weekends and then some to juggle all of the new tasks that managing a team entails. Sure, there are some companies which expect that from everyone, but it’s rarely a sign that you’re using your time effectively. Look at your team. Is it a well-oiled machine? Do you feel like the team is able to operate independently, get things done, without you micromanaging every detail? If not, you’re probably stuck on the basic needs of your current job. Some examples of this include:
  1. Can’t delegate. Look at all hands-on tasks you own, and ask yourself whether you are the only person who could be completing these tasks, or whether you could assign them to another senior engineer. If you are spending a lot of your time doing hands-on work that someone else could be doing, you probably aren’t delegating effectively.
  2. Not training your team. If there are too many tasks that only you can complete, you have made yourself a key dependency for your team. Who are your potential successors, and have you spent time training them on the things only you can do?
  3. Not enough attention to the process. Is your team drowning in alerts with no end in sight? Why haven’t you spent the time to allocate people to fix that? Have you spent time paying attention to the way work is assigned in your team? Do you actively participate in the planning process? When was the last time you tried changing it to see how it could improve? Process is part of your life now, and you need to tend to it.
  4. Won’t say no. If your team is completely overwhelmed with work, well, it’s partially your fault. You are the manager, and you are the person who is responsible for pushing back on the work commitments for the team. 

Scenario Two: You haven’t shown that you can expand beyond your team, aka, failing to manage up

Maybe your team is running well enough, but that’s all you’re doing. Opportunities for advancement are usually given to people who show up for those opportunities. You can easily get stuck by just getting comfortable in the place that you’re sitting. Someone who is failing to manage up often exhibits one of the following problems:
  1. Doesn’t attend to the details. Everything from clearly communicating the things that your team has accomplished, and sharing challenges or setbacks, to keeping your manager in the loop about major design decisions or roadmap changes, these details all matter. The best managers push information up without being asked and are quick to provide more details as necessary. Your manager wants to know that you are paying attention to what is going on.
  2. Complains a lot about things that are not working well, but never volunteers to fix them. If you are free with your criticism about the way things work, but don’t feel the need to do anything more than complain, you are holding yourself back. Instead of complaining, volunteer to lead the initiative to fix that team-wide problem. Bring problems and solutions.
  3. Drags her feet when given a clear task that is outside of her comfort zone. I have seen so many managers fail at the simple act of taking a clear assignment and seeing it through to completion. When your manager asks you to do something, either do it, or say you can’t/don’t really want to. But don’t just drag your feet and fail to do it.
  4. Doesn’t show a professional face to more senior managers. Do you openly look bored, distracted, or impatient in meetings? Do you write emails that communicate clearly? Do you think your manager would be comfortable having you present to her peers, alone? Your verbal, written, and body language communication is more and more important the more senior you become, and if you are lazy here it can hold you back.

Scenario Three: Fails to show peer leadership, aka, failing to manage sideways

Some people have well-running teams, they jump on fresh assignments, and yet they still get stuck. This is often due to the fact that your manager knows that she cannot put you as the manager to any of your existing peers. You are stuck because you haven’t shown enough peer/relationship management. This can sometimes look like:
  1. Doesn’t build strong peer relationships. If you spend most of your time focused downward or upward, you’re missing a step. When was the last time you helped out one of your peers? How often do you spend time with your peers, 1–1? Do you seek out feedback from your peers on your ideas, or ask them for help with your challenges? Having peers who trust and respect you, and more to the point, who might want to work for you if they had to, is needed for successful growth.
  2. Doesn’t look for additional tasks. You should be looking for opportunities to lead projects or initiatives outside of your team. How can you help your peers? You may be the best person to lead your area, but if you rarely push yourself outside of that area to talk to others and see places you could volunteer to improve, you’re missing a critical element of leadership.
  3. Doesn’t create a compelling vision or strategy that others want to buy into. You might have a clear roadmap for your team, but how much have you thought beyond your team? Have you ever shared any ideas you have for the larger group with your peers, and gotten their buy-in? Many people think that strategic thinking starts and stops with forming the strategy itself, but getting people around you excited by your ideas is critical to achieving them. 
  4. Doesn’t seem like someone a manager would want to report to. Ultimately, if you want to manage managers, a manager should want to work for you. That means that you are going to help train them, help them grow their career. You’re not going to be spending all of your time telling them exactly what to do, when to do it, no questions asked. If one of your peer line managers wouldn’t want to work for you, you might be stuck on giving the impression that you’re looking to progress solely so that you can acquire more power and influence.

What about senior ICs?

As you may have noticed, this advice applies to more than first-line managers. Many senior individual contributors start to trip on these issues. They can crank out code for days, but communicating, getting buy in, and going outside of their comfort zone stops their progression. Few senior ICs get promoted beyond a point on the strength of their ideas and code alone. 

Getting Unstuck

How do you get out of your rut? It starts by noticing where you are stuck. I noticed something that I’m not doing well just writing this list! Be honest, which of these are you really doing well at, and which are you failing? If you brought this list to your manager, what would they say? There’s only one real way to find out, so think about it, ask for feedback, and start to formulate your plan of attack for the things that are holding you back.
For more ideas, check out my book, The Manager’s Path, which addresses many of these stuck points!

Friday, January 6, 2017

How Do Individual Contributors Get Stuck? A Primer

Occasionally, you may be asked to give constructive feedback on your peers, perhaps as part of review season. If you aren’t a naturally critical person but you want to give someone a valuable insight, you may find this task daunting. To that end, I suggest the following:

Pay attention to how they get stuck.

Everyone has at least one area that they tend to get stuck on. An activity that serves as an attractive sidetrack. A task they will do anything to avoid. With a bit of observation, you can start to see the places that your colleagues get stuck. This is a super power for many reasons, but at a baseline, it is great for when you need to write a review and want to provide useful constructive feedback.
How do people get sidetracked? How do people get stuck? Well, my friend, here are two incomplete lists to get you started:

Individual Contributors often get sidetracked by…

  1. Brainstorming/architecture: “I must have thought through all edge cases of all parts of everything before I can begin this project”
  2. Researching possible solutions forever (often accompanied by desire to do a “bakeoff” where they build prototypes in different platforms/languages/etc)
  3. Refactoring: “this code could be cleaner and everything would be just so much easier if we cleaned this up… and this up… and…”
  4. Helping other people instead of doing their assigned tasks
  5. Jumping on fires even when not on-call
  6. Working on side projects instead of the main project
  7. Excessive testing (rare)
  8. Excessive automation (rare)

Individual Contributors often get stuck when they need to…

  1. Finish the last 10–20% of a project
  2. Start a project completely from scratch
  3. Do project planning (You need me to write what now? A roadmap?)
  4. Work with unfamiliar code/libraries/systems
  5. Work with other teams (please don’t make me go sit with data engineering!!)
  6. Talk to other people (in engineering, or more commonly, outside of engineering)
  7. Ask for help (far beyond the point they realized they were stuck and needed help)
  8. Deal with surprises or unexpected setbacks
  9. Navigate bureaucracy
  10. Pull the trigger and going into prod
  11. Deal with vendors/external partners
  12. Say no, because they can’t seem to just say no (instead of saying no they just go into avoidance mode, or worse, always say yes)
“AHA! Wait! Camille is missing something! People don’t always get stuck!” This is true. While almost everyone has some areas that they get overly hung up on, some people also get sloppy instead of getting stuck. Sloppy looks like never getting sidetracked from the main project but never finishing anything completely, letting the finishing touches of the last project drop as you rush heedlessly into the next project.

Noticing how people get stuck is a super power, and one that many great tech leads (and yes, managers) rely on to get big things done. When you know how people get stuck, you can plan your projects to rely on people for their strengths and provide them help or even completely side-step their weaknesses. You know who is good to ask for which kinds of help, and who hates that particular challenge just as much as you do.

The secret is that all of us get stuck and sidetracked sometimes. There’s actually nothing particularly “bad” about this. Knowing the ways that you get hung up is good because you can choose to either a) get over the fears that are sticking you (lack of knowledge, skills, or confidence), b) avoid such tasks as much as possible, and/or c) be aware of your habits and use extra diligence when faced with tackling these areas.

Wednesday, January 4, 2017

Hey Diddle Diddle, Data to Fiddle

When I worked in finance ages ago, there was a system used by many (but not me!) that was basically a combination of a gigantic distributed database plus a scripting language that allowed you to run calculations over information in that database. One of the things that you could easily do, as far as I understand, was "diddle" a piece of information. The "diddle" would change that piece of data inside of a particular scope, so that you could quickly see different calculations over the graph, without necessarily persisting that data back to the larger system. This was a useful construct for exploring what might happen with changes to different input data and exploring different scenarios. (The first half of this blog post provides some insights into how the system might have worked).

Whether my understanding is exactly right or not is irrelevant except that this concept of "diddling" stuck with me. There are times when what you want to do is take persistent data, make a small change to it on the fly, and use the results of that change without necessarily persisting it back to the original data set.

I've often thought that this concept is particularly useful in places like personalization. Imagine the situation where you have a complex set of results that you wish to display to a user, like say, the google search results. We all know that the ranking system for google results is a complex beast, relying on a huge amount of precomputed data, for example, the links between pages. But now, to compute that graph with personalization taken into account? You're probably not calculating all personalization vectors on the fly, but when I go to search for "java" you're also probably not doing a lookup of pre-computed personalized results for "java + userid:camille." Instead, you're applying a "diddle" function to the top set of the overall graph, and showing me the results in the diddled order that makes sense for me.

There are two parts to the concept that make it powerful for me. The first is the idea that you are changing things temporarily. To serve large sets of results fast (or, in the case of google, to be able to function at all), you need to pre-calculate a huge amount of data. You're doing a complex piece of work that takes some time, you don't want to have to redo it for every request. However, you don't want to force yourself to store all the work for all possible scenarios up-front. But, diddling in my mind presents a second element: it is only applied to the set of data within a limited scope. You don't diddle across the entire search index. You diddle the first few results, the ones that matter to the user in question.

There can be a ton of technical complexity to implement such a concept in practice. One immediate challenge is that of "diddling" in such a way as to drop results from the top set, thus requiring a re-querying for additional responses to get enough data to satisfy the user. The purpose of this post is not to go into the technical details of how you might implement such a thing, but to show you that you can reframe your thinking on a problem like this through its phases. Just because you have a list of thousands as your first pass of results doesn't mean you need to personalize across that whole data set to get the best results for the end user. If your goal is to get the most personally relevant of the most generally relevant, you probably want to operate on the top of the generally-ordered list, not necessarily the whole list itself.

There's many ways to attack such problems, and I have no idea how companies like Google solve the challenge of personalizing results under the hood. I do know that, to me, the idea of mixing indexed and computed results in personalized querying is a sticky one, and it's an analogy I use frequently. It helps you remember that there is value in the underlying order of the results as provided by the source of truth, and that personalization is often an enhancement on an underlying set of computed data, not the fundamental computation itself. Pulling out to a larger picture, remember that when your data gets in front of a human end-user, they are going to operate on only the tiny surface area they, as a human, can process at any one time. So in cases where you're serving humans, you can apply different patterns on the fly to the human-visible surface area that would be too expensive to apply to the entire data set at large.