Working Together Means Owning One Thing

Note: a lot of the inspiration for this discussion came from my talk with @cap on @DeveloperTea, which you can find here: http://spec.fm/podcasts/developer-tea/17457

Digital firms, in large, have a serious problem when it comes to collaboration.

We see collaboration more like a very serious game of telephone than what it should be: building something amazing by combining the best of all of our opinions and talents towards a single, unified goal.

The pipeline for digital creation so often looks like this:

1. Idea: Come up with your message. Your app. Your selling points. Call this the content phase, or the business strategy phase.
2. Visual iteration: Come up with your aesthetic representation. We often call this the design or prototyping phase.
3. Execution and implementation: Build the functional underpinnings of your thing. We call this development.

We couldn’t be more wrong in this approach, and here’s why.

1. Partial ownership is a myth.

Pretty much any great digital product, in its prime form, has such a high level of cohesion between these separate “phases”, that (surprise) it looks like one thing.

Want to know a secret? The great products don’t separate their concerns into phases. They take the harder route — the holistic route. The best products don’t separate design from content, or development from marketing. They don’t separate business concerns from artistic integrity. The best products have a single voice — they are a singular expression, developed by highly collaborative teams composed of responsible individuals that are invested in more than their expertise; these individuals are invested in the success of the entire project.

What’s the deal with ownership, anyway? How is it that we can own one part of a whole? And yet, we hear the idea thrown around so often, that the engineering team needs to have ownership over the code, the design team over the aesthetics or experience. The marketing team over crafting conversion language, the executive team over the strategic vision.

What we say and what we mean are two different things. And this is a problem. The semantics cause a problem, because they frame our decisions.

When we say “the development team has ownership over the code”, what we mean to say is that the development team is intimately familiar with the process of writing code, and is responsible for high quality execution in that part of the project. This is a subtle, yet incredibly important, difference. If my need for ownership over the code ultimately compromises the health of the digital production that code is interconnected with, then my ownership is a problem.

If I am so dedicated to writing tests that I’m unwilling to ship a project unless it has 100% test coverage, doesn’t that endanger the time-to-market part of the business strategy? And if the business strategy proposes an entirely unrealistic timeline for developing stable software, doesn’t that compromise the quality of the product?

If we all commit to our own, separate, competing goals, then compromise becomes difficult. The goal ends up being a series of decisions to balance competing interests, instead of the goal being singular and center.

The goal should never be a side effect.

The reality is, the code is so interconnected with the design of a thing, and the marketing is so interconnected with the code, and the business strategy and content are so intertwined with everything else— owning anything means owning everything. Let me say that one more time: owning anything means owning everything. Ownership isn’t a thing, unless you own it all. Every person on the team must care about the success of the whole thing. Successful teams share ownership over one thing.

2. The pressure shouldn’t just be at the end.

When we organize our projects with the traditional pipeline approach, the pressure often falls on the development phase more heavily.

A few reasons, I think, for this phenomenon:

1. By the time the project has gotten into the hands of developers, the client (or the idea itself) has been solidified in people’s minds. This creates an environment that is hostile to change. The design and strategy of a project is often canonized before it hits development. Hopefully if you’re reading this, you already know that inflexibility to change is an enemy of progress and quality.
2. The development phase is often viewed as a waiting period rather than a creative period. Like putting a casserole in the oven. The reality is that the project is likely to change drastically when it reaches the developers in a pipeline approach, because the developers have not had a chance to weigh in on technological restrictions, and design problems are uncovered at this phase just as much (or more) than any other phase.
3. If there’s a deadline on the project, the ramifications of being late is the heaviest on the development team than on any team before them in the pipeline. Even if there isn’t a deadline, the anticipation and pressure of being the “last person” before a project is handed off puts a higher pressure on the development team.
4. The development team is viewed at as an executor of polish and bug fixing, rather than primary strategic thinking, which effectively bars the developers from being a part of the problem solving and treated as a calculated resource.

Don’t get me wrong — pressure can be a great thing. Pressure creates change, and change often creates great products. But the pressure should be shared by the whole team, because those changes affect everyone involved with the project. If the development team is the only team that is blamed for the hard parts of necessary change, then the development team naturally becomes resentful of “creativity” as a part of business, and will begin to seek concrete, logical, well-defined tasks to complete to avoid working on things that are likely to change, because they have no decision-making power at the end of the pipeline. Developers begin to hate the thing that makes a product great: the flexibility necessary to invite change.

Put yourself in this position — you receive a mockup or a wireframe, and you have some insight to a change that you would like to make. But that wireframe has already been approved. That direction has already solidified, and it’s your job to simply build it. You have to make a choice: suggest a change at this late stage, or shut up and code.

If you are asking your developers to shut up and code, you’re doing it wrong. If you hire smart individuals that you believe in as members on your development team, you are limiting their potential if they aren’t a part of the process from the beginning.

