October 29, 2005
Writing and receiving emails at work can be challenging. Itâ€™s definitely a learned art, one thatâ€™s critical to career success. If youâ€™re too reactive, you can accidentally send emails that you regret or read ones that you misinterpret. At times, you have to assert yourself by defining boundaries with a colleague, but if thatâ€™s the case, I wouldnâ€™t use email to convey those boundaries. I recommend going directly to the source. My point is emails can escalate quickly, creating unintended consequences.
It was an interesting day for unintended consequences. First, I read CTO’s initial email response, which was positive to my demo changes and proposed new features and functionality. I had laid the groundwork with the CTO, preparing him for my ideas in a casual one-on-one discussion. Then I received a second email and didn’t know how to take it. Was he threatened? Was he defining boundaries between Marketing and his department? Here’s his response:
<Beginning of email>
Look and Feel of Website and Demo
You should decide what design and UI architecture you want on the demo site going forward. My goal is to give feedback, as requested. Take what you want, discard the rest: it’s up to you. This is our main sales tool and as such should fit in seamlessly with the rest of the marketing and sales tools/branding/activity and be under your control. I’d like to get out of the sales tools business all together, but happy to help when requested.
In this way, you’re functioning for our public site/demo site in the same way that the marketing folks at the client decide how the center fits into their existing public site and intranet. We’re going to start to treat ourselves like one of our clients. This is a huge step up from our current “cobbler’s daughter has no shoes” status of our own website.
Feature Set Definition, Design, and Deployment
As for the feature set, my philosophy is to define features that are responses to:
- Client descriptions of existing problems with their current processes
- Client complaints of our current functionality
This philosophy leads to the following process:
- Problems are articulated throughout our engagement with the client [sales, technical close, kickoff, and post-launch]
- They are prioritized by the number of client requests or by the importance of the client or both
- We then cook up screenshots
- We immediately vet these ideas against the clients, so that we can see if we were successful above
- We repeat this cycle 3 or 4 times, until we get us and the beta client to agree
- We then build it for the beta client
- Add it to demo
- Demo the new feature to the rest of our clients as part of their feature upgrade. Start demoing to new clients, as well
- Repeat steps 5 and 6 for each client. Usually only a cycle or two for clients 2-5, by client 5, feature is complete
This method has many advantages over the current product development best practices bandied about by others. The main advantages are:
- The voice of the customer is heard early and often
- We’re able to define/design/build/deploy rapidly, shortening feature cycle time
It’s this ability to be faster that is our core source of competitive advantage. Happy to chat more in management meeting or breakout. This topic hasn’t formally come up, which is why I think it’s helpful to have the whole group participate in the discussion.
<End of email>
Get an Objective Point of View
Perhaps the CTO was threatened? Maybe yes or may no. Either way, I respected his explanation of the boundaries between his function and mine, while also explaining our product development process. I took the approach of not replying to this email that was sent to Tom and me, copying COO, and Controller.
Instead, I talked with my new work buddy, the Controller, to get his advice on the matter. The Controller said that he hasn’t clashed with the CTO yet, but that’s mostly because heâ€™s a finance guy so there isn’t much overlap. The Controller did mention that the CTO likes to get his way, using email to document something carefully, if he feels strongly about it. I gave the Controller the background of the situation, mentioning that I tried to lay the groundwork, so the CTO wouldn’t be completely taken off guard.
“I’ve been in this industry for ten year as a product marketing manager, product manager, authored product requirements, functional specifications, and designed admin backend tools for my own product. I also know business intelligence and reporting. Our product is simple, not complicated, nothing compared to products I’ve had to manage. I know my this area. That’s why I’m so excited about our product because is simple, but has so much potential in its simple elegance. I just need to figure out how to share all this knowledge with CTO in a way that doesn’t threaten him. I know he’s smart and does the right thing.” The Controller acknowledged my comments and replied, “I know that the CTO had to learn this industry. He’s a quick study, so I think he’ll be open to your ideas. Just talk to him.” I thanked him, knowing that I’d be talking to the CTO shortly.
Back Peddle, Back Peddle, Back Peddle, then Clarify
Seconds after the Controller gave me advice, I found the CTO in the boardroom next to my office. He looked nervous when I entered the room. At first, he couldn’t meet my eyes, and then finally said, “I really like what you came up with. See how it solves some of the client requests we’ve had. [the CTO opens the email from his first reply, the one that was positive.] It will save us so much time in supporting our clients.”
Sensitive to how he appeared to be feeling, I kept my facial features attentive while trying to evoke a kind Mona Lisa smile, letting him know that I had no issue with his second email. I kept the friendly look, validating what he was telling me, and then I explained the process I went through. My process unintentionally evolved into new product features and functionality that crossed into his area. I shared my ideas with him in our one-on-one discussion earlier and then sent these documented ideas in an email to him. I mentioned some of the challenges my former company had in certain areas. The CTO appeared to want to let me know that he loved my ideas and that it solved product and customer problems.
Use Patience, Compassion, and Respect
So what was the CTOâ€™s email about? Apparently, the CTO wanted to take initiative in the email, recommending how our existing client-driven process needs to evolve, so he recommended that the broader group to review it. Good for him for clarifying this for me. All is well in our universe.
The CTO feels better after talking with me. I’m still a little surprised that his email didn’t match the what I heard from him personally in the boardroom. Maybe he reconsidered? Maybe I read it wrong. It doesn’t matter. Either way, always to go the source of an email, especially if the email may appear to be confrontational or if the sender appears threatened. I always try to let people save face, regardless of the situation because they are my coworkers and not enemies. I try to treat people like I would like to be treated, with patience, compassion, and respect. After all, weâ€™re working towards the same goal. Email can be so problematicâ€¦
The Smart Lemming Diary is a series that chronicles a journey of laid-off worker, who becomes a Vice President of Sales Operations & Marketing for a small entrepreneurial healthcare technology company. For previous entries in this series, click here. For the first diary entry, click here.