You are here: Home / 2012 / Archives for February 2012

Managing Up vs. Sucking Up

February 27, 2012 by Leave a Comment

“Managing up” has a bad reputation – it’s often seen as a synonym for sucking up.  Isn’t it a waste of time that could have been used productively to move the team forward?  I disagree.  If you have a manager, managing up is part of your job.  And it should be.

Why Bother?

Let’s think for a minute about what a manager is supposed to do.  Among other things, they should

  • Have a clue about what you are doing and help, as appropriate (and no more than appropriate)
  • Backstop you to make sure your projects aren’t going off the rails
  • Manage up to their manager
  • Advocate and scout on your behalf
  • Understand key risks the team faces and make sure they are being managed
  • Give you guidance and hold you accountable

Now how are they supposed to do all that, if they don’t get any information flow from you?  If you’ve ever managed somebody, you may have discovered that mostly you have no idea what they do all day long.  This plays into one of the things I’ve noticed, which is that people often become easier to manage after they become a manager.

Many people push back on this idea of managing up.  They might object that

  • My accomplishments should speak for themselves, right?  Well, no.  Most managers see a tiny fraction of what you do.  They often can’t tell how much of the outcome you were responsible for.  And, they (should) care not just about what you achieve, but how.
  • Isn’t this overhead that makes us less efficient?  Yes.  Tough.  Part of the reality of being in a team is that it takes overhead to get groups of people to work well together.  Get over it.
  • Isn’t this a disguised name for sucking up?  Sometimes.  Stay tuned.

Ways to Screw This Up

From what I’ve seen, a lot of people aren’t very good at managing up.  They tend to fall into one of two traps:

  • Refusal to engage.  “I shouldn’t have to manage up – my work should speak for itself.”  If your manager is basically engaged in the same activity that you are, this may in fact be true – say your manager is a lead programmer who is in the codebase with you all day long.  But if your manager is not deeply and directly involved in your work, this is probably not going to work out well for you.  By failing to manage up, leaving your management chain in the dark, you are hurting the team and hurting yourself.  You are sabotaging your manager’s ability to do their job well.  If you hear phrases from your manager like “I feel out of the loop” or “I don’t have good visibility into this project” or “where did <this disaster> come from – I thought we were on track”, then you are probably failing to manage up well enough.
  • Looking like a suck up.  Managers vary a lot in their ability and desire to discourage this kind of behavior.  They are never as immune as they think, but even the lame ones can tell if you are really obvious about it.  Once they decide that you are a suck-up, they won’t trust what you tell them.   Your peers are also very good at sniffing it out .. and they won’t like you better for it.  Two quick tests to check yourself:
    • Are you reporting at least as much bad news as good?  If so, you are much less likely to be seen as a suck-up.  Don’t spend your “manage up” time taking victory laps.
    • Are you talking about other people’s accomplishments more often than your own?  That’s another good antidote.

When you bring bad news to your manager, they will often be inclined to start trying to fix it (with or without you).  If you want help, then that’s just what you were hoping for.  But often, you don’t want help.  You own the problem, you are on it, and you are just keeping your manager informed.  So make sure that you are clear when reporting a problem whether you want help.

Food for Thought

Here are some principles that I have found helpful:

  • Managing up is part of your job – help your manager be effective in doing their job
  • Be transparent: bad news is the news they have to have.  Don’t sandbag your management chain – they hate that.
  • Be very explicit in your own mind and with your manager whether you want help with a problem that you are reporting
  • Shine the light on others more often than yourself
  • Figure out how your manager likes to be kept in the loop – it varies a lot depending on the person

Are you doing this part of your job well?  What’s worked for you?

Filed Under: 1x, Managing People Tagged With: ,

The Sacredness of Ownership

February 24, 2012 by 1 Comment

sa·cred (sā′krid) – secured as by a religious feeling or sense of justice against any defamation, violation, or intrusion; inviolate

The word “sacred” is not one to be used lightly, but I chose it on purpose to talk about a principle I believe is at the heart of any healthy team culture: ownership.  I’ve spent most of my career building large scale software projects, and these are intensely complex systems.  No one person can understand all that complexity and track all the infinite detail of a large-scale project.  And it only takes one person writing a few lines of sloppy code to introduce a security hole that can cause tremendous damage to your customers and to your company.  The success of the whole venture rests on the decisions that the people at the front lines of the team are making every day.  So they’d better feel like they own their work, and they’d better be right!

What It Means to “Own” Something

