With, not For

I felt bad for the manager sitting across the table from me. Let’s call him Chris (not his real name).?This meeting had not gone at all the way he expected. But let’s back up. I need to explain the context for the meeting before I explain why Chris ended up having a very bad day.

Chris and I worked for the same company, but in different parts of the organization. His group was in a centralized function supporting my department. As is common in internal accounting systems, Chris’s group charged my department for their services. No actual money changed hands, but the more funding we allocated for Chris’s group, the less budget we had for other things.

It was annual budget planning time. I was new in my role, so Chris had reached out to introduce himself. In his email he also asked me to commit to the usual level of funding. He included a rather large number. A sticker-shock-inducing number. A number that my department might have paid in the past but that I knew we could not continue to support.

I replied to Chris and asked him to help me understand where the number came from. He responded with a high level categorization. It turned out that fully half of that eye-bleedingly large number was for projects that Chris and his team had undertaken on behalf of my department.?

“Before I approve the funding, can we meet to discuss these projects?” I wrote back.

“Of course!” Chris was more than happy to explain. We set up a meeting.

At the appointed time I found myself sitting across from Chris in a small conference room. Chris hooked up his laptop to the monitor and displayed the list of projects. He started walking through the list line by line rather quickly.

Chris had strong opinions. “I’m on a mission,” he explained. “I’m going to modernize how your department develops software.”

As near as I could tell from what Chris said, no one in the department had been involved at all in shaping the work, including my predecessor. (My predecessor also had not done a good job of controlling costs, and that’s why we needed to cut the budget, but that’s a story for another time.) Every project Chris described was something he himself had decided that we needed, and that his group would do for us.

“Um,” I interrupted. “Let’s start over, back at the top of the list. I'm making some changes in the department, and we need to talk through what that means for each of these projects.”

We started at the top of the list again. As we talked through each line, Chris slowed down to explain the project’s purpose in more depth. Then we talked about how the project might or might not support the changes I was making. Each project got a designation: continue, stop, or change.

Chris’s face fell with each “stop.” By the end of the meeting, only one project was marked “continue.” The rest were “stop” or “change,” and the scope of the project list was cut by about 75%.

From a business perspective, the outcome was perfect: we got the budget back to a reasonable number and had a plan to move forward. I did feel bad for Chris; he looked devastated. However, I was confident we’d be able to partner on the remaining 25% and hoped that Chris would value that partnership.

My confidence was short-lived. (This is not a story with a happy ending. At least not for Chris.)

Chris was less enthusiastic about partnering than I hoped. Within a couple months Chris decided to leave the company. He wanted to steer the projects himself and resented the shift in direction. Without their passionate leader at the helm, the group that Chris had led disbanded. Some people left; the people who stayed moved into different roles. With no one left to continue the work Chris's team had been doing, my department took over responsibility. That suited us just fine since it gave us autonomy over building the things we needed, but I was sorry that we weren't able to make a partnership work.

Of course, I could understand Chris’s disappointment and frustration. His intentions were good, and he was right about many of the issues he identified.

However I don't think Chris quite understood the how much of a problem it was that he insisted on doing work FOR the department instead of WITH us. We had serious budget issues. He was making decisions that fundamentally shaped our world. He relied on our funding. But he was not at all accountable for our outcomes. That separation meant we weren't in the same boat. He didn't think about tradeoffs or priorities the same way we would because he didn't have to.

I've seen this FOR instead of WITH problem over and over in a variety of contexts. Other examples include:

• A tools team that built automation for developers. The scripts they delivered reflected how they thought developers should work rather than what the developers actually needed. They were frustrated every time they delivered something that the developers chose not to adopt, but continued to insist they knew better than the developers what was needed.
• An infrastructure team that built a cloud platform that no one used. They came in with past cloud experience and believed leadership would mandate use of the new platform, so they designed it without investigating the specific needs of the groups that would have to use it.
• A front end team that built a shiny new administration console for customer success agents. It turned out the new console removed features that the customer success agents relied on. The team ended up having to support both, and the customer success agents were frustrated by having to remember which console to use for which tasks.
• A team adding an API to allow another team to write plugins. The two teams had gone round and round. Each time the API team delivered a new version, the client team complained that it didn’t do what they needed or was too hard to use or broke their code in subtle ways.

You might think these are all examples of design problems, that in each example there was a missed opportunity to do real user research. It's absolutely true that having one or more people with UX design skills involved would have been a very good idea. But that wouldn't solve the whole problem. This isn’t quite the same as a customer-facing UX design problem. These are all groups that existed within the same company. They didn’t have to work at arms length. They could have collaborated. Built together. Cross-team paired or even jointly staffed the initiative.

Also, to be clear, FOR instead of WITH isn’t a one-sided problem. Often those who are on the receiving end actually like the hands-off delegation. My predecessor who funded Chris's initiatives did so because he didn’t want his department to be bothered with what he considered to be irrelevant details. He just wanted Chris to take care of everything.

That's the core of the problem: FOR often feels like the easier path, at least for a while. It gives the team doing the work more autonomy, and frees the recipient from having to engage. Is also involves less arguing…up until things fall apart. And when things do fall apart, they do so spectacularly.

WITH is harder but it’s worth it. When the plugin team started co-designing with the API team, both the API and the ultimate deliverable that customers used improved rapidly. When the developers and the tools team started cross-team pairing, the automation became far more useful. In every case I’ve seen where a team shifted from doing work FOR another team to doing work WITH them, they executed more effectively and everyone ended up happier (although it sometimes took a while to get there).

The lesson here—a lesson I hope Chris learned, but I'm not optimistic since he decided to leave rather than partner—is that although FOR is so tempting, WITH is so much better in the long term. So if you're doing work that is used by another group, make sure it's WITH them, not FOR them.