Balance ? - Managing Status vs. Employee Autonomy

[Craino]

I recently had an employee turn in her resignation. It was not unexpected. One of her main gripes was she thought she was being micro-managed. This was interesting as I thought I was actually giving her a lot of free rein.

A little background. I am a Director in a medium-sized company. I have technical and business responsibilities. I have a small team consisting of an application developer and a systems administrator. It is the developer that resigned.

I got the HR Director involved and we all three had a debrief session that lasted 2 hours. A LOT came out in the session. Basically, this resource's idea of how things should run was:

1) She would completely control the development process from user request, through analysis, design, development and implementation, with no intereaction with me.
2) She would sit on the IT steering committee.
3) Status reporting would consist of a brief, informal update no more than once a month.
4) Formal project plans were her domain and didn't need to be reviewed by me.
5) Formal status reporting, with weekly status updates and ETC's were not required. If she said it would be done in 6 weeks, I didn't need any updates. I just mark the calendar and that's when it was done.

I hope it's obvious that a Manager can't effectively run a department in the scenario this resource was looking for. But it got me thinking... What is the right balance of trust and autonomy vs. management and reporting. Ultimately if something doesn't go in as promised it's my butt that gets kicked; on the other hand, I can't be so metric-oriented that people feel like there aren't trusted.

Another dynamic is that everyone assimilates information in different ways. For some, informal conversations every once in a while suffice. For me, I need to see concise (i.e. one page) status and issue snapshots on a frequent basis. Aren't I allowed to run my department how best suits me?

I'm just curious what thoughts the rest of you have...

 

[flapeyre]

I think that the person you mention had unrealistic expectations. You can't have the inmates running the asylum like that.

I have worked at a place where everyone was micro-managed (I was once told, down to the last detail, how a new application should be written, right down to the field names they wanted used in the work files!) I obseved to some colleagues, that the co-star of Tarzan of the Apes (the chimp, not Jane) could accomplish that goal.

Here is what it's like where I work now:

Let's say I am assigned a task. If there is a hard and fast deadline (usually there is not), I am told up-front. For the really big projects, we may have a meeting or two with the users (more often than not, it's done with e-mail communication). My supervisor doesn't want to be innundated with non-essential details, but does want to be kept informed as to what's going on. She will stop by everybody's cube every other day or so and ask how things are going. Every so often, we will have a lunchtime team meeting, and we all share what we've been working on.

Also, the next levels-up in management are not generally interested in the project details (at least, not from me). They are only interested in results. And we give them that.

You can run your department the way you see fit, however, speaking as a worker bee, if we are not given justification for some things that might seem perfectly reasonable to you, as a manager, but not to us, as workers, you can expect some friction.

Of course, a lot depends on how much your manager expects of you. But if you establish some general guidelines without getting too specific and detail oriented, I think you will be rewarded with a happier and more productive team.


"When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return."

--Leonardo da Vinci

 

[Provogeek]

I'm not in mangment, just a monkey reporting to the boss man, but it sounds like you had an unreasonable employee.

1) She would completely control the development process from user request, through analysis, design, development and implementation, with no intereaction with me.

She would dig her own grave if this actually happend. When I worked in development, I was the buffer between the developers and the users. The developers were very talented, and really got tired of dealing with some of the users unreasonable requests. So my job was formed to verify these requests were do able or verify if the bug was real or not. IMO leaving a single developer in total control with out any interaction from managment would be a mistake. You may not personally know all the technical details, but you know the upper managment better that he developer, so you also know what the expectations are of upper managment better than this developer.

2) She would sit on the IT steering committee.

This would be a good idea, but only for information, but only have input on areas that directly affect her job. Your admin should have some control over the direction IT goes, but ultimitly, it's managments choice, bad or good, us monkeys just have to deal. It is in managment's best interest to listen to your admin.

3) Status reporting would consist of a brief, informal update no more than once a month.

This is obserd and out of line. If it was only once a month, then the report should be formal. In my experience, I had to provide daily informal reports to my direct supervisor, weekly informal reports that went to my groups director, then, if I was working with an important client, a monthly formal report that went to the department VP.

4) Formal project plans were her domain and didn't need to be reviewed by me.

