All Posts in Career Management

|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: Career Management|Last Updated:

How does anyone ever get their first programming job?

The question is personal. My daughter Kimberly recently graduated from a software boot camp, having acquired coding proficiency in several useful languages, along with practice in a number of popular development techniques. Now she’s doing what she’s supposed to be doing to make the proper connections and all.

But she’s caught in a well-known Catch 22: HR and hiring managers want applicants to have at least two years of experience under their belts, but to get two years of experience, someone first has to hire you.

I have to admit, the problem is personal for another reason: I’ve been part of the problem.

Every new hire is a risk. Unlike promotions or transfers, with new hires all you have to go on are interviews, which are highly unreliable (thanks to long-time correspondent Leo Heska for bringing the linked article to my attention), and test scores if you use them, only many of the tests used to screen job applicants are junk science at its worst.

Even the best programming schools have limits as to how close they can make classrooms and assignments to what their graduates will have to handle once hired. You know experienced applicants have been through this transition. Were they successful? You at least have a basis for having the conversation.

And if you insist on a few years of experience, you know even the worst of the bunch have had to cope with juggling responsibilities and dealing with personalities, along with the technical assignments themselves.

Did they cope well? You at least have a basis for this conversation, too.

But when you accept new graduates as applicants, all you know for sure is that the individual on the other side of your desk knows how to turn specifications into working code. Even the most promising will have to learn what are politely called “soft skills” after you hire them.

And “soft” is a poor description of these skills, because …

In addition to being an organization that delivers business results, every department in every business is also a society. New employees are immigrants who have to figure out how to live in it. Experienced applicants have been through this before. Trainees have not.

No question: Applicants looking for their first position are riskier hires than those who have a few years under their belts. When I was a hiring manager, I usually insisted on a few years of experience, too. I wasn’t willing to take the risk.

But … CIOs are complaining bitterly about a talent shortage. Whether it’s real is debatable — every time a company needs an Oracle DBA and refuses to consider otherwise excellent applicants whose experience is limited to MySQL, SQL Server, and DB2, the talent-shortage meter clicks up another notch, even though the talent shortage comes from a self-imposed refusal to consider highly qualified applicants.

But forget all that and accept the IT talent shortage at face value. Further, accept that entry-level applicants shouldn’t be considered part of the solution.

What we as an industry have just done is to make the talent shortage permanent. The experienced men and women who are worth hiring are all now employed. We won’t take a chance on new entrants to turn them into IT workforce members.

It isn’t quite fair to say nobody is hiring entry-level programmers. As an experiment I searched for developer positions on LinkedIn. In round numbers, perhaps one out of every hundred position descriptions indicated a willingness to hire newly graduated talent.

If only one percent of hires are inexperienced applicants, the IT workforce just isn’t going to grow very quickly.

In a completely different context, Elon Musk looked at the state of the electric car industry. He sees Tesla as being part of a larger ecosystem. To improve the health of that ecosystem he open-sourced a bunch of Tesla intellectual property. It wasn’t an act of altruism so much as it was enlightened self-interest.

Once upon a time, employers considered IT talent so valuable they were willing to train their own, and to accept a cadre of new graduates every year. Doing so helped build the industry while gaining highly loyal employees.

Those were kinder, gentler times for our industry. But I wonder: Maybe being kinder and gentler might also, in the long run, turn out to be more profitable as well.

Comments