This has the effect of sharing the load of pressure to make good decisions with everyone. And the pressure to execute individual tasks becomes equally distributed at the same time. I’ll say it again: successful teams don’t split ownership. Every person on the team must care about the success of the whole thing. Successful teams share ownership over one thing.

3. Transition is Always Accompanied by Energy Loss

No matter how efficient your process is, transferring always comes with energy loss. We never work in a vacuum.

We can create processes around making transfer more efficient, certainly. A good step in that direction would be documentation, style guides, justification prose, etcetera. But if I, as a developer, enter a project with no context and I try to digest 3 months worth of process distilled into a few documents, it is impossible to gain as much context as I would have if I were present from the beginning. The transfer process — call it a handoff, or a phase shift, or whatever — is always going to result in a loss of energy that could otherwise be used to make the product better. When we create discrete phases that wall our teams away from each other and then try to connect those phases together with some kind of “process”, we lose energy. We can never become masters at those transitions, because they happen so few times in a given year.

It’s hard to practice something that you can’t repeat often.

It’s a redo every time. The context is different, the project is different. Creating processes for things we do so few times and with such variance is often revealed to be, at best, a vain effort, and at worst, restrictive and perhaps ironically, expensive.

“How then, are we supposed to collaborate?”

I’m not saying that your marketers need to know how to write SQL queries, or that you need to start sending your developers to illustration classes.

What I am saying is that we all own one thing. And when you have collective ownership, you make decisions with a perspective that is in the best interest of the thing you own. So, a relatively messy list of ideas for ways we can collaborate better:

1. Iterations and changes, more often than not, should go all the way through your team. A design iteration or business goal should not be solidified without the development team being looped in, and given a voice. A development decision shouldn’t be made without the strategic business team being involved.
2. Trust the opinions of your experts. When a member of your team suggests something, feel free to challenge them to back up their claim with justification. But remember that sometimes, it comes down to trusting the decisions of the experts on your team.
3. Being aware and having an opinion are two different things. Design by committee isn’t collaboration, and it doesn’t work. Design by committee simply attempts to balance everyone’s opinions and make them happy, and it can kill a product. If you follow the previous rule of trusting the opinions of the experts on your team, then sometimes it’s useful to reserve your opinions, and know that they are better than you (or smarter than you) at some things. Being “aware” doesn’t always mean you get your way, but rather that you always have a sense of what’s going on in the project, and your voice is valued. Some of the most powerful and successful products come from individuals. Teams that act like a group of individuals aren’t nearly as successful as a group of individuals acting like a unified team. (Remember, we all own one thing together.)
4. Visualize your team as a group sitting around a round table and the work being in the middle, rather than as an assembly line passing work down to the next person. Take a minute and think about how this simple perspective shift would change your working environment. There is no “last link in the chain”. The work is placed front and center, all the time. The work one does is seen by the other. Conflicts are resolved in person rather than via passive aggressive emails.
5. Write about what you’ve done and why, every day. I’m not kidding. In a given week, about 5–10% of your energy should go into documenting and justifying your decisions in the work you’ve done, and this should be visible by everyone on the team and open for comment (this works out to about 2–4 hours per week in a 40h/wk job, or as little as 20 minutes some days). Not only will this create a transparent and collaborative atmosphere for your work to live, but it will also force you and your team to cultivate effective communication skills and sharpened vocabulary, which will pay you back in spades. I’d even suggest that at “major milestones” (or feature releases, or whatever you call them), the person who has done the bulk of the work should digest that work into a short presentation to give to the rest of the team.
6. Cultivate interest and respect for other disciplines. In a culture of discrete partial ownership, interests are competing and can thus be viewed as the enemy. This can create a culture of malice and frustration towards other teams — a “us vs. them” feeling is all too natural when your main point of frustration is the mistakes and inaccessibility of other teams. If you all own one thing, then mistakes are less emotionally charged, and instead are addressed by the whole team together. And, by cultivating an interest and respect for the disciplines and focuses of the other practitioners on your team, you learn to understand the depth of the problems they experience. Your respect for their process naturally grows, and no one works in a black box.

Conclusion

When your team was small, fast, and awesome, there wasn’t much room for people to claim ownership over sub-parts of that team. Everyone shared everything, and when one succeeded, so did the other. How many times did one of you say, “hey, check this out!”? How often did you wear someone else’s hat for five minutes? How many times do you do it now?

Growth can cloud your vision, because the machine gets big, and you start adding extra systems to manage the size. The problem is, you’ve lost sight of the simple fact that your machine is built for one purpose, and everything you add that stands in the way of that purpose is messy.

You own one thing.

Managers, associates, executives — you all own one thing. If you ever want a project to work as smoothly as it used to when the company was small, take a lesson from your past. You own one thing.