VFPConversionLogo
HomeBlogLearnProductsEventsServicesAbout UsFAQ
Mike Yeager's Blog

Wednesday, October 18, 2006
Shifting Gears

More than ever before, the ability to shift gears - to move from project to project, customer to customer, technology to technology is not only a 'nice to have', it's required.  Gone are the days of working on a single project for entire days or weeks at a time.  Companies need you to change focus much more quickly now because they no longer have one or two projects in the works.  Most companies are juggling dozens of projects at once because technolgy has permeated the entire business.  Systems are developed faster and more systems are required than in the 'good old days'.

It's no secret that shifting gears frequently is not the most efficient way to work.  There is overhead in switching gears - some time is lost getting up to speed and getting your mind focused on the new task at hand. 

So how do we balance the benefits of shifting gears, agility, manpower balancing, etc... with the inefficiencies?  Part of the solution is to realize that not all gear shifting is bad.  It's nice to have always have at least one project on the back burner.  Whenever there is a schedule interruption in the main project, switching to another project that you're already familiar with is a very good use of time.  I also find that when you have a back burner project or two in the back of your mind, your mind tends to work on the problems unconciously so that when you do switch back to that project, you've figured a few things out.  This is a much more productive way to work than spending unproductive hour after hour banging your head against a wall on a problem that's eluding you.  I find that switching to another task and revisiting the problem later gives me a new perspective and allows my brain to work on the issue in the background.  I can be productive now on another task and be productive on the problem I encountered when I return to it.

The key for me is in finding the right level of gear switching.  Too few things to work on and I lose productivity because I can get stuck on the task at hand and have nothing else productive in the queue to switch to.  Too many things to work on and I lose time to to the overhead of task switching and eventually I become overwhelmed.  Unfortunately, I've found that my peak performance comes when I have approximately 3 tasks.  Not good enough in today's world!

Currently, my focus is on trying to manage a larger number of tasks without being overwhelmed.  So far, the best method I've found comes from a piece of technolgy I call a pencil!  A good friend once told me that once you write something down, your mind can safely forget about it for a little while because it knows it's safe.  It sounded ridiculous to me at the time, but it works.  Once I write this stuff down, they stop swirliing around in my head and I can focus again.  Making a list of tasks on a piece of paper next to my keyboard is the best medicine I've found for task overload.  I refer to the paper occasionally, scratch things off as I need to and add notes here and there.  For me, I find that it's better to NOT have the information on my computer because I don't have to switch to it and I can annotate on paper more easily (maybe I need a Tablet PC?).  Having the list in my peripheral vision is a non-invasive cue to occasionally check on my list of tasks, decide if I'm on track and switch as necessary.  In sight, out of mind.

Try it.  it might work for you too.

Mike


Posted @ 12:11 PM by Yeager, Mike E (myeager@eps-software.com) - Comments (31)


Monday, October 02, 2006
My take on Process and Methodology Wars


 

We recently had a brief firestorm of e-mails around the office about a blog on the productivity loss experienced when multi-tasking and it got me to thinking.  The blog came down unequivocally on the assertion that multi-tasking decreases productivity.  There was some sentiment that organizations should reduce the amount of multi-tasking and task-switching to maximize productivity and some sentiment that workers who are better at multi-tasking and task-switching are better employees.  In most things, I find that the "sweet spot" lies in between the extremes.  I also recognize that it can be just as healthy to vascilate between extremes as to always stay in the sweet spot.  Humans are like that, we need to be stretched occasionally.  Companies on the other hand would love nothing more than to stay in the sweet spot at all times - it's most productive.
 
While I generally agree that mulit-tasking and task-switching reduce productivity, I really have no hard evidence that it's true and I don't believe that it's an absolute rule.  My wife for example, can multi-taks with great ease.  It's one of her many strong suits and she makes it work to her advantage.  On the other hand, at work I tend to make plans around reducing multi-tasking and task-swithing for both myself and the people who work for me because my experience tells me that productivity does drop and it has been advantageous for me to plan this way.  But I do not adhere to this as an absolute rule.  There are few absolute rules in my world.  To quote "Pirates of the Carribean", "They're more like guidelines".  Generally when confronted with a decision, I tend to go with the guidelines.  They're guidelines for a reason - they usually work!  But I don't consider myself a very good manager if I don't consider the alternatives and use my skills and knowledge to make the best call.  When I was managing a group of developers, I learned a lot about them including three key measures that I want to pass on:  1) what "factor" are their estimates consistently off by and 2) how many projects can they work on simultaneously for peak performance 3) what type of work they are best at.  Of course, there were other factors like, how well do they get along with other people and who did they (and didn't) work well with, etc, but the most helpful things I leared as a manager were the three I listed.
 
1) What "factor" are their estimates consistently off by
It's well known that when you ask a programmer how long a task will take, they almost invariably underestimate.  15 minutes is a standard response.  I tried for a long time to work with my programmers and 'fix' this problem, but always came up short.  Then it occurred to me, "Don't 'fix' the developers, fix the reporting system".  I went back through a combination of my memory and the work records and came up with a multiplier for each developer based on past estimates and actual completion times.  I also figured in some time if a programmer was prone to having the work kicked back to them from testing.  It turns out that this ''factor', while I adjusted it occasionally was a very precise measure. I'd simply multiply Bob's estimates by 1.5, Jean's by 2 and Fred's by 1.1 (oooh Fred was GOOD!) and the numbers we used for project planning were usually very, very accurate.
 
