My first prezi: Staying afloat in email

Yeah, I know, I know, Prezi isn’t exactly so new. But at work, we often have to use MS PowerPoint, and the presentations that I’ve had to prepare needed to have sufficient text so that the audience (well, more of the reader) can go through the material on their own. So anyways, my manager asked me to do some knowledge sharing in our team meeting. I took it as an opportunity to do a presentation using Prezi. That and I worked on it on my home PC which doesn’t have MS Office installed.

My presentation is about managing email, and I used my previous post on staying afloat in email as the reference for its contents. I do wish I had more time to find and add better/more images. But I did manage to sneak in a few pictures of my dog.

Just in case the embed code doesn’t work, here’s a link to the prezi.

Today’s team meeting: leadership and failure

We had our regular team meeting yesterday and Dwight shared a couple of videos. They’re both from TED talks. The first video is a talk by Derek Sivers where he shows a dancing guy whose top looks like he’ll have a pretty mean sunburn right afterwards. He starts dancing like no one’s watching, first by himself. And then one other guy joins in, and soon there’s a big crowd dancing. The video and a transcript of the video is available here: http://sivers.org/ff. The key lesson I suppose is that although leadership is important, but being a courageous follower is also important.

The next video is by David Damberger, who is the founder of Engineers Without Borders. He discusses how projects that sought to help the needy — through building physical structures like schools, wells, and such — would often fail due to lack of maintenance. And then there would be similar projects also aiming to help the same cause but also ending up with the same problems. In the end, these projects don’t end up helping as much as they should have. Here’s a link to the TEDx vid: http://tedxtalks.ted.com/video/TEDxYYC-David-Damberger-Learnin. This reminds me of the value of lessons learned. And being in the software industry, it reminded me of the Classic Mistakes that I read about from Steve McConnell’s Rapid Development: Taming Wild Software Schedules. I previously blogged about it, so I got the notes from there and shared it to the team. In my post, I said that this list is not about rubbing salt to the would or adding insult to injury. It’s about knowing what most likely could go wrong (based on what had gone wrong a LOT), and taking measures to avoid them.

When are you free?

A colleague asked me when was I free for a 30-minute meeting. I thought the answer should be pretty obvious and can easily be found out if he’d check my calendar. But then again, people don’t use the calendars the same way all throughout the company. So it might not have crossed his mind to check my Outlook calendar at all because he was using his calendar differently.

For my part, at the very least, I try to observe the following:

• Set the work hours in the Outlook Calendar. This can be set by going to File > Options > Calendar. The work hours specified more or less identifies the window when I’ll be available for work or meetings.
• When I need a particular time blocked off from meetings, I set an appointment to block it off. So just in case someone wants to set a meeting with me and checks my Outlook calendar, he/she can see that I’m not available during that particular time, and he/she can refer to my available blocks instead.
• I mark off local holidays as an all day appointment.  Recently, I’ve been doing the same for my planned vacation leaves.
• When I receive calendar invites, I try to send a response (accept / decline / set as tentative) as soon as possible. This is so that accepted invites would already show up on my calendar to hopefully keep other folks from using the same schedule.

Essentially, I try to keep my calendar clean and up-to-date for my own reference, and for reference of other folks who might need to schedule something with me.

Malabo

Malabo is a Tagalog word meaning “unclear”. So if, for example, you’re near-sighted then your eyesight is malabo. If you’re looking through glass which has smudges on it, then you can’t really see through it because it’s malabo.

On the other hand, the word’s figurative meanings are things one could find annoying and in a lot of instances quite inconvenient. Say if you’re talking with someone who’s very ambiguous, then that guy’s malabo. He says one thing and does another, then he’s malabo. She says she’ll do something and completely forgets all about it, malabo. If that other person is so confusing, again malabo.

You might be thinking that this is a ranty kind of post. As much as dealing with malabo folks can be a pain, nah… well, not so much :p. My intent on writing this is to send out an invitation to anyone reading this (most likely, just me in the future) to not be malabo. Don’t be difficult to deal with. Be straightforward. Say what you mean and mean what you say. Don’t be malabo.

Looking into improvement opportunities… Laziness FTW

