11.22: Long Team-Focused Message

Last updated
Save as PDF

Page ID: 46280

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

Learning Objectives

Write a long team-focused message.

When considering how to communicate a fair amount of information to your team, it is wise to step back and consider which channel would be best, not only to send your message but also to allow for your colleagues to comment and interact with the rest of the team. Here is an example of a long message to a technical team sent via email.

Hi Team,

I had the opportunity to talk to some customers about our primary competitor’s new product. Here are some of the areas where it may fall short based on the feedback. Many people agree that Product X is easy to use and adopt; however, the problem is you also need to provide access and views for other users and roles across many teams so that the whole organization can view performance.

Product Managers using Product X complain that there is no way for them to manage a single backlog for multiple teams or report back on how the teams are doing on higher-level initiatives. As PMs you need a lot more than issue tracking to manage the growth and development of your product line.

Portfolio Managers involved in setting strategy are limited with Product X on how to represent investment themes in an agile enterprise. They need more visibility than just an iteration or two of work. The need would be for more layers than just a stream of customer requests and defects.

For Development Managers and Engineering Managers, Product X doesn’t provide them the ability to do capacity planning. At the root of that is the ability to get a good understanding of their team’s velocity—something that is not possible if you can’t split stories across multiple iterations. In the Product X world, you have to move the whole story if you can’t finish the story in one iteration. As a result, stories languish across multiple iterations, and the whole concept of velocity is lost. With no understanding of a team’s velocity, productivity improvements and predictability metrics are lost as well. With no capacity planning across multiple teams—or people split among teams—managers struggle with their ability to manage people and resources needed to meet their commitments.

Program Managers complain that they are “swimming in a sea of user stories” that are not associated with higher-level objectives. There is no concept of a multiple project hierarchy.

I will keep you posted when I receive more feedback.

Thanks,

Ellie

What can we say about this message? Yes, it is long and contains much detail. The author has broken it up nicely with boldface headings to make it more readable. Besides using email to send this message, what other means could the author use to inform the team in the most interactive way? Certainly short message forms like IM, text, and chat would not be appropriate for the volume of information.

A report, blog, podcast or document- sharing repository could handle the amount of information, but each would have some drawbacks. Reports are good for large amounts of data but are not interactive in nature. Podcasts would also be good for the first viewing, but they are static, and the information is not searchable. A blog could be a good answer because it could become a “living” document for team members to append as more information about the competitor’s product become available. The drawbacks of using a blog in this scenario would be managing hundreds of such blogs being used for multiple topics as well as quickly finding the blog you want in the corporate wiki. The same drawbacks could be in play with standard document-sharing technology when you have hundreds or thousands of emails or documents to handle.

The best way to send and manage long, team-focused messages could be to take advantage of some of the new team collaboration software platforms. Applications like Stride, Slack, Workplace, Flowdock and others help teams keep related information—whether it is received as a IM, chat, email, report, or podcast—organized by topic or subject category, including the feedback from team members adding new content or commenting on existing material. (See Module 9: Communicating Through Technology for more information on collaboration software/multi-feature online platforms.)

Figure 1 shows Facebook’s Workplace. All of the messages, chats and announcements on the page look to be general team information. For a specific project, you could envision everything on a page having to do with that project—e.g. emails, team chats, links to related outside articles, links to related areas in the wiki—collected in one place.

Figure 1. Workplace by Facebook is just one collaboration platform you could use

Practice Question

https://assessments.lumenlearning.co...sessments/8668

Contributors and Attributions

Long Team-Focused Message. Authored by: Robert Danielson. Provided by: Lumen Learning. License: CC BY: Attribution