The Barefoot Philosophy Cornerstone #3: No Salaries

[This is part 4 of an 8 part series: The Barefoot Philosphy.  It is based on my experiences as the founder of a business—Barefoot Software—which I ran for 12 years.  Please start with the intro.]


Salary is one of my personal hang-ups.  I hate it so much that I’m not sure I can adequately describe it.  But of course I’m going to try.

The basic idea behind the concept of salary seems to be this:  We expect each employee to produce X hours of productivity (we’ll get to the sticky question of what “X” is in a bit).  Now, some weeks employees will produce exactly X hours.  But this is going to be the exception.  It’s far more likely that some employees, some weeks, will produce less than X.  In which case the company is getting screwed.  Whereas, other employees, or other weeks, will produce more than X.  In which case the employee is getting screwed.  Salary is, therefore, a system by which the vast majority of the time, someone is getting screwed.

If I were to come to you today, and you’d never heard of the concept of salary before, and I were to explain it to you, you’d look at me like I was insane.

And yet this is the way the vast majority of corporate workers are paid.  In fact, it’s become a status symbol in some weird way: hourly pay is for blue-collar workers.  White-collar employees get salaries.  It’s like you’re proud that you’re getting screwed.

It’s completely unfathomable.

The whole system seems to be predicated on the idea that the amounts that everyone is getting screwed will somehow balance out in the long run.  Perhaps ... for the company.  If it’s lucky.  But almost never for the employee, because it’s less likely that there’s variance over the weeks and more likely that there’s variance over the employees.  That is, some people are just prone to work more hours, and some people are just prone to work fewer.  So your underperformers are likely consistently screwing you, and your overperformers are likely consistently getting screwed.  And this is penalizing exactly the wrong batch of employees.  The last thing you want your most productive employees to do is wake up one day and wonder why they’re slaving away for you and getting paid the same amount as the people who slack off and only put in half as much time.

At Barefoot, we had a simple solution for this dilemma.  Everyone got paid hourly.  Everyone.  And we had a very simple policy: if you’re working, you’re getting paid.  Corollary: if you’re not working, you’re not getting paid.

Now, there were technical hurdles to overcome here as well.  We developed our very own “timer” program, and everyone had to remember to “start a timer” when they started working, and “pause the timer” when they stopped for the day.  Or when they got interrupted.  Or when they just moved on to a different task.  This was a difficult habit for us to form.  But we helped each other out.  Just as everyone knew what everyone else was making, everyone knew when you were running a timer.  (The timer program was run off a central server, so you could access anyone’s timer from anywhere.)  And it was everyone’s responsibility to police each other.  If you saw your coworker talking on the phone to his mom (or girlfriend, or bank, or whatever), you checked their timer to make sure they’d remembered to pause it.  If they hadn’t, you sent them an IM reminding them.  (Or just waved at them and pointed at your wrist, which was often sufficient.)  We did this to each other so often that we never got offended—after all, you weren’t accusing the other person of defrauding the company, which was never true.  It was always the case that they just forgot.  (If your employees are intentionally trying to rip you off, you’ve screwed up all the other cornerstones, and also your hiring process.)  So we were just being helpful.  The rule of thumb was: if you’re going to be away from the work for more than five minutes, pause the timer.  A quick trip to the bathroom was okay, or perhaps a dash to the kitchen to get a drink, but extended hallway conversations or smoke breaks meant you paused.  New people found this weird at first, but you rapidly get used to it and it becomes second nature.

Your timer, by the way, was not only what we used to pay you, but also what we used to bill the customer (assuming you were a billable employee, which most of us were).  So people were not only conscientious for their own sake, but also for the sake of the customers (more on why that would be true when we hit our last cornerstone).

Next, we have to consider what a reasonable value for “X” is.  This brings us to one of my favorite corporate myths: the myth of the 40-hour week.  I could probably write an entire blog post on this by itself.  In the interest of brevity, though, I’ll just hit the highlights here.  The fundamental problem that corporate managers seem to have when considering the 40-hour week is mixing up two fundamentally different measurements of time.  At Barefoot, we always kept them very distint, and we called them “work” and “availability.”

If you work from 9 to 5, as is typical in the corporate world, then you are at work for 40 hours.  This is radically different, however, from producing 40 hours of work (or productivity, or however you want to phrase it).  You can’t possibly do 40 hours of work in 40 hours of clock-time.  It’s not physically possible.  You have to go to the bathroom, at the very least.  And you have to eat every now and again.  And your family is going to call you, and your coworkers are going to pop by to talk about the game this weekend or that party they’re having or whatever.  And, even if you could approach 40 hours of work in 40 hours of time, you shouldn’t: it kills your productivity.  You need those regular breaks to keep your mind fresh.

At Barefoot, our completely unscientific research showed us that almost all of our employees produced between 30 and 35 hours of actual, productive “work” if they gave us 40 hours of “availability.”  We defined “availability” as any time that you’re available to do work, even if you’re not actually doing it.  You were generally available while you were in the office, of course, but you were also allowed to be unavailable in the office.  Or you could be available at home (obviously we encouraged working from home), although most of the time you were unavailable.  Your availability was set when you logged in for work, and unset when you logged out.  So, just like anyone could see your timer, they could tell if you were available or not.  (In our case, your availability was tied to our IM client.  Everyone was required to be online in IM when they were availble.  That made working from home, as well as full-time telecommuting, feasible.)

So, if we expect that people are only going to put in about 30 hours a week, then we need to pay them accordingly.  Which is exactly what we did: to pay a competitive wage, we took an annual salary for what the employee was worth (remember: merit-based pay), turned that into a weekly salary, then divided by 30 to produce an hourly rate.  So if you worked 30 hours for us, you’d make about what you made elsewhere.  If you worked more, you made more.  If you worked less, you earned less.  Nice and simple.

Of course, employees had to pay for their own health benefits.  If they wanted to take vacation days, they didn’t get paid, so they had to set aside money for that too.  So we just made sure that our hourly rate was high enough to let people cover those things.  Isn’t it better to let people handle those things themselves than try to enforce ever more baroque company policies?

This solves so many problems it ain’t even funny.  First and possibly most obviously, it completely eliminates the need to yell at people for not working.  As long as their timer isn’t running, who cares?  You want to sit at your computer and play Doom, or Star Siege Tribes for a few hours?^*  Fine.  Just clock out first.  You could even make it clear whether you were allowed to be disturbed during your game by setting your availability appropriately.

Just like merit-based pay, this is a self-regulating system.  People who slack off and never get enough work done also don’t earn enough to pay the rent: they either have to start working harder, or find another job that doesn’t mind their lack of productivity.  And the self-regulation is enhanced by the self-forming teams: no one wants the slacker on their team.  Well, unless you need someone to pitch in for like 10 hours a week.  And, hey, if you only want to work 10 hours a week, and you can afford to do that, and you can be useful to the company doing it, why shouldn’t we let you do that?

No salaries also completely eliminates the “death march.”  If we had some deadline and we needed people to put in extra hours, the first thing is, we never had to ask.  Partially because of the other cornerstones, but mainly because some people would want the extra cash in their pockets and they’d just volunteer.  If you weren’t one of those people—if you didn’t want the extra dough, or maybe you just couldn’t afford the extra time away from your family—that was cool too.  But more people would volunteer than not.  Because they knew that they might be putting in long hours, but at least they were getting paid for it.  And some of you more money-conscious entrepreneurs out there might be wondering: what about overtime?  Didn’t we have to pay time-and-a-half?  Well, first of all, if your normal work week is only 30 hours, that gives you a bit of headroom before you technically have to pay anyone overtime.  But, more importantly, the federal rule is, you don’t have to pay people time-and-a-half for overtime if they make more than six times the minimum wage.^**  And we paid everyone so well that that was true for almost everyone in the company (certainly it was true for all our billable employees).

