Imagine you’re a developer, head-down in code, when you have one of those moments where you need clarification on the details of a feature. Do you send an email or leave a message for project management, hoping to hear back soon (and by soon, I mean hopefully the next day, or week, or a day before the end of the sprint)? Do you get up from your desk and go looking for the first person who might have the answer (walking through hallways, down an elevator, out a building, across a desert, and find them after giving the secret password to a very large, very hairy body guard)? Do you pick the answer you think is best, and hope it’s not too difficult to change things later when you submit the feature to QA or your PM (but you will FIGHT tooth and nail to keep your implementation, dammit)?

What if you swiveled your chair around and asked your project manager, who is sitting just a few seats away?

What is a balanced team?

Immediate feedback loops, open communication, and frequent cross-disciplinary interaction are what drive the balanced team methodology. I recently attended a talk at, which focused on the benefits of implementing balanced teams in an organization.

Balanced teams are encouraged to co-locate, and to essentially work on top of each other. All the people responsible for finishing a project make every effort to overlap their processes, to over-communicate, and to play up the strengths of individual team members, all in an effort to prevent the road blocks that plague so many teams, such as miscommunication, lack of understanding around project goals, and disorganization.

Throughout the lifecycle of a product, each discipline (project management, design, development, QA, etc) has a higher level of involvement, which increases the ownership individual team members feel for their project. This is accomplished by including more of the team on planning meetings, by pairing on problems across disciplines, and by having various scheduled “touch points” where updates are given on a daily basis, weekly planning meetings inform the team of upcoming project focus, and team retros focus on lessons learned for moving forward.

Pros for balanced teams

Probably my favorite term from the talk was “continuous discovery.” It emphasizes that unforeseen circumstances will come up, and that they should be treated as exciting moments, not as dreaded catastrophes that bring morale down. Balanced teams embrace their mistakes, and they look forward making them because it means they’ll learn more about their processes and will be more efficient in the future. This can only translate to positives for everyone involved.

Balanced teams emphasize each person’s expertise. Even though there are multiple decision makers at every stage in the project, design still belongs to designers, prioritization still belongs to project managers, and building the product still belongs to developers. There are opportunities for people to wear multiple hats, or to blur the delineation between roles, either when they possess a skill (such as a designer with amazing CSS skills), or when their roles overlap (a designer might interview end users, and the PM might want to sit in to better understand prioritization).

There was also a refreshing awareness that one discipline might not always have the best answer. In early planning stages, why not bring the developer in, to see if they can poke holes in early logic, point out edge cases, or to prevent the entire project from promising more than it can possibly accomplish? Later on in the project lifecycle, having more people involved in the process more likely translates to better decision making, just by virtue of having more brains thinking through the same problems.

Potential downsides

The balanced team methodology talk was presented by Pivotal Labs, who uses balanced teams in its offices around the world for consultancy work. They work in the same office as their teammates, they can turn their chair around and ask a question to the person who has the answer. So, what about remote and distributed teams? Although their answers seemed much more theoretical and less tried-and-true, they continually returned to one piece that balanced teams has taught them: communication is everything. Whether you set up a slack channel, increase your touch points, implement retros, or ensure that your team physically meets at least once a quarter, it is your team’s job to find the communication breaches and fix them. Talk often. And then talk some more.


The most striking pattern I noticed from the question and answer session was that people who don’t have balanced teams were very rigid when thinking about their teams. They seemed hesitant to “blur the lines.” They wanted rules and regulations. They wanted a formula for success. We all want that! But the lesson here is that you’ll never find it if you don’t dig deep. You need to implement a system where you start communicating better, and that also includes following up and learning from mistakes in a positive way. As a team.