I found this bit (screenshot at the left) a couple of days ago as I was going through a Business Analyst reference. It lists some common examples of improvement opportunities that a BA is likely to identify. But I think it extends to any role, after all, continuous improvement can and should be everyone’s business. Sometimes when I’ve got time to kill at the office, instead of visiting Facebook, 9gag or other time sinks, I make it a point to think about my work and my team’s work to reflect on what can still be improved. I try to leverage on “laziness” to look for ways to do things faster or make things simpler. Looking into the common examples given in the list can be a good starting point.

Automate or simplify the work people perform.
For instance, in a previous project, there were SQL queries or Unix commands that I had to run frequently. What I did was to tie them all together into scripts so I just need to run the script and then review the results afterwards. Another example is the sharing of shortcuts or other quick workarounds to the team during our test team meetings. If there are tedious tasks – especially those that have to be performed repeatedly – these could be something worth reviewing or automating. If you come across a tool that could help you do your work faster, share it.

Improve access to information.
Consolidating references into a repository that is accessible to those who need them is an example. Another example is generating reports from our defect management tool which captured information that we had to focus on (e.g., number of days the bugs remained open). In both cases, you make the relevant information easily available to those who need them. If there are things that are hard to find or hard to retrieve, yet should be available to the team, then this could be an area for improvement.

Reduce complexity of interfaces.
For most of the tools deployed to a previous team, I prepared a README reference to hopefully make it easier for them to use the tool. Another example is creating a view for our defect management tool which displayed only the fields that were relevant. The default view displayed all fields which could look a bit daunting as there were so many columns. If there’s something that looks far more complicated than it should be, then this could be something that needs to be worked on.

Increase consistency of behavior.
In my old team, there was a tendency for meetings to start late – so folks who actually come in on time end up penalized since it’s their time that gets wasted the most. This wasn’t the consistency I wanted though. What I did was I took ownership of the test team meetings and made it a point to start on time and with a prepared agenda. Another example is preparing a set of standard test cases for checks that are needed across certain applications. Without this in place, the tendency is tester X tends to miss out on some stuff, while tester Y covers them but misses out on other stuff. If there’s something that has to be done consistently, support it by reinforcing the behavior behind it or by providing some structure to reinforce it.

Eliminate redundancy.
In one project, a colleague and I did a review on test cases and we managed to eliminate some overlaps. There was tester X who worked on A, B, C; and tester Y who worked on C, D, E. They might not have been aware that they were working on C had it not been for the more holistic review. Another example is we had a couple of scripts that functioned quite similarly. One summed up a couple of fields from a text file, while another did the same thing but with the ability to do groupings. I asked a volunteer to merge them so that there’ll be only one script to use and maintain. If two folks are working on the same thing, then that might be a waste of effort; their energies could be diverted into something more useful or worthwhile. If you have more than one working solution, it could be worth examining whether the cost of maintaining them all outweighs the benefit.

(Fiction) How to NOT get people to reply to your email

(An open-ended mix of fiction and truth… Or writing you end up with when you’re short of sleep and hyperacidic)

Once upon a time, one Monday morning, Dev received an email. He and his fellow developers had given some requested estimates last week, and PM sent a follow-up email peppered with project management buzzwords.

“What the heck does she want exactly?”, buzzed Dev. Rereading the email for a second and third time didn’t help, even with squinting involved. “Oh, well. Maybe the others have a better idea.”

Later that day, Nutherdev approached Dev. “Hey, did you see PM’s email?”

“Yep,” replied Dev.

“Did you get what she was saying?”

“Nope.”

“Me neither.”

“Hi, guys, ” Yeta chimed in. “What’s up?”

“Just talking about a cryptic email we couldn’t parse, ” Nutherdev said.

“You mean PM’s mail? Yeah, I saw that too. Didn’t bother. She lost me at ‘Hello’!”

At that moment, TL walked in. “Guys, PM just pinged me following up for a reply to her email. She needed it an hour ago.”

“Where exactly in the email did she say that?”, Dev asked.

“Apparently, it was implied by ‘URGENT’ in the email subject.” TL replied with a shrug.

“But she adds that to ALL of her email?” Dev replied with an expression perfectly captured by this: O_o

“Yeah, one time she even added that to her reply approving my vacation leave, ” chuckled Yeta.

Ah, vacation leave. TL wistfully heard the words echo in his head. He quickly pulled himself back to reality, and reiterated the need for the reply.

Staying afloat in email