This was probably the most radical departure from traditional business practice for us, but honestly I feel it was one of the most important.  It put employees in charge of their own financial destiny in a way that would have been impossible with salaries, and it completely obliterated a whole slew of sources of corporate friction.

Next week we’ll see what the corporate structure looked like.

Part: << 1 2 3 4 5 6 7 8 >>

* Remember, this was the 90s.

** At least that was the rule at the time; I assume it’s still true.

The Barefoot Philosophy Cornerstone #2: Merit-Based Pay

[This is part 3 of an 8 part series: The Barefoot Philosphy.  It is based on my experiences as the founder of a business—Barefoot Software—which I ran for 12 years.  Please start with the intro.]


Last week I promised I’d tell you why it doesn’t matter if everyone knows how much everyone else makes.  The answer, of course, is simple: pay everyone what they’re worth.

Netflix puts this slightly differently: they call it “paying top-of-market.”  They encourage their managers to ask this question:

What would we pay to keep that person?
— If they had a bigger offer elsewhere¹

I don’t like this quite as much as the Barefoot philosophy.  For instance, Netflix goes on to say:

Some people will move up in comp very quickly because their value in the marketplace is moving up quickly, driven by increasing skills and/or great demand for their area
Some people will stay flat because their value in the marketplace has done that
—Depends in part on inflation and economy
—Always top of market, though, for that person²

This makes good economic sense, but I ain’t here to tell you how to make good economic sense.  I’m here to tell you, in case you’ve forgotten, how to make your employees deliriously, ecstatically happy.  Here’s how we did it at Barefoot.

In order to get hired as a programmer,³ you had to write some code for me.  I reviewed this code with you, and we talked about it.  I pointed out things you’d done wrong, and you told me why you made those decisions.  Perhaps there were factors I couldn’t know about just from reading the code.  Perhaps you just didn’t know any better.  At the end of this process, I knew how good a programmer you were, relative to me.

If you were, for instance, half as good as I was, you made half as much.  If you were twice as good as I was, you made twice as much.  Or whatever percentage was appropriate.  That simple.

There are a few technical details you have to contend with if you want to make this work.  First of all, you have to jettison the silly notion that you can only give raises once a year.  This is a terrible idea anyway.  It produces what I like to call “Academy Award syndrome.”  You ever notice that powerful, serious dramas only ever show up just before the Oscar nominations are announced?  Meanwhile, the period just after the Oscars are awarded generally sees the worst cinematic dreck ever regurgitated hit the movie screens.  Do you really want your employees doing their best work in the month or so leading up to raise annoucements, and slacking off all the rest of the time?  Hell no.

Barefoot had what I call “anytime raises.”  You could get a raise any time, for any amount.  From my Employees First manifesto:

I gave raises whenever you showed me you were better than your rate said you were, and the raise was for as much as you deserved.  I gave someone a 50% raise once.  I gave someone a raise once before he ever got his first paycheck, and I made it retroactive to his first day, because he demonstrated that he was better than I thought he was when I hired him.

Which also demonstrates that you have to be willing to admit you screwed up in your initial evaluation.  If you underestimated, you just fix that by raising their rate appropriately.

But what if you overestimated?  Well, I tried to be very conservative when evaluating for that very reason.  It’s always easier to give someone a raise than a pay cut.  But, if you’re committed to merit-based pay, you have be willing to do just that.  Not only can you overestimate someone initially, people can become less productive over time.  In an environment like the one we had at Barefoot, that was very rare.  The whole point of an employee-focussed workplace is to get everyone doing their utmost to push themselves to be the very best they can be.  But sometimes it just happens that people slip.  When that happens, you just have to sit them down and say, “I’m sorry, but I have to reduce your pay right now.  When you get back to where you were, we’ll put it back.  But right now this is what you’re worth.”  Remember: you aren’t doing anyone any favors by overpaying them either.

Valve does this even better, I think.  They use what they call “stack ranking,”⁴ which takes into consideration a lot of different factors, from technical ability to group contribution.  I’ll freely admit that they have a more complete handle on this, although at Barefoot certain things (such as productivity) were factored in to pay scale, but only after initial evaluation (which was completely based on technical ability).  But, the point is, your pay rate reflects your value to the company.

This is important, and it not only made it okay that you knew what everyone else made, it made it vital.  Your pay rate was what you used to assess your position within the company (in a couple of weeks we’ll talk about why you couldn’t use your job title for this).  By comparing how much you made to how much that guy over there made, you could tell if he or she was better than you.  At every other company I’ve ever worked for, the fight (silent, but deadly serious) over who is the “top dog” programmer was an ever-present distraction from getting the work done.  Not at Barefoot.  You knew who was better than you were, and you either accepted it, or you didn’t.  If you didn’t, there were two possibilities.  Either you thought the ranking was wrong, which inspired you to prove to me (or one of the other top guys) that you were better than we thought you were.  Or you knew the ranking was right, but you wished it was wrong, which inspired you to improve your skills and earn a better ranking.

And knowing where everyone stands in relation to each other is important if you want to have self-forming teams.  (Valve talks about this briefly.⁵)  Every team needs to know the relative skills of the people they’re recruiting.  And don’t worry about the less experienced people never finding a spot.  It only takes a very small amount of exposure to self-formed teams to figure out that you need those “junior” folks.  Lead singers get all the attention, but drummers and bass players keep the songs moving.  A team composed of nothing but “senior architects” is the most disastrously useless thing in the known universe: they all know exactly which direction the team should go in, and it’s never the same one.

Merit-based pay is also a self-regulating system.  People who aren’t that productive either get better, or they get gone—they have to, in order to pay the rent.  On top of that, with self-forming teams, the underperformers never get “picked.”  I never fired a single person in all my years at Barefoot, but that doesn’t mean that we never let anyone go.  There just wasn’t any work for them, eventually (which works because of next week’s cornerstone).

It also goes even further along the path that we started with financial transparency: there is no division between the people who run the company and those who work for it.  Myself and the various people who served as CEO, or COO, or CFO, got the same merit-based pay as everyone else.  We weren’t “special” because we had been there longer, or because we were nominally in “charge.”

This theme of equality also extended to benefits.  I note that Netflix figured this out as well: they offer a flat yearly amount for health care coverage; if you don’t use it all, you pocket the difference.⁶  At Barefoot, it was even simpler: we didn’t pay for any of your health care.⁷  Of course, our pay rates were higher to help compensate for that (but then, as we’ll see next week, they were higher for other reasons as well), but the point was the same as it is at Netflix: you pay for what you need, nothing more.  And you aren’t entitled to more health care just because you’re married, or you have children.  Why should you compensate your unmarried employees less?

Now that we know how to compensate employees relative to each other, we can look at the technical details of how to express pay rates.  Next week.

Part: << 1 2 3 4 5 6 7 8 >>

1 Netflix Culture: Freedom & Responsibility, slide 97.

2 Netflix Culture: Freedom & Responsibility, slide 102.

3 The process was different for non-programmers, but the philosophy remained the same.

4 Valve Handbook for New Employees, page 27.

5 Valve Handbook for New Employees, page 10.

6 Netflix Culture: Freedom & Responsibility, slide 109.

7 This is not quite true.  There was a way to get the company to cover part of it.  But we’ll come to that towards the end.

The Barefoot Philosophy Cornerstone #1: Financial Transparency

