We’ve been privileged to work with some very large teams. Each time we do, I learn more about the intricate balance between unity and diversity. The following are some thoughts concerning how we’ve gotten where we are and how we can continue to get better.
Enterprise Teams
Part 1: A Divided Team
I remember the days when every major company employed a webmaster, that mythical creature capable of building the server, writing the copy, designing the site, and deploying it. Webmasters. Masters of the World Wide Web. The webmaster was all-powerful—the one human standing between a major brand and the largest audience any company had ever considered. It didn’t take long for us to realize the people who were best at writing code weren’t always the best at deciding how the site should look. So, we split the webmaster role into web developers and web designers. These days, we have information architects, content strategists, UX researchers, UX designers, UI designers, frontend designers, frontend developers, software engineers, database administrators, product—and project—managers...and the list goes on.
I’m afraid the fracturing of our roles is leading to a Web of fractured experiences. I’ve written about this before, but I still have the same underlying concern that prompted that first writing.
Nowhere is the pain of fractured roles more evident to me than when looking at common enterprise team dynamics. Working with large teams is exciting. We have the budget to build a real team—breadth through specialization and depth through expertise! On the other hand, we generally have two warring factions: IT (or Development) vs Communications (or Marketing). Why is it that most major companies still spread the ownership of the single most important platform for reaching potential customers across two different groups? I’m dumbfounded by this. Perhaps there was a time in our history when this structure made sense. But the more meetings I sit in where I can tell that the IT group and the Communications group simply don’t get along, the more I’m reminded of Einstein’s definition of insanity: “...doing the same thing over and over again and expecting different results.” How can enterprise teams do great work if they can’t stand to sit in the same room together?
Part 2: A Divided Process
I remember when Ethan Marcotte wrote Responsive Web Design. The article that shifted our industry toward a more flexible design approach. The idea that our sites should be smart enough to adjust themselves to display well on any screen size was not new, but the techniques to make it happen were. And all at once, our process was broken. Suddenly, it wasn’t enough to have UI designers do the design and frontend developers do the code. Questions like, “What happens on old Android?” Or, “Did anyone test this on a Kindle Fire?” became common in our office.
We accepted the idea that every little design change had far-reaching implications to areas typically owned by developers, and we learned that shifting the way we wrote our code could have impacts on what was possible from a user experience perspective. These seemingly independent disciplines were revealed to be so very intertwined, and wholly dependent on each other.
Over the following few years, we worked through it. “Should designers code?” “What is a frontend developer?” “How do we fix education for web design and development careers?” We dug in, and we’re still digging.
Part 3: Unity
If we’re honest, our divided teams and divided processes were always lacking. But this industry is always evolving. The increasing importance of the web as a communication platform for companies forced us to take it seriously, so we specialized the heck out of that webmaster role. The flexibility of a responsively designed web property forced those who work on the web to recognize the invalidity of our “throw it over the wall” processes, so the industry is trying to embrace that flexibility. With each major shift, we’re ridding ourselves of approaches that kept our teams segmented. So what does the future hold for those same teams?
As a leader, I am beginning to see how immensely valuable the idea of unity can be. A group of people who know where they’re headed, with a single mission, are almost unstoppable. Yet this has to be balanced with respect for all of the amazing experiences that make us individuals. And so, it comes down to values.
Values can create unity in situations where the default is more like a powder keg. I’ve seen teams transform from reluctant participants to respectful collaborators. After doing the hard work of defining what we’re all trying to accomplish, we begin to see the potential in others, not just the ways they differ from us. This can happen for your enterprise team. This can happen for your product company. This can happen for your startup. Take the time to understand why you’re doing the things you’re doing, and let that feed into a set of values your team can unify around.
Project Values
Establishing the values of a project is so important that we’ve made it a part of almost every collaboration now through our discovery process. It’s allowed us to work with disparate groups inside any company to find a common purpose. That purpose—those values—become a filter through which we can make decisions. But, more importantly, it distributes the ability to make the right decision to every person on the team. So, what are the values for your next web project? I love to talk about this, drop me a line.
