Page 2 of 15



The Employee Management System

Oct 5, 2019

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.

Better Way to Change Behavior

Sep 29, 2019

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.

Refactoring Budget

Sep 22, 2019

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.

How to Structure Feedback

Sep 15, 2019

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.

Feedback Fallacy

Sep 7, 2019

Inspired by Justin Rosenstein, I wrote about blunt feedback six months ago. I still stand behind that post and I do consider it a worthwhile read. However, there's stuff in that post that I should revisit.

In the aforementioned post I wrote "I can elevate my co-workers by sharing feedback with them." This feedback can be blunt or negative if it has to. It can be something that elicits a defensive response from a colleague.

A month later Harvard Business Review published Marcus Buckingham and Ashley Goodall's article "The Feedback Fallacy". The piece made me consider if everything I thought about feedback was wrong. Does my feedback actually elevate my colleagues or does it bring them down instead?

Here's Buckingham and Goodall's argument in a nutshell: Blunt feedback is bad. It smothers learning. Also, organizations are way too obsessed with this kind of unhealthy, unproductive feedback.

Why is blunt feedback bad feedback? Here are the three systematic errors we make when we tell our colleagues that their communication isn't assertive enough or that they lack strategic thinking.

First, we think we are a source of truth. Too often we treat feedback as objective statements especially if we collect it from multiple reviewers. In reality, our perception of good versus bad is highly subjective and we all have our false assumptions and unconscious biases. The feedback we give tells more about us than the work we try to review.

Second, negative feedback triggers our lizard brains. Hearing negative feedback makes us raise our guard while positive feedback opens us up for learning and the possibility of change. You should try to keep your colleagues out of the "fight or flight" mode – not push them towards it.

Third, you can't codify excellence unless you're trying to replace machines with humans. When you pursue excellence in creative fields, you are navigating uncharted territory. You can't model creative excellence, and because of that you're never really sure if your colleague is "on the right track" whether you like her work or not.

Buckingham and Goodall aren't proposing us to steer away from instructions and responses to mess-ups. System failures should be investigated. Teams help new members navigate unfamiliar programming languages and frameworks. But these kinds of feedback situations are more about putting out fires and getting up to speed rather than professional and personal growth.

Want to help your colleagues learn? Here are two tips from Buckingham and Goodall:

  1. Acknowledge that your feedback is subjective: instead of telling your teammate not to do something, use a pattern such as "when you do X, I feel Y."
  2. Point out moments of greatness: Direct the focus of your feedback away from mistakes. Look for positive outcomes and help your colleagues notice them also.

If the majority of the feedback you give your colleagues are reactions to mistakes, you're not helping your colleagues grow. Often your colleagues don't even need you to tell them that they messed up (they probably know it themselves already). Instead, look into your colleagues work and tell them what's so great about it.

Page 2 of 15