[This is part 2 of an 8 part series: The Barefoot Philosphy.  It is based on my experiences as the founder of a business—Barefoot Software—which I ran for 12 years.  Please start with the intro.]


My business preceded a lot of those that have made a splash in the business world for doing things in an unconventional fashion.  One that I didn’t precede was SRC, which was founded in 1983, while I was still in high school.  But that company is still around today, and, according to Wikipedia, its revenue is $400 million.  Its founder, Jack Stack, championed a new business philosophy which has since come to be called “open book management.”  What it means is very simple: you open your financials to your employees.

There are no closed-door meetings among the senior team.  There are no secrets.  Everyone knows everything.  Everyone knows exactly how much the company is earning off of their labor at any given moment, and maximizing that is everyone’s business.

Article after article reaffirms that this works.  And yet very few businesses are run this way.  I actually suggested this methodology to my current employer once.  It wasn’t a pretty conversation.

I’ve yet to understand exactly why, though.  Does upper management imagine that they are the only ones smart enough to understand the financial intricacies of the business?  Do they perhaps not trust the employees to be responsible with the company’s money?  Well, I hate to be the one to break it to them, but this lack of trust is one of the major reasons for low employee productivity.  To quote one of those many articles:

High performers don’t thrive in an atmosphere of secrecy and uncertainty.  They want to work for a company that treats them with respect and values their problem-solving skills.¹

Perhaps some people are worried that employees will be unhappy once they realize how much money the company is making off them.  First of all, if you have to worry about this, you probably are making too much money off your employees (and you should fix that).  But we’re also going to discuss how to fix that perception in later cornerstones.

While I was running Barefoot, my attitude was always, “I need to understand how everything works financially.”  I broke things down all the time.  I was very influenced by an article I read in a doctor’s waiting room somewhere² that talked about calculating profit, and all the things most people forget to consider.  I started creating all these Excel spreadsheets with profit calculations and models on them.  Everything went into them: even the money I paid our office manager to generate biweekly payroll was spread out amongst all our billable employees and turned into a line item.  Without those numbers, how could I know whether we were making money or not?  And, once I had the numbers all laid out, why should I be scared to show them to everyone?  Hell, some of my employees were smarter than I was; they might help me find mistakes.

So all those profit spreadsheets were on a network drive where everyone in the company had access to them.  But we didn’t stop there.  Our accounting info was in QuickBooks.  It was, of course, password protected.  But everyone in the company knew the password.  Or at least could know the password, if they were so inclined (some were, some weren’t).

The first objection that some of you are going to have is:  Doesn’t that mean that everyone knew how much everyone else made?  Yes, it does.  This isn’t as bad as you think it is.  Mainly that’s because of the cornerstone we’ll cover next week.  But the bigger issue is, what problem do you think you’re solving by keeping everyone’s salaries a secret?  Perhaps you think that, if no one knows what anyone else makes, there will never be any jealousy over compensation.  Unfortunately for you, keeping salaries secret and no one knowing what anyone else makes are two entirely different things.  You see, each employee knows what he or she makes, and employees talk.  Managers usually know how much the employees that work for them make, and managers are employees too, and employees talk.  There really is no way to keep these things secret, no matter how few people you tell.  Worse, when people don’t know how much their coworkers make, they speculate.  And they’re often wildly wrong.  Now all of a sudden you can have people being jealous of coworkers who actually make less than they do.

Quite simply, this is one of those cases where honesty really is the best policy.  Honesty with all your employees means that they understand things.  When things are bad, you just tell them things are bad.  Not only do they have the financial background to be understanding about it, they often have the knowledge to actually do something about it.  And, when senior management treats their employees like mushrooms,³ the employees aren’t going to assume that everything is fine since no one is telling them anything.  They will often imagine things are much worse than they are and start panicking.

Most importantly, employees (human beings in general, really) need to understand why.  Why does the company do this?  Why does the company set the margins here?  Why won’t the company spend money there?  Why does this project need to be done so badly?  “Because I said so,” is an answer for children (and not a very good one even for them).  Tell them the real reason, and they’ll respect you more, and they’ll do better work, and they’ll do it more efficiently, and they may even fix the problem for you when you aren’t looking.

Maybe your fear is that employees just won’t understand all that financial mumbo-jumbo.  But this is just conceit, plain and simple.  None of us understood the financial mumbo-jumbo, at first.  We had to learn it.  Your employees won’t understand it either, at first.  Teach it to them.  This is an investment which will repay itself tenfold and more.  And while some of them will be annoyed at having to learn something they don’t particularly have any interest in, not a damn one will ever curse you in later years for forcing them to learn it.  It will always serve them well, in every job they ever have, for the rest of their lives.

I’ll tell you one last thing about Barefoot’s financials that I’ve found superior to every other corporation I’ve had the opportunity to work for or with—how we did bonuses.

We had sales commissions, and we had referral commissions.  Those worked pretty similarly to how they work in other companies.  We also had another type of commission: employee commission.⁴  Employee commission was based on what we called the “direct profit,” or sometimes just “the diff.”  It was basically just the difference between how much we charged the customer and how much we paid the employee doing the work, with just a few other direct costs subtracted (specifically, sales and referral commissions, if applicable).  The commission wasn’t a straight percentage though; it was a more complex formula, and one of the factors in it was squared, resulting in a quadratic progression.  So if the diff was very low (say, $5 per hour), the employee commission might be miniscule (say, 10¢ an hour).  But if the diff was very large (say, $50 per hour), the employee commission would be substantial (perhaps $10/hour).

We would take the employee commission and put it in a pool, and that pool was what went to pay your quarterly bonus.  You got rated on a scale of 1 to 5.  I don’t remember the exact percentages, but it was something like, 1 was 80%, 2 was 90%, 3 was 95%, 4 was 100%, and 5 was 110%—something along those lines.  Whatever percentage you got, you got that much of your employee commission.

Now, there’s a number of things going on here.  First of all, the more the company makes off you, the more you get back on your bonus, and the quadratic progression means that your “cut” is going up faster than the company’s.  So that makes employees happy, first off.  But probably what’s more important is that we’ve guaranteed that the bonus pool is paid for out of the profits.  This avoids things such as “calibration.”

“Calibration” is what it was called at eBay, at any rate.  Under this plan, there is a certain amount of money available to give out to employees.  The performance is also 1 to 5, but the percentages are different: 3 is 100%, while 5 goes up to 150% and 1 gets nothing at all.  The “calibration” part is what you have to do when everyone on your team is really good at what they do.  Instead of a performance rating reflecting an employee’s actual skills and utility to the company, the ratings are forced to fit a curve: only so many 5s allowed, only so many 4s, and so on down to the 1s, which you are required to have some of.  This is moronic.  This actually encourages managers to keep underperformers around so they have somewhere to dump their 1s.  And how discouraging is it to tell some of your top performers that you can’t actually rate them as top performers because too many of their coworkers are top performers too?  It’s like being penalized for building a superior team.  Netflix addresses this in their culture document (emphasis added):

We avoid “top 30%” and “bottom 10%” rankings amongst employees  ...  We want all of our employees to be “top 10%” relative to the pool of global candidates⁵

In the end, financial transparency avoids creating an artificial gulf between “senior executives” and “low-level employees,” keeps employees in the loop and engaged, and demonstrates respect and trust, which in turn keeps your best and brightest from looking elsewhere for those things.  It’s the first step, but not the last.

Part: << 1 2 3 4 5 6 7 8 >>

1 “How much should you tell employees about the financials?”, ReliablePlant, Quint Studernot.

2 After doing a bit of research, I’m pretty sure it was this one.

