Monday, June 05, 2006

How I Manage Email

One of the most frequent questions I get is how to I manage the volume of email on a daily basis. Here are a couple quick tips:

  • Use Rules. I have emails that come from my management chain, product management, and my directs automatically go to a dedicated folder that I ready every day

  • Filter out Work SPAM. Every company has announcements that go out via email. These are usually just reposts of what ended up on the intranet. I have all emails from these addresses automatically go to my work SPAM folder, and I never read them

  • Don't read emails that are more than 3 business days old. This may sound strange, but if I don't get to an email within three days, I stop worrying about it. If it is really important, it will be resent, or I'll get a phone call about it.

  • Isolate Customer Email. All customer emails should be sent to their own folder. Read these ASAP. No one is more important than the customer, and if they are taking the time to send you an email, you need to take the time to read and respond.

  • Never Delete Anything. I have hundreds of emails that I've never read, but I don't delete a single one. All of my emails get archived monthly, and I use a desktop search program to make all of the information accessible. It doesn't matter which one, they all work basically the same. Just make sure that you have a record of everything you've received and everything you've sent.

I'm not advocating any particular method, and I'd be interested to know how others manage hundreds of emails a day. These are just a few tips that I follow to keep my Inbox manageable.

A Week in the Life of ...

Here is a summary of how I spent last week


A holiday for me means that my daily email load is down from 200 to about 50. I have teams located in three countries, so there is no such thing as a true holiday for me. No major customer issues today, only a few administrative questions from me team. I'm able to answer most of these from my phone's email, and I only have to make three phone calls, 1 to each of my leads.

And the week begins. Today I received my typical 200 emails. Most of the requests fall into a few categories:

  • Development Questions

  • Question from Sales about feature set

  • Question from Sales about a future feature

  • Question from implementations about fixing a "bug", which really means helping them configure the system

  • Questions from support that they are escalating for help from development

  • Customer Issues

Of my 10 hours today, I spent 3 on the phone with customers addressing everything from product concerns, future product vision, complaints about other groups (support, implementations) that were directed to me since I was on the phone, and general issue management. I spent 2 hours with my leads between a few different meetings, going over this week's reported customer defects, upcoming installations and upgrades, and a status meeting on an upcoming release of software on our older product platform. I spent about 2 hours going through my email to read the 200+ that I received today (I'll post my theory on email some other time). Of my remaining 3 hours, I dealt with administrative issues: I checked in on some of my staff, took one guy out to lunch since he has just been killing himself and exceeding all expectations, talked with a developer who is falling behind on his development tasks and put a daily status tracking system in place that he is sending directly to me and his dev lead, and met with my QA team to address holes in our testing process, and ways to improve on this release.

Today was similar to yesterday, as yesterday was a fairly typical day. Spent most of my day fielding questions and phone calls that have to do with current customers, future sales, current installations, or current product problems. I got through less than 50 emails today. I also spent some time developing a high level staff allocation template to share with my peers on other products. Short day today of 8 hours, since I have to catch the red-eye tonight.

Today and tomorrow represent what our company calls a Bug Bash. These happen a few times during the testing phase of a product development cycle, and the goal is to get the entire team, and anyone else willing to help out, to put in extra hours, eat meals in the office, and get to a predetermined goal of a resolved number of software defects.

After last night's red-eye, I'm in the office at 6:30. This is perfect since I need to prepare the tracking sheets, status conference calls, and goals for the bug bash. The goals include targets for development, QA, and the team in general. They are also broken up into today's goals, and tomorrow's goals, so that we can track better. By 8:00 AM, I have an email with an Excel attachment sent to my team, and ready for our 9:00 AM kick off call. This gives me time to run out and pick up breakfast for the team, since the catering service didn't show up (They are still coming for lunch and dinner). Our goal for this bug bash is to get from 500 outstanding defects down to 150 in the development queue, and 0 left for QA to validate. We'll be having a quick status meeting at Noon to make sure that everyone has their roadblocks out of the way, and again at 5:30, to check today's progress. Most of our team is in the office until 7, the last person leaves at 8:30, and I walk out with them.
When you're team is putting in long hours because they want to, that's one thing. When you ask them to do it, then you better be there with them, first one in the door and the last one out.

