Taking Baby Steps (part 3): Dashboards - A managerial love story

Overview
Part 2 of this series "Taking Baby Steps (part 2): Only one person reads my Blog and I've already won" discussed some ways in which posts to personal, work-related Blogs (aka Knowledge Bases) are relevant to our team-mates and managers. Additionally, techniques on targeting posts through use of Tags were also presented.

In this 3rd post, I will talk about Dashboards, what they're for and how to set them up.

The Basic Unit of Information about which people relate at work
Projects.

Just the "sweet spot", please
There is an inverse relationship between someone's social proximity (in a "Social Degrees of Separation" sense) and their

1. Tolerance for Irrelevant Information
   
2. Amount of time willingly spent extrapolating "important" information

That is, the farther apart two people are in a socio-professional environment, the smaller their overlap of interests. Let's say 70% of my time is dedicated to Project A and 30% to Project B. My colleague Bob also dedicates 30% of his time to Project B. What this means is that out of all the information and knowledge I deal with on a daily basis, only 30% of it is relevant to Bob and I only have 30% of my time available to share this information.

Furthermore, depending on the roles being played, it is important to understand which 30% of Project B Bob focuses on. If Bob is the Project Manager, odds are that the details of your application's algorithm beyond a statement that "it works" is not very relevant to Bob. Including Bob in day-to-day, back-and-forth conversation about algorithm optimizations negatively impacts Bobs productivity given his slice of the pie. This should not be interpreted as "Bob should be left in the dark for the other 70%". Rather:

• Amount of information sent through the pipe is important.
  
• Quality of information is very important
• Order of information is also important

Some elaboration. For example, most people skim through email until something of importance catches their eye. Then they will read around that which jumped out. This is an act of validation. The reader is Gauging and Confirming Level of Relevancy. As was stated earlier, we all have a threshold. Whether this is acknowledged or not, we all associate Quality of information relayed to us with the originator of the communication. We even have functionality built into our email clients to reward those sources of information that we believe to consistently relay High Quality information. People whose communications I wish to help penetrate through "my" noise get their own Mail Folder and a Rule. The Folder makes it into my Top 5 and so on. Rather than skimming I tend to read these communications "normally". High Quality/Highly Relevant information from the originator creates a level of Trust. Perhaps its a bit too cliche to claim that Trust allows for solid Feedback Loops. Rather, its very clear that a lack of Trust results in a well stocked Trash.

Ideally, communications to Bob are well targeted bringing the 30% of the project Bob is involved in to the forefront. (Bob thanks me for not wasting his time.)

A not so "Side Note". I really dislike emails that say "FYI" followed by a long thread of bracketed who-knows-what. Figuring out the part that is in fact For My Information will require me to skim not just one email, but all the accompanying threads. Cliff Notes at the top, please!

Information Trickle
Why do "executive" summaries exist everywhere but in our routine communications within our Social Networks? The "Cliff Notes" quip above actually deserves some discussion. Clues about content subject matter and how it pertains to "me" are very helpful because they grant me the opportunity to cash out sooner rather than later. Tags are great but not as great as a one-sentence summary that speaks right to my forehead. Descriptive titles/subjects also help a great deal!

Whether we skim, or jump back and forth as we consume written information, it is still done (for must of us) in a linear way. Pardon the nerdy analogy but this is like a Disk Head tracking back and forth over a Hard Drive. Meta information about files, directories etc in all File Systems is also at the "top". Search Engines construct indexes that pull out relevant information so that from then on the engine can gauge a match - "this data is relevant" - as quickly and efficiently as possible. There are many other examples of almost identical optimizations that happen in technology because we demand it. Somehow, similar optimizations fail to make it into routine meeting, emails, phone conversations, and so on. It would be nice to have that Trickle from High Level but High Quality information to Low Level details in all mediums of communication.

Dashboards are about creating this kind of Information Trickle for other forms of Project-related information.

Dashboards and RSS Feeds go hand in hand

My Dashboard at work contains the following:

• Tab 1: 20,000 feet -
  Idea here is to create that High-level but informative "At-A-Glance" View of team-wide activity. This High Level but High Quality landing page is relevant to anyone who may be interested in the activities of the team. For a manager 1 or more Social Degrees away, this is a good place to begin "dipping" into our "world" without being overwhelmed by all the details. For my team-mates, this Tab can serve as the Sync-Point for meeting agendas, follow-ups, Iteration refinement and so on. My team-mates will most likely want/need to drill deeper, the manager 1 or more Social Degrees away will not!
  
  Specifically, our first Tab contains:
  
• Changes to Production - Feeds that describe changes to portions of the "production" environment we are responsible for. This is a feed coming out of our Turnover Control System. It's not RSS at this point but hopefully will be soon.
  
• Work plan for the entire team spanning 2 weeks time (this is the Two-week Iteration). This is just an aggregate feed that collates Two-week Iterations from individual product blogs based on the "iteration" Tag.
• Top 5 Bugs or Issues spanning all our products. This is yet another RSS Feed filtered for items tagged or flagged as "important" from our issue tracking system.
  
• Links that allow the reader to subscribe to any of the RSS feeds exposed on the page
  

• Tab 2-x: Product-specific pages
  Each of these Tabs is dedicated to a specific Product/Project the team works on. These tabs are a natural "drill-target" from the 1st Tab. My Product Tabs contain:
