Thursday, April 30, 2009

Inbox Zero, Take Two

A year and a half ago I tried to get to “Inbox Zero” and failed.  This is the idea that you get your inbox down to zero mails every day.  I’m making another run at it and this time have been a little more successful.  I’m not perfect, but I haven’t fallen off the horse yet either.  Here’s what I have found to work.

  • Let all interesting mail fall directly into the inbox.  Don’t use separate folders for stuff from your boss or an alias/list that is important.
  • Move non-interesting mail into a separate folder by a rule.  I have rules to shunt off aliases I find merely interesting but not important into their own folders automatically.
  • Read or skim every mail that is in your inbox.  For each, make one of the following decisions:
    • Respond.  Read it and take the appropriate action.  If you can do this in a minute or two, just do it.
    • Delete it.  You have the information or it wasn’t interesting.  Either way, you don’t need to keep it around.
    • Archive it.  You may need to refer back to it later, but you don’t need to take any action on it.
    • Mark it for further reading.  It’s not critical to act on it, but too long to read now.  Put it in a folder to read later.
    • Mark it for further action.  It will take longer than you have to respond, but a response is necessary.  Put it in a folder for later response.

Following these rules makes my inbox look something like this:

  • Inbox
    • Action Required
    • Archive
    • Read Later
  • Interests
    • Various subfolders for the non-critical aliases I am part of.

I also have a rule to move all mail sent to: or cc: me directly to my inbox.  This way mail intended for my eyes won’t get filtered into an “interests” folder.

I have found this system simple enough to keep up with it.  It also means I no longer miss mails which got filtered into some folder I haven’t yet read for today.  I now see every interesting mail and am at least aware of it.  It also helps me keep track of the mails I really need to go back and respond to.  My old system was just to leave them unread, but this got unwieldy very quickly and I never made it back to most of them.

Monday, April 27, 2009

Don’t Worship at the Altar of Accuracy

Earlier today I found myself faced with a common management situation.  I had been sent an e-mail which showed that a piece of data we were using was inaccurate.  The specific issues was what percentage of a certain test run was automated.  We had said we were at 100% and it turned out there were a handful of tests that were being run on our behalf by someone else and those were not automated.  My initial response was to investigate how big the non-automated block of tests was, why it wasn’t included, etc.  Then I stopped and thought about it.  Even if the number were as large as reported, that number would be 10% of the total test suite.  That is almost certainly an over-exaggeration.  When we make the numbers more accurate, it probably slips to 1%.  Whether we are 90% automated, 99% automated, or 100% automated, does that change anything?  Is that number going to change what I ask of my team?  Probably not.  In all cases the items that are manual are intended to be that way.  I won’t stop running them or try to automate them.  All that I will gain by going through the process of making the number more accurate is a more accurate number.  Is there value in that?  I assert that the answer is no.  A number’s accuracy matters only to the extent that the difference will change behavior.  Within some range, different numbers won’t change behavior and so are not worth expending effort increasing the accuracy.

This isn’t to say numbers don’t matter at all.  They do—but only when decisions will be made based on them.  Effort is not free.  Spending energy refining a value that is accurate enough means not expending that same energy on something that might bring more value to the team.  It isn’t hard to find something which brings more value because the value an increasingly accurate number brings is zero.  This is especially important to note as a manager.  A manager typically does not spend a lot of effort making data accurate.  He or she merely asks others to do so.  In this way the costs are hidden and thus the tradeoff not as apparent.  Beware the cost of obtaining accuracy for its own sake.  I know it is in our DNA as engineers.  Suppress your inner urges and don’t worship at the altar.  Get to good enough and stop.

Wednesday, April 22, 2009

Simple Management Tip: Tracking 1:1 Conversations

Here’s a quick tip I’ve found very handy.  When doing 1:1’s with your team (you are doing these regularly, right?), take notes to keep track of the conversations from week to week.  I currently use a 5-tab notebook with one tab for each direct report.  Each person has their own section.  Each week when we meet, I take notes on the next page in their section.  This makes it really easy to refer back to last week’s notes and follow up on any ongoing issues.  Each week I circle the items I need to follow up on the following week.  This makes it trivial to pick them out.  Having one section per person means the previous week is only one page back.  I tried just keeping a continuous set of notes on everyone, but then finding the last time we talked could be difficult. 