In between the coordination of my team's bug bash, I go back to my typical day's tasks of answering questions for sales, and working with implementations and support on customer issues. Today's email count: 306. Today's read email count: 42.

Second day of our Bug Bash. We have a quick status call to kick off the day again, and to celebrate the team's amazing progress on the first day. Last night, I sent an end of the day status sheet, and highlighted a few major accomplishments in the email. I intentionally copied our team's VP and CTO, hoping that one of them would respond to the group reiterating the congratulations. To my surprise, both of them did. The team reached 80% of their two day goal on day 1, reduced the QA defect queue to 0 by 6:00 PM (of course, this goes back up as development resolves more issues), and started onto our stretch goals of attacking some of the low priority defects.
Nothing gets your team motivated like knowing that their accomplishments are being announced and recognized by senior management.
As their direct manager, I am responsible for giving my team praise, but also responsible for giving criticism and keeping everyone on task. Since my team does not interact with senior management on a daily basis, seeing any of them take time out of their day to publicly acknowledge the team gives a huge morale boost that I could never give.

Unfortunately, today's bug bash is not as successful as yesterday's. Almost 100 new defects are created today, most of which focus on 1 module. The module has a very complicated set of requirements, and most of the defects relate to a misinterpretation of the requirements, but they are defects none the less. Also, the frustration of the product manager not having the developer understand the requirements affects her efficiency. I spend some time with her, understanding the defects, and then take on the task of translating them to the developer (English is his third language).

I also have a weekly management meeting today. I'm hoping today's is cancelled since I have plenty else to do, but it is not. For added fun, today we'll be discussing the new budget planning process that we need to start engaging in so that we're prepared for the budget meetings that start in July. The meeting goes almost two hours, instead of the normal 45 minutes. During the meeting, I'm taking notes, reading emails, sending emails to my team, checking our defect tracking system, responding to instant messages, and speaking to the group for a few minutes on some division wide initiatives that I'm responsible for.

At 3:00 PM, it's back to the Bug Bash. The team is starting to drag, and we have just a little further to go in order to make at least one of our goals, getting the QA backlog to 0. I call a quick pep talk / status call. On the call, we reassign the remaining defects among the entire group, and agree as a team to get these all cleared out within 60 minutes. Our configuration manager leaves the meeting early to get the latest version of code onto our QA server, and at 3:30 PM our team hits the pavement for one final sprint. By 4:15 (15 minutes early), the team is finished, we have a congratulatory call, and everyone heads home for the weekend.

Except me. Now, I need to finish my weekly tasks. Timecards, expense reports, travel itineraries, double checking reservations, checking in on my other products that are in less critical stages right now since I've ignored them for the last two days. I also have a handful of blogs that I read and I never like to fall more than a week or two behind, so I spend 30 minutes catching up on the latest news, trends, product reviews, conferences, and projects. I leave the office around 8:00 PM.

As a rule, I try not to work weekends, but we have a customer going live this weekend, and the implementation has had its issues. I have a status call with the on site team at 10AM, and make myself the key contact if anything needs to be escalated to development. Typically, they would contact my dev lead directly, but he just put in some serious hours with the bug bash, and he's actually in the office still working on defects. I'll try to absorb as much as possible, and only defer when I have to.

Only one phone call today, so basically an easy day.

My Background

It probably makes sense to start out by introducing myself and my background

Resume Paragraph:
I have over 13 years of software development experience, ranging from custom development, enterprise development, enterprise application integration (EAI), ASP commercial software, packaged commercial software, architecture (software, enterprise, and infrastructure), SDLC (RUP, XP, Agile, SCRUM, MSF), and project management. I have held varying levels of leadership and management positions of groups sized between 5 and 40, and been responsible for communications at al levels within and outside the organization, including staff, executives, and board members.

