The Dangers of Micro-managing

What’s one sure way to get the least out of your team? Micro-manage them. I’ve seen this again and again – Micro-managing, or supplying every little detail and expecting every little comment you make to be executed literally will quickly shut down their brains.

I saw this with one of our consultants. He was working on a project where the manager had very specific, non-explicit requirements for how the solution was implemented. After two or three of his suggestions were shot down, he stopped making them. The funny thing is that his suggestions would have made the product more robust and maintainable. Even more interesting than that, this senior developer started asking me how to implement specific lines of code. I have not coded in 10 years, but I understood why he was asking and what he needed. He wanted to give the customer what they wanted, and knew they had very specific ways they wanted it coded.

Thinking about my own management style, I think I may err too far in the other direction. I’ve been told, more than once, that I have made my directs uncomfortable because I don’t tell them exactly what to do. I do try to make sure they know I have confidence in them, and that I’m there if they have questions, but sometimes it still seems like they’d like very specific direction. My question is: Is this just because they have become used to being micro-managed, or is there a middle ground that I’m missing?

Virtual Development Teams

Sometimes when I read about trends, I wonder if they are “real.” How many people are actually doing it and is it working for them? I am getting to see one trend in action more and more often lately – virtual development teams.

I’m working with a few companies that are completely virtual – no one works in the same physical location. Right now, I’m even looking for a developer to work with one of these teams. One of the many benefits of this arrangement is that we can look anywhere, and I do mean anywhere.

I’ve managed individuals that worked in remote locations, and teams that were in multiple locations, but never a team where no one was co-located. The most interesting thing about this engagement is that the client is ok with not meeting the developer. I’m not sure I would have been but in this case I can see why. They are looking for someone with Open Source experience. They’ll be able to see real code this person has produced, and see how this person interacts with another virtual team. This is so much more revealing than the typical (or even a good) interviewing process.

The broader implications of this are fascinating. Are we really moving towards a true talent market where we can work with the best of the best, from anywhere in the world?

Is your technique working?

I've been working on improving my sales skills, and one thing I've been reading a lot about is “Question Based Selling.” It says, engage your prospect in conversation, earn their trust, and learn about their issues before proposing anything. Makes sense.

So I was at a trade show yesterday, wandering the floor and wandered into a booth and asked the man there to tell me what his company did. He gave me something very vague then asked me a series of questions about my company and past experiences.

I answered quite a few of them before I realized that he either did not understand me or was not listening to me because the follow-on questions did not make sense. I finally asked him again if he could tell me what his company did. He replied again that the did many things, and at this point asked me if it made sense for us to meet and continue talking.

By this time, I was a little annoyed that he would not answer my questions and my first reaction was “no it does not make sense for us to meet.” It was not until later that I realized that he was probably new and probably asking the questions that he had memorized, but the key was, that his technique was not working. I think that’s an important observation whether you’re selling, managing people, or developing software. Know what’s working and what’s not. In order to do this you need to pay attention to the results you’re getting. Even the best technique does not always work and we all need to be flexible. Have plenty of tools in your toolbox, and use them wisely.

Part 2 -- What can you do when a project goes terribly wrong?

In my previous blog I recommended steps to follow and pitfalls to avoid once a project is in trouble. Now that we have a strategy for change and have management buy-in, it is time to take action.

It is best to start by assembling the entire project team and communicating the change strategy. In order to turn-around a failing project effectively you need buy-in from all the team members --- even those not directly involved in implementing the change.

The project plan and schedule needs to be revised and shared with all team members. This is a good time to ask a few questions. Do we have enough or the right resources to move forward? Do we have the right tools? One common outcome I have noticed with projects that get into trouble, is that the original project team did not have the appropriate level of expertise in a new technology. To turn the project around you may need to add a temporary resource with special skills. Find this resource(s) - fast! Get the right tools. Then update the schedule.

Once the Team is assembled, start at the beginning. Review Requirements, Architecture, Design and Test Procedures, in that order. Make necessary modifications before starting development.

As you can see there is a lot of legwork before you can effectively change the course of a project, but you must do it for the project to be successful.

Fear and Loathing in IT

I read an interesting article today on Web 2.0 in the enterprise. I think the author was dead on with this one. Many of the senior IT executives I’ve known fear Web 2.0 technologies. They say it’s all about security, but I think she got the real reason right – it’s about information sharing.

I worked in one organization where there was so much “confidential” information shared at the senior staff meetings that you couldn’t share anything discussed there with your team, for fear of disclosing something you shouldn’t. In fact, most of this information did not need to be confidential, and much of it was already in the rumor mill.

Unfortunately, the problem is not a technology issue – it’s cultural. Hopefully, the author is correct in her assessment that this will start to shift as the generation of workers familiar with IM, Wikis and MySpace enters the workforce. If you ask me, the sooner the better.

As organizations learn to share information freely, they empower their most valuable resource – their people.