Categories
Uncategorized

Finding meaning in agency work

On creating beacons of meaning when there’s a client in the mix

One of the tough things about agency life is being a extra layer removed from the users.

At a product company, the developer is building for the user. At an agency, the developer is building for the client who is acting on behalf of the user.

Product companies make money by making users happy. Agencies make money by making clients happy, and those clients make money by making users happy.

In my old post on jelling teams I mentioned the importance of closure:

Everyone likes to see the fruits of their labors. If you spend a month building something, you want to see that thing go live for people to use it. You don’t want it to be shipped off into the void, never to be seen again.

The book The Culture Code by Daniel Coyle talks about it with “beacons of meaning” and their importance:

This is the way high-purpose environments work. They are about sending not so much one big signal as a handful of steady, ultra-clear signals that are aligned with a shared goal. They are less about being inspiring than about being consistent. They are found not within big speeches so much as within everyday moments when people can sense the message: This is why we work; this is what we are aiming for.

Daniel Coyle, The Culture Code

It’s easy to find meaning in our work when we feel a connection with the user. Adding a client in the middle makes it harder to feel that connection. The “beacons of meaning” are fewer and farther between when they have to go through another layer to get back to the team.

So in agency life, there are 2 ways to get “steady, ultra-clear signals” from the users to the team:

  1. Train the client to provide them early and often.
  2. Bypass the client and work directly with the users.

Neither of those are right or wrong. In a trusted partnership, many clients would love to give product ownership to the agency (i.e., option 2). Or if the client has a strong user connection already or an enthusiastic product team, then option 1 is the way to go.

Either is better than neither. Otherwise we’re asking a team to build things for people they never see or hear because a client says so. That’s death to closure, death to jelling, and death to meaning.


Thanks for reading! Subscribe via email or RSS, or follow me on Twitter!