Aaron Houghton

People vs. Culture. How to Act When Team Members Violate Culture.

Aaron Houghton
People vs. Culture. How to Act When Team Members Violate Culture.

Teams are incredible things. I've personally felt great enjoyment from accomplishing goals as part of a team in sports, wilderness survival, high adventure, and professional services environments.

In my 20 years as an entrepreneur I've had the opportunity to work as part of a team in a wide variety of professional arrangements.

Thinking through the various hats I've worn while working as part of a team, I've been a(n):

  • Consultant delivering digital marketing services and software solutions to managers, CEOs, and Presidents
  • Technical Co-Founder prioritizing product roadmaps and delivering software features to my co-founders and business leaders
  • CEO buying services from agencies and individual consultants
  • CEO leading internal teams to deliver software products and marketing services
  • Board Chairman leading operational and non-operational directors
  • Board Chairman consulting with internal departments to refine strategy, increase efficiency, and test new ideas
  • Company founder coordinating with my co-founders to refine ideas and bring them to market
  • Advisor guiding CEOs on founder issues, marketing strategy, and growth challenges
  • Board member leading community organizations to create and deliver effective strategies

Regardless of the type of team and the task at hand I believe the success of a team comes down to two things: leaders set expectations, and team members deliver results to meet expectations.

I believe the best teams set the most reasonable and clear expectations. The expectations can be reached in the time allotted with the available resources, and everyone understands how their work will be measured and exactly what they are expected to deliver.

The best leaders work collaboratively with their teams to set the right goals, but leaders are ultimately accountable for delivering the desired result through their team's resources.

This simple framework for small functional teams can be applied to companies as a whole, as all workers in a company are part of a large team.

At the company level, expectations for company performance over specific periods of time - like quarterly revenue and customer addition goals - are the goals of the collective team, not any individual contributor. For instance, it's unlikely you're going to expect a single employee to deliver your quarterly revenue goal.

And finally there are general expectations that don't apply to specific periods of time but instead to all behavior at any time. This is where I believe culture lives.

Although a company's culture can change over many years, one of the goals of a company culture is to provide a set of expectations that every team member can trust will generally be true throughout their interactions with other team members over the period of time they can be reasonably be expected to work for the company. This of course is why as leaders we try to hire and fire based on culture.

This creates a reliable environment in which every team member knows that to expect and can feel safe to be creative and push the limits to deliver their best work. Simon Sinek goes as far to say in his presentation Why Leaders Eat Last that our brains release the relaxing chemical serotonin when we feel safe within our teams.

I think most leaders are prepared to handle situations where team members fail to deliver expectations on a project, maybe by missing a deadline, or when expectations aren't met for a monthly or quarterly sales goal.

But what do you do when a team member doesn't meet the company's expectations for culture?

First of all, make sure you already have a clear and excessively communicated company culture, created by your team, or created by company founders before hiring your team, and that team members appreciate each value that makes up that culture.

Now, assuming you have that framework in place, you have a clear set of rules that have just been broken by a team member. As a leader, what should you do?

Let me share a story from one of my personal experiences as a team leader.

It was early 2008 and I was CEO of a ten-person digital services agency with midsize non-profit and startup customers across the Southeastern United States. Our customers expected us to deliver cost-efficient services on deadline, at high quality, and with professionalism. And we strived to do just that.

As a small agency ourselves, we lived off customer referrals, which meant exceeding expectations on every single project was critical to our future growth and success. Needless to say, tension was always high, and resources were always tight.

Our staff of ten was organized into three primary teams: sales, project management, and services. Sales delivered new customers and new projects, project management kept track of everything we promised and kept customers updated, and services delivered the goods.

We were a few weeks into a new digital marketing property for a regional Diabetes foundation, whose board of directors eagerly awaited their first peek at their highly anticipated new website, and our services team has just put the finishing touches on a functional prototype of the content management features that would allow them to control content on their new website.

My services team followed their internal protocols, delivering functional, fully-tested software and my project management team had triaged resources to meet the breakneck deadline we had promised in order to earn the contract. We were thrilled with our performance.

The foundation's board of directors salivated as they began to review the interfaces that were already powering their new website management framework.

Then came the bomb.

And of course it arrived through my sales team, like the worst news always does. As you know, if the customer is slightly dissatisfied they'll relay the concern to their project manager, who is their primary contact for any project, and it will be fixed. But if they're really pissed they go straight to the salesperson who originally set the expectations that are tied to money.

And before you go "oh yeah I've been there before" assuming the problem is a mismatch in project scope or timeline, just give me a second here.

While the project owner at the non-profit was reviewing their website, live with his board of directors watching along, directly in the middle of their shiny new website they all together encountered a high resolution picture of a scantily clad bikini model posing alongside a horse.

It wasn't nudity. It wasn't pornography. But it was in fact a lightly dressed woman posing next to a horse. Upon clicking to the next page they found more pictures of similar taste.

You can guess the antics that immediately ensued in our office as I - let's say as delicately and reasonably as a sledgehammer - began to unravel the pieces of our service delivery and customer management processes that allowed a priced piece of customer property to be delivered peppered with awkward quasi pornography.