One of the things I’ve noticed when folks share their screens and they happen to toggle over to their email client is there’s a lot of email folder names in bold. They’ve got these unbelievable piles of unread mail. With the volume of unread mail, they tend to miss out on replying to some items, so the original sender sends a follow-up email, and so they end up with more unread mail. I guess email management isn’t exactly something that’s taught by our parents or in school. What I would like to share with younger folks is that they don’t have to work like this — drowning in email, dreading having to open their email, griping that they’ve got so much mail. These are stuff that works for me, or things that I would like to develop and encourage more with respect to email.

Inbox zero

With inbox zero, you don’t just check your email. You process it or convert it to actionable items. For any thing that comes into your inbox, there are 5 possible things you can do with it.

• Delete (or archive) – especially if it’s just spam or you know it has no relevance to what you’re working on
• Delegate – if it’s something that has to be addressed by someone else, go send it to the appropriate person. You might also want to have some system for following up.
• Respond – if it’s something you can respond to right there and then, go ahead and send your 1- or 2-line response
• Defer – this is for stuff that’ll take some time to respond to e.g., if you need to gather info first, or if it’s something that requires more thoughtful writing
• Do – if it’s going to take just a minute or two, then go right ahead and do the action needed in the mail

A thing to remember is that your inbox is not your calendar; not your address book; not a task list; not your bug list. Keep it tidy so that you’ll be able to respond more promptly, and you don’t end up feeling overwhelmed. The author of the inbox zero idea has a video explaining this much better. Around 30 minutes of the video goes to the explanation, the rest is for the Q&A.

Email charter

This site – emailcharter.org – lists 10 rules for saving our inboxes:

1. Respect recipients’ time – the fundamental rule
2. Short or slow is not rude – being terse doesn’t mean you’re cold, angry, rude. You’re just using fewer words.
3. Celebrate clarity – this also includes having a subject that clearly correlates to the content. Don’t you just hate that long “Re: Hi!” email thread.
4. Quash open-ended questions
5. Slash surplus cc’s
6. Tighten the thread – sometimes the email thread has gone for so long, the original questions or concerns have been buried and overlooked.
7. Attack attachments – don’t you just hate it when someone sends you an excel file for a little table that could’ve been copy-pasted onto the email body itself
8. Give these gifts: EOM, NNTR – add as needed to the subject line. EOM = End of message, so that the recipient won’t have to open the actual message anymore. NNTR = No need to respond, sometimes you don’t need the email response just saying “Noted, thanks.”
9. Cut contentless responses – you don’t have to reply to each and every mail especially if it’s just a “Yeah”, “Great”, “Wow, thanks”. They provide no additional value.
10. Disconnect – less time on email would mean less email. You don’t have to check your mail every minute (unless that’s what you’re actually paid to do).

Mastering the short email

This lifehack article shares a quote that I like and an outline for a 5-sentence email. First, the quote:

“I apologize that this letter is so long. I did not have the time to make it short.” – Blaise Pascal

It actually takes more effort to come up with lean, coherent content than to ramble on. But it saves more time especially if there are a lot of recipients.

Now, an outline you can use for your 5-sentence email:

1. Who are you? This might be skipped if you already have a relationship with the recipient; otherwise, in as little space as possible, explain the relevant facts about yourself.
2. What do you want? Explain why you’re writing the email, what you expect your recipient to do about it, and any relevant information they need to respond with the appropriate action.
3. Why should you get it? Or, more to the point, why should they bother? Explain why your request is important, and if relevant, what’s in it for them.
4. When do you need them to act? Open-ended requests get open-ended responses – that is, they get responded to whenever the recipient gets around to it. Be as specific as possible, so that your recipient a) has a sense of urgency, b) feels that their response is important to you, and c) feels inspired to act.

Back to an old new team

Last October, I rejoined a former team but this time as a test lead. Previously, I was a tester in this team but I got pulled out in Nov 2010 to lead another test team. That other project had come to an end, and the options that my manager had for me was to either go back or join QS (another division). I ended up going back. It was like joining a new team altogether though. Only 1 of the original set of testers I knew remained.

One of the first things I did was try to collect my bearings. I wanted to know where is what, how do I find this, and so on. It was a bit all over the place. My OC-ness kicked in and I ended up centralizing the available testing-related materials and tools, and deploying the structure to the team. I didn’t want any new guys feeling lost as I was, and I don’t think you should need to ask more than 1 person for stuff that should be readily accessible to you.