3 I.e., keeps them in the dark and feeds them bullshit.

4 Employee commission was for our billable employees.  Non-billable employees had a separate sort of commission—admin commission—based on the gross profit of the entire company.

5 Netflix Culture: Freedom & Responsibility, slide 113.

The Barefoot Philosophy: An Introduction

[This is part 1 of an 8 part series on business philosophy.]


Twice in the past few weeks, someone has sent me the manifesto of a company, explaining why they do the things they do, which things are radically different from the way other companies do them.  The first was a culture statement from Netflix.  And the second was the employee handbook of Valve.  I’ve read both of these, and you know what I kept thinking the whole time I was reading them?

This sounds familiar ...

You see, I founded my own business—Barefoot Software—in 1992, four years before Valve, and five years before Netflix.  I ran my business in ways that were considered radical at the time: in fact, one of the reasons I worked so hard at it was undoubtedly just the satisfaction of proving a bunch of people wrong.  At Barefoot, we referred to our way of doing business as “the Grand Experiment” exactly because it was so different from how anyone else had done things.  Now it seems like everyone is jumping on that bandwagon.

Now, don’t get me wrong; I’m not saying that either of those companies (or any other company) stole my ideas.  You see, those companies have one major advantage over mine: they succeeded.  My company was mildly successful for a while, but in the end it didn’t last.  Thus you’ve never heard of it, and thus the people who founded Netflix and Valve have never heard of it, and thus it isn’t sensible to imagine that anyone stole my ideas.  On the other hand, those companies (and others who have championed radical business approaches, such as Google, Zappos, or GitHub) not only lasted, but managed to make shit-tons of money.  So in one sense, you should listen to those guys and not to me.

Still, I wonder if my experiences have some merit.  Many of the things I did are similar to the policies of those companies that followed me (yes, I preceded all those other guys too).  But I also did a few things differently, and I think that, supposing you were someone who was interested in creating your own personal business philosophy for whatever reason, you would want to study as many different examples as possible and look to combine all the best points.  So perhaps my offering will be useful.

Of course, it may occur to you to wonder why you should listen to me if I freely admit that my business failed.  There are two reasons that I think you should.  First, failure is how we learn.  In my experience, and in my research, I find that the best and most successful business owners have a failed company or two in their past.  But, more importantly, it’s crucial to note why my business failed.  I was good at a lot of things, but not everything.  In particular, I was pretty awful at the sales and marketing side, and that’s one of those things that you can’t neglect.  If the way you get all your new cusomters is mostly by luck, eventually your luck runs out.  The fact that I made it for 12 years is actually pretty impressive, if you look at it that way.  But the main point is, I’m not going to offer you any advice on how to attract new customers, since that’s obviously an area I’m not particularly qualified to comment on.  You’ll have to handle that side of it yourself.  What I want to talk about is how to run the company on a day-to-day basis.

In researching this article, I looked around to see if I could find any of the original stuff we wrote about the “Barefoot Philosophy.”  I remember doing a sort of “mission statement” ... such things were just getting popular back in those days, and, even though on the one hand it seemed a bit silly and unnecessary, on the other hand I was an English major, with an inherent understanding of the power of words, and I thought maybe there might be something to it after all.  So we came up with something.  I don’t seem to be able to locate it in my files (no doubt it’s on one or more of the hard drives I have sitting around in boxes somewhere, which are all that remains of the many Barefoot servers), but you know what they say: the Internet is forever.  Yay, Wayback Machine!

So, looking at the most recent version of the Barefoot Philosophy I could find, I notice several things.  First of all, it’s crap.  That is, it’s sincere enough, but it’s all fluff.  There’s very little substance there.  There are a few important concepts, and I encourage you to read through it, but I think you’ll come away with the same assessment as I did: it’s almost entirely content-free.  All talk and no action.  Now, in my defense, most company mission statements are, in my experience.  Also, at least back then, most entire web sites were.  Having your web site actually do stuff came later.  At that time it was all about looking pretty and soundy lofty.  Which that page achieves about half of.

The other thing I notice is that, back then, pretty much anything you wrote to describe your company’s way of doing business could be called a “mission statement.”  Nowadays, there are mission statements, vision statements, value statements, culture statements, and all sorts of other statements.  What we called our “mission statement” is actually closer to a values statement in today’s terminology.  Which is nice and all, but values statements are pretty abstract.  I already mentioned that I think mission statements are almost always content-free, and I think vision statements are even more so, almost by definition.  But culture statements, on the other hand, can be useful.

Both of the documents I referenced at the beginning are culture statements: one explicitly so, and one disguised as an employee handbook.  The values statement of Barefoot’s that I found on the Wayback Machine can give you some vague insight into what sort of lofty goals we aspired to.  But a culture statement is more useful: it tells you how you’re going to get there.  What specific policies are you going to enact (and enforce) in order to achieve those lofty-sounding goals?  What are you going to do when a problem crops up? or when something threatens your business philosphy?  How will you ensure that the policies are embedded into the organization and will outlive you, whether by death, disenfranchisement, or just plain disinterest?  Those are the things which interest me in the two documents I read, and Barefoot never had those things written down for it.

So I’m going to write them down now.  And share them with you.

Now, I’ve written about my business experience before, so I’ll take advantage of that and refer back to a few things I’ve written previously, just to save time and not have to repeat myself.  The primary culture of Barefoot can be summed up in two words: Employees First.  As I said more recently when I was talking about managing programmers:

I ran my own software development business for 12 years, and I followed one simple philosophy: keep your employees happy.  I never worried about keeping my customers happy, because I found that, if you keep your employees happy—and not just content, but deliriously, ecstatically happy; happy to the point where, at the end of the day, they’d rather stay at work because it’s more fun than going home—they’ll produce such amazing software that the customer satisfaction thing just takes care of itself.  I had more than one employee tell me that it was the best job they’d ever had.  Very few of my employees ever left for any other reason than I’d run out of work for them, and nearly all the ones that left because of that ended up coming back later.  I had an employee once sit at home jobless for a year and a half because he was just waiting for me to call with more work (and also because I’d paid him well enough that he could afford to do that).

Most business advice you’re going to see out there tells you to listen to your customers, to worry about keeping your customers happy.  Which you should.  But I’m going to advance a pretty radical departure: that shouldn’t be your first priority.  Why not?

When I started my own business, it wasn’t to get rich (and good thing too, since I didn’t).  It wasn’t so that I could be in charge and tell everyone what to do: in fact, I spent a good deal of time trying to hire someone to be my boss.  It was mainly because I felt that most of the companies I’d worked for treated their employees like shit.  And I thought that was a terrible thing to do.  Even though I never actually wanted to run my own company—never wanted to be in charge of anyone—I did so because I felt it was the only way to create a workplace where the employees would be valued, treated with respect and dignity.  I never tried to get rich.  I only wanted to make enough money for me and a bunch of my friends to have a cool place to come to work every day.

But despite the fact that I started out with very anti-business motivations, I soon discovered that this was an excellent way to run a business even if you’re very profit-centered.  I explained the financial aspects of this a bit more clearly in my Employees First manifesto:

Your customers want excellent work done for reasonable rates.  And here’s what I discovered when I ran my own company: if you make your employees happy—not just a little happy, but deliriously, ecstatically happy, or as close as you can damn well come—they will do excellent work, and they will do it for reasonable pay.  If they get reasonable pay, I can charge reasonable rates.  Now I have excellent work for reasonable rates, and that’s called outstanding value.  If I put my employees first, I can make my customers happy without even trying.  If I put my customers first, my employees are not as happy, and they won’t do their best work for reasonable pay, and I can’t make my customers happy.

