What I'm about to share is based on my personal experience. I'm still in the middle of perfecting my technique and getting better at communicating with the team. If you have any suggestion or improvement idea, I would love to know.
---
I thought I was different. I thought I knew better. I somehow felt that I did not have to subject myself to explain every details of my thought process. I believed that sharing too much detail was counter productive. What mattered the most was the result, the final answer.
It may have been watching too much Apple commercials in the late 1990's. Or it may have been cockiness of a recent graduate where just about everything was graded on a curve. I fell into the trap of thinking that I was different, and I knew a better way to deal with emails.
And that led to not sharing information quickly. I would rather have the perfect final answer in an email rather than sending a premature half-baked reply. When I get an email requesting for some information, I would dig up my old email to confirm, retest the code to validate and send what I personally verified data back to the requester.
It often took a few hours to reply to an email. When I did not have the answer, I would start fishing for information, consult people who might have the latest knowledge, and have multiple IM conversations to figure out the sender's intent. Only when I had a sure answer to give, I would sit down to craft a message that I would feel proud of.
It worked okay when I was working at a 5-person startup. But I soon realized that this was not scalable. Once I moved from solo coder position to manager role, my email volume just about tripled, not counting the automated emails. Once I moved from engineering manager role to product manager role, my email volume doubled again. Now I routinely get emails up to 200 messages a day.
In addition to my old email habit not scaling, I realized that it had other unintended consequences:
1. My behavior was destroying the trust.
Whenever I did not give timely response, the sender did not know whether I saw the message and was working on it. It left the sender wondering whether to resend the message. It created doubt and uncertainty. In turn they were destroying my trustworthiness.
Just because I neglected to send a quick 'I got it' message, I was sabotaging my trust score. Even when I was working on it, the sender had no idea her answer was on its way. The consequence was exactly the opposite to what I intended. I was perceived as incompetent and not trustworthy. No one cared to know that I was busting my butts to get the best answer possible back to her. (I also wrote about how to build trust earlier.)
2. I ended up missing the deadline because things piled on.
Because it took me a long time to craft an email, I usually had dozen email requests that were waiting on my queue. Although I tried my best to answer them all, invariably I would miss a few emails with deadlines. Each time this happened, it had devastating effect on my credibility as a reliable resource.
3. I had too many goals, but very little steps.
Most emails were not simple yes or no answers. They required investigation, thinking and discussion with other members to figure out how to deal with it the right way. It created frictions between responding to the email rapidly and following up on it to properly execute the right solution. These goals where steps to get them done were not visible piled on, and it following up on those tasks even more challenging. (Read about goals and steps in my earlier post.)
4. No one knew that I was doing the work.
For some reason I thought that it did not matter whether other team members knew what I was doing or following up on their request. I thought I was on a mission to amp up the quality of our work. By providing updates when I felt they were ready to be shared, I was reducing the visibility of what I was working on and in fact lowering the team efficiency, not improving it.
5. Things seem to be working, but they really did not. I had an unique perspective to see the problems, and noticed no one was fixing them.
As a product manager, I got to see the 360 view of where my product was and where it needed to be. But those feedback were not getting injected to many conversation threads that were passing through my inbox.
I had a big problem in my hand. I needed to come up with a fix right away. Fortunately it was a problem that I could fix on my own. So I've created a process to solve this problem. My solution was to flag everything that I should read and reply.
My rules were as follows:
Let me say that it's not easy to keep up with emails. We all have way to emails in our inbox than we care to go through. But that does not mean that we can neglect replying to those emails from people that we serve.
Let's do our job well. Don't sit on the reply.
---
I thought I was different. I thought I knew better. I somehow felt that I did not have to subject myself to explain every details of my thought process. I believed that sharing too much detail was counter productive. What mattered the most was the result, the final answer.
It may have been watching too much Apple commercials in the late 1990's. Or it may have been cockiness of a recent graduate where just about everything was graded on a curve. I fell into the trap of thinking that I was different, and I knew a better way to deal with emails.
And that led to not sharing information quickly. I would rather have the perfect final answer in an email rather than sending a premature half-baked reply. When I get an email requesting for some information, I would dig up my old email to confirm, retest the code to validate and send what I personally verified data back to the requester.
It often took a few hours to reply to an email. When I did not have the answer, I would start fishing for information, consult people who might have the latest knowledge, and have multiple IM conversations to figure out the sender's intent. Only when I had a sure answer to give, I would sit down to craft a message that I would feel proud of.
It worked okay when I was working at a 5-person startup. But I soon realized that this was not scalable. Once I moved from solo coder position to manager role, my email volume just about tripled, not counting the automated emails. Once I moved from engineering manager role to product manager role, my email volume doubled again. Now I routinely get emails up to 200 messages a day.
In addition to my old email habit not scaling, I realized that it had other unintended consequences:
1. My behavior was destroying the trust.
Whenever I did not give timely response, the sender did not know whether I saw the message and was working on it. It left the sender wondering whether to resend the message. It created doubt and uncertainty. In turn they were destroying my trustworthiness.
Just because I neglected to send a quick 'I got it' message, I was sabotaging my trust score. Even when I was working on it, the sender had no idea her answer was on its way. The consequence was exactly the opposite to what I intended. I was perceived as incompetent and not trustworthy. No one cared to know that I was busting my butts to get the best answer possible back to her. (I also wrote about how to build trust earlier.)
2. I ended up missing the deadline because things piled on.
Because it took me a long time to craft an email, I usually had dozen email requests that were waiting on my queue. Although I tried my best to answer them all, invariably I would miss a few emails with deadlines. Each time this happened, it had devastating effect on my credibility as a reliable resource.
3. I had too many goals, but very little steps.
Most emails were not simple yes or no answers. They required investigation, thinking and discussion with other members to figure out how to deal with it the right way. It created frictions between responding to the email rapidly and following up on it to properly execute the right solution. These goals where steps to get them done were not visible piled on, and it following up on those tasks even more challenging. (Read about goals and steps in my earlier post.)
4. No one knew that I was doing the work.
For some reason I thought that it did not matter whether other team members knew what I was doing or following up on their request. I thought I was on a mission to amp up the quality of our work. By providing updates when I felt they were ready to be shared, I was reducing the visibility of what I was working on and in fact lowering the team efficiency, not improving it.
5. Things seem to be working, but they really did not. I had an unique perspective to see the problems, and noticed no one was fixing them.
As a product manager, I got to see the 360 view of where my product was and where it needed to be. But those feedback were not getting injected to many conversation threads that were passing through my inbox.
I had a big problem in my hand. I needed to come up with a fix right away. Fortunately it was a problem that I could fix on my own. So I've created a process to solve this problem. My solution was to flag everything that I should read and reply.
My rules were as follows:
- Create automated rules to
- Flag everything that has my name on To: list.
- Flag everything from my customers, my boss, my boss's boss and my direct report.
- Unsubscribe any notification email that I don't know what to do with.
- Reply and unflag.
- If it does not require response, unflag.
- If I know what to say, reply and unflag.
- If I don't know what to say, schedule a time to research, reply that I will get back to it and unflag.
- When the scheduled time comes, research and reply.
- Goal is to unflag everything every single day.
Let me say that it's not easy to keep up with emails. We all have way to emails in our inbox than we care to go through. But that does not mean that we can neglect replying to those emails from people that we serve.
Let's do our job well. Don't sit on the reply.
No comments:
Post a Comment