Category: team communication

I am currently reading the book The Art of Scalability by Marty Abbott and Michael Fisher, both of them ex-eBay executives. An approach they have described to make sure the entire product development team stays on top of things caught my attention. The model they recommend to use is called the RASCI model. It stands for:

R – Responsible – Individual(s) responsible for a task, project or initiative.

A – Accountable – Individual(s) to whom R is accountable to for the completion of the task, project or initiative. This individual(s) will need to approve the task, project or initiative before it gets underway.

S – Supportive –  Individual(s) that will need to support the task by providing resources towards completion of the task, project or initiative.

C – Consulted – Individual(s) that may need to be consulted because they may have data or information that will be useful to complete the task, project or initiative.

I – Informed – Individual(s) that need to be notified or kept informed of the progress of the task. They do not need to be consulted or asked to provide input to the task, project or initiative.

I believe that communications is a root cause for many of the organizational problems. For whatever reason, there is a tipping point in an organization’s growth where communications is ignored because it is taken for granted – “of course everyone knows” is a bad assumption that often gets made – and the net result ends up to be big surprises, annoyances, discontent and frustration.

Given that we as software product managers have to communicate with most of the other departments in the company, I thought the RASCI approach would come in very handy. I have previously written a post where I believe that if there is no head or a date associated with any task, it is not getting done.

About the book

Full disclosure – I was send a free copy by Michael Fisher so that I can read it and write a review here. While I am still reading it, I like the novel approach they are recommending for creating a scalable company. Given that both of the authors are highly technical, I expected the book to be about how to architect your software such that it can scale and not have any performance degradation as the number of users grow. Instead, the book is more about how to create an organization that will scale when business grows. Based on what I have read so far, I do recommend that you check this book out.

Have any of you read the book? If yes, what are your thoughts and comments?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the right column.

As  product managers, our work lives revolve around working with cross functional groups. Leading by influence and not much authority, our jobs are to motivate people to get things done for the benefit of the paying customer. Sounds easy right? But when different groups have their own goals and priorities, a product manager’s job often feels like herding cats. Even after 13+ years of doing product management in multiple companies, I am in no way close to mastering this. It is easy to unknowingly step on some one else’s shoes. It is easy to get emotionally attached to problems and solutions.

Last week when I was reflecting on my years of experience and the instances where leading a cross functional team had been challenging, something very simple occurred to me. What if we product managers always use the following as a guiding principle – Ask yourself “What? When?How? Who? and in that order”.

1. What is the problem to be solved? – Do we agree?
2. When do we need to solve it by? – Determine the priority – is it something important to solve, is it worth the time and effort?
3. How do we best solve the problem? – What is the best possible solution?
4. Who is the expert(s) in the team that is best equipped to solve the problem?

If we approach any problem in the following sequence, I think things will fall into place. The biggest challenge usually is getting everyone aligned first on the problem to be solved, then the timeline and then how best to solve it. Once the consensus sets in and team feels invested in solving the problem, who needs to do the work to solve the problem becomes the easy task. I am not trying to discount in any way that it then becomes a cakewalk, but such a structure I believe will allow all involved to step away from their emotional engagement with a problem and look at it in a very objective manner.

Thoughts?

Image: Courtesy of newsday.com

I am sure everyone is inundated with emails these days. We also have become notorious in generating a lot of these emails at work. As product managers, we are constantly required to stay in constant touch with our team members in development, quality assurance, sales, documentation, product marketing, press, PR, customers, partners and you name it.

But is there a way to tame this email monster such that it does not become a productivity killer for us and for others. I remembered a good set of tips that one of my colleagues Graham Rae, VP R&D Operations at SolidWorks (my current employer) had send us way back in 2003. I dug this up and even to this day, these are great tips to reduce the email volume. I still use them and they help a lot.

Enjoy and hopefully you can find them useful. Thanks to Graham for these valuable tips.
**********************************
Reply to all
This is the number 1 cause of controllable email excess. Most of us are guilty of perpetuating the Reply To All habit without considering the volume of unwanted email we are generating and the potential follow on explosion as the recipients exacerbate it by following up with their Replies To All. You should always consider trimming the list of people you respond to rather than doing an automatic Reply to All:

• Always ask yourself if the entire original distribution list really needs to see your specific response
• Can the distribution list be pruned as the issue comes to closure? For example some people on the list may want to see the first email that defines the issue and the last email that defines the solution or the options – the details in between are not always of interest to everyone on the distribution list
• For general announcements that go to all encompassing distribution lists like corporate distribution lists. Never use Reply to All

Distribution lists
Replying to Distribution lists can generate 10’s or 100’s of redundant emails. Again, consider if the list can be trimmed back:
• Check to see who’s on the Distribution list (double click the Distribution List to show its members). Some Distribution lists are made up of a concatenation of smaller Distribution lists – consider if one of the smaller lists would be more appropriate
• If you have Office 2003 or later, you can click the [+] sign in front of the Distribution List and it will expand to the individual members – you can then delete individual names from the list
• Check to see what Distribution Lists you’re included on that no longer apply to you. This may help reduce the amount of mail you receive. To check this:
o Create a dummy email and enter your own name
o Right mouse button over your name and select Properties. Select the “Member Of” tab. If you want to be removed form a list, select the list to find out who owns it and request they remove you.

Be economical with words
Get your point across succinctly, politely and quickly. Long emails sometimes get pushed off to be read later and may not get read to their end! – a problem if you’ve made your main point in the final few sentences.

Using the To versus Cc list
Many people have their Cc’d email go to a different Inbox folder or use a different color to identify they are Cc’d only. When you send an email or reply to an email, consider moving recipients from To list to the Cc list to help them prioritize their email. You can select and drag names between To and Cc fields.

Consider the alternatives to email that may work faster/better
Most people work better as a team when they get to know each other. Email alone doesn’t create close working relationships. Substituting email by phone calls/face-to-face discussions/meetings or webEx will over time improve overall communication and potentially reduce email. This is especially true if the person is within a few offices of your own.

If an issue is diverging, taking too long to close or the ball has been dropped then a meeting may be the way to go. Short focused meetings may be far more effective at getting agreement and decisions quickly – many times email simply can’t compete with a meeting.

Although our culture is one of fast/immediate response, some issues/questions may be able to wait until your next group meeting rather than having an email discussion

Avoid email for expressing strong emotion/strong disagreement or criticism
It’s easier to be mis-interpreted via email than by the spoken word. It’s usually far better to have these dialogs face to face or by telephone so that your emotion is not misinterpreted and you can have a 2 way conversation in real time. Make personal visits/use the telephone more often – especially if the issue is controversial or there is strong disagreement. Email messages in this situation can do more harm than good. Good working relations (especially across groups) aren’t established via email, they’re established and enhanced by personal contact

Read your email before you send it
Check:
• Can it be shortened
• Is it clear and unambiguous
• Is the tone correct
• Can the Distribution list be reduced
• Does it contain needed “calls to action”
• If you disagree with what’s being proposed in an email, offer alternative proposals/solutions
• You have included any intended attachments (surprising how many emails use Reply To All with “you forgot the attachments”)