Does “owning” something mean you get to do whatever you want with it?  No.  In defining ownership, many people focus on making decisions, which is important.  But to me, the most important thing about being an owner is that you are accountable for the success of what you own.  Therefore, the first and most important thing that an owner should do is to define success.  This sounds easy, but it isn’t, and many people do this wrong.  If you are a developer and own a feature, success doesn’t mean that you wrote good code and checked it in.  Success means that the whole feature team understands the feature and why it is needed, you coded it, you nailed the basics like performance and security, it works well, it shipped, and many happy customers are using it to solve real needs that they have.  A good owner defines success in terms of impact, not activity.  They include key stakeholders.  They feel accountable for the whole success, not a narrow part of it.

It is very tempting to define success in terms of what you control.  This is a classic mistake that people make, especially when they are early in their career.  They only feel accountable for the part they fully control.  “But I’m the developer .. isn’t it enough that I write great code that works?”  NO.  The customer does not care if you wrote good code.  The customer cares if you solved their problem.  Shareholders don’t care if you wrote good code.  They care if customers love the product and buy a lot of it.  You need to feel accountable for the whole success, even though you almost certainly don’t control it.  If you did everything right that you control, and the feature fails to be successfully used by many happy customers, then you failed.  The reason this is so important is that people generally try very hard to succeed.  If you define success broadly, you won’t settle for the excuse that “my part works – it was the other bonehead who blew it”.  You’ll go the extra mile, you’ll escalate if somebody else is screwing up and taking the whole ship down.  It doesn’t matter how beautifully you polished the handrail on the Titanic.  You still drowned.

Decision Making and Overlapping Ownership

One thing that’s confusing about ownership is that multiple people can seemingly own the same thing.  For example, the people designing a product and the engineering team that builds it all need to own what they work on.  Doesn’t that violate the whole idea of ownership?  No, if you internalize the accountability model.  All of the groups contributing must feel accountable for the whole success of their work.

Great, but then how do decisions get made?  The answer is that it depends what you are deciding.  For example, the ultimate decision maker about the way to code a feature better be the developer.  But there are other stakeholders – developers might have to do a code review with their lead or a fellow developer.  They might need to follow development guidelines set up by the development manager, so other people can understand the code and it fits in with the rest of the system.  The designer needs the feature to actually meet the user’s needs.  The developer still owns the code and is accountable for its success, but they must honor the (legitimate!) roles of other people in achieving that success.

Stakeholders

Let’s say you are the owner and hence the decision maker.  One of your responsibilities as owner is to understand who else has a stake in the decisions you are making and what their role is.  Sometimes this is obvious, or you can just use intuition and it all works out.  That’s often the case in small teams.  But as you own more important and complicated things and are part of larger organizations, you will run into the limits of the ad hoc approach.  That’s when it becomes useful to think explicitly about the other stakeholders and their roles.

Once upon a time, the Windows team realized that decision-making was a mess – people weren’t sure whom they had to consult, who was the butt on the line for key decisions, etc.  And so things fell through the cracks or there was gridlock, and accountability was lacking.  As a result, they created a role/stakeholder model that has been used with a lot of success at Microsoft (called OARP).  There are industry equivalents (a popular one is called RACI) – which one you pick isn’t that important.  The key thing is to be explicit about the roles in a particular decision and make sure everyone understands what their role is.  Writing this down will often reveal misunderstandings (“what do you mean I don’t get to review the decision before it is finalized??!!!”) and problems (“we have to review this with twenty people before we lock the decision down?  That’s not going to work.”).  In general, the owner’s life and the team’s efficiency will improve radically as you reduce the number of reviewers, approvers, and other obstacles to progress.

Dealing With Misbehaving Stakeholders

Just because you have done a great job defining the ownership model and gotten everyone to understand it and agree to it in theory doesn’t mean that’s actually how things are going to work out.  People will frequently violate their role, often through the best of intentions.  Maybe your lead says you are the owner but they don’t respect your ownership and are always micromanaging you or giving direction to your team without including you in the conversation.  Maybe people elsewhere in the organization who are supposed to review decisions start turning into participants or are making decisions on your behalf.  And so forth – the opportunities for misbehavior are legion.  Sometimes they happen because people are too eager to help, often because people are being thoughtless, and sometimes from malice.

Your responsibility as the owner is to treat these as problems and get them fixed.  That super-helpful senior manager who comes down and straightens things out for you without you asking for help?  Problem.  Either you blew it, or that very helpful manager did, or you both did.  The participant who thinks you are blowing it as an owner and second guesses your decisions without confronting you about it?  Problem.

