Self-Managed Teams Are Effective Teams

This is the snack counter in our office. It’s centrally located, which means the phrase “co-located, poly-skilled, self-managing teams of makers” is visible from pretty much anywhere in our office. I’ve written before about how our poly-skilled teams function. In that post, I touched on how our teams manage their own projects instead of reporting to a project manager. In this post, I want to talk a little more about this and to delve deeper into how self-managed teams are beneficial for makers, clients, and products alike.

Traditionally-managed software teams usually work with a dedicated project manager. It is that person’s job to watch the budget, to act as an interface between the software team and the client, and to generally make sure things are happening when and how they are supposed to happen.

A Different Approach

At Atomic Object, we don’t have dedicated project managers. Instead, product teams work together to manage their projects. At the beginning of a project, one person from the team (a designer or a developer) steps up to be the project lead. He or she takes on the extra responsibility of counting up the number of hours burned each week, watching the budget, keeping an eye on project scope and timeline, updating the spreadsheets, keeping an eye on invoices, reporting project status back to the team and the client each week, and other housekeeping duties. But just because one person is keeping an eye on the numbers, doesn’t mean everyone else is off the hook — it is everybody’s job to watch where the numbers are and to care about budget and timeline.

The Benefits of Self-Managed Teams

Why should a designer or developer spend his or her valuable time working on budget spreadsheets and writing status reports? I can tell you firsthand that the benefits to this approach are many.

1. Enhanced Communication

When thoughts, feedback, and requirements are passed back and forth from client to product team with a project manager acting as an intermediary, it’s easy for messages to become garbled, diluted, or misunderstood. Extra layers of communication tend to cause confusion, not mitigate it. When software teams communicate directly with clients and customers, there is less chance for misunderstandings, and they can be clarified right away.

2. Faster Communication Cycles

In agile, it’s important for clients and product teams to be responsive to one another so that the project can progress. If a project manager is acting as an intermediary, there is the potential for information to bottleneck. When the lines of communication are direct, things get done quicker.

3. Increased Trust between Client & Product Team

When we interface directly with our clients, we come to know them and develop increased empathy for their needs and their goals for their product. Likewise, when our clients see product teams in action and communicate with us regularly, they develop trust in us and confidence in our ability to create a great product for them.

4. Decreased Conflict

In the traditional setup, there is potential for an adversarial relationship to develop between the project manager and the software team. Often, the project manager has to act as the “heavy,” laying the smack down when it comes to budget and timeline. He or she also has to be the bearer of bad news if the client is unhappy. When teams do a good job of managing their own projects, budget and timeline are kept under control, and unhappy clients are rare.

5. Increased Motivation

Since I’ve become a project lead, the project budget is now My Budget, and the timeline is My Timeline. Every week, when I run the calculations and report back to the team about our progress, our budget, and our timeline, I get to see firsthand the impact that our work has made. Watching the numbers every week also prompts me to think about how we can increase efficiency in our work, and thus build a better product for the same amount of money (or less.)

6. Informed Decision-making

Because we’re personally involved with the data every week, my team and I know the impact that our decisions make for our projects. When we’re writing code, thinking about adding features or tinkering with the interactive design, we bring firsthand, experiential knowledge of how our decisions will affect the product, from both the technical and business perspectives.