To Delegate or Not To Delegate

This week I want a personal road to talk a little about delegation.  Specifically delegation related to managing your team at work. Five years ago, I was given the responsibility of a small team to develop a new portal for our organization using SharePoint.  SharePoint was a new tool for all of us and we spent much of the first year just learning how the platform worked.  To make matters more challenging, much of our team was new not only to SharePoint, but they were also new to our organization.  I had no senior leads to help work with them.  (I still don’t.)  It was very much the blind leading the vision impaired.  Somehow, we made it through the early years deploying our Internet, intranet, school public-facing sites, and most recently collaboration.  While we had some consultant help for the first 6 months, we have been on our own since the summer of 2007 to the point where now we support over 4300 sites.  We did some things right and some things wrong, but overall, I proud of what our team has accomplished.

With that said, the hardest thing for me to learn as I moved into management was to delegate more and more of the work to my team.  I was use to being solely responsible for the tasks given to me.  I don’t think that is anything unusual.  In fact, I suspect that most programmers need to feel in control of the work they are responsible for.  Giving up some of the control is hard.  On the other hand, it is the only way to get major projects done.  So here are some of the ‘secrets’ I’ve learned over the years.

Keep your entire team informed about the direction you are going in, even if that involves multiple projects.  Make sure they see the big picture, not just the code they are working on this week. While you need to be open about the path taken to get to the destination, you can never compromise on the destination itself.

Encourage interaction between the team members.  Just because one team member has been assigned a task should not preempt another team member from making suggestions
or even questioning why a process is being done in a certain way.  This means making sure that all team members are open to talking about their work with other team members. Open discussions should not be limited to a weekly summary at a team meeting but should occur throughout the week if they encounter a problem that they cannot solve on their own.

Find out what each of your team members is good at doing and try to allocate tasks so they get tasks that they enjoy and in which can excel.  With any team, individuals will naturally begin to specialize in slightly different aspects of the projects your team gets assigned.  Some of this might be due to natural abilities, but I believe some is also due to a need to differentiate themselves from their other co-workers so that they can be the expert in at least a few areas where other team members are not as strong.

Provide a feeling of participation to all team members by inviting different members to project meetings based on the topic to be covered and the work that team member is doing. If they are so inclined, let them make part of the presentation at the meeting.  This may take time especially for a team member who prefers to work by him/herself behind the scenes.  Start with little things, but then get them involved more and more until you can trust them to work with clients on their own without your presence.

Encourage your team to learn new things, especially things outside of their area of expertise.  Sometimes a good developer can also be a good trainer, or documentation writer, or a presenter.  They may have a knack for working with clients to come to agreement on needs and wants of projects.

Training money these days is often scarce.  So encourage your team to look for other ways
to improve their skills (or as we say, sharpen their saws).  Local conferences can be a lot cheaper than conferences in another state especially if there is no travel expense and maybe no lodging.  On-line training courses can be significantly cheaper than in-person training.  Webinars, local user groups, books and trade magazines can fill in the gaps as well. The key is to make sure that any of these resources are used and that the training is something that the team member can put into practice immediately.

Does that mean that the manager can delegate everything and let the department run on autopilot?  No. Ultimately, you are still responsible for the work done or not done by your team.  However, the Information Technology manager who is not familiar enough with the technologies used by his/her group so that they can pitch in and help during heavy workloads is quickly perceived as just a boss and not a leader.  This does not mean that they need to be an expert in any of the technologies used by their people.  However they must have at least a fundamental understanding of how the technologies work so they can be a resource when the team is stuck on an issue or is divided over the approach to solving a problem or just has too much to do.  Of course, maybe my perception on this is due to the fact that I am still trying to home-grow that team lead that I never had.

Ultimately, I’ve learned that to some extent, you need to let your team find its own path.  With a clear understanding of what needs to be done and with some help from me, I think we have moved closer to utilizing each team member’s strengths. Are we 100% of the way there yet?  No, but we are getting close.  If that means giving up some of the tasks that I use to like to do, well, I can tell you that there can also be a great deal of satisfaction in seeing your team succeed.

So if I delegate all of the work I use to do to my team, what do they need me for?  Right now I like to think of myself as the SharePoint evangelist within our organization.  I look for and prototype new ways that departments can use SharePoint and some of our other tools.  I’ve talked to departments about using metadata to create document libraries that are easy to navigate without a ‘rats nest’ of folders.  I’ve talked to other departments about digitalizing forms so they might be able to go paperless.  Recently, I’ve been working with a few groups trying to combine SharePoint surveys with Excel Pivot tables to analyze the results to both prove suspected relationships and hopefully to uncover new ones.  While I am doing all of this, I know the rest of my team will handle the rest of the details all because I learned how to delegate more.


One comment on “To Delegate or Not To Delegate

  1. This is really interesting, You are a very skilled blogger.
    I’ve joined your rss feed and look forward to seeking more of your great post. Also, I have shared your web site in my social networks!

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s