views:

1410

answers:

13

Where I work, my role has been evolving from a pure development role to team leadership. I find that this suits me, and I'm generally enjoying it.

One aspect of the job that continually vexes me, though, is time management. My day used to be pure coding. Now, I still have a largely full plate of coding duties, but I'm expected to mentor other developers, work on requirements, make design decisions for other developers, evaluate bug reports from users, assign them to developers, and so on.

I find that my day has become on interruption after another and the prolonged periods of sustained concentration needed to get any actual quality coding done are becoming rarer and rarer.

Today, I finally grabbed my laptop and escaped to a coffee shop so I could get some actual work done.

How do the team leads here manage their day -- or manage their workplace -- so they don't let their administrative tasks overwhelm them?

+2  A: 

Designate certain days of the week as 'code days' and others as 'normal days'. Make it clear that on 'code days', you should only be interrupted for emergencies.

GWLlosa
I couldn't disagree with this more strongly - as you transition into a team lead role, your job is no longer to get code written - your primary job is to keep the entire team productive. Sequestering yourself is almost always counter to your primary goal.
Jared
I would mostly agree with Jared here. If you can get away with having "leave me alone so I can code" days, then do it. If team leadership were shared with one or two other people, then each leader could conceivably have days when they're not on call for providing assistance and guidance to the team.
Phantom Watson
The assumption I'm running on is that the "Now, I still have a largely full plate of coding duties" statement implied that his job is still at least partially to get code written. If the only way to get the code written is to shut out interruptions, then you need to schedule those blocks in advance
GWLlosa
+4  A: 

It's harder when you're physically close to others that need your assistance, so getting out of the office works pretty well.

I find, though, that a lot of it is an act of mental will or concentration. I have to partition myself in a manner that allows me to recall easily what I was doing before the interruption, and get back into as quickly as possible.

If I think an interruption will take more than 30-40 seconds, I'll open a GTD tab and write a little note with my current state (problem, solution notes, where I'm at, critical info) and that will allow me to switch back into that task very easily. Using the GTD method has worked very well in prioritizing things and keeping track when there are fires on top of fires. You might consider taking some Franklin Covey classes as well - there is a ton of management expertise packed into an hour or two seminar, which will really help you if you try those tactics.

I find that beyond 5 minutes, without notes, I'm lost and it will take the fabled 15 minutes per interruption to get back into it, and that's unacceptable if I want to get anything done, because interruptions come far more frequently than 15 minutes.

Oh, and delegation is king. "See john about that." Don't go to work without it.

Adam Davis
+7  A: 

Try to group similar tasks together so you are not switching 'mode' too often.

  • Wait for email to pile up a little then respond to all of it at once (everyone hour, every 2 hours, ect.)

  • Write down things you want to discuss with each person on the team. Make a list for each and get through all items at once.

  • Break your coding into even smaller task. (down to under an hour) This way you can squeeze in coding and still maintain progress without "forgetting where you left off"

  • I make all my meetings on Wednesday. It makes one busy day, but Tuesdays and thursdays always seem to be open then to code.

The more you are organized the more your project and your time will be too.

Glennular
+6  A: 

You need to be extremely efficient and not waste any time, because your extra time can at any point be taken up by members of your team. Somebody is getting a divorce and they need you to talk with them and reassign some of their work to other members, or someone has just discovered a terrible bug in your code that will keep you from shipping on time and needs immediate attention.

The things you can change are:

  • the amount of time you spend working.
  • your availability by various means of contact (in person/phone/e-mail) to your team, other members of your organization, and the world at large.
  • the balance between assigning coding tasks to other members of your team versus programming things yourself.
  • ways in which you can easily insulate your team from avoidable distractions.

A lot of these depend on the make-up of your team. Do you have a team of superstars, all of whom just need an optimal balance of direction and freedom to make amazing things happen? Do you have seven mediocre developers and one superstar whose time you need to manage so that the superstar can do exceptional work? Are you the superstar coder for your team?