If someone in your management chain comes in and starts proclaiming this and that, there are two common reactions: 1) denial/rejection/anger and 2) “yes, sir, thank you”.  Both are wrong.  The right response from the owner is “good input, thanks”.  Then YOU go take action.  Don’t ignore what the manager thinks.  Sometimes they are giving you new data, sometimes advice (hopefully good).  Sometimes you are screwing up and they feel a need to jump in.  But if you are going to be a good owner, then you have to get the dynamics right.  You own the decision until ownership is taken away.  That should always be an explicit act – you might ask the manager to take over, they might inform you that they are taking over; that can be the right thing, but it is a very important change in the state of the project.  If ownership is leaving you and going somewhere else, you are no longer accountable for success.  That’s a big deal, and everyone needs to be clear about it.  You don’t have the right to demand to stay on as owner if your manager becomes convinced that you are not up to it.  You do have the right to demand clarity.

Final Thoughts

In my opinion, ownership is a crucial tenet of a healthy team culture.  How to take action on it?

  1. Figure out what you own.  Make sure everyone (including your manager) agrees.
  2. Define success.  Don’t be narrow.
  3. Figure out who the stakeholders are and respect their role.
  4. Go own the hell out of it.  Everyone is depending on you to get it right.
Filed Under: 1000x, 100x, 10x, 1x, Managing People Tagged With: , ,

What’s the Dimwit Duration On Your Team?

February 20, 2012 by Leave a Comment

One of the sad realities of life in a team is that decisions often become stupider as they filter their way from the decision maker to the place where they get implemented.  Over and over, I’ve seen something that started out as a rational and well-intentioned idea become twisted into something pointless or annoying or awful as it percolates its way through an organization.  If you are the one at the end of that process, it can be really hard to believe that it ever started out as even vaguely rational.  Why does this happen?

Decision “Telephone”

Well, one problem is that the person implementing the decision often doesn’t really understand the original idea.  You’ve probably played “telephone” as a kid – take a phrase and pass it by word of mouth down a line of people.  At the end, the result is revealed to much hilarity since it never even resembles how it started out.  Well, that’s what happens to decisions – their basic shape might make it down, if you are lucky, but the context and the rationale for it are often mangled beyond recognition.  This is just a fact of life about people – they are a very lossy channel for communication – and it isn’t fixable.

Decision Combinatorics 

The other problem is that a single decision will often end up getting applied in a lot of places to a lot of people, and the person who made it doesn’t always have a clue about them all.  And, multiple decisions, each of which may make a lot of sense in isolation, combine into a mess.  For example, “we won’t push out an update to our web site until we run our test passes on it.”  And, “our test passes will try out all the different browsers that people are commonly using.”  Result: the site is down for hours because you can’t push an update that is a tiny little tweak to a configuration setting.

Can Rationality Prevail?

You can try to counteract these problems by having rational people at the tip of the spear who apply the decision with flexibility and humor.  That way, something that becomes completely impractical is not rammed down the throats of the team.  It is very hard to create a culture at scale that works this way; it is just a lot easier to be rigid than to be thoughtful, and people are inclined to be lazy.  Also, someone is much less likely to get into trouble for applying a policy than for setting it aside, and many people are very risk averse.

By all means, try to do this .. but don’t be surprised if it fails a lot.

Enter the Dimwit Duration

The only real cure I’ve ever seen for the bad decisions that slip through is to minimize what I call the “dimwit duration”.  This is the period of time that the stupid implementation of a decision stands, before somebody with the power to undo it finds out and can fix it.  Now a lot of factors play into this:

  • How often the decision maker meets and talks to the people who implement their ideas
  • How much power and authority is pushed down the organization
  • How detail-oriented and open-minded the decision makers are about what’s really going on
  • How egregious the decision is and how many people are affected
  • Where the team falls on the culture spectrum between “ruthless candor” and “sir, yes sir”.

The size of the team also has a lot to do with it – it’s one of the many reasons that I like smaller teams, where the doers and the leaders bump into each other often and know each other well enough to be honest.  In many large organizations, they never really do meet, and bad decisions can persist forever.  People can fall into a sense of despair that sanity will prevail, and you get the kind of bureaucratic inertia that Kafka satirized so effectively, with everybody just marching along.

What’s the Dimwit Duration on your team, and what are you doing to shorten it?

Filed Under: 1000x, 100x Tagged With:

100x – Primal Sweet Spot

February 20, 2012 by Leave a Comment