Note the repitition of the phrase “deliriously, ecstatically happy.”  I use that phrase nearly every time I broach this topic, and for good reason.  This is what you want to achieve if you want to have an awesome company.  Now, I was working with creative people (primarily programmers), but I tend to think this applies to all employees (although admittedly I lack the experience to back that up).  When your employees are deliriously, ecstatically happy, you will produce value that is so outstanding that your competition will cringe.  Your customers’ loyalty will be unbounded.  Of course, as I mentioned above, this is not sufficient to creating a very successful business.  You’ve still got to think about marketing, and how you attract interest, and how you create buzz, and all that other stuff that nowadays is generally lumped under “branding.”  I don’t mean to downplay that stuff at all.  But while keeping your employees deliriously, ecstaticaly happy is not sufficient, I believe it damn well is necessary.

In the next 5 parts of this series, I’m going to tell you exactly how to do it.

Part: 1 2 3 4 5 6 7 8 >>

Little Things Add Up

It has long been an axiom of mine that the little things are infinitely the most important.

— Sherlock Holmes (“A Case of Identity”, Sir Arthur Conan Doyle)

A few years ago, the architecture team at my work (of which I am a part) put together a presentation for the business designed to explain why a serious rearchitecture was important.  We all contributed ideas and analogies and metaphors, and different ways to illustrate the problem.

One of the ones that I contributed was this:  Many times throughout your work week as a programmer, you run across things in our ten-year-old codebase that you just don’t understand.  Things that look insane.  Things that look like they couldn’t possibly work, and may in fact represent subtle bugs that no one’s ever been able to catch.  When you find such a thing, you have two choices: you can ignore it, or you can fix it.

If you fix it, you risk breaking something.  This, after all, is the source of the ancient adage that “if it ain’t broke, don’t fix it.” By “correcting” something without a complete understanding of just what the hell it’s supposed to do, you may correct one subtle bug only to introduce another.  The new bug could be worse.  It could cause a loss of revenue that’s not immediately obvious, and you might end up six months later in some business meeting trying to explain how you cost the company tens of thousands (or hundreds of thousands, or millions) of dollars because you “fixed” something that no one asked you to.  If you are a corporate programmer with any reasonable amount of experience, this has already happened to you in your career.  Probably more than once, even.

So, for any one given situation like this, the smart thing to do is to ignore it.  That is, from a risk vs reward perspective, or from a return-on-investment perspective (both of which are very proper business perspectives), the right thing to do, the responsible thing to do is to just leave it and move on.  Because the advantage of making your codebase just a tiny bit more sensible and sane isn’t worth that risk.

But the problem is, all those little things add up.  When you stand back and look at the big picture, over the course of ten years you’ve made thousands (or even tens of thousands) of individual decisions where each one was the right decision individually, but together they spell disaster.  Together, this approach means that you are literally incapable of ever improving your code.  Your code is, by definition, continually going to get worse.

Among the maxims on Lord Naoshige’s wall there was this one: “Matters of great concern should be treated lightly.” Master Ittei commented, “Matters of small concern should be treated seriously.”

— Yamamoto Tsunetomo, Hagakure

It’s very popular in business culture to quote Sun Tzu.  After all, the competition of companies often seems like a war.  Plus pithy quotes like “attack the enemy’s strategy” and “speed is the essence of war” sound really cool when you break them out in a business meeting.  In reality, The Art of War does have quite a few valuable lessons for us.  For instance, “lead by example” (technically, “a leader leads by example not by force”).  That’s pretty good advice.  Or how about this one: “Pick your battles.”

Actually, what Sun Tzu said was: “Thus it is that in war the victorious strategist only seeks battle after the victory has been won, whereas he who is destined to defeat first fights and afterwards looks for victory.” But most people interpret that as just a more flowery version of “pick your battles.” And plenty of people have expounded on this theme.  Jonathan Kozol, educator and activist, once said: “Pick battles big enough to matter, small enough to win.” It seems like where Sun Tzu started was an aphorism on trying not to get into battles you know you can’t win.  But where Kozol, and most of us, seem to have ended up is closer to the military version of “don’t sweat the small stuff.” That is, learn to let the little things go so you can save your strength for the big ones, the ones that are really worth fighting for.

And certainly this seems to make good sense.  If you’re going to be losing any battles, they probably ought to be the ones that don’t matter as much ... right?  As we contemplate where to direct our energy, where to concentrate our efforts, when each little battle comes along, it’s always going to make sense to let it go and wait for the big problem that’s inevitably going to show up tomorrow.  But, the problem is, there’s a flaw in this reasoning.

See, little things add up.

I think we’re looking at the wrong end of the trite maxim spectrum.  Maybe we should be considering that “mighty oaks from little acorns grow.” Or that “a journey of a thousand miles begins with a single step.” This is what disturbs me about the (quite common) corporate attitude that, as employee freedoms are eroded bit by bit in the name of increased efficiency, each such loss is a small battle, and not worth fighting over.  I often speak out about such things, when I have the opportunity.  And I’m often told that I need to learn to let these little things go, because, you know, there are bigger fish to fry.  Pick your battles and all that.

So I get a lot of eyerolls, and shaken heads, and derisive snorts, because I’m making mountains out of molehills.  I need to go along to get along.  Because my argument is one of those “slippery slope” arguments, and you know how silly those are.  Let gay people get married today and tomorrow we’ll have legalized bestiality.  Stop people burning flags and next thing you know our free speech is gone.  That sort of thing.  Poppycock.

But here’s the thing.  When you first start a job, the world is full of possibilities.  And the environment of the place—the culture—is awesome ... if it weren’t, you wouldn’t have taken the job, right?  And if, later, after you’ve been there for a while, some little small thing that attracted you to the job is taken away, it’s not a big deal, right?  There’s still all the other things you liked.  And, the next year, if one other little thing disappears, it’s still no big deal, right?  This job is still far and away better than anything else you could find out there.  And if, the year after that, one more little thing is taken away ...

Here’s another saying for you: death by a thousand cuts.  None of those individual cuts hurt, really, but one day, you just realize that there’s no point in going on.  And you start to question whether it really is true that there couldn’t be something better out there.  And you toss off an email to some random recruiter and next thing you know you’re moving across the country to an even more awesome job.  (But then I’ve told this story before.)  And then you start the whole cycle all over again.

The really sad thing is that, no matter how often this happens, the corporate managers will never see it coming.  See, from their perspective, people are quitting over stupid, trivial things.  And people that will quit over stupid, trivial things ... you don’t want those people anyway, right?  There was nothing you could do.  They were unpredictable.  Anything might have set them off.

They’re missing the big picture.

They let the little things slide, because they weren’t worth fighting for, and the little things added up.  There were haystems snapping dromedary spines right and left, to coin a phrase.  Is it really true to say there was nothing they could have done?  I wonder ...

I wonder what Sun Tzu would say if asked that question.  It’s sort of difficult to know for sure, seeing as how he’s been dead for about 2,500 years.  But I could hazard a guess.  I think he’d say this:

Treat your men as you would your own beloved sons. And they will follow you into the deepest valley.

— Sun Tzu, The Art of War

The Care and Feeding of Code Monkeys

Welcome to part 3 of my 2-part series on how to make Agile Development actually work.  This one has to do with managing programmers, which is both completely outside the purview of Agile and yet inextricably tied to it.  (It also ran a little long, since it’s a topic that I’m very passionate about.  Hopefully you’ll stick with it.)