Now this is utter BS. All project plans should be reviewed by a second set of eyes, and those eye normally belong to the direct supervisor.

5) Formal status reporting, with weekly status updates and ETC's were not required. If she said it would be done in 6 weeks, I didn't need any updates. I just mark the calendar and that's when it was done.

This would only work if no one asked you how the project was going. It makes managers look bad when they don't know what their emploeeys are doing. I personally have three issues that would cause me to loose all respect for my manager and the first would be ignorace. My manager needs to know what I am doing so he does not over load me with to many projects. When a sales rep asks him who is avilable to take a project, he could assign it to me not knowing I was already booked with 3 other network design projects due in 6 weeks, adding another one would cause me to miss dead lines.

The other two items that loose it for managers in my eyes are ones that arguse with other company managers in plain view and hearing of any company employees out side of managment. The third is a manger that yells or diciplins employees in the open. Both those issues should be behind closed doors, and stay there.

Brent Schmidt CNE,Network +

 

[DonQuichote]

I think there is enough room between your vision and hers.

1) She would completely control the development process from user request, through analysis, design, development and implementation, with no intereaction with me.

I smell there is more to it than that. There is the eternal customer-programmer-problem: The customer does not know much about the possibilities and impossibilities of a program and the programmer does not know much of the process that is to be automated. If a working solution is to be made, communication is really essential. Actually, there is a growing tendency to involve programmers in more than just typing. See, for instance,

http://www.xprogramming.com/xpmag/whatisxp.htm#planning

However, you are to be present or at least informed. Especially with the user request. I think you have more power to keep a user from requesting the impossible than a programmer does. And, after all, you are responsible for the work at your department. But a programmer is responsible for his/her job as well, and needs some "space" to work.

2) She would sit on the IT steering committee.

Same smell as above.

3) Status reporting would consist of a brief, informal update no more than once a month.

Informal: yes, please. No more than once month: No!
If you have a separate room, it might be worth a try to have all members of the department in the same room. Separate rooms tend to create a "us vs. them" situation. Even if your door is always open. Informal communication every day is the best thing you can have, I think.

4) Formal project plans were her domain and didn't need to be reviewed by me.

If you don't use the plans to "nail" someone to it, but just to order your thoughts, it is wise to have the plans reviewed. It does not matter very much by whom. (did you know that even explaining a plan to a plant in your room may give you more insight?)

5) Formal status reporting, with weekly status updates and ETC's were not required. If she said it would be done in 6 weeks, I didn't need any updates. I just mark the calendar and that's when it was done.

Same as number 3. Keep things as informal as possible. But be informed. After all, when things go wrong, you are the person to help (by hiring extra people, for instance). The sooner you and the customer know, the better.

Just my view as a programmer.

Best regards

 

[chiph]

This person was obviously on the unrealistic side -- for a medium to large company. However, this sort of activity goes on all the time in a start-up, where you've got 4 or 5 people, and you're very close to the customer.

Different people require different levels of supervision -- some are very good - you just give them some specs and they come back with a completed project. Others need a little more feedback and guidance. That's sort of a trap a lot of software shops fall into - assuming people are replaceable cogs in the machine.

Chip H.

 

[KenCunningham]

A small thought. Categorising a person as a 'resource' doesn't, in my opinion, bode well for that person's stature or feeling of belonging in an organisation.

 

[dwarfthrower]

Haven't you been 'barcoded' yet Ken?

 

[Craino]

Just a quick followup to Ken and Dwarf's comments. I realize many folks react negatively to the term "resource" as very impersonal and disrespectful.

It certainly wasn't meant with disrespect. It was meant somewhat impersonal as I was trying my best to phrase my questions objectively, without mentioning names or genders of the other person involved.

 

[dwarfthrower]

No sweat mate, I was just being tongue in cheek. From an organisational point of view it only makes sense to view employees as resources. Although, as you mentioned, some sensitive types do get a little riled by the term. I'm of the opinion that when employees start getting their backs up about little stuff like being called a "resource" (which is precisely what they are) it's probably symptomatic of a deeper rift within the organisation.

 

[KenCunningham]

Sensitive, moi? Doesn't sound like me, mate! Seriously, I was probably being somewhat overly touchy when I wrote that. Haven't been bar-coded yet, but the tattoo is starting to wear off!