Working as a Unit

Many of us technical folks are on teams with 3 maybe 4 or more different skill sets. Not all of which are technical in nature, some more people focused, others may focus on statistical analysis, perhaps skills that are focused on art and graphics. It takes all kinds to build software, no one person can do it all. With teams of this topology, it is easy to get stuck in a game of not my problem. Where even though you are right next to each other (physically or virtually), something that is "outside" our job description gets shoveled over to another person with the tooling to complete the remainder of the work. This behavior is even more common with the front-end/back-end engineering team split. Or worse yet, the split between engineering/quality assurance.

Why do we do this to ourselves?

Honestly, I have no scientific answer. But, as someone that has lived it in a couple different organizations. Frankly, it's easier. Or so it seems. As a QA person that finds a bug in some software. I had other things to test that have been waiting in the queue to be processed. I didn't make the bug I just found it. So I would send it back to the developer to fix their crap, while I move the next item forward. Or for some graphics, as the developer, I just want the artwork. The appearance doesn't matter to me I need a thing to put in the space so I can close the task. If there is a change to the artwork later, we can log another work item to update it in the software. Closing the task so I could move on to the next and bolster my standup update was the game. As a developer, we were graded on the number of items that we can close in a given period. As a QA team member, it was to minimize the number of defects found in production-grade environments. For years I was on teams like this, locally optimizations of my workflow.

What can we do to break this cycle?

Of all the top-performing teams I have been on and seen in action, they all have one thing in common. Understanding of each other's role on the team and the importance of flow through the team. To get to this state, the first step is that teams need to share everything. Understanding approach on how to solve the most basic of problems, both within your skill set. More importantly outside of your skill set. You may be no designer, but you can bet sitting with a designer for a couple of hours talking through the problems they are solving you will pick up something to learn. Seeing the work through the designer's lens. Hearing the questions they are asking, understanding their flow. Same with all the specialties on your team. This is no task, of course, the larger the team the more time it will take. But, where to start?

Start by doing. Imagine sharing this information for an hour with one member every week. In that hour, you may each get 30 minutes to share your part of the picture. Making time for this each week soon will become a habit. As it continues, you will have learned how to cover some of the basics for all of the team's skills. Another side effect of this sharing, your team will build stronger bonds on a more personal level. It won't take long for someone to wander off track and share that they really like gaming or see the family pictures on the desk. This new team relationship carries weight when times are difficult on the team.

With this gained empathy for each role on the team, the members are more apt to help carry the load. I have seen this on many great teams. Where one role is completely overloaded with work. An example is the beginning of a project when the UX role is putting in the work to sort how users may want to interact with the software. The developers have a vested interest in these mocks, they can jump in and tackle the better-understood areas of the design. When the development team is churning through the implementations, this same designer can become underutilized. They often jump into the working software to help tweak and test the platform along with the development team.

As this state is achieved, the team begins to understand flow through the team is the metric to measure. Work items do not matter, counts of defects caught before making their way into production do not matter. If the team can work together to create a high-quality product quickly. All of those possible defects can be quickly resolved. The team has already made great strides in optimizing for success by working as a unit to solve problems.