First, a word on nomenclature:  At my current job, I am a “software engineer.”  At my last job, I was a “code monkey.”  What I really am is a programmer.  You can dress that up however you like, but, if you primarily write code for a living, you’re a programmer, and the following thoughts apply to you.  Be careful applying it too broadly, though: folks in other tech pursuits that hardly sling code at all, like system administrators and DBAs, may not fit the mold I outline here, and folks who write a lot of code but also do a lot of other things (e.g. QA engineers who specialize in automating tests, release managers who have to help code up things like continuous integration systems) may sort-of-kind-of fall into these patterns ... or not.

And, though I say above “if you primarily write code for a living, you’re a programmer, and the following thoughts apply to you,” what I really mean is, “if you primarily manage coders for a living, you’re managing programmers, and the following thoughts apply to you.”  For the advice I’m going to give you is pretty useless if you’re the one being managed.  We typically have so little say in those sorts of things.  Which is sad, really, but a topic for another time.

Next, a note on my qualifications.  I ran my own software development business for 12 years, and I followed one simple philosophy: keep your employees happy.  I never worried about keeping my customers happy, because I found that, if you keep your employees happy—and not just content, but deliriously, ecstatically happy; happy to the point where, at the end of the day, they’d rather stay at work because it’s more fun than going home—they’ll produce such amazing software that the customer satisfaction thing just takes care of itself.  I had more than one employee tell me that it was the best job they’d ever had.  Very few of my employees ever left for any other reason than I’d run out of work for them, and nearly all the ones that left because of that ended up coming back later.  I had an employee once sit at home jobless for a year and a half because he was just waiting for me to call with more work (and also because I’d paid him well enough that he could afford to do that).  When I tell you that I know how to manage programmers, I ain’t fucking around.

And finally (at least as regards this introduction), a cautionary note.  I generalize.  I think it’s good to generalize, even about people, as long as you remember that, at the end of the day, we’re all different, and we all need to be treated just a little bit differently.  You must be careful not to fall into the trap of stereotyping.  But there’s still a lot to be gained by understanding the whole through understanding the majority (because, even though we’re all different, we’re all the same), so absorb what I’m saying here, but remember that you’re always going to encounter exceptions.

So how does one go about managing programmers?

Well, there are two things that you must remember.  The first I’ve already discussed in some detail, and it would be pointless to belabor it again.  I’m talking about the issue of perception vs reality.  If you’re too busy to click that link, here’s the executive precis:  Programmers spend all day talking to computers, which are insanely literal; they tend to lose their concepts of perception.  You, however, are most likely a business executive, for whom things like your perception in the marketplace, your reputation, and your perceived brand value are paramount.  This leads to a fundamental disconnect.

The second one I touched on in my exploration of what agile means: programmers are craftsmen.  Very few people get this.  Most folks think programmers are all logical and mathematical, like Vulcans.  And it’s true that programmers have to have a logical component to their personality.  But some of the worst programmers I’ve ever met were mathemeticians, or mechanical engineers.  Not to disparage those professions—they’re very fine careers.  But the point is, those fields attract people who like things to fit together neatly and sensibly.  Programming isn’t neat.  It’s heinously messy.  Stuff goes wrong that no one can really explain, there are bizarre interactions between complex systems that were never foreseen, and there’s all these terribly illogical users involved in the process.  People who like things tied up in a bow get really crazy when they have to develop software.

But, even more than that, coding requires creativity.  There’s actually one backwater of mathematics that I remember from my school days which was a bit like programming: proofs.  I first learned them in geometry, which I took in the ninth grade.  A proof is a way to chain together different rules: this rule leads you to that rule and thence to the next, and so on.  To chain these rules together requires a very logical mind.  But you also need to have a sense of where you’re going, and that’s where the creativity comes in.  You need to be able to make a creative leap to the end first, and then be able to logically work your way there from the beginning.  If you start a proof without a clear idea of where you’re going, you most often end up right back where you started.

And so it is with programming.  That creative leap is absolutely crucial to being a top-notch programmer.  Without it you’re just a monkey pulling wrenches.  If more people understood this, the world (or at least the business world) would be a better place.

Because I think that the business world already understands that you have to manage creative people differently.  Advertising agencies, for instance, routinely hire artists, and writers, and people whose sole job is just to come up with ideas.  They’ve figured out that you can’t treat these people in the regimented fashion that you do for other workers—giving them dress codes, and set hours, and making up weird little rules about what they can and can’t put on their cubicle walls.  (Not that I’m saying that those are good ways to treat anyone, really.  Just that trying to treat creative people in such a fashion is even more doomed to failure.)  The Internet culture that came out of California in the ‘90s (and in particular out of Silicon Valley) has gone a long way towards fixing this for programmers.  There are many businesspeople who now understand that programming can be fun and they need to encourage their employees to have fun while doing it.  (That attitude is still more prevalent on the West Coast than the East, in my experience, but we’re getting there.)

But what I’m not sure of is whether the business folks realize why they need to promote the culture of fun.  See, there are many jobs where you don’t really need to think very hard to get the job done.  You just do them.  They’re mostly easy, and a bit repetitive, and, once you’ve done them two or three times, you can practically do them in your sleep.  Again, this is not to denigrate any of those jobs, or any of the people who enjoy them.  I can certainly appreciate a job where I can let my mind do its own thing all day while my body churns out work.  That’s a cool gig.  But that’s not my job.

My job doesn’t just require me to think; it requires me to innovate.  Every day, in a thousand little ways, I make tiny little creative leaps (and sometimes, if I’m lucky, a few giant creative leaps).  In order to do that, your mind has to be relaxed, and clear.  Focussed is good, sometimes, but other times stepping away and focussing on something else entirely (like a rousing game of ping-pong) is exactly what the doctor ordered.  The one thing you absolutely cannot do is just plug away at it until it works.  That takes forever, and ususally produces a mess.  You need to be able to distract yourself, or maybe even just close your eyes and lean your head back and ponder.

Note that I say you need to be able to distract yourself.  Having other people distract you doesn’t help.  In fact, it’s horrible.  Just ask Samuel Taylor Coleridge.  Programming is brief periods of seeming inactivity (waiting for inspiration to strike) followed by intense bouts of insane productivity (where you put the inspiration down on paper, or in this case on screen).  This is why programmers always want to work from home.  Other people can distract you at home occasionally (particularly if you have a family and if you don’t sit them down and go over the “rules”), but in general the phone doesn’t ring, and people don’t wander by your desk for a quick chat, and there are no meetings.  I know that you, as a businessperson, value meetings.  You think that if you spend all day in meetings, you’ve actually accomplished something.  We programmers are different.  Our job is to write code.  You can’t write code in a meeting.

And the business world (even the California business world) is reluctant to let programmers work from home.  It’s changing, a bit, but still there are too many classically trained managers out there who believe that, if they can’t see you working, you must not be working.  This is 100% a trust issue.  I’m a programmer.  I’ve been a programmer for 25 years—that’s over half my life (actually, I’ve been a professional programmer for over half my life; I’ve been a programmer for about two-thirds of it).  I want to program.  You want me to write code, and that’s what I want to do.  If you let me go home, you know what I’m going to do when I get there?  Program.  Programming has got be one of the few jobs in the world like this.  When you’re a programmer, you relax after a hard day of writing code by writing more code.

So you don’t have to come up with strategies for making me do what you want me to do.  What you need is strategies to make sure nobody stops me from doing it.  Reduce my interruptions.  Reduce my meetings (agile helps with this).  Reduce my emails, if you can, and reduce the people who just pop over to get my opinion on something.  Stop telling everyone that they should not send me an email because it’s better communication if they come talk to me face-to-face.  It may be better for you, but it’s death to me, and to my productivity (and isn’t that what you’re striving to maximize?).  I want fewer emails too, but given the choice between a communication that I can attend to when I was going to take a break anyway and one that blows my concentration and makes me drop the threads I was juggling in my feverishly inspired brain, guess which one I’m going to take?