I’ve always loved being part of teams that are around 100 people.  For years, this was the classic size of a product unit at Microsoft – if you were in one that ran well, it was great.  The team had enough people to really get something done – most of the medium sized products at the company used to be created and built by teams around this size.  Everyone pretty much knew everybody else.  And everyone knew how to get any decision landed – you could always go to the person running the product unit and they could make the call.  You ran into that person pretty often since everyone was physically pretty close together.  The second startup I was in grew to be about this size, and it felt really good in terms of getting things done.

I watched Microsoft evolve from these kinds of teams to much larger ones, and I saw how hard it was to make those larger teams move with the same kind of speed and conviction that product units used to have.  I was moved to do a little research, and was intrigued to find that 100 seems to be a sweet spot generally for primates.  Pre-industrial human tribes were (and are) often around this size.  In visiting Africa, I noticed that baboon tribes commonly have 50-100 individuals, and some poking around on the web confirmed that this is true of other tribal primates like chimpanzees.  Because clan-based primates are intensely status-conscious social creatures, we want to be and to feel connected to the social structure that we inhabit.  Without any technology for communicating further than voice can reach, the status structure of the organization is dependent on personal interaction.  Individuals want to know how they are connected to each other and to feel a sense of membership, and direct physical interaction is a key part of that feeling.  We like to think we have evolved unrecognizably from our origins, but there is a mountain of evidence showing how deeply those early evolutionary experiences continue to shape our behavior today.

Recently, I discovered that there has been some research that supports this idea – there is a concept called “Dunbar’s number” that shows the cognitive limit on the number of people that somebody can have a stable relationship with.  150 is a common number that people have proposed for it.

What it all boils down to for me is that I really like being part of a team this size.  This section talks about ways to make them run effectively.  Have you found this to be a sweet spot for you, too?

Filed Under: 100x Tagged With: ,

1000x – The Challenges of Scale

February 20, 2012 by Leave a Comment

When teams get this large, some good things happen, but a lot of bad ones do, too.  Along with an incredible amount of potential horsepower to harness, you just entered Dilbert country.  If you are helping to run the team, you just became the pointy-haired boss.  Yup, that’s you in the mirror – smile!

The biggest problem with teams this large is that there is spotty at best contact between the people who are doing the work on the ground and the people who are making the key decisions that affect the whole team.  Human connections just don’t scale to this size – if you did a one hour 1:1 with everyone on the team for 40 hours every week, you could only talk to everyone once a year .. and you wouldn’t get much else done.  In another post, I talked about the “dimwit duration” – how long it takes for a decision that has become stupid to make its way from the point of stupidity (the person affected) to the decision maker who can fix it.  That duration, for a lot of decisions, just went to infinity.

Some other things that tend to happen:

  • The people “in charge” have lost their connection with what’s really going on .. but don’t realize it.  To quote Will Rogers, “Ignorance is not the problem in the world. It’s the things people ‘know’ that aren’t so.”
  • There is a lot of structure that can become rigid and calcifying.  Business reviews, corporate policies, complex approval processes, etc.
  • There are many stakeholders for every decision.  A pipe is leaking; in a small team, somebody slaps some duct tape on it.  On a big team, there is the person who represents the maintenance department.  There is the person who manages liability – maybe there is a health issue caused by the pipe?  There are representatives from the teams affected by the leaky pipe.  Somebody is responsible for the budget – how much will it cost to fix the pipe?  There is the decision maker who can actually approve a new course of action – they have to be pretty senior because they have to be seen as an authority figure by all the different stakeholders.  And they are really busy, so you can’t get on their calendar for a meeting until next month.  Decision making slows to a crawl, even for relatively trivial things .. and making a truly major shift in the direction of the team is like turning an oil tanker.
  • People become abstractions.  Part of the nature of the beast if you run teams at this scale, is that you have to do things that affect the whole team.  You manage the budget, you manage staffing levels, you build review models, etc.  And the actual human beings in all their messy individuality tend to turn into numbers in a spreadsheet.  It’s hard to remember how much impact a decision has on real actual people.  I minored in military history when I was in college, and the same thing happens when you study strategy – the people who are suffering and fighting and dying become chess pieces on a board.  But much of what makes a team successful is not the grand strategy and the spreadsheet wizardry, it’s the organic minutiae of execution.

In this section, we’ll talk about what you can do to keep your hair from getting too pointy – if you wear a cool hat and a funky T-shirt, maybe not too many people will notice.

Filed Under: 1000x Tagged With: ,
%d bloggers like this: