Flashover

We love to smirk at company values and culture statements, don't we? They all tend to say the same things: "our company values its employees!" or "trust, collaboration, and integrity are our core values!"

We also know that often the company values are just wishful thinking from the employer's side: the reality is something completely different.

I fully admit my cynicism towards company values. The idea of a company refusing to write down their values in order to spare us from the never-ending flow of corporate bullshit gets me excited. Unapologizing honesty and provocation can be thrilling.

But then there is the marketing agency Ogilvy & Mather and their eight organizational virtues. These are values that make me listen, not yawn. Ogilvy & Mather describe creative work in a way that communicates insight: it's clear that they know how the world tries to suppress creativity and what it's actually like to try to grow as a creative community. Here's an article about the virtues. Go ahead and read it – it's short and concise.

These are the three things that Ogilvy & Mather' get right with their company values. Quotes are from the company's book "The Eternal Pursuit of Unhappiness."

1. They aspire

Helen Keller, the deaf and blind activist, was asked by a journalist what she thought would be worse than being born blind. She replied without missing a beat, ‘to have sight and no vision.’

One of Ogilvy & Mather's virtues is idealism, and this quote from Helen Keller sets the bar for expected idealism pretty high. However, often when you set the bar higher, you start to see the average going up also.

2. They make a stand

We waste our beautiful mind by leaning lopsidedly on logic.

To say that we solve problems "through intuitive leaps" instead of interpreting the data is bold. Not everyone is going to agree with your process.

3. They support

If the client kills your day, do him a better one.

Few culture statements tell you what is expected from you when things don't go according to plan. Few culture statements don't even seem to understand what it's actually like to do the work at your company.

***

Do you get excited about the values of your company? Are the values fun to talk about? Or does it even matter what they are?

All organizations are made out of people, and all companies need people who are ready to contribute. But people inside agencies and consultancies play a different role as opposed to people inside product companies. If you run a service company, your employees are building relationships with your customers. Inside a product company, this relationship doesn't exist. Your customers have a relationship with your product, your brand, and maybe with your sales people, but not with your designers and developers.

Since as an agency or a consultancy your employees are part of your offering, you can't really ignore employee performance whenever you're discussing things like growth and profitability. Employee performance plays a part in making sure that you help your customers reach their goals. In return, satisfied customers lead to more business and better projects.

Employee management refers to all the actions taken to help employees succeed at their work. Frances X. Frei from Harvard Business School talks about employee management systems and how to design them: Your employee management system is badly designed if your employees need to stretch themselves to the limit over and over again in order to succeed. Well designed systems give employees a reasonable chance to succeed with a reasonable amount of motivation. You shouldn't rely on heroism to get the work done. You can read more about Frei's points here.

Inside your agency, employee management is not another HR function. HR is back office work. How good will it be at building systems that fuel customer success? Does it have the required experience, knowledge, and empathy for understanding customer-facing work and the realities of consultant work? A change in your employee management system is a change in your strategy.

So how do you help your employees achieve excellence? Approach this question from an engineering perspective and you can see opportunities to codify consultant work into a process with detailed steps. Achieving excellence won't require excellence from your employees but compliance instead: great work will be a result of meticulously following the given instructions. However, translating creative work into systematic code is not going to be possible for you as an agency. Creative work involves unpredictability which makes all attempts to create comprehensive manuals or handbooks useless.

This doesn't mean that you won't have a process. It just means that no process will be ever enough. Yes, you will have parts of the work that can be codified, you will share tools, you will adopt company-wide practices, and you can approach problems with specific mental models or frameworks. But you can't replace your employees with assembly line workers.

Recruiting is going to be a part of your employee management system. You can have your employees succeed at their work by hiring the "perfect" people: people who are exceptionally good at what they do and who's skills match perfectly with the requirements. Service excellence will be a result of individual excellence. However, here are the problems with this design:

• You can't find enough people with the right skillset.
• You need to pay a premium for exceptional skills (or provide work that is exceptionally motivating).
• You don't have room to hire for potential. Your system can't handle people who are still learning.

***

Designing an employee management system looks more like wayfinding and less like meeting specifications. Recruiting will be a balancing act between skill, cost, availability, and potential.

The environment you operate in will continue to change. People will join your company and they will leave. Since change is the only constant, maybe the following two questions, asked regularly, can provide you with direction:

• What does great work look like?
• Why isn't all our work great already?

"What does great work look like?" forces you to define excellence. You can't move towards a goal if you don't know what the goal is. "Why isn't all our work great already?" assumes that everyone wants to achieve excellence but there are forces blocking them from reaching this goal. Find and remove those blocks and you'll make progress.

Psychologist Kurt Lewin taught us that our actions are influenced by two opposite powers: helping forces and hindering forces. Helping forces drive us toward our goal. Conversely, hindering forces restrain and block us. A helping force is you pressing the gas pedal to try to make the car go faster. A hindering force is the air resistance experienced by the moving vehicle.

The same way a car's speed is a result of helping and hindering forces, our behavior is a result of the forces that drive us and forces that restrain us.

If we want to align our behavior with our goals, we can increase the helping forces or reduce the hindering forces. The natural, but less effective, way is to try to increase helping forces – to use more arguments, incentives, and threats in order to change behavior. The more powerful approach is to change the environment and remove blocks and restraints.

Instead of asking how can I get this person do something, you ask why aren't they already doing it. If you struggle with bad documentation, don't ask how you can get your team to keep the docs more up-to-date. Instead, ask why isn't documentation already a priority for them.

It's unintuitive but it makes us focus on the environment around us.

We need to think twice before posting a refactoring ticket on our team's Kanban board. I get that there's value in refactoring: refactoring makes future changes easier and therefore gives us the opportunity to move faster in the long run. However, a refactoring ticket isn't going to help us build trust. Instead, it can do more harm than good for our overall credibility.

Let's divide our product team into developers and non-developers, or to people who write code and people who don't write code. Refactoring is a hard sell for the non-developers because while the cost of refactoring is guaranteed, the benefit isn't. In addition, cost (hours spent on refactoring) is easier to measure than any of the gains: have you ever tried to track how many developer hours do you actually end up saving with refactoring? Non-developers also lack coding experience and will have a hard time empathizing with the pain that comes with bad or out-of-date code.

What about the developers in your team? They might not be happy about our refactoring ticket either. Similar to non-developers, developers are also aware that the benefits of refactoring are both hard to measure and uncertain. While developers will have an easier time empathizing with you, they also know that sometimes we developers refactor code because we're not proud of our work or because we're constantly bumping into our past mistakes when working with the codebase. These reasons are rarely valid justifications for refactoring work.

Instead of time boxing refactoring or turning refactoring work into stories for your Kanban board, make refactoring an everyday practice. Use TDD's "Red/Green/Refactor" cycle and don't forget the last step of "Refactor" before moving to the next thing. Leave your code cleaner than you found it. Most importantly, stop telling yourself that you'll get to revisit a feature with a refactoring budget. Consider the likely situation that you will have to live with the code you write for a very long time.

I've come across two wonderful feedback formats for helping your colleagues deal with difficult situations. First one is from David Emerald; I read about it when doing research for my post The Drama Triangle. Second one is from Buckingham and Goodall's article "The Feedback Fallacy" which I wrote about last week.

Both of these formats are meant for situations where your colleague is trying to fix issues such as their alarming career trajectory (not enough responsibility, uninspiring work, too little salary, etc.), a struggling project, or dysfunctional team dynamics. If you need to discuss areas of improvement with your colleague, consider reading "Blunt Feedback".

Both of these formats are also about asking the right questions – not about giving the right answers. In addition to making sure that the majority of your feedback is positive (research shows that we actually learn more when we get positive feedback and not when our grammar gets corrected by our colleagues), you should remember to avoid handing out quick fixes to your colleagues. Helping our colleagues think productively about their problems – not solving the problems for them – is our gift to them.

I'll introduce both of the formats briefly and then share my own notes about them. Feel free to make your own conclusions about Emerald, Buckingham, and Goodall's work.

Emerald asks the following three questions from his colleagues when they come to him for advice:

1. "What do you want?" When dealing with tension and stress, we often focus on the things we don't want or like. Put the focus back on outcomes with this question.
2. "What are your current realities?" We don't have to pretend that limitations don't exist.
3. "What are the steps you can take?"

And here's Buckingham and Goodall version:

1. What's working for you right now? Focusing on positive things opens us up for more creative and open-minded thinking. Think of this question as warm-up for your colleague's brain.
2. What has previously worked for you when solving similar problems?
3. What do you already know works in this situation? Assume your colleague knows the answer to their problem once they have reflected on their strengths and past experiences.

Both of these formats share a similar flow: First, we should help our colleague direct their thinking away from the negative. We want our colleagues to focus on visions and personal strengths – not problems and everything that's wrong with their current situation.

Second, we offer a way to structure our colleague's thinking. Emerald frames the problem as a puzzle by establishing concrete limits. Buckingham and Goodall frame the problem as a pattern recognition challenge by trying to find similarities with past problems.

Third, we trust our colleague to know what to do. We can share some of our own experience and knowledge with them but the focus should remain on our colleague and their reflection.

Hope you get a chance to practice these questions. You can even try the formats on yourself the next time you're hoping for some good advice.