Your Job is NOT Telling People What To Do

with 15 comments

This post is part of my series on Managing Developers – How not to suck

I’ve had many people tell me they would like to be a manager. The first question I ask is ‘why’? The absolute worst answer is any variant of ‘Because I want to tell people what to do’. Any thing remotely like this is the wrong answer. These people are not ready to be managers – they are far from ready. Organizations that make people like this managers are making a huge mistake.

Much of your job as a manager is to enable your team. You are paying them to think, solve problems and get stuff done on time. Let them do it. Your job is not telling people what to do.

Enabling your team means setting them up for success, making sure they do their best work with good continuity over time, not just at crunch time, or ‘when it counts’. If you are thinking, "Yes! A managers job is to make people do their best work." Then you are not understanding this advice.

Merriam Webster defines enable like this:

  • to render able as in enable a person to
  • give power, strength, or competency to
  • to make possible, practical, or easy
  • to give the opportunity to

The term make is defined like this:

  • to cause to act in a certain way. To compel

Making people do things is telling them what to do. Enabling them is an entirely different thing. There are lots of ways to do this. I cover some of them in this series of posts. Here are a few in no particular order

  • Don’t forget what its like to be an individual contributor (post)
  • All developers shall have good equipment (post)
  • Don’t treat people fungibly (post)
  • Know when to shut up and just listen.
  • Depending on Heroics is "Epic Fail"
  • Praise in public, criticize in private
  • Make sure people know what to accomplish, by when and what ‘done’ looks like
  • Be your team’s champion, not their defender

This may not sound too hard. But let me make it harder – you can’t do this sometimes, like just at crunch time, or just when the bug count is high, or when the requirements change. Your job is to help your people deliver their best work all the time. It sounds impossible, but the closer you come, the better it is for everyone.

Now, this doesn’t mean you can avoid making decisions.  Part of your job is defining constraints, specifying requirements, setting expectations and defining direction. 

You will also sometimes need to be directive or proscriptive.   Yes, you will sometimes need to tell people what to do. But remember, there is a big difference between reluctantly doing this when necessary, and with good reason and explanation – and being a tin pot dictator.

Here is what I’d like you to remember. If you feel your role is to help your team, you are on the right track. If you feel a visceral need to order people about, then you will suck as a manager – not matter how good you are at everything else.



Written by foredecker

March 13, 2011 at 8:12 pm

15 Responses

