Earlier today one of the people who works on my team (Sudhakar Frederick, or Freddy) sent me an email challenging me to do a blog post on how I manage our technical team. He is going through his yearly review, and he found that he was able to pull his information together in record time. I don’t know if it is worthy of a blog post, but Freddy is a pretty smart guy. I learned a long time ago that it pays to listen to his opinions. I’m not sure if he wanted me to highlight another effective usage model for RTC and Jazz, or if he felt that I should highlight the management style and philosophy, so I’ll try to highlight both things.
Background
I am a pretty technical guy, and I like being a technical guy. However, at some point in time each one of us technical types runs into the horror of being recognized for our work, and rewarded with a position as a manager. For some folks the thought of it is so unpleasant that they turn the job down. I didn’t, and for the past three years I have been a manager.
IBM/Rational has a performance rating system that we go through every year. Each year people are evaluated on the results that they have achieved over the previous 12 months. Each person needs to briefly describe how their actions contributed to some type of measured results. Now the results being looked for differ depending on your job. So the relative importance of my results is viewed in the context of my current job.
So each year our technical people are asked to put together a short narrative on their significant accomplishments over the past year. The key here is that we want a focus on measurable results. Management will then go over these narratives, and be able to give people feedback on where their results rank within the organization, and then give the technical people feedback on what they can do to improve.
How We Ran Jumpstart – and Run Emerging Technologies
When the Jumpstart team formed, we decided that the best way to learn everything about Jazz was to actually use the tools ourselves. So while RTC might not be a perfect fit for team focused on customer enablement and education, it can do a pretty good job. We designed our own work items, with one type representing our customer engagements, as well as the existing Agile work items for epics, stories and tasks.
We record information in the work items, using the discussion area to keep notes, observations, and to share the progress that we make. We record what we have done, what we learn, and current status of our various tasks and customer engagements. By having someone indicated as an owner of each work item, we force ourselves to be accountable for moving things forward. We also added an additional owners field which we use to indicate efforts where a small team of people are collaborating on something. My team runs with the motto of, “if it isn’t on my dashboard, then it doesn’t exist”.
When we help customers, or provide some sort of enablement and training session, we record these in a specific work item type. We also use epics, stories, and tasks, to help define and track the work that we do that might not be related to a specific customer. So if we know that we want to create a “Getting Started Guide”, we will create an epic for this. Then each chapter of the guide will be a story that is a child of this epic. In this way we can divide the work across the team, while everyone is able to see what the other guide authors are working on.
Because we collect notes and observations on ALL of our work, the Jazz instance becomes something of a knowledge base for my team. We often get questions from either our IBM field teams or our customers that we know we have seen before. We just cannot remember the answer. When this happens, we can go back through our old work items and search for the situation that we dimly remember from before. Even if we have not noted the solution to the issue in the work item, we can see other people who were involved, and this often allows us to get input from other people who DO remember how to address that particular situation.
We also use the subscribers field in ALL of our work items, and add the names of team members (or managers) that we want to be aware of what is happening with any particular piece of work. One of our other techniques is to use @username in the discussion areas of our work items. When someone is called out in the subscribers area, or in the discussion through the use of their username, they will get an email alerting them to changes in the work item. It’s a simple technique that we use to help us get the right people involved in any work that we are doing.
This is all predicated on people updating their work items, and in people keeping their notes in the discussion area of the work items. As long as we stay disciplined about this, then we all reap the benefits of this approach.
How We Share Our Information
We use dashboards, and I refuse to use slides. We have multiple Jazz instances within our organization, and I need to be able to share information with all of these stakeholders. Some of this information is direct from the widgets that I use on the dashboard that my team uses. Because we use special work items for our customer engagements, we are able to easily create queries and widgets that quickly inform people who we are working with, and what we are working on. In these instances, we need to establish friend relationships between the different Jazz instances.
We use a common convention on what we use for the Summary field of our work items. We use the customer name followed by WHAT you are helping them with. This allows me to use Work Item widgets coupled with queries on open work, to provide a quick list of the things that my team is doing.
How do I filter out just the open content? I look at the state of the work item, and check to see that it is unresolved. To see not just what is open, but what people have been working on, I use a different query. In this Active work query, I look at the open work items, and then I add an additional condition that the Modified Date is after some period of time (I use 14 days, so I see what we have been working on in the past two weeks). This allows the team to see what has really been actively worked on in the past 14 days.
I often provide analysis and bullets that help describe the data that we are posting on our dashboards. This is usually in the form of single sentences and bullet lists, which is EASY to do with HTML. I used to do this with HTML widgets, but I quickly ran into the issue of having to update the same HTML widget in multiple dashboards. I didn’t like doing that, and I made mistakes. Not a good solution. So I decided that I could leverage the new External Content widgets in Jazz. These widgets allow me to build some simple HTML pages, and then provide a simple pointer to include the content from those pages on my dashboard. And on a bunch of other dashboards. So I now can just update a simple HTML status file, and my updates get reflected immediately on ALL of the dashboards of my various stakeholders. This allows me to focus on giving all of my stakeholders a consistent message and content, based on real data from my team, with each of them seeing the things in the context that they want to see.
Using this approach, with some simple HTML files used to report common status across multiple Jazz instances, does have a downside. Our various Jazz instances use secure HTTP (with an https:// web address). My simple HTML status pages are served out as unsecure http content (with an http:// web address). Newer browser versions will often block this content by default. You can get around this in a couple of ways:
The first option is the best option, but for the short term I am currently employing option #2. I don’t have an secure HTTP server just lying around that I can use to host my little status updates.
What Do People Think?
My bosses love being able to surf around and see how my team is doing. They love having this ability. They also like being able to put widgets that update automatically on their own dashboards. They probably also love the fact that they can find out what my team is doing without having to actually talk to me (although none of them will admit it!).
I like only having to update a small set of HTML files to report a consistent message to all of my stakeholders. If I use a WYSIWYG editor to access those, then I can essentially give this to someone who is not technical, and have the reasonable expectation that they would be able to successfully use this solution.
My team loves this because they get to tell me what is happening, as it happens. When we talk, they don’t have to remember everything that they have done over the past week. If they have been updating their work items, then I already know about it. No need for status reports! (Hooray! I hate writing status reports, and I hate reading status reports.) It allows us to focus on and discuss the issues that we can collaborate on and resolve together. When we get to end of the year reviews, my team can easily do reports and queries that remind them of all of the work that they did during the year. They are able to easily and quickly pull together a powerful narrative that highlights their accomplishments and results from the past year. It also helps us validate who participated in certain efforts, and by looking at the work items, we can determine the relative contributions made by our team members.
As a manager, I love it. It allows me to see things at a glance, and see what my team is involved in. By looking into the work items, I can “get up to speed” on any issues that have come up, and I can ask intelligent questions to help people discover solutions to their problems. So while the dashboard gives me good information, it is only valuable in that it allows me to ask good questions. You cannot just use it to blindly drive your team, and I don’t try to. What it does do is give me an efficient way to get an overview of what we are doing, how we are doing it, and discover ways that I can help us improve. It also gives me a way to consistently report status and analysis to my numerous stakeholders, so they can all have a consistent picture of how my team is performing, and the things that we see in our customer environments.
Key Points to Remember
- In a team with people solving new problems and discovering new approaches every day, it is important to capture this knowledge somewhere. We often get so focused on the NEXT thing, that we forget about the solutions that we have already discovered. Being disciplined about updating work items helps us remember things, and helps us share information inside of our team.
- We use subscription and the “@username” indicator in discussions a lot. We use this to pull people into conversations and work. You team should have a culture of holding each other accountable to responding to these types of alerts.
- We also use the tags field. We use this to tag certain work items for inclusion in very specific searches. If I have a series of work items related to a particular issue, or pattern of issues, then I will tag all of the work items with the same tag, and create a query that returns only the work items with this tag. That allows me to use a work item widget with this query on my dashboards to bring these things some executive level visibility.
- I create dashboards for a lot of my stakeholders. I use the team dashboard for my team, but I create a personal dashboard (and then share it) for many of my stakeholders. If stakeholders only care about a subset of the activity that my team does, I create a specific tab for them on this dashboard. That way they can see things in the context that they want to see.
Dan Toczala's Blog 