I can't answer this question definitively for you, but you should think about treating management of your time as an optimization problem in which you're trying to maximize the productive output of your team. These types of multi-variate optimization problems are known to be very hard in mathematics, but if you're thoughtful about the makeup of your team, what you can do to help them be productive, and how you measure productivity, you can probably be a good team leader.

You also have to balance things with your personal life, but I'm sure you already know that. :)

Good luck!

James Thompson
Great post James.
Mat Nadrofsky
+13  A: 

Unfortunately, if you love coding then being a team lead, at many companies, means you will need to start delegating more of the coding to team members. You are advancing into a leadership role because you have shown an ability to get things done and have a trusted opinion.

As part of this new responsibility you need to delegate more of the hard/fun tasks to others and assign smaller (less critical path) items to yourself. If you are successful as a team lead your time will increase to help with requirements analysis and mentoring leaving less time for code.

Things that have worked for me:

  • Get into work early. You can normally grab 2-3 hours a very productive time early in the morning before most staff get in.
  • Work with your staff to have question free times. Let people know you are not going to answer email, phone, or desk interruptions for a period in the morning and afternoon. Once people get used to this "closed door" policy they will be accommodating to your "open door" hours.
  • Work from home for a few hours each week. I used to do 2 mornings a week. Scheduling can be a problem here but it works sometimes.
  • Delegation is your friend.
  • Spend more time on design. Well thought out designs and requirements for your team members will help them to know what is expected from a deliverable making your life easier.
  • Turn off pop-up alerts for everything (email, IM). Turn off new mail alert in system tray.
Mark Thistle
Just turned off my "New Mail Alert" good idea. It pulls my mind off what I was doing/working on. I've also started to work from home now and then to catch up on things. Some great tips here.
Mat Nadrofsky
+23  A: 

I've found that I have to change my perspective on what my job is.

As an individually-contributing developer, my job was to turn my own time in to software that the business could sell for a profit.

As a team lead, my job is to see that the team effectively turns their time in to software that the business could sell for a profit.

Some things fundamentally change when your perspective changes like that. These things have become much more important:

  • Keeping other members of the team in a state that they can be productive
  • Delegating tasks to the least loaded team member
  • Strategically choosing which developer needs to learn which new skill to better load-balance the team, and investing some degree of my time in helping them learn that skill
  • Effectively communicating requirements

Notice that "writing good code myself" is no longer on my list of top concerns. If the task of "develop this major new thing" falls on me, it's almost always for one of a few reasons:

  • The new thing is a framework item that will enable the rest of the team to be more productive (thus keeping them in a productive state)
  • The thing I'm working on is super-critical for customer satisfaction (usually that means it has to be done quickly and with little risk of failure)
  • The thing I'm working on has poorly-understood requirements, requiring someone with a high degree of domain knowledge to make quality requirement decisions while simultaneously doing development (one could argue that in this case, my inability to adequately form the requirements is the real shortcoming.)
  • I haven't done the other jobs well (delegating, improving skillsets, or communicating)

In the case of #2 above, it might very well be worth sequestering myself from the team to get the job done - but you have to keep in mind that doing that will hurt your primary goal: helping the team most efficiently and effectively turn your collective time in to software that the business can sell for a profit.

Jared
It's worth noting that on the best teams I've ever worked on, each and every member of the team felt and behaved this way - i.e. it is the job of all developers to maximize team output.
Jared
+1  A: 

I was once given the following advice. The key to success is to find a few competent people in your team who you can trust and delegate everything you can to them. Usually, there is a few of these; motivated, smart, communicative. You can help them grow by essentially offsetting your work to them.

Don't think of yourself as 1 leader with 8 developers. Think of yourself as a leader with two guys who manage 3 developers each (or whatever structure makes the most sense to your team).

Disclaimer: This will certainly not always work, but if you have 8 devs, you really shouldn't be coding anyways.

siz
+1  A: 

First things first, one needs a place to store tasks and mindtraps: some swear by GTD software, my weapon of choice is Toodledo (great iPhone app). I don't care if my todo list never reaches empty state. The important thing here is not missing a beat.

