At DrupalCon CxO, I mentioned that the connection between your employees and customers can be a powerful way to influence employee loyalty.  There was a bit of confusion about the topic, though, so it might be helpful to give an example.

When I was leading a small team of employees in a software team back in 1991, we were working with customers that weren’t really well served by the larger organization.  We had a weird product, serving a weird need, and the rest of our division didn’t focus on that.

One of our key strategies was to meet with each and every customer.  Rather than assign that relationship to our marketing guy, I spread the responsibility around the team – every role.  Their responsibility was to form a friendly bond with the customer, to let them know that we valued their input (not just money), and to champion that customer’s needs into our decision-making process.

It was even more powerful than I had hoped.

What I found was that each employee grew to identify with “MY customers,” even to the extent of sending them informal emails when something interesting was happening.  And when the employees were reorganized to a different place a couple of years later, they really missed those connections that had formed.

That’s what got me thinking about this in the context of employee retention.

Many Drupal developers have the opportunity to work closely with customers, to actually meet with them, work out issues, and collaborate.  I’m an ardent fan of this approach.  As a CEO or manager, you might worry that this kind of bond might mean that the customer is more tied to the developer than to your company, but I’ve rarely seen this happen with IT contracts.  The customer is mostly attached to the contract with your company, and the employee becomes attached to the customer and his needs.

This means that the employee, by proxy, becomes emotionally attached to your company.

There’s other benefits, of course:

  • Your developers will more clearly understand what the customer REALLY needs
  • They’ll actually care about whether the customer is happy at the end of the day
  • The customer will see your development team with a human face, not just an anonymous group of code monkeys hidden off in a dark room somewhere
  • Issues of customer dissatisfaction will be raised (and therefore solved) earlier

Yeah, I understand your nervousness with not always inserting yourself or your project managers in the middle of every conversation.  But seriously, let your developers out of their cages to interact with their Real World.  You’ll be glad you did.