Now, it’s true that you also have to find a way to focus me.  Programmers, like magpies, are notoriously easy to distract with shiny things, like new computers, new software, new web sites, and discussions about geeky hobbies like roleplaying and MMORPGs and Renaissance Faires.  And, along those lines, we can get off track, chasing down something that seemed like a good idea at the time, but in retrospect turned out to be a giant temporal black hole.  Getting back to how agile addresses these issues, that’s what “daily scrums” are for.  It’s the chance for the programmer to say “well, yesterday I spent all day looking for a decent Javascript beautifier that would unravel this minimized code I’ve been staring at for the past week,” and the chance for someone else on the team to say “dude, I got one back at my desk; I’ll email it to you.”  There you are: problem solved, distraction eliminated, yak shaved by proxy.  Or perhaps they’ll describe the problem they’re stuck on and someone else will say hey, I’ve solved that before, I can help.  Whatever.  The point is to keep the coder on track and working towards the solution.

And, as I also mentioned in the agile theory post, we programmers are tinkerers, and it’s the responsibility of the business to help us from getting lost in that and never finishing anything.  You have to be careful not ot take it too far of course, because some amount of tinkering is necessary to keep things running smoothly.  It’s a careful balance, but you’ll get the hang of it.  Give us some rope, and be prepared (but not anxious) to tug us back if we range too far.

But, other than that, there’s actually very little you have to do to get us to produce the software you want.  In fact, the more you do, the more likely you are to make it worse.  Programmers react to micromanagement by slowing down: you want to focus on trivial things? fine, I’ll focus on trivial things.  Programmers react to attempts at measurement by getting picky and measuring everything in sight.  Programmers react to bonuses based on lines of code by writing unnecessary code, they react to bounties for finding bugs by adding more bugs, and they react to having to meet detailed performance goals by adhering to the exact letter of the goals and completely ignoring the spirit.  Businesspeople tend to find this more than annoying: they find it downright insubordinate.  But think of it this way: first, a programmer is prone to taking things very literally (talking to computers all day, remember?), and secondly you actually pay them to find the most efficient solutions to thorny problems.  Don’t get ticked off if they end up turning that ability against you when you try to control their workday.

In fact, getting the most out of programmers generally amounts to not pissing them off.  Not treating them with respect, or not trusting them, pisses them off.  Asking their opinion about something and then ignoring it really pisses them off.  Asking them to produce shoddy software because you’re in a hurry makes them livid.  Expecting them to do a lot of things at once and not understanding the simple fact that shit takes time (and also that nine women can’t make a baby in one month) makes them rethink their choice of employer.  Agile will help you with a lot of this.  Some of it, though, you just have work out on your own.

And it ain’t hard.  We programmers are simple creatures, really.  You’re just not used to us because we’re different from anything you’ve ever had to manage before.  And here I’m going to be presumptuous and move from giving you advice on programmers to giving you general advice on management (but, remember: I’ve actually managed people, even people other than programmers).  Robert Heller, a well-known writer on the topic of management, once said:

The first myth of management is that it exists. The second myth of management is that success equals skill.

Now, like any good quote, that’s going to mean different things to different people.  But here’s what it means to me:

The first sentence merely means that most people treat management as an active thing, whereas they should be treating it as a passive one.  Voltaire (supposedly) said: “The art of medicine consists in amusing the patient while nature cures the disease,” and the same applies to management.  Much of the time, the best way to succeed is simply to get out of the way.

The second sentence means that you must be careful not to let yourself get caught in a feedback loop.  If you undertake a style of management which is actually very horrible, and your employees succeed despite you, you may believe your ideas are validated.  This is important to understand, I believe, because it answers of the question of “why haven’t people figured all this out by now?”  If you’re a business executive reading this post and shaking your head and saying “man, this guy is crazy!” then I urge you to go find a programmer and give it to them to read.  They will no doubt nod and mutter “oh, yeah, that’s so true” under their breath the whole time.  The fact is, nothing I’m saying here will come as any surprise to any programmer working in America today (and probably not to the ones working in other places either).  And yet business has managed to go 50 years without figuring it out.  How?  Are businesspeople stupid?  No, of course they’re not.  But management, like medicine, can seem like it’s working even when it’s doing more harm than good.  Remember leeches?  People thought they worked too.  Those people weren’t stupid either.  But, as it turned out, leeches were a pretty bad idea.

So rethink your strategies with your employees, particularly if they’re programmers.  Don’t stand behind them and push.  The definition of the word “lead” implies that you have to be in front.  And not pulling either: just striding ahead, with confidence.  (And a few donuts wouldn’t hurt either.)  You don’t even have to look back that often.  If you are a business with hard problems to solve, we’ll be following you.  After all: solving hard problems is what we live for.

Pitfalls in Agile

[This is part 2 of a series of posts on Agile Development.  First you should decide if you care about that at all.  Then, if you decide you do, you should make sure you’ve read what I wrote last week about what agile means.]

So now we know what the attitudes towards agile should be.  But, as I’ve said, often they aren’t.  Sometimes it is that tech are the ones who don’t get it.  But I’ve found in my experience that it’s more often business.  Tech, after all, is used to not always getting what they want.  But business is the driver of a business—it’s right there in the name, after all.  What business needs, they get.  They’re not used to hearing “no.”

But here’s a crucial fact: agile did say to business “you’re not going to get everything you want,” true.  But that’s not the same as saying “no.” What it’s saying instead is, “you must make a choice.”

In 1975, Frederick Brooks was considered a revolutionary for pointing out that nine women can’t make a baby in one month.  When I said that in a meeting recently, I got nervous titters and a few frowns.  Yes, that’s right: even after forty years, people are worried that I might be talking about something vaguely related to sex instead of recognizing that I’m quoting The Mythical Man-Month, possibly the most seminal work on software management ever published.  How is it that there is a single person in software development who doesn’t know this work, or at least the general concepts of it?  MMM is whence cometh Brooks’s law, which states simply that “adding manpower to a late software project makes it later.” Surely if you’re in the business of software development—from either side—these are concepts you need to understand.

But the point that both Brooks and agile are attempting to make is that we don’t say “no.” We must instead reframe the question.  If you need to buy two items that each cost $100, and you have $100 in your budget, you don’t say “no” to one or the other—you simply choose which one you will buy now, and which you will buy later.  In fact, allocation of limited resources is something that business does extremely well.  This is because of the numbers thing again.  Juggling numbers and balancing expenditures is the true forté of business.  Agile is not attempting to deny business’s requests.  It is reframing the question in terms of prioritization of one of the scarcest resources business has: the time and effort of its tech department.

Because tech can’t possibly do everything at once.  It can often do many things at once (depending on the size of the team), but it shouldn’t come as a surprise to anyone that coming up with ideas is easy and implementing them in the real world is hard.  Which means that business will always have more for tech to do than tech can possibly complete.  Which, in turn, means that business has to choose which things are the most important.

This should not be a radical concept.

And, yet, in every corporate environment I’ve ever worked in (and I dare not even exempt the business I ran myself for 12 years), business tells tech that every project is “the most important one.” Perhaps not all the time—perhaps not even most of the time—but always there comes that time when somehow it seems rational for business to just expect tech to do it all at once, without exceeding the budget, without missing the deadline, and without any one project suffering or dragging down the others.