As of interruptions, I flow with them. I have come to believe that you can learn to switch contexts and, at the end of the day, being able to multitask -or have a smaller time-slice- is what distinguishes an efficient leader from someone that becomes a funnel of tasks.

I've been leading a team of six developers for six months now and the most important thing I've learned is to delegate: there is no possible way that you will be able to supervise each and every member of your, don't even think of correcting their work. Jeff Atwood's «Are you creating micromanagement zombies» is great food for thought.

pantulis
You should link to Jeff's resource on this.
Mat Nadrofsky
sure, got this fixed!
pantulis
+3  A: 

I have 3 pieces of advice for you :

1) Take control of your email. It is likely that this is the first place that changes, from a few mails a day to an insane amt : see my answer to this Question How to organize your mail

2) Understand your role has now changed. You are now primarily a innovation catalyst, since innovation happens in the white spaces between the organogram and that is where you must operate - to do this you need to get NOT BUSY ( delegate )

3) Don't get lost is the white space and lose touch with the actual development, keep doing it, but don't get on the critical path.

Stephen Bailey
I really need to blog the idea of innovation in the white spaces of the organagram at some point, but I hope the picture is clear.. innovation happens outside the typical work flow, and middle management ( with time ) is perfectly placed to effectively do this.
Stephen Bailey
Okay I was inspired here is the blog I have always wanted to write on innovation in the white spaces : http://www.blog.stackingit.com/2009/02/innovation-happens-in-white-spaces.html
Stephen Bailey
+3  A: 

Transitionning from a technical position to a managing position can be extremely challenging.

It took me a while to realize that I was the bottle neck on some coding tasks and that the project would not move forward when I insisted on coding. I moved from coding myself to help other code, and help them debug code. I was able to mentor through code reviews, pair programming, and debugging sessions. Now, I am no longer coding. It took over four years to fully transition.

Some colleagues in the same situation, who feel that they can not give up on coding, manage the day to day operations while they are in the office and code at night. I admire them but would not be able to do this myself.

Getting Things Done is a life saver and given your situation, I would emphasize delegating. Don't engage in a task that other would do better than you. Lack a delegation is a poison. Your reports don't grow and you get overwhelmed.

Finally, I was recently given this article which really summarizes the situation we are facing when moving from a technical role to a supervisory role. It is a different set of rules, a different game. The faster you understand the game, the faster you becomes efficient at it.

Good luck!

David Segonds
+3  A: 

Delegate, delegate, delegate.

Understand that there is more than one way to solve a problem, and the people on your team can get it done.

Be results driven, not process driven.

This will allow your team the flexibility to code their own path, and provide you an escape from the "If I want it done right, I have to do it myself" way of thinking.

Lastly, understand that you were put in the position you're in because you now have a greater value as a mentor than as a coder. Explore that responsibility a bit more, and make yourself available to the team, not just to the coffee shop.

criddar
+3  A: 

First thing every morning, Write a Todo list!

Even if you don't look at it again, the brain works through what has to be done. And you've got a sort-of plan. Of course, it'll never go accordingly, but the effort will make it easier to remember what needs doing.

Stu Andrews
Good advice, though with my Todo list running at 22 items, I rewrite it out every week, not every day. Writing by hand with a real pen on real paper allows my brain to slow down enough to be reminded of the items I might have not thought about for the last week. (Maybe my Todo list needs to be shorter, but I have to record the "needs to be done sometime" tasks somewhere.)
Paul Stephenson
A: 

I'm not a team leader but a programmer, but my team worker use a great tools which send email and have a large Project tools cutting into multiple task with status and priority. Any change to any tasks send email to who's assigned to it. There is also a possibility to add "milestone" to project and assign task to it. I think this can help a lot. Here's the link.

There also a great module for "Timer". For a specified Task or general one (Quick use or anything), you start timer. Great feature is that you can close your browser and timer still counting up and when you open back you interval's, timer still working. Then you can close it and it assign it to the task if not done.

http://www.myintervals.com

(Sorry for my english, I'm talking french)

Simon