What is a team?

A couple of months ago I gave a series of talks on creating team charters. As part of my preparation for this piece of work I asked myself a number of questions about what a team actually was, and what sorts of questions teams should be asking themselves regularly. Some of this content was used in the talks, but I’ve tried to make this article more about teams than team charters, as I’ve written and talked about these a lot elsewhere.

What is a team?

A team is a group of people who collaborate to deliver value. Value is anything that a customer would pay for.

A team doesn’t have to all report to the same person, or do the same kind of work, they just need to be able to combine their skills and expertise in a way that delivers something that someone else finds valuable.

Why does the team exist?

Each team should understand why is exists, and be able to articulate that in a short phrase. This should be a mission statement (what you do now), but may also incorporate elements of a vision statement (what you hope to achieve).

You should also understand who your stakeholders are, both the people you deliver work to, and the people outside the team who you depend on for things that you need. Ideally a team should be able to control everything it requires to deliver value, but this is unlikely to be the case in most organisations, and you are likely to have stakeholders who provide data centres, networks, offices or financial processes. Think about everything you need to do your work, and work out where it comes from, and how to get enough of it for what you need to do.

What skills does a team need?

That depends very much on what the team are responsible for delivering, but can be split into 3 main categories:

  • Subject matter expertise
  • Organisational skills
  • Leadership and management skills

These skills should be present across the team, but it’s fine for one person to have aspects of all three. What you don’t want is people who don’t have any of these skills, as they will find it harder to contribute meaningfully to the team.

How many people should be in the team?

That very much depends on what skills the team needs, and how those skills are distributed between individuals.

I like teams of 4-6 people, because they are small enough to make collective decisions quickly, but large enough to realistically contain a good mix of skills and experience. I may also add 1-2 interns, graduate trainees or apprentices, especially if the work being delivered would benefit from the unique experience people at the start of their career will bring. It’s also a good way to ensure that people starting out are being given a positive experience about what it’s like to be in a team.

How do we empower a team to be self-organising?

A self-organising team understands what it is there to do, and receives work from customers rather than managers. It prioritises work based on what value it adds to one or more customers, but also improves how the work is done so that valuable work is delivered more often. It is free to make decisions on how the work is done, providing any institution-wide restrictions are factored in. The larger the institution, the more likely a team will be restricted in some of the tools it uses, or in where and when it works, but it is still worth thinking about these things and contributing expertise towards redefining the institutional standard, rather than just using something different and then struggling to collaborate with other teams.

Working in this way can require a bit of unlearning, especially for people who hold leadership or management roles. An understanding of the key principles of Agile can help with this, as very often ceremonies associated with Agile (especially Scrum) are used to plan and deliver work in a self-organising team.

How does leadership and management work in a self-organising team?

In a traditional team you would expect the team manager to provide all (or most) of the leadership. management, and organisational skills, but also a fair amount of subject matter expertise. In an agile team we still need all of those skills, but they are more likely to be split more evenly between different team members.

How this might work:

  • One person who has a primary responsibility for ensuring that the work the team does continues to provide value to customers.
  • One person who has a primary responsibility for providing an environment for the team to do their best work.
  • Several people with subject matter expertise, who also have enough leadership, management and organisational skills to ensure that they can deliver within their subject area without hitting blockers on a daily basis.

Ensuring the skills are more equally distributed helps the team when one of more people are on holiday or otherwise unavailable to work. It means that a team is better positioned to deal with things that might slow down delivery, and that the team is not reliant on one person for many different things.

What meetings should the team attend?

There are a number of internal meetings that we find useful:

  • Daily stand up, to ensure that we have a collective understanding of what we are doing each day, and that we can identify anything where we might need help
  • Sprint planning, so that we understand what is being delivered in the next 2 weeks, and who is doing what
  • Retrospectives, to enable us to scrutinise how we work, and suggest improvements that can be fed into the next cycle

We still conduct 121 meetings, but these are less like status update meetings, and more about personal and professional development. Meeting every day to talk about our work doesn’t make 121 meetings less important, it just means we can focus them more effectively.

What about all those other meetings we attend?

Review all meetings and regular time commitments to ensure they add value to customers or directly contribute to improving how the work is done:

  • Why do you attend the meeting?
  • What contributions do you generally make?
  • What outputs do you get from the meeting, and are they valuable?

These questions should help identify meetings that could be dropped in order to free up more time for collaboration and individual contributions.

It is expected that people with leadership and management responsibilities will attend more meetings that individual contributors, but that in general there will be less meetings than in a traditional hierarchical team. Managers should be protecting their teams from meetings where possible, but this does not mean that people should stop collaborating with other teams; just that they do it in a way that only the people who are directly contributing to the collaboration are involved.

Christmas projects

