The word you are looking for is “People”…

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

About these ads