Another advantage of having each person in their own section is it provides a space for next week’s agenda.  During the week as things come up, I jot them down on the next week’s page.  Then when it comes time for the 1:1, I already have a list of items to follow up on.  This also helps stop my subconscious mind from dwelling on these items (ala Getting Things Done) because I know they will be handled.

I have also seen OneNote used successfully for this purpose, but I prefer not to have a laptop between myself and the other person in our meetings.  It is a matter of taste.

Tuesday, April 21, 2009

Becoming a Manager: Learning to Rely on Data

Having been a manager* for a while now, I’ve learned more about what it means and what changes it requires in thinking.  This installment of the “Becoming a Manager” series covers the increasing reliance on abstract data that is required as you move up the ranks.  Everyone who is an IC knows that upper management demands lots of charts and data.  Sometimes this makes sense.  Other times we know it distorts the reality which is apparent on the ground.

When I was a lead I managed by walking around.  I didn’t pay much attention to statistics.  Instead, I would regularly touch each of my team members.  I would have 1:1s, regular scrum meetings, and hallway conversations.  This allowed me to have a strong sense for what was going on in my team.  This worked great with 6 reports.  When I became a manager I tried to continue this same method of staying on top of what my team was up to.  The problem was, however, that I now had 20 reports.  It’s not possible to touch all of them regularly enough.  It is also a lot harder to keep the issues at play in 20 peoples’ daily work in one’s head.  Finally, most of these 20 had leads which stand in the org chart between myself and them.  Trying to manage by walking around undercuts these leads because now their reports have 2 managers, not one.  This is confusing for all involved.

What about just touching my direct reports and getting a sense for the product from them?  This would seem to work, but is not terribly effective.  Each person reports differently and normalizing the information coming from each is difficult.  It becomes worse when people use the same words to mean different things.  When I try this technique, I almost always later find out that while I’m getting the same information from each, the results on the ground in each team differ greatly.  How then to get a normalized view of what is going on at the IC level in each team without going to each person to ask?

The answer lies in gathering data across the team.  I’ve come to rely on the dreaded charts for much of my knowledge.  I have learned to take advantage of tools to track how the team is progressing in getting its work items done, how many bugs are active, what our pass rate is, etc.  This allows me to get a view at a glance of how we are progressing across several key metrics.  As long as I am gathering the right data, I can have an accurate view of how the team is doing.  Based on this data, I can know which areas are doing well and which ones need more personal attention.

The key here is choosing the right metrics to measure.  The team will optimize for whatever it is I am measuring.  A wrong metric will distort behavior in undesirable ways.  I have found it is important to track only a few items.  A small number of items can be understood by all.  These do not describe everything about the team, but they can act as the proverbial canaries which point out trouble early.  I make sure everyone knows exactly what I am tracking.  Every one of my leads knows the queries I use to monitor things.  This allows them to point out flaws in my methodology and gives them transparency so there are no surprises.  It is also important to keep the metrics stable over time.  A different chart each week gives people whiplash.

One point about using data to monitor a team:  you need to stay flexible in the use of the data.  The data is a rough facsimile of a real thing that needs to be done.  The data itself is not the goal.  I have seen too many managers confuse the data with reality.  This causes them to push for clean metrics even when this causes undesirable distortions in behavior.  If the data is showing a different state than reality, fix the metric, not the behavior.  Align the data with the team’s actions, not the other way around.  It is important to note that data hides a lot of things.  Relying solely on data is a surefire way to fail.  I still get out and walk around to validate the conclusion I’m drawing from the charts.  The data merely helps me know which areas to spend my limited time digging into deeper.

It takes a while as a manager to become accustomed to viewing the world through the lens of spreadsheets and charts.  Just as it is difficult to learn to trust others, it is difficult to learn to trust data.  It is even more difficult to learn when not to trust the same data.

 

* Manager means having leads report to you.  A lead is someone who has only individual contributors reporting to you.

Wednesday, April 1, 2009

I'll be posting on Twitter occasionally

As I surf the net I often run across articles of interest.  If I feel they warrant a comment, I'll post them on this blog, but most don't rise to that level.  I've decided to try using twitter as an outlet for such items.  If you want to see the articles I think are most interesting, feel free to follow me on twitter:  https://twitter.com/steve_rowe.