Foredecker

Jibe!

The word you are looking for is “People”…

with 6 comments

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

My wife says I have too many pet peeves. Oh well, we all have our crosses to bear. One of my peeves is calling people ‘resources’. Managers do this all the time: “How many resources will project banana need ?”, “Our resources are all subscribed.”, “Our team doesn’t have enough resources to do any additional work”.

Resources are ‘things’, including computers, tables, chairs, graphics cards, solid state disk drives, the lab. Money, and time can be resources too, but are important enough to treat separately.

Short story: people are not resources. Don’t ever forget that the people that you mange are people, not resources.

Treating people as ‘resources’ leads to all kinds of manger mistakes. The biggest sin is assuming people are fungible. We all know this isn’t true; developers (people) have a wide range of skills, aptitudes, aspirations, and experiences: people vary – wildly – in many dimensions. This means they cannot all be assigned the same tasks while expecting the same results.

Of course, we expect all developers to share some basic skills; using the source code control system; building the code; using the debugger; etc. It is also fair to expect more from more senior developers; sometimes this is more work, or the ability to solve tougher problems, or to be responsible for more code, or drive things in broader ways. We also often expect more senior people to provide more leadership.

But beyond the fundamental expectations, developers are almost always very different. They are almost never interchangeable and – most importantly – given the same task, will almost never solve problems the same way, write the same code, or otherwise do things the same.

One thing a good manger spends time on is assigning the right work to the right people. Treating people fungibley screws this up. You can’t just smear work around like peanut butter on a bunch of crackers and assume it will all be done well.

Work to understand the people on your team: read their old reviews; talk to them; understand what motivates them. Learn what they find interesting and challenging. Observe what they do well, where they struggle. Understand their experiences and where have they had successes and failures. Ask them where have they struggled and where they feel they can grow. Understand how they best like to hear constructive feedback. To the extent possible, make sure you have well matched the task to the person.

If you understand your team as people, then you can more effectively help them do their best work with good continuity over time. This is 80% of your job.

Don’t treat people as resources – that sucks.

-Foredecker

Advertisements

Written by foredecker

March 5, 2011 at 1:48 pm

Posted in Managing Developers, Uncategorized

Tagged with

6 Responses

Subscribe to comments with RSS.

  1. This is definitely my pet peeve at work too. My favourite manager I ever worked for did just one thing right, she got to know her team’s strengths and weaknesses – the difference in output was so dramatic I’m constantly surprised how many people seem to fail at this.

    Tom

    March 8, 2011 at 3:45 am

  2. […] Don’t treat people fungibly (post) […]

  3. How do you deal with the ‘bus factor’ following this approach, especially in small teams? Also, how far does one go in defining what you consider ‘fundamental expectations’ – i.e. would you consider the ability to work on any aspect of an application a fundamental expectation?

    I’m curious because our team is currently debating whether we should be growing by employing people who enjoy the generalised, full-stack development approach or who like to really specialise in things.

    Roland

    March 14, 2011 at 3:32 am

  4. Amen to that

    Paul

    March 14, 2011 at 10:09 am

  5. You still have some ‘mange’ and ‘mangers’ all over this series… It’s still a nice read, though.

    Joachim Schipper

    March 14, 2011 at 11:03 am

  6. You know, after reading this series of articles, I’m wondering how many companies do this right. (I’m a Senior in a CS Undergrad program) – I wonder what the “my company is awful and runs devs wrong” : “everything’s fine so I’ll not blog about this” ratio is.

    Zacharias

    April 2, 2011 at 8:32 am


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: