All Posts in Leadership

|In: Business Ethics|Last Updated:

“Do the right thing” is to ethics as “best practice” is to business processes. They’re phrases that sound just like they might mean something.

Except that they don’t.

Case in point, based on a recent request for advice: You’re on a team. The team’s job is to figure out a better way for the company to do something or other.

In the early stages of analysis two alternatives came into focus as potential solutions. Neither was obviously wrong, but over time a team consensus has emerged as to which of the two was the better path forward.

When the time comes to report the preliminary solution to the project’s sponsor and steering committee, though, the project manager presents the other alternative. He’s completely within his authority. You and the rest of the team simply disagree with him.

The ethical question: You’re on the team. Your company’s Values Card makes it clear you’re supposed to do the right thing.

What, however, is this “right thing” you’re supposed to do?

The most obvious approach is to blow the whistle. That’ll show him.

And it might. Or it might not, but the telltale here is “that’ll show him.” Blowing the whistle might in fact be the right choice, but you’d have no way of knowing, because what you’d be doing is satisfying your urge to vent, not holding yourself to high ethical standards.

There is, after all, a reason mutiny on the high seas is frowned upon, even when the captain’s orders appear highly dubious to the crew. Blow the whistle and it won’t be just the project manager’s standing that is lowered in the eyes of the project sponsor — the entire team will look bad whether or not you persuade the sponsor to overrule the project manager.

Add to that the impact on ongoing team dynamics. Your ability to work with the project manager will be permanently impaired. So will your ability to work with many of the other members of the team, who, while on your side with respect to the design itself, disagree with your decision to escalate.

As an alternative to whistleblowing you might simply leave the team. Except, you can’t just leave the team. You’ll have to provide a reason, or perhaps three reasons — one for the project manager, one for your reporting manager, and one for your soon-to-be-erstwhile teammates.

For each audience you can either be honest about the reason or you can make up a plausible excuse. Plausible excuses being convenient falsehoods, this branch probably won’t survive ethical scrutiny, while honesty will result in everyone who knows about what’s going on concluding you’re a prima donna who bails whenever something doesn’t go your way.

So far, so bad: Two alternatives, two unsatisfactory outcomes.

Here’s another one: You can confront the project manager. “What the fleep do you think you were doing!?!?” you might calmly ask at the next team meeting, or, if you’re in the mood to be discreet, privately.

If the project manager were the sort to accept that he’d done something wrong, he wouldn’t have violated the team’s consensus in the first place. If you choose the public option the blow up you’ve just engineered will further damage the ability of the team to function. If you do this privately you’ll merely damage your ability to work effectively with the project manager.

Either way, you won’t change the outcome.

Hmmm.

Another possibility: You can accept the project manager’s decision and move on from there without comment. This avoids all the previous downsides. It does, on the other hand, encourage a repeat performance.

The point of this little tale of woe? It started as a what-do-you-think-I-should-do inquiry, and from that perspective my answer is simple: Keep your mouth shut and document the event. That way, if everything does fall apart as a result of the project manager’s poor choice, you have some hope of salvaging your own reputation.

But there’s a difference between doing what’s most prudent and taking the most ethical course of action.

Those who advocate doing the right thing generally imagine the main barrier standing in the way of right-thing-ness is fear of the personal consequences.

That may be so in some situations. But in just as many, to my way of counting, the biggest barrier isn’t timidity.

It’s the difficulty of figuring out just exactly what the right thing to do is.

Comments

|In: Industry Commentary|Last Updated:

The subject: Bimodal (or trimodal, or agile, or high-speed) IT. The challenge: Culture. Culture is a challenge to IT agility. It’s a challenge if you buy into the bimodal model, where systems of engagement need to change and adapt at lightspeed while systems of record need accuracy and stability above all else. It’s just as big a challenge if you embrace the trimodal model described here last week.

Culture is a challenge because it means “how we do things around here.” It’s the set of shared assumptions that let people work together efficiently. Think of culture as an organization’s cognitive infrastructure — a foundation everyone builds their thinking on, confident that if they do, everyone else is likely to agree with their conclusions.

Start with the six dimensions of optimization: Fixed cost, incremental cost, cycle time, throughput, quality, and excellence.

With bimodal IT, systems-of-record employees assume quality, throughput, and incremental cost are what matter most, while systems-of-engagement employees are equally sure cycle time, excellence, and fixed cost are what deserve the most attention.

It’s a recipe for conflict. Now add this: Systems of record are part of the business infrastructure. They’re necessary but not strategic. Businesses invest in them to preserve the value they’ve been delivering for quite a long time.

Systems of engagement are strategic. Businesses invest in them to get new value. One way or another, directly or indirectly, systems of engagement are part of how businesses get the cash register to go ching!

Which means fast-mode IT projects get better and easier funding, and the IT professionals who staff then get more … and more career-enhancing … attention.

The trimodal analysis is a bit different. Understanding its built-in conflicts starts with another property of culture — it’s a big part of how employees define identity, affinity, and, as a natural byproduct, ownership.

The trimodal model isn’t built around the systems of engagement vs systems of record model. It’s built around a progression, from prototype to production-grade, and then from production-grade to part of the core architecture.

In Simon Wardley’s version, described here last week, the progression is managed through a process of theft — “settlers” steal “pioneers'” prototypes to make them production grade; “town planners” steal settler’s production-grade systems to make them suitable for inclusion in the core architecture.

Think pioneers are going to thank the settlers who take over control of their creations and impose strict new rules for their evolution? Think the settlers, who have carefully adapted their systems to support their part of the business, will be delighted when town planners take them over and generalize them so they support the whole enterprise better by imposing one-size-fits-nobody design compromises?

Think again. No matter how what system of governance IT and the rest of the business impose to regulate this process, it’s still going to feel like kleptocracy to those on the receiving end of it.

You’re the CIO. One way or another you need to keep the lid on conflicts within IT. So you instituted DevOps, not only to help speed things up but also to reduce the usual and natural conflicts between Development and Operations. But DevOps exacerbates conflicts between the high-speed culture that uses it and the low-speed one that avoids it.

You’ve already instituted some form of Agile Enterprise Technical Architecture Management (ETAM). (Haven’t you?) With some trepidation you incorporate the kleptocratic town-planner function into it. But you recognize the resentment it will create, and want to minimize it.

What’s the plan?

There are no best practices for this. Not that there ever are, but some fields at least have proven, tested practices. Here, the best we can do is apply what we know to what we don’t know. Three suggestions:

  • Avoid false dichotomies. System of record vs system of engagement is one. These aren’t opposites. They’re the poles of a continuum. System-level governance should establish the proper trade-offs between system-of-record-ness and system-of-engagement-ness for every system IT manages.
  • Rotate staff. No, don’t have them spin in circles. With some exceptions — your deep system mavens who like being deep system mavens — move applications staff from one system to another, and in and out of your ETAM function. Move operations staff from one DevOps team to another, and through ETAM as well. Resenting them is harder when they become we unpredictably and often.
  • Promote “Form Follows Function.” As the first rule of design it’s already at the heart of your architecture (isn’t it?). Those who embrace it are more likely to assume those who do things differently are dealing with different circumstances.

Making it part of how we do things around here will reduce cultural conflict.

And happily enough, it will also improve design.

Comments