• Changes to productions affecting this specific product
• Iteration posts for this product. This is a regular RSS Feed coming form my Product Blog filtered on the "iteration" tag.
• News Items or Alerts coming from the Blog or the Product Site. (The Product Site tends to target the end-user/customer. It's not very technical but provides enough insight about the Product's stage in it's life cycle, and the standard "what" and "how")
• Top 5 Bugs or Issues for this specific product/project
• Links that allow the reader to subscribe to any of the RSS feeds exposed on the page

RSS Feeds are a natural way to "summarize" content that lives elsewhere. As you can see, no content is actually managed by the Dashboard. The Dashboard simply assembles information into easily consumable pieces. The Trickle is enabled by:

• At-a-Glance views of tightly-correlated information
  
• Ability to stay High-Level yet still obtain more detail. The reader can explore Product-specific Tabs without leaving the context of the Dashboard.
• Link-backs to the source of information. The reader can drill even deeper by clicking on any item in any of the feeds and be taken to the full "article". The reader does this by choice - this is key.

Technologies at Play

1. Blogs with RSS capabilities -
   Blogs tend to be more appropriate for Weekly Summaries and Iteration posts. My Blog allows me to publish via email so I don't have to change my habits to post. I publish from my Email Client.
   
2. RSS Web Part -
   RSS is not just about getting news from slashdot. It can be a very powerful Glue for information that lives everywhere yet needs to be correlated in a single View.
3. A portal framework with a Tabs Layout -
   The Sharepoints of the world all have this built in. Acquiring RSS Web Parts is also not too difficult. Some Wikis out there (like Twiki or Confluence) allow you to inject all sorts of content into a single page view, including RSS. These are all basic things. As always, your friendly neighborhood IT department will have some options for you.
   

How to get started
Naturally, I recommend taking "baby" steps. Most teams will fall into two categories:

1. A lot of unorganized documentation floating around in multiple formats
2. All project-related know-how is stored in the brain of the guy two weeks away from retirement

For folks that fall into the 1st group, it's a matter of figuring out the kind of information that is most useful to highlight on a dashboard. Some teams I've worked with went straight to:

• Top Bugs
• Testing Results
• Latest activity around portfolio work for a client

Folks falling into the 2nd category should consider starting with Personal, Ad-hoc Knowledge Bases and expanding out from there.

In general, the type of information that is of Highest Value to your social network should be exposed first. The gains will be emergent and will inspire further investment into not just the Dashboards but also into creating and persisting the High Quality data underneath.

Conclusion and what's up next
Dashboards just front the Collaborative Environment. If the information in Product Blogs, Wikis, etc is not up-to-date, Dashboard's highlights are meaningless. It does take some work and consistency to provide this kind of transparency to your team, your manager and your customers.

Typically, gate-keeping Knowledge Bases and their Dashboards is the responsibility of Team Leads and Product or Project Managers. To get started though, all you need is a Champion, someone who will get the team going, while incrementally proving value. Once your manager is convinced (unless of course you are the manager) some top-down "encouragement" never hurts.

In my next post, I will propose a 10-Step Plan to putting these concepts to practice so we can move on to topics such as Wikis, Issue Tracking, and Interruption Management.

Firefox EWG - Meeting #3

Summary
Call on Sept 19th was about useful Extensions for the Enterprise. A larger portion of the meeting, however focused on the apparent dwindling interest in Enterprise Firefox within the larger community.

Is the Enterprise simply not ready to bring Firefox in-house? Or, are the majority of institutional adopters simply happy with a consumer product floating about?

Perhaps one of the problems is that we still talk about Firefox as a Web Browser as opposed to a "Productivity Platform" for the Desktop.

Firefox is a Productivity Platform
All the features that make Firefox a consumer favorite deal with productivity. Tabs, keywords, search bars, extensions, dictionaries, etc help us be effective and productive in our work and home lives. When consumer says "better usability", enterprise says "better productivity".

Mike Kaply spoke about adoption at IBM. Developers are finding ways to enhance the end-user experience by writing custom extensions for Firefox. Whether the extensions glue several applications together or simply automate the tedious process of filling out web-forms, end result is a boost to productivity.

If Firefox is the gateway or glue between what's on the Desktop and what's on the network, potential for productivity-boosting application is something to ponder.

Raising awareness
Mike and I are going to take lead on a few initiatives to help raise awareness on the Enterprise Firefox front:

• 10 Steps to adopting Firefox in the Enterprise -
  Now that we've begun to pool experiences, we should be able to bake out a definitive guide of sorts for things to consider when bringing Firefox into an enterprise environment
• Good Ol' Conference -
  We will begin looking at opportunities to present at some Conferences
• Blogging - check...
• Code Day and Training -
  The learning curve for any kind of Mozilla-related development is rather high. Perhaps training targeting institutions and enterprises (like an Enterprise track) will help developers scale this wall.
  
• Enterprise Firefox Incubator -
  Talk has alway been cheap. As we address settings management, security, tools etc we will kick off projects within the Enterprise Working Group.
  

Enterprise Working Group Incubator
On my end, I'm going to kick off some projects for the Incubator. Specifically there has been interest in:

• Mission Control - how to get up and running, what the back-end implementation can look like and benefits over GPO
• Customized Reporter Extension - so that you can redirect Broken Website reports to a repository on your intranet
• Managed Security Zones for Firefox - how to configure and lock capabilitiy.policy settings in Firefox, how to create a "trusted" zone and fully leverage Web2.0 technologies within your trusted intranet.

As always, if any of these topics or projects are of interest to you, please visit http://enterprisefirefox.org, participate in the calls or simply leave a comment on this here Blog.