Subscribe to comments with RSS.

  1. I appreciate what this article is talking about and from this summary article it sounds as though I’d agree with you on the rest.

    I would just like to note that your tone in some parts of this is not helping make a case to anyone who does not already know this information.

    “This post is part of my series on Managing Developers – How not to suck”
    “If you feel a visceral need to order people about, then you will suck as a manager”

    Statements like those are non constructive and if your goal is to make people better managers you may want to rewrite them to be positive and helpful instead of negative and finite.


    March 14, 2011 at 5:45 am

    • I’d like to add that my above comments were my initial reaction, which is why I posted it to let you know. Overall I think the information you provide here is invaluable.


      March 14, 2011 at 6:24 am

      • I think you over-thought it. That sort of sensitivity about everyone else’s opinion won’t do a lot to help get the posts read, and the message dies because of yet another dry, boring, reasonable yet completely humdrum lecture on the topic.


        March 18, 2011 at 3:56 am

  2. I look forward to your post, “Depending on Heroics is Epic Fail”. I agree.

    The manager who depends on heroic efforts is like the always-late guy. The always-late guy is the person who judges transportation time based on his personal best. Once, he caught all the trains with no transfers and made it to the weekly 11:00 am brunch in 20 minutes. In his mind that’s how long it should take. So he leaves at 10:40 every morning and usually shows up at 11:15. The manager who depends on heroics is, analogously, the one who remembers that one time he got his team to work 120 hours in the final week to pull something off– and either (1) wants to relive it, out of some bizarre machismo and the tendency of an adrenaline-fueled brain to “write” good memories despite suffering– this is the neurological reason for people to remember their crunch-time heroics with nostalgia– or (2) at least, thinks its possible. 22-year-olds with no obligations and no prior work experience will do 120; real people generally don’t.

    If I were a manager, I’d set a 25 hour per week core time, 10:30 to 3:30, with the expectation that lunches usually be spent with co-workers (if people wanted to run occasional errands, that’s fine; but lunch is when people share ideas and cross-pollination happens). I’d make it very clear that I expected a 2000-hour work-year (not enforced to the letter, but I’d expect people to follow it in spirit) but that, during low-stress times, people could read programming books or do side projects and call it work. During real crunch times that called for it, of course, I’d expect singular, 60-hour-per-week effort. The price of high autonomy is defending the fort when in a pinch. Then in the week or two after the crunch, going back to 35-40 hour weeks with light work (reading technical books, “20% time” side projects) would be allowed, if not mandatory.

    If you run people at 50+ hours per week, with low autonomy and in a sense of constant urgency, when things aren’t actually urgent, then you don’t have legroom when real urgency occurs. It’s “The Boy Who Cried Wolf”. The problem is that mediocre managers (most of them, that is) always say things are “urgent” because they think it’s a magic word that makes people work harder. You know how unskilled programmers have a tendency to use “magic incantations” without knowing what they really mean, like inlining “always” making the code go fast? (It doesn’t, and compilers are generally better judges of when to inline and when not.) It’s the exact same thing.

    I actually don’t think middle managers are to blame for this culture. Their bosses are breathing down their necks, so they merely conduct it. The problem is that Americans associate type-A, borderline abusive (“tough love”) types with leadership, which is actually counterproductive because those people are toxic. You need people who *can* become tough, decisive leaders when necessary, but who have the wisdom to judge when that behavior is required and when it’s not– usually, it’s not– and also the humility to apologize for their effects on others when they do have to decide against their subordinates’ interests.


    March 14, 2011 at 7:40 am

    • The only one comment that was true to the core is quote” If I were a manager”. Working on a 25 hour week is totally unrealistic and if you know people then this is how they see things. People who come into work will look at the clock and count when their first break will be. So, if the break is at 10:30am they will generally finish about 5 or 10 minutes before the stated time so on and so forth. Maybe even a toilet break before they go on break ext. You push for 25 hour week then productivity wise they will go for less. If you push for more hours then productivity wise will be more. This is a basic human nature and we all do it, including managers??????


      August 26, 2011 at 4:37 am

      • That’s a pretty bleak view of humanity: some people actually care about their responsibilities.


        August 26, 2011 at 4:43 am

  3. How does this work when you are tasked to change the culture and environment of a development team? Perhaps this team doesn’t know current of a current engineering technique that could help on a project- such as test driven development?

    I don’t disagree with the sentiment of this post, and for the post part, I agree. But perhaps missing is the concept of “enabling better project execution”


    March 14, 2011 at 8:29 am

  4. I just wanted to take a minute to say how much I enjoyed reading some of your posts… I recently started my blog and my inspiration was a night attempting to find “business blogs” with great content. As I am sure you know, most blogs of this nature get bogged down with entirely too much technical content… I felt that your material has much more of a personal approach as well as providing the necessary technical language… Thank you for posting quality material, I look forward to reading more.



    March 14, 2011 at 11:58 am

  5. Though I overall agree with idea of the what is presented in the post, I disagree with directly going by what someone says is their reason to be the manager. Sometimes people don’t give too much though to what they say and say things in the spur of the moment. Usually when someone desires to be the manager of a team, they already have a strong motivation to be the manager, but it is your job to then figure out if they will be fit for the position (as per the idea of your article indicating what a manager’s role is) rather than to go by what they claim to be their motivation (because they just might’ve read your article and claim just the right things that align with your perception ;-)).


    March 14, 2011 at 1:29 pm

  6. […] Your Job is NOT Telling People What To Do This post is part of my series on Managing Developers – How not to suck […]

  7. I like manage and manage is like. Like to be managed is different from like manage which is unlike like manage.

    Friden Machin

    March 15, 2011 at 3:00 am

  8. The veracity of this statement depends *entirely* upon the people involved. Sometimes it *is* my job to tell people what to do. Sometimes it’s my job to tell them *how* to do it. Sometimes it’s to explain what needs to be done and let them do the rest. Sometimes it’s just to point them in the right direction.

    There is *no* “Maxim of Management” that fits all people in all situations.


    March 15, 2011 at 9:26 am

    • I completely agree. You are right that mangers somtimes need to tell people what to do. My poitn is that if that’s why someone wants to become a manger then they are not ready. Its also not a mangers primary job. I belive that very little of a good mangers time is spent telling people what to do – ordering them about as some might say.


      March 15, 2011 at 12:03 pm

      • Ah, gotcha–yeah, that’d be a bad reason 🙂


        March 15, 2011 at 5:11 pm

  9. […] Your Job is NOT Telling People What To Do […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: