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

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.