Next up, I worked on the training materials. Again, I remember having received a lot of references (some obsolete) and not knowing where to start. So I made a visual outline. In the course of doing so, I also identified needed training topics with no available references. I prepped a couple or so slides for some of the topics, and also revisited the older ones. Still a long way to go, but at least the ball is rolling. My teammate, Tin, has taken over the training area so that’s one thing off my back.

In one of our earlier test team meetings, Tin facilitated a rant session to identify potential areas for improvement. The thing with rant sessions though is they’ll only work if someone drives the initiatives for improvements, otherwise you’ll end up with just a list of rants. There were nice ideas, but there weren’t any plans on working on them. Those things won’t just happen. I asked for a copy and posted them in a tab in my excel task list. That was another thing the test team didn’t have prior, btw, a task list or a less forgettable way of tracking the stuff they were doing for the test team. So far, I’ve picked off some of the low-hanging fruits marking them off to indicate whether something was or is being done for them.

(I’m nearing the edge of the page, need to wrap up.) Feeling lost or frustrated has been the starting point for all these. There are some things that shouldn’t have to be as difficult as they are. There’ll always be something to complain about. But you either let it defeat you (in which case you’ll just keep complaining about it) or you actually do something about it. It doesn’t have to be so radical so as to change things overnight– baby steps are fine — as long as you’re heading towards something.

Be not afraid of going slowly; be only afraid of standing still.

[Notes, Feb 2012]

A mashup of 2 writings on meetings

Last year, in my more personal blog, I ranted about meetings. Currently, I’m down to 3 regular meetings per week. For the testers’ meetings, I think they previously had the meeting manager role rotate across the members. But I opted to just preside over the meetings for now and so far we’ve been starting on time, I prepare beforehand for whatever needs to be announced or discussed so I reckon the meeting goes smoothly, and we end earlier if not on time.

So I mentioned I had ranted about meetings, here are just some excerpts from the rants…

[Jul] …What turns me off about meetings anyway. Here’s the stuff I loathe about meetings… all center on it not being done right:

1. Meetings that don’t start on time. Time is eaten up waiting for everyone to arrive. And just as you’re about to start someone excuses themselves so that’s yet another delay.
2. Meetings with no agenda. No point, no objective, no direction.
3. Meetings without someone presiding well over it. When the discussion has gone off track, it simply continues to go downhill.
4. Meetings wherein attendees are ill-prepared.
5. Meetings wherein attendees are there but aren’t really present.
6. Meetings with no minutes. Yes, commit everything to memory.
7. Meetings wherein the same things are being said over and over again. This happens when folks aren’t really paying attention, or when someone comes in late and asks the same thing.
8. Meetings that drag on for hours.
9. Meetings that were set on a short notice without the slightest hint of apology for being called at a short notice. Yes, my life revolves around you — I have no other plans that would have to be moved around.

[Nov] …In instances like these, I feel penalized for actually being on time and for even bothering to book the conference room ahead of time. Which is weird because those should be as expected. So no more Ms. Nice Punctual guy. I’m setting some meeting policies.

1. Be there on time! +/- 5 minutes. Especially if you’re the one who called the meeting.
2. Notify! Notify in advance if the meeting is canceled. Notify if there are changes to the meeting. Period.
3. One third to two thirds in and the meeting hasn’t started buys me the right to consider the meeting canceled.
4. If the meeting location was initially set as TBD, let folks know where the venue is even before the meeting starts.
5. If you’ve hijacked my room reservation, I can politely kick you out of the meeting room.

Two developers working at a rate of N hrs/day…

A friend told me an odd story. Two developers from another team were allocated at a total of 40% into a particular project. They were given a task which they’ve estimated they could complete by January.

The PM Prodded and pushed. “Finish it by December,” he demanded. Eventually, after tireless nagging, the two conceded and said they will deliver by December as requested.

“How will they do that,” I wondered. Apparently, nothing changed — only the deadline. The amount of work to be done is still the same. Their measly 0.25 and 0.15 allocations were retained as is. What was the January estimate then? Had they padded their initial estimates such that it would actually be feasible to complete the task by December? Or will they have to render overtime work to cope and meet the deadline?

Instances like these make me wonder whether the PM ever did math problems while he was back in school. Joe works at a rate of N hours per day. A given task takes X hours. How many days will it take for Joe to finish his work?  Judith needs to complete a task that requires X hours in N days? How many hours per day will Judith have to work? How many Judiths are needed if each Judith can only work Z hours per day?