It’s surprising to me that this problem arises so frequently in American business. A company may have an overarching corporate culture, an overall attitude that pervades the business at all levels. Yet within a company there may be several such cultures, divided by role. One of the challenges I’ve seen is where those cultures clash inside the company, damaging its overall success. A frequent example is the conflict between Sales and Legal, two teams who, at first glance want the same things: a positive outcome for the company, often have, when we peel back the veneer, have opposing needs.
The Legal department is tasked with protecting the company’s legal interests. This means that contracts have to be favorable to the company and any details of a deal and its corresponding agreements must similarly favor the company. Sales is, by definition, concerned with closing the deal. It wants to successfully complete the business with the customer and move onto the next deal. from a Sales team member’s perspective, the contract is a formality, something that only delays closing the deal and getting paid. From the other team’s viewpoint, the contract is a pivotal document that ensures the deal will go as planned and that the company is protected.
For this reason, I’ve often heard, “Lawyers kill deals.” Of course, both teams have valid points and a compromise makes sense here.
I also often see, in technology companies, a similar conflict between Sales and Engineering. The Engineering team may be tasked with designing technology that is effective, reliable, and valuable to the company’s customers. Often, such teams are pushed to accelerate going to market, getting the product “ready” before it’s been fully tested. The advent of so-called “agile” development has made this a reality in the software industry, for example. Shorter development cycles require shortcuts somewhere and Engineering teams are required to do this. Particularly in high tech, such shortcuts can result in a flawed product: a defective device or buggy software.
If you are an executive or manager trying to solve a productivity issue, it pays to learn the interdynamics between the company’s teams. If there is a culture clash between them, and they are at odds, they’re likely not only ineffective, but potentially working against one another, ensuring both teams’ failure. And ultimately, who suffers? The company overall. To sharpen the point a bit: You suffer.
Influencing change in such teams is not as difficult as it’s made out to be. We all do what is reinforced, so if someone is using a behavior, it’s worked for them reliably enough in the past that they count on it now. Remove that reinforcement. Introduce a new motivator. Bonus engineers on the number of “bugs” they fix, which removes a commonly-seen problem: Developers refusing to acknowledge such bugs in the first place. If they make bonuses for not only acknowledging bugs, but for fixing them, you now have a motivator in place that will encourage them. One company I met used a method I myself wouldn’t condone or recommend, but it did work for them: a “Wall of Shame” on which, when bugs were reported, the developer responsible (using their own internal criteria) would be listed with a little sticker of an insect on the wall. The more stickers, the more “shame” or suggestion the developer lacks skill. This was a proud bunch, so it was an effective punishment.
The reason I wouldn’t recommend it is that punishment has been proven to only be effective in decreasing a behavior, not increasing anything. So in most sentient beings, not just human, punishment would not increase attention to detail, care with testing, and pride in work. For most technical employees, it would be ineffective in shaping the desired behavior. I also see the potential for an unexpected side effect: denial. There’s one way to overcome getting a bug sticker attached to your name on the Wall of Shame: produce fewer bugs. Sure. But there’s at least one other: Deny that the reported bug is in fact a bug.
A more effective way, using positive reinforcement, that overcomes this is the aforementioned bonus idea. When a bug is identified, the Engineer would now be reinforced for acknowledging the bug as this represents an opportunity to fix it and win the bonus. Denial would no longer make sense.
From another team’s perspective, Sales, the bugs represent a problem. Yes, they may have closed the deal they wanted. But Sales is a reputation-based domain. Once your reputation is tarnished, it can have devastating impact. When the salesperson calls on that customer again, the customer will assign part of the blame for the buggy software to the company name, itself, but also a good part to the salesperson. Meaning they will no longer be willing to just trust the advice of that salesperson. The mythical “trusted advisor” lost his or her status. So sales professionals who think beyond the current quarter care very much about quality and customer perception. If you alter the reinforcements for everyone else in the relationship, you can bring them all into sync, all working toward the company’s shared goals–which is true leadership.
Copyright © 2019 Chris Gingolph