How I got here...

  • Owned my own custom software development company for 6 years. This is where I got my start, made a tone of mistakes, and learned the value of customer service above anything else. If you've never interacted with your end user on a regular basis, you need to. It will be an very humbling, eyeopening experience

  • Fell into a very lucky opportunity and joined a global Fortune 100 company to help through ERP customization, Y2K readiness, CRM Global Installation, and lead a custom development and data warehousing team. This position lasted 2.5 years.

  • Then I moved on to a commercial software company focused on all sectors of the health care market, providing both packaged and ASP software. First, I ran a team that developed real time data extract and portable data warehouse product to the pharmaceutical industry. After the success of that project, I received my second lucky break. I was selected to run a new initiative for the company from the ground up. I hired the team, architected the product, and managed the relationships with key partners and customers. This position lasted 2.5 years

  • After that, I moved into my current position. Now, I am responsible for the strategy, development, and support of one of my company's products. We have two different generations of products, so I manage two teams, each consisting of anaylsts, developers, and testers. My company does have a separate product management organization, and there are two product managers dedicated to my product (I'll post about this later, but never agree to anything with an industry specific product unless you have dedicated product management with experience in that industry). Current tenure 1.5 years and counting

Current Technologies:

  • Microsoft .NET Framework (C#, VB.Net)

  • Java (J2SE, J2EE, Tomcat, Weblogic)

  • SQL Server (4.2, 6.0, 6.5, 7, 2000, 2005)

  • Oracle (7.1.3, 8i, 9i, 10g)

  • Data Warehousing

  • Enterprise Architecture

I won't pretend that I've earned my positions based solely on merit. While I do think I am very qualified for my position, and I've been successful in my previous positions, I did receive a couple lucky breaks. Everyone gets a few chances presented to them during their career, but it is a matter of timing and execution to make the most of those opportunities. The other key that has opened several doors for me is that I have a strong set of soft skills. This is especially key for engineers, and is one of the easiest ways to set yourself apart from the rest of the pack. Anyone who understands the technology behind a software solution, this could mean an analyst, developer, or tester, and this person can effectively communicate (written and verbal), concisely summarize technical information, and understand the relationship between technical and non-technical information has a very bright future ahead of them. The last key attribute, and this might be the most important, is the ability to inspire others. People talk about leadership, courage, and confidence, and there are shelves of books at Barnes and Noble discussing these ad-nauseum, but I believe that it all comes down to one attribute that makes the difference between successful and unsuccessful leaders. If you can inspire others, push them to do more than they thought they were capable of, make them believe in a common cause, make them want to help the team succeed, then you've got it. I don't think this is a skill that can be learned. It can certainly be honed, trained, perfected, but not learned. And you don't need to have a management position to start inspiring others, it just happens naturally. Do you notice that your peers come to you for answers? Are you usually the one persuading a group in a planning or design meeting? Do you find yourself worrying about how your peers are doing on their tasks, and want to help them to finish on time or overcome a difficult challenge? If so, then you probably have it.

Well, enough preaching for now, I know I tangent a great deal, but as I create more posts, they will be more and more focused.

Introduction to this blog....

I currently manage a commercial software product, and one of the most frequent questions that I get from both my staff and staff on other product teams is "How do I move into management?" I've been answering this question for a few years, and have decided to start a blog so that I can answer these same questions for more people than those that I interact with at work. Not only would I be happy to answer questions through comments or email, but I'd also be interested if there are any other program managers who would also be interested in posting.

The answer I always provide in one form or another to developers / testers / analysts looking to move into management is always the same, and always in the form of another question. "Do you know what management is like day to day?" That's the question that I plan to address with this blog, but not only answering questions and going into my background and how I got to where I am, but to chronicle the day to day activities. I find that it is critical for people to understand what a move into management truly entails, and that they are motivated and ambitious for the right reasons. Generally speaking, the motivation that the only way to make more money is to move into management does not really apply to software, and the same concept is spreading to more and more knowledge based industries. Companies are learning that talent comes in many forms, management being no more or less of a skill than a deep technical expertise.

I've been thinking about this blog for a while now, so I have some pre-planned entries that I'll post in the days to come...