2) How many projects can they work on simultaneously for peak performance
My personal peak performance is at two projects.  I like to have one project in the front of my mind and one in the back.  When I switch from one to the other, my brain has figured out exactly how to proceed on some background thread that is vastly better at strategy than the foreground thread, which is always more tactical.  I've had developers who's peak is one project at at time, period.  If we look at an arbitrary period of time, say 3 months, and either gave them the same tasks either sequentially or in parallel, they always got more done if it was sequential.  I've also had they developers that I call the "McGyver" types.  They like to work in short bursts and were brilliant at banging out a quick solution, but their productivity just fell apart if I had them work on something for two straight months.  Yes, sometimes multi-tasking is good.  Even though there is a loss when switching from one task to another, this effect is smaller for some people than others and some will just get downright bored if they DON'T switch tasks and that isn't good either.  It can cause not only a loss of prductivity, but ultimately a loss of the developer and all of the time and money the company has invested in them.
 
3) What types of work they are best at
Fred was fantastic at T-SQL stored procedures and a solid programmer, but if I needed someone to troubleshoot a program that had issues reading from a serial port, he was NOT the guy.  Bob was the guy for the serial ports and he also had written a couple of inventory managment apps, so he was also the guy to write the WinCE handheld, physical inventory piece.  Jean had great ideas and was way ahead on designing new stuff, especially web-related stuff because Jean had an atristic streak and an intuitive sense of UI design that end-users loved.  Left alone to work on the project however, Jean's code would become arcane and hard to maintain.  Jean got to design and do the UI, but Fred and Bob did the database and coding.  This was a fantastic group of programmers to worked with as long as I could keep them all doing what they were good at and working with each other to teach the others.  I found that having them present a piece of work that they had just done well to the others was a gerat way to not only keep everyone up to speed on what was happening, but also to let them shine a little bit and to teach the others some tips at what they were not as good at.
 
From my point of view, it's the manager's job to know this stuff and to make the best use of the developers they have.  I DO think that managers should try to make their developers more flexible and stretch them a bit so that they can be more effective in more situations, however, you can only take that so far.  I think trying to fit all of your developers into one mold is a mistake and you'll leave a lot on the table that way.  Being a good manager does not mean pushing people to do get work done on-time and on-budget.  Being a good manager means getting the best and the most from your people.  Let me say that again, "Being a good manager means getting the best and the most from your people."  Sometimes it means getting rid of someone who simply can't cut it or can't fit in well enough with the organization as a whole.  I usually take that a a personal failure as a manager, but never the less, if we can not work it out, they have to go.  Sometimes it means saying "no, I can't move Bob off of this project right now because by the time he switches over and then back it will put this schedule too far behind and we'll miss that deadline.  Here is someone else who has the skills you need and who can switch on and off of his current project without missing a beat."  Sometimes it means saying, "Bob, take the rest of the day off and come in late tomorrow.  Go see your kids, get some sleep.  You're not doing me any good here, you're burning out.  Come back fresh tomorrow."  Sometimes it's, "You told the team you'd have this ready and it's not.  I have not one else available right now.  I need to to stay late and finish it for the demo."
 
I'm fascinated by the nearly religious ferver with which people attempt to learn and adhere to processes.  What REALLY fascinates me about the blogs flying around is how hard people tend to fight to shore up their "position". While I understand that you really can't judge a process until you've wholeheartedly attempted to embrace it and work with it, I believe that as a manager, you have an obligation to do better than simply blindly follow what someone else has written.  You have to experiment and try things for yourself, you have to recognize when something isn't working and adjust and you have to steal from what does work.  You must have an open mind, but untimately it is your call as a manager and that responsibility goes well beyond implementing a process.  Your goal ultimately is to do the best thing for the company and the client.  Your responsibility is to constantly improve your ability to do that whether it comes from a methodolgy or not.
 
I really don't have time for blogs about whether VB.NET is better than C# or whether Scrum is better than Agile or whether multi-tasking is simply bad.  I skim over them because they can often clarify little aspects of the subject, but I'm totally turned off by people "selling" their point and arguing right and wrong.  I steal from all of these things and I find valuable information in every single one and I make the best decisions I can based on the SUM of my knowledge.  You can find lots of people who can follow a methodology or process, but good managers are hard to come by.  Good managers use the methodologies and proeceeses for best effect.
 
Nuff said.
Mike


Posted @ 11:16 AM by Yeager, Mike E (myeager@eps-software.com) - Comments (4)


Blog List
VFPConversion Blog
Markus Egger's Blog
Ken Levy's Blog
Claudio Lassala's Blog
Blog Archive
March, 2008 (1)
February, 2008 (1)
October, 2007 (1)
September, 2007 (2)
July, 2007 (1)
May, 2007 (3)
March, 2007 (3)
January, 2007 (2)
December, 2006 (1)
October, 2006 (2)
September, 2006 (2)
August, 2006 (6)
July, 2006 (3)
June, 2006 (2)
May, 2006 (4)