How should we pay and manage knowledge workers?

It’s cheaper and easier to let developers work offsite, and it makes them happier, as well.  So why do we insist on managing them like 19th century factory laborers, or elementary school children being graded on attendance?

Solving the wrong problem

When we pay people for attendance or hours worked, we are solving the wrong problem.  We are solving (or attempting to solve) the attendance problem, when what we should be solving is the results problem.  This is true for W2 employees and for contractors.  A focus on hours worked (and worse) where they were worked incentivizes people to show up regularly, but doesn’t help identify and reward your best and brightest.  In fact, it demotivates because your best people have no reason to work any harder than your least productive staffers!

Unethical consulting

The issue is more glaring in the case of consultants (see “leech firms”, above).  If you were snake-bitten, wouldn’t you want your doctor to administer the cure administered as fast as possible?  But what if your doctor insisted on doling out the cure over 6 months, so that they could bill you by the hour?  I contend that hourly billing by consultants is flatly unethical, and counsel my clients against it.

Results, not hours

What C-level executives care about is results, not process;  lower level managers should, too.  So how can we restructure our incentive systems to compensate people more for results than for hours?

Results-based pay:  How should software developers be compensated?

Rather than measuring hours, many of which might be spent thrashing or shirking, software developers and other knowledge workers should be compensated as true consultants: for results against a fixed set of criteria.  Each engagement could be as short as a month, though quarterly might be more manageable.   This already happens in many organizations, as use of staff augmentation contractors has become more popular over the years, and, for better or worse, an effective way for a new CEO to impact stock price- layoff permanent W2 employees, and replace them with contractors.

Outsourced contractors are not true consultants

Outsourcing means “someone else handles that for us.”  That definition has become perverted.

There has been a tectonic shift towards contracting many knowledge-working jobs to so-called  “consulting” firms of one sort or another, including high-value jobs like software development.  But in reality, most of these companies are merely providing staff augmentation, not true consultants. That is, the 1099 contractor is still being managed by internal team leads and middle managers; they are simply not on the W2 payroll.  Internal managers still evaluate their teams largely based on hourly productivity estimates.

In other cases, consulting companies like Accenture, KPMG, CSC, and others may provide help on a vendor (corp-to-corp) relationship basis, with bespoke staff managed by their own on-site leaders.  However, they still bill the client company by the hour, rather than by results.

Need true consultants, not staff aug or leech firms

What most companies need, in fact, are true independent consultants, not staff augmentation, and not contractors masquerading as consultants.  I refer to the latter as leech firms, because their business model depends on placing as many people as possible in the client engagement, and billing hourly for as long as possible, regardless of how long it would actually take to deliver an effective solution.

To understand why the current model is broken, let’s go down in the trenches:

No trust

From 20 years in the trenches running global teams of software developers, analysts, writers, and creatives, one thing is abundantly clear:  nobody trusts them.

How do I know?  Because virtually every company large and small spends thousands- or millions-  of dollars on time tracking systems.  I’ve seen managers pull their hair out over developers who clamor to work from home.  These managers are unequipped to supervise anyone who is not sitting in the office.  Why?

For one thing, the further up the ladder managers climb, the more their reporting tools and requirements are essentially shared spreadsheets used to report “capacity” and “demand,” as though each developer was equally-spec’d robot, and each project was and equally-sized widget.  Of course, in the world of software, especially in highly competitive, complex, and reactive businesses, nothing could be further from the truth.

Worse, many managers simply don’t have the training and tools they need.  “Management” for them consists of checking what time the person arrives at their desk, and whether Facebook is on their computer screen during business hours.  What they are doing, effectively, is taking attendance, and trying to measure time-and-motion, they way Frederick Taylor did back in 19th-century factories.  Said Taylor to a Congressional committee:

“I can say, without the slightest hesitation, that the science of handling pig-iron is so great that the man who is … physically able to handle pig-iron and is sufficiently phlegmatic and stupid to choose this for his occupation is rarely able to comprehend the science of handling pig-iron.” (Montgomery, 1988)

Is this the way we want to treat knowledge workers today?

How do I know if they’re working or shirking?

Jack Warner, co-founder of Warner Bros. studios, was infamous as a controlling, dictatorial boss.  In the days of ‘captive’ studio writers, Warner used to prowl the lot outside of the tin army barracks where the writers were housed, listening for the furious clacking of typewriter keys. “If I don’t hear typing,” he raged, “how do I know they’re working?!”

Speaking as someone who’s run global teams, and managed a software dev factory of 60-plus people, I can tell you, it’s disconcerting as an executive to walk into the office and find it largely vacant, even though your employees are, ostensibly, working.  As a manager, most of us are not equipped with the right toolkits to manage remote staff, so we fall back on “bum-in-seat” methods, requiring everyone to show up at the office and look busy.  At least then we feel like we have someone to manage.  This is as much about our own egos and insecurities as managers as it is about real productivity.

The new factory worker

Peter Drucker coined the term knowledge worker circa 1959 to describe the type of worker most common in corporations today:  people who solve problems and create innovation with their minds, then document the results with their hands (through computer code, graphic design, writing, or other).

The speed at which each person accomplishes their mental task varies greatly across a team, much less across a company, and the speed at which they document and publish those results varies even more (touch-typing is not a prerequisite for a computer science degree).