But agile exposes the fallacy in this.  Agile gives us the concept of the “Iron Triangle.” One side of the triangle is time.  Another is functionality.  And the third is quality.  And, what agile tells us, quite explicitly, is that, if business will not move the deadlines, and will not accept any redcution in functionality, there’s only one other place where reductions can be made.

In fact, the whole point of agile is to institute a negotiation over functionality: the concept of “if you want to add something to this iteration, you have to take something out” is exactly that.  The time is not negotiable in one sense, because the dates of the iterations (often called “sprints”) are fixed.  But agile addresses time as well, by forcing regular releases before the final deadline of the whole project.  In this way, business gets value earlier, which mitigates potential losses should the deadline have to be pushed back.  And the end result is that tech can put in the quality that they wanted all along.

Where can this all go wrong?  Several places, but one of the big ones is with the Product Owners.

Agile is designed to work with small teams.  If you have a big team, you divide it up into several small teams.  These are tech teams, but they’re led by a person called a Product Owner, or just “PO.” The job of the PO is to be the liaison between business and tech.  That is, the job goes something like this:  First the PO goes to the business and say “What do you want?” Business tells the PO all the things it wants (of which there are likely very many).  The PO nods sagely and goes back to tech.  “Here’s what the business wants,” they say.  Tech promptly objects: it’s too much, or it doesn’t consider this challenge or that hurdle, or it will result in this drop in quality or maintainability, or it conflicts with this other piece of the system over here.  In this conversation, the PO represents business: “If you don’t want to give them this,” they’ll say, “then you better tell me why.  And use small words, and hard numbers.” After some back and forth, tech gives in on a few points, but stands firm on others.  Once the PO has pushed all they can push, they go back to business, and now they’re representing tech.  “The good news,” they say, “is that you can have this and this.  The bad news is that you can’t have that and that, or you can’t have it right now, or you can’t have it in that form.  And here are the numbers that demonstrate why.” Business loves this, because they love having numbers to analyze.  That makes it all make sense to them, as opposed to vague technical discussions of efficiency and flexibility.  “Okay, we’ll grant you that one,” business may say, “but this one over here we just can’t give up.” And the PO responds: “Tell me why.  And use precise words, and outline the risks and challenges of not doing it.” After more back and forth, the PO goes back to tech and represents business again.  “They agreed to give up on this thing.  But they have to have some solution to the other thing.  Here’s exactly why we can’t just not do it.  If you say you can’t give them exactly what they want: fine.  But you have to give them something.  You’re the technical geniuses: figure it out.” Tech loves this, because now they’ve been given a challenge, a hard problem to solve, something which will require them to think outside the box and push themselves to the limit to come up with an elegant solution.

So, as you can see, the PO has to represent both sides, at different times.  So obviously the first mistake you can make when trying to implement agile is to choose the wrong people to be the POs.  Most often what happens is that the Product Managers are chosen.  This is disastrous.  They have an inherent conflict of interest: when tech says “no,” they take it personally and throw up roadblocks.  When it’s time to go back to business, they are business.  They only people they’re likely to be reporting to are their bosses, and are they really going to push hard to represent the interestes of tech when it means disagreeing with their boss?  You can’t blame them for not doing that—it’s political suicide.

And agile is supposed to be all about communicating.  When a problem comes up, you’re supposed to report it immediately, so the business is aware that there’s a potential problem.  And the person you should report it to is, of course, your PO.  What happens when the PO is also the Product Manager?  You get immediate pushback.  “Unacceptable!” you’re told.  Suddenly you’re in the exact situation that agile is supposed to avoid: you’re under pressure to agree to continue to meet a deadline that is no longer feasible.  And tech people are, for the most part, an agreeable bunch who really don’t like confrontation: usually they’ll tell you what you want to hear, eventually, just to stop the uncomfortable situation.  So now either they have to work extra hours to make an unreasonable deadline (which leads to employee burnout and your best and brightest tech resources polishing up their résumés on Monster), or they starting cutting corners (the Iron Triangle strikes again), or the deadline just plain gets missed, which was probably going to happen anyway, except this time business didn’t get to find out ahead of time (surprise!).  All that communication that agile was supposed to be fostering gets destroyed.

The other thing that suffers when Product Managers become POs is team cohesion.  Agile is all about small teams, and people working together, and helping each other out, shoring up each others’ weaknesses.  This is why you always measure the velocity of the team and never that of its individual members.  When people work together on a team for long periods of time, they develop efficiencies of coordination: they know when someone is going to have trouble with this, or exactly who to go to when there’s an issue with that.  They can do things efficiently with a minimum of noise-to-signal in their interpersonal communications, because they know each other so well.  But when Product Managers are the POs, or even just assigned to teams, they have a tendency to want to shuffle the team members around instead of shuffling the work around.  If Product Manager A has more work to do than her team can handle, she goes to Product Manager B, who happens to have less work right now.  She wants to borrow some of his team members.  Perhaps Product Manager B doesn’t want to give them up; what happens if my projects heat up while you’ve got some of my people?  Even if you somehow manage to avoid the disruptive turf wars, and the transfer of resources is smooth, you’ve destroyed your team dynamic.  The transfer only appears smooth to the business side: on the tech side, the employee has a whole new team to learn about, new politics undreamt of, new social waters to navigate.  And, on top of everything else, you give your chronic underperformers a way to hide: in a situation where teams are for the most part permanent, you can count on your good employees to root out people who aren’t pulling their weight; when teams are constantly in flux, it’s more likely that they’ll just try to pass them around to another team, to (again) avoid the confrontation.

I’m not actually suggesting anything radical here; in Dean Leffingwell’s excellent Agile Software Requirements, for example, he makes it clear that Product Managers are not ideal POs, and I could cite many other sources.  But, in the end, this is a symptom, not a cause.  The cause is business not taking agile for what it is.  Too often it’s seen as some palliative: let’s just keep the developers happy, because we need them.  If this is what keeps them around, fine.  But we still want our deadlines met, no matter what.

This is contrary to the spirit of agile.  Agile, as we started out discussing, is about making hard choices.  It’s about saying what’s most important and how long things should take and how to deal with problems as they ariese.  When the business says, “this must be done on this date, and it must include all the features,” I’m somehow reminded of talking to small children.  Declaring something to be so doesn’t mean that it will happen.  You may even stamp your foot and hold your breath, if you like.  That’s not going to make the work go any faster.

In fact, unreasonable date pressure is probably the most common area where agile fails.  Of course, the hardcore agilists will complain that, if you have hard deadlines without functionality negotiations, you’re not doing agile at all.  And, perhaps, in a strict technical sense, you aren’t.  That doesn’t actually help address the problem though.  The problem is that tech people get very frustrated with these types of situations.  They’ll either buckle to the pressure, and make themselves miserable (back to polishing their résumés), or they’ll mentally give up, slow down, and make business miserable (and, I don’t know if business has noticed this or not, but it’s typically not the tech people who get fired if this scenario deteriorates).  Either way, business loses.  Their numbers suffer.  And this is not what business wants.

So the solution is for business to come at it with a fresh perspective.  For them to take the time to understand what agile means, and what it has to offer.  Agile is certainly not perfect (nothing is).  Agile certainly has lots of room for improvement (everything does).  But agile also takes a lot of different aspects into account, and actually produces a process that has the potential to make everyone happy in the long run.

There are companies out there who have seen that potential fulfilled.  Perhaps your company will join them.

[Having finished the second part of my two-part series, you may think you’re done.  However, I encourage you to stay tuned for part 3, where I talking about managing programmers.]