I have all sorts of things planned this Christmas, some of which may happen and some of which may take a little longer to reach fruition.

  • Albums of the year (which I always do), and which will be ready on or around 31st December.
  • One movie a day, where I will watch one decent movie a day, and list them all with a few notes on why I chose them and how they all fit together.
  • A writing project, which I’ve started, and which might end up being a “one poem a day” type exercise.

It is good to have some time to work on this sort of thing, and I’m hopeful it will redress the balance a little after a year of too much work, too much responsibility and not enough creativity.

Life on the bleeding edge

I love new things.

I still get that thrill when I buy a new piece of hardware or download a new piece of software.

I still run the latest version of Ubuntu on my laptop and my netbook, and generally upgrade to the next release whilst it is still in beta.

The only drawback with this is that I occasionally run into the sort of bugs that new software is well known for. It’s been a while since I’ve come across a show-stopper, but there have been occasions where running bleeding edge software has hampered my productivity somewhat.

I’ve also recently come to the revelation that whilst I love new software, I’m also very keen on making my desktop look and feel the same no matter what operating system I’m using. Which is why it’s often very difficult to tell what version of Linux I’m running, as I tend to have a very minimalistic looking desktop that is probably quite close to how it looked in 2005 (and also quite close to how Debian 6 looks today). I also tend to use the same wallpaper on all my computers (regardless of OS) which can also muddy the water a bit.

What I seem to be moving towards now is running the latest released software at home, and dual booting between something stable and something experimental at work (where I do need to keep up with the bleeding edge of whatever I’m working on, which at time of writing is Mac OS X and Ubuntu). This ensures that I have a stable platform to use for email, writing documents etc, but that I also have the latest builds of Ubuntu and Mac OS X running on real hardware so I can iron out any potential support issues early on. I also have at least 10 virtual machines that I use regularly, and I wonder how I ever got by without Virtualbox (actually the computer graveyard in our spare room offers some clues).

What kicked of this train of thought was Ubuntu 11.04, which ships with a new default desktop called Unity. I’ve had a play with it, and don’t hate it as much as I thought I would, although I’m glad I can still make a fresh install look exactly like my existing desktop in under 5 minutes. It does seem like a further step towards the UI of Mac OS X, but as someone who has always preferred that to Windows then I don’t mind that at all. I’m still not sold on dark themes, but as I’ve said many times, these things can be changed easily.

So yes, another version of Ubuntu that I can work with and will upgrade to on my home machine. I might also spend some more time with Unity to see if it’s something that I can one day grow to love. Of course, I also wouldn’t say no to a new Mac once Lion is out, but I do get to use quite powerful Macs at work at present, which does scratch the OS X itch for now.

Job titles, and why they are important

As part of my role, I am involved in recruitment within my team. This involves reading through a lot of CVs and application forms and trying to work out some sort of correlation between a person’s job title and what they actually do. And it’s not as easy as you would think.

Take for example the humble Sandwich Artists (sometimes known as Sandwich Architects) at Subway. This role has nothing to do with art or architecture, and everything to do with making sandwiches to order, and could easily be misinterpreted when skim reading a CV. Similarly, it might be possible to misunderstand what a Nail Technician actually does, as well as misunderstanding what type of nails their skills relate to.

We have this problem in IT as well.

In IT we are blessed with legions of IT Managers, Network Specialists and Computer Officers who may have had the same job title for 15 years, even though what they do now bears no relation to either what they did 15 years ago or what other people with the same job title do now. This is particularly noticeable at conferences, where the same rough skills set might be described in 20 different ways on people’s name badges, but it also makes recruitment a bit of a minefield.

We also have a few more esoteric job titles, including a few Data Architects and Infrastructure Architects (who again are nothing to do with architecture). It’s often difficult to make a stab at what some of them do, and sometimes even the (proud?) bearers of these job titles are a little hazy about what they actually mean.

There is also the issue of job titles that only refer to a small part of what someone actually does. I’ve fallen foul of this one myself a few times, and think that is is very important that managers review the job titles, job descriptions and duties of all of their staff on a regular basis to ensure they are still fit for purpose.

It makes me think we need some sort of unity, or at least a naming convention. Should managers have to manage people, or is it fine for them just to manage a service? What makes someone a specialist, an analyst or an advisor? And shouldn’t we make job titles easier for people to understand, both internally and externally?

Maybe then we might have a chance of working out what someone does without having to read their whole job description.

Coming soon…

I have so many things I want to write about right now. Starting with some of the really productive conversations I’ve been having with staff and students about how they use IT, and ending with everything I’ve learned over the last few days at the UCISA conference in Edinburgh. I reckon that’s probably at least a few thousand words of writing, but as I’ve got a few other things to get finished first, I thought I’d at least make a list for my own benefit.

  1. The move towards phones and tablets and away from traditional computers, and what this means for service delivery and support.
  2. Why job descriptions, job titles, and what we actually DO at work should be as closely aligned as possible.
  3. Balancing innovation and stability.
  4. Google Apps, live@edu, and email for life.

I think that covers most of it for now.