Without a doubt, the person who solves the mental challenge most quickly is the most valuable to the team, since the more or less rote work of implementation can be accomplished by less stellar thinkers.  Yet, global Fortune 500 companies with tens of thousands of such employees still insist on paying them like factory workers, whose output could be measured by the number of minutes their butts are in a chair each day.  Most managers of thought workers today have the same empty management tool bags as Warner.  But their workers have a lot more employment options than did Warner’s staff writers.

A caveat:  many brilliant people in this area are simply awful at implementation.  They get bored so quickly that they end up taking all kinds of shortcuts when it comes to the most tedious part of the job.  In my experience, this is at the heart of fully 50% of corporate process and project failures.  So, having a magnificent thinker who is patient enough to do the ‘drudge work’ is a rare and most valuable find.

The beatings will continue until morale improves

Mistrust of your most valuable (and most expensive) employees leads to a dismal work environment. DeMarco and Lister wrote about the measurable effect of the work environment on productivity in their book Peopleware. The news was not good. IBM, for example, found a 50% productivity difference between programmers in a well-designed, developer-friendly workplace, and those in standard office cubicles or open workspaces. Many other companies found the same. This was one of the reasons behind the foosball-friendly IT environs in startups of the late 1990s and mid-2000s. Joel Spolsky, founder of, has not one but two excellent articles on designing the just-right office space.  One Fortune 50 client of mine claims that each cubicle they install costs them $10,000 per year;  so only W2 employees get 3-wall cubicles- a real perquisite!  Contractors and consultants are packed six-to-a-table in a semi-open, noisy, two-walled environment.  Makes for a wonderful thought-work ambiance, as you can imagine.  Developers are notorious about coming in late and calling in sick, and wanting to work odd hours. Small wonder.

Agile pay

But rather than pay these employees per hour, which still encourages leaders to manage to the wrong metric (hours worked), we should pay them for results achieved.  CIOs and COOs familiar with the “Agile” school software development will see this as a logical extension of Agile:  evaluating actual delivered code, rather than hours reportedly worked.  How might this be put into practice?

Code demo and sign-off

In Agile development, there is an emphasis on working code and features over complicated documentation, which rarely gets read and is cumbersome and expensive to maintain. Instead, Agile uses a checkpoint called a “code demo,” in which the development team demonstrates to the business clients who funded them what the software looks like after, say, one month intervals. The clients give input and feedback, request changes, and the team either goes back and implements those changes, if minor, or provides new estimates for the following month’s delivery, if the changes are major.  At the end of the demo, the client team signs off on those features they agree are ready to implement at the end of the current iteration.

Code demo, sign-off, and invoice

What if, at this point, the software programmer invoiced the company?  The developer could point to actual results achieved, and new work could be assigned.  The iterations, or delivery cycles, could be as long or as short as the client company wished, and the criteria could be defined as clearly or vaguely as the consultant developer was comfortable with (he would be forced to read the documentation, so he has an incentive to keep it light, too).

If the client was not happy with the code, they would have two options:  send the developer packing, or agree to pay for the work done, and request further changes ( a new contract, or extension to a Master Agreement).

Risk Mitigation

What if the developer puts in a month’s work, feels like they’ve delivered what was asked, but the client isn’t happy and won’t sign off?  In this case, either party can terminate the agreement, and move on.  To prevent the developer from being shafted, they request a deposit up front, equal to two weeks, one month, or whatever both parties agree.  The money could even be placed in escrow.  If the company terminates, the developer keeps the money.  It’s a small outlay for the company relative to litigation or arbitration, and reduces the risk of taking on a bad contractor then being stuck with them for 6-12 months.   For the software coder, it sounds less appealing than a six-month contract, but most such 1099 agreements allow termination for cause (or at-will) without notice, so the 6-month time frame is illusory, anyway.

True independent consulting

The arrangement I just described is no brave new world.  It is what my clients get when they  consult with me, and what yours should get, too.  It’s what client companies should strive for:  a consulting agreement with known, fixed cost, ROI, and acceptance criteria.

HR and Accounting dictate your operations

What stops more companies from doing this?  The draconian control that most HR and accounting department exercise over the hiring of “helper” resources is shocking.  Many Fortune 500 companies have made it all but impossible to hire an independent consultant without direct intervening approval from a C-level executive.  They force vendors to run a complex gauntlet of RFIs, RFPs, multi-stage approvals, and least-cost provider guidelines.  The result?  Well, as anyone’s  who has spent time in the bowels of a major company can attest:  not good.

You get what you pay for, and if your organization’s executive leadership has ceded control of their operations to mere gatekeepers, who do not understand your specific operational challenges, but who insist on limiting you to a “preferred vendor list,” or finding a vendor who will conform to hourly billing arrangements, no matter how quickly you want the solution, then you should be concerned, both for the health of your company, and for your own position.

Imagine that you told your boss that you need a socket wrench to do the job, and HR and Accounting clerks told you, “No.  Only hammers are on the ‘approved tool’ list. You can have a hammer.  The cheapest one.  It’s made of balsa wood and plastic. And we’ll need an RFP. We should be able to get you that toy hammer in 3-6 months.”

Such short-sightedness perpetuates the hourly billing and people management foolishness that has deprived major companies of so much value from their knowledge workers.  It leads vendors into business models built on hourly wage pyramids, and hamstrings leaders into taking attendance and babysitting, rather than managing for results.

Share your thoughts

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s