All Posts in Policies and Procedures

|In: Policies and Procedures|Last Updated:

“Do you know how much Curt Cousins makes?!?!?!”

Expressing outrage over professional athlete compensation is a popular pastime. And yes, on the face of it the hundreds of millions they’re paid is absurd, unlike the completely reasonable tens of billions paid to team owners in exchange for broadcast rights to the games their teams play.

Personally, I don’t see the problem. Athletes are paid for their work. Team owners? Not so much.

The question team owners must answer when negotiating athlete salaries is much the same as the question management must answer when setting compensation, whether it’s for current staff or new hires: What would constitute a fair number?

I’m happy to help. Here’s a framework you can use, both to arrive at the right number and to communicate the logic of it. It has four components: (1) raises; (2) the annual bonus; (3) spot bonuses; and (4) promotions. One at a time:

Raises: A raise, in theory, adjusts the employee’s base compensation – their salary or hourly rate – to what a competitor would offer to hire them away, based, for the most part on the position in question. It’s where the law of supply and demand holds sway. The perfect raise makes each employee’s pay high enough that they have no incentive to leave and the company has no incentive to replace them.

The company’s payroll analysts should be able to provide a reasonable estimate for each job title, although it’s worth noting that they’re likely under some pressure to underestimate what the market would really have to offer.

Raises have nothing to do with an employee’s performance – an essential and often botched aspect of how compensation should work. That’s because a raise is an annuity – it pays employees in future years for their performance this year.

The annual bonus: Unlike raises, employee performance this year has everything to do with their annual bonus. There’s no algorithm for calculating it. Think of the annual bonus as the company’s way of saying thank you to the employee for going above and beyond what their base compensation would lead their manager to expect.

Among the reasons for using the annual bonus to recognize exceptional performance is that in round numbers it can be three times what the company could offer were it to recognize it in the form of a raise. That’s because the bonus is a one-time event where a raise is, as mentioned, paid year after year after year.

Spot bonuses: Where the annual bonus recognizes a year’s worth of strong performance, a spot bonus is a handy way for a manager to thank an employee for something exceptional they just did. It should be in proportion to the business value of what they did, and it should be big enough that the employee sees it as a big number.

Promotions: A raise increases an employee’s base compensation in line with how the labor marketplace has changed for the job they’re paid for. A promotion changes the job they’re paid for, which means their base compensation should change along with it.

It’s worth noting that promotions come in two forms. One recognizes an increase in skills that makes an employee more effective in the job they hold. You might, for example, promote a developer to senior developer – same responsibilities but better at them.

The other changes the job the employee does, for example, from developer to project manager.

This framework has the advantage of clarity, but it will require strong and consistent communication, because how it addresses skills and performance can be unsettling. Especially, decoupling raises from performance just isn’t how most employees think about what they should expect.

Bob’s last word: You might have noticed that nothing in this framework is expressed in terms of rewards and incentives. That’s deliberate. As Alfie Kohn pointed out in his classic “Punished by rewards,” (1993), managers who rely on compensation for motivation are trying to bribe them to perform. And, it sets up a reverse expectation: If the employee doesn’t get the raise they want the manager shouldn’t expect them to perform at their best.

Smart managers don’t think about compensation in terms of incentives and rewards. They think of it as the company’s loudest and most sincere voice when it comes to expressing its appreciation for a job well done.

Bob’s sales pitch: No, I haven’t changed my mind. I’m still planning to retire the end of the year. I’m still interested in your ideas for what KJR might discuss between now and then. Let me know, either through my Contact form, or in the Comments.

On CIO.com’s CIO Survival Guide: “6 ways CIOs sabotage their IT consultant’s success.” The point? It’s up to IT’s leaders to make it possible for the consultants they engage to succeed. If they weren’t serious about the project, why did they sign the contract?

Comments

|In: Policies and Procedures|Last Updated:

Including Keep the Joint Running and its predecessors – InfoWorld’s IS Survival Guide and Advice Line – I’ve been sharing thoughts and opinions for more than 26 years.

When I started, I wanted people to read what I had to say and think, “Wow!” Now, I’m gratified if they think, “A column a week for 26 years? Wow!”

Quantity seems to have gradually overtaken excellence as my most crucial KPI.

Meanwhile, I’m more likely to remember having written about a subject than you’re likely to remember having read about it for, I think, obvious reasons. As a result I sometimes obsess about avoiding repetition – that if I’d written about a subject in 1998 you’ll feel cheated if I write about the same subject here in 2023.

Which brings us to this week’s subject: “Shadow IT,” also known as “Rogue IT,” “DYI IT,” and, if you want to encourage Gartner in its perennial game of claiming concept ownership by attaching snappy new names to unoriginal concepts, “Citizen Developer.”

Or, you could use the handle my co-author Dave Kaiser and I introduced in There’s No Such Thing as an IT Project, as a contrast to Shadow IT, namely, “Illuminated IT.”

As with so many ideas in life, illuminated IT comes with trade-offs, making it sadly easy to succumb to confirmation bias when deciding whether to encourage it or try to stamp it out.

The stamp-it-out logic

End-users aren’t trained developers. They might fall short when it comes to application architecture, testing, or security. And if or when something goes wrong, IT will have to pick up the pieces.

Not only that, but when the end-user developer “calls in rich,” IT will be called in to support the mess the end-user developer left behind.

The philately-free logic (okay, it’s a stretch)

DIY development increases IT’s bandwidth – not once, but in two complementary ways.

The first is the obvious one: a DIY developer still counts as a developer. Maybe not an ideal developer, but I’ll bet not all of the developers housed within the IT organization are ideal ones either.

The less obvious one? For the most part, IT development, along with IT “development” (when IT configures and integrates commercial off-the-shelf software), involves a business analyst here and there. DIY IT does not.

Related: No more arguments about whether what IT delivers is what the business needs.

The best of both worlds

Once IT jettisons its protectionist instincts, and once business users jettison their IT-distrust instincts, getting the best of both worlds isn’t particularly complicated:

1. Encourage using what you already have. It isn’t uncommon that an application suite you already license provides the additional functionality the business needs. The formula for success: Inform, train, follow up.

2. Encourage COTS. If some application provider licenses a solution that does what business users need, it reduces the risk of losing support due to the end-user developer finding something else to do.

3. Establish platform standards. Whether it’s Excel, Access, or a “no-code/low-code” cloud-based alternative, setting one of these as the supported and recommended development environment reduces IT’s support burden. Once you’ve established the standard, offer training and support as needed.

4. Inventory. Ask business users to provide three layers of documentation for anything they develop. Layer 1 is the application’s title (“MS Word” is an application title). Layer 2 is the application’s headline (“General-purpose word-processing application” is an application headline. Layer 3 is a no-more-than-three sentence explanation of what the application does. With this inventory, should IT have to swoop in to save the day there’s a good starting point to swoop from.

5. Establish a Mentor Program, aka a Power Users Cool Kids Club. How to do this? See “Mentors are your friends. Be nice to your friends,” which first appeared in InfoWorld September 23, 1996.

Bob’s last word: For far too long, IT’s “best practice” on DIY development has been “We won’t do it for you and won’t let you do it for yourself.

Without a doubt, DIY development comes with some risks attached. But then, DIY prevention comes with risks of its own, namely, that various parts of the business will forgo important opportunities for technology-enabled improvements in effectiveness, all because a focus on what might go wrong blinds decision-makers to what might go right.

Now on CIO.com: “The 7 venial sins of IT management.” What it’s about: Seven mistakes to worry about that probably aren’t on your to-don’t list already.

Comments