One day my staff informed me that I was practicing “seagull management” and it was driving them crazy. “What’s seagull management?” I asked. They explained it’s what happened when I flew in, crapped all over what they were doing, and then flew away again.

At the time, there were four big development projects underway and I was responsible for all of them. So I felt quite justified in giving each of these projects a lot of my personal attention. What I learned though, was that my behavior was counter productive and the best work happened when I gave people clear directions about what they needed to accomplish and then let them figure out for themselves how to get the job done.

Whenever I’d drop in on a project team and start asking what was going on it would take them a while before they could describe to me what they were doing and I got the sense that they were floundering. So I’d start telling them what I thought they should do. Every week and often several times a week, I’d drop in like this. And the more I did it the more strained things became between me and the teams.

Luckily, I also encouraged and respected people’s right to speak up when they had issues and concerns with decisions I made. I also encouraged them to offer their own ideas when they saw a better way to get something done. I still do this, and it has saved me more than once.

It doesn’t mean people can argue endlessly with me or ignore my decisions, but I want to hear peoples’ good ideas and I want to make sure I don’t miss something important and make a dumb move. It can be pretty irritating when someone questions a decision I make and even more irritating when they offer ideas that are actually better than my own.

However, I’d rather be successful than egotistical. So after several frank discussions with my project teams I began to see what they were talking about. I noticed that people who were actually doing the development work usually had better ideas than I did about how to get things done.

I came to see that the tension between me and my development teams was mostly caused by the fact that sometimes I wasn’t real clear about what I wanted done (or sometimes I didn’t even know myself) so the teams would start off in a direction that I didn’t agree with or didn’t understand. Then that triggered me to step in and start micromanaging them.

Here are some lessons I learned from that experience. The first lesson is to be real clear about what I want a team to accomplish. That means a clear description of the system the team is supposed to build and a clear statement of the basic performance requirements, and the budget and the delivery date for the system. Then the team can get to work and fill in the details and figure out how to build such a system.

Another lesson is that I need to have a separate project office in place that gives me accurate and constantly updated project plans and status reports. Good developers working on a fast-paced project don’t have time to constantly update project plans and budgets. But if I don’t get that information on a regular basis then I get nervous and start flying in and asking the team what they are doing. That

You do not have flash or javascript support.

Average (7 votes)

Reply