As it turned out, one of our software engineers, who admittedly had a good sense of humor, had used that sense of humor to entertain himself while preparing the framework for our customer's new website, and found and used the horse-lady-bikini images as part of the functional testing procedures to verify the integrity of the code behind the system.

As it turns out, he had been using the images while testing several recent customer websites, but in this case, he simply forgot to delete them from the customer website before handing it over to them for inspection.

So, what now?

Of course like any CEO, you first speak with the customer, make apologies and promise you'll review and fix internal procedures so this can never happen again. In this specific case the customer demanded cancellation of their entire project and return of their 50% deposit in full. Those dollars would likely be the immediate concern on any CEO's mind.

But once that was resolved, what should you do next?

I think the answer to that question really has to do with what went wrong. At a high level you have one of these problems:

  • Personnel professionalism problem: a software developer took a completely unnecessary risk and used unprofessional images when any old professional image would have done just fine
  • Personnel quality problem: a software developer forgot the last step of the testing process which was to delete the test images.
  • Quality assurance problem: a flawed customer product was delivered to a customer, after passing through the hands of a services team manager, and a project manager.
  • Customer sense of humor problem: okay, I'll entertain that the customer reacted strongly, but I have to agree with them that what happened did not meet our own standards for professionalism.

How you respond to each of these problems is pretty straightforward.

If it's a personnel issue (professionalism or quality) you reprimand the team member and act accordingly, providing some reminders of your expectations for them, or maybe firing them if you believe they won't be able to prevent other similar issues in the future.

If it's a quality assurance issue you create a new unilateral layer of mandatory reviews. For instance requiring the services team manager to review all client deliverables, or maybe the project manager. Or maybe both of them if you want to be even safer.

If it's a customer issue you return the customer's money and send them on their way.

At face value it seems your options are pretty clear, and honestly all of these options seem pretty similar in the short term.

Personnel issue: You may be able to live with the software engineer making another mistake like this in the future, or without the software engineer as you rehire for the position.

Quality assurance issue: You may be able to live with the bit of extra process and inefficiency you gain from adding new mandatory work reviews.

Customer issue: You may be able to live without the revenue from that one customer, and the potential sales referrals you would have received from them in the future.

But I think the real question is, can your company live with the message that your decision sends, a message about you as a leader and the type of company in which your team members work?

Also, it's less about this one decision and it's instead about the sum of five, ten, or twenty situations that need similar decisions made over the course of weeks and months and years.

Because the mistake the software engineer made probably isn't unique to them.

If you fire everyone who makes this type of mistake you may end up with a team full of people without any sense of humor at all. You also create fear and inflexibility in the minds of other team members who are scared to take any risk because they know you'll fire them. Who wants to work on that team?

Needless to say you'll also constantly be paying recruiters to find replacement members for your teams, and it will be nearly impossible for project managers to efficiently manage work among fluctuations team sizes.

On the other hand, if you simply re-educate the software engineer on the company's standards of professionalism, and you do this repeatedly over multiple mistakes, you set a precedent that will negatively affect motivation, performance, and longevity of other team members who have to work alongside this person whose unreliability is being regularly excused.

If you add new layers of review, you create inefficiency that will grow with you at the scale of every new customer project and team member, eroding profit and increasing turnaround times. You also excuse the mistake and shift the burden of enforcing professionalism from everyone to specific team members.

And of course if you let every customer go that ever encounters a snafu, you'll find yourself with far fewer customers and far fewer opportunities to be referred new customers in the future.

So, which action is the right action?

The core issue here is that a team member missed one of the expectations of our company culture. That expectation was our value of professionalism. The engineer had not acted professionally when he inserted unprofessional pictures into his internal testing process.

At the time this actually happened in my company, I made the decision to re-educate the software engineer on our standard of professionalism (it was a short conversation, hey, you, be professional) and I created a new policy of mandatory work review by a project manager before anything is delivered to a customer.

In retrospect I believe that was the wrong decision for my company for two reasons. One, because I allowed the engineer's mistake to create new work for other team members (the new review process), and two, because I re-educated the engineer directly.

In reality, company culture is a contract between each team member and every other team member, regardless if they are leaders or peers. When the engineer violated the value of professionalism he broke his contract with everyone. The rectifying conversation should instead have been between the engineer and the entire company.

Now, maybe this wouldn't be appropriate if we had 100 employees, but in a 10 person company - because everyone from sales to project management to services was involved in fixing the subsequent fallout of the engineer's mistake - I think it would have been the best action.

So, how would that work? Maybe something like this.

At the next all-hands company meeting (which we held weekly) the engineer would have explained to the team what he did and he could apologize to everyone for not meeting the expectation of professionalism set by our culture. It might also be nice if he explained what the company's value of professionalism means to him.

This gives everyone the opportunity to hear the human story behind the mistake, and to provide corrections if the engineer's understanding of the specific company value is incorrect. It also reinforces the importance of the company's value of professionalism and shows everyone how seriously leaders take the company's culture.

In a world where culture and simple value statements have replaced the company handbook and more formal ways of representing team-wide expectations it's more important than ever for leaders to take the correct action when values are broken.

I learned my lesson when I responded incorrectly. I hope others can learn from my mistake and benefit from the efficiency and restored trust that come from taking the correct action.