Posts Tagged ‘management’

One of my pet peeves about business is the constant consternation among executives about employees doing personal business on company time. Even if the transgression is just a few minutes browsing on the Internet, it’s viewed with the greatest concern. Business experts talk earnestly about what such loss of productivity might mean to the nation, and devise ways to spy on employees, or to block web sites that employees might like to view. Doing business on company time, they gravely explain, is the worst sin of our secular age – stealing from your employer. What annoys me is that such concerns are a grotesque hypocrisy.

I’m not talking, you understand, about the extreme cases, where a middle manager spends five or six hours a day on a gambling site, or a system administrator watches porn all day. Such behavior is obviously unacceptable to anyone. I’m talking instead of people who take five or ten minutes a couple of times a day to read a news or hobby site, or to dash out on a family errand.

Of course, even this behavior was unacceptable thirty years ago, when people worked regular hours and rarely deviated from them. After all, the lost time quickly adds up.

But the workplace is different today. Instead of receiving an hourly wage, the average office worker is on salary – a ploy that forces them to work hours of unpaid overtime. Especially in high-tech, the norm is to take advantage of this situation, putting heavy pressure on those who leave after eight hours and implying that anyone who doesn’t devote evenings and weekends to the company are not being good team players and letting everyone down. More than once, I’ve encountered supervisors who had a habit of starting meetings ten minutes before the end of the day and forcing people to work overtime, knowing very well that the social pressure would keep most people from objecting.

And only rarely does anyone get a day off to compensate for their extra hours. Rather, unpaid work has become the norm.

Under these circumstances, how dare employers complain about the loss of half an hour or an hour a day when they are averaging twice that in unpaid overtime from their employees? If anything, they ought to be glad that employees are taking short breaks. Otherwise, productivity would decline steadily after about nine hours. By taking those breaks, employees are actually making better use of the time actually spent working, because they are more refreshed than they would otherwise be.

An employer with any knowledge of human nature should be glad that employees know how to pace themselves. Otherwise, employees risk falling into the unproductive habit of a resident doctor I once knew. When I asked how she handled the thirty-six hour shifts that are part of the hazing ritual for new doctors, she explained, “I try to make all my decisions in the first twelve hours. After that, I just try not to make any mistakes.”

Anyway, what choice do employees have except to conduct personal business on company time? When employees are working long days, often the middle of the day is the only time they have for errands or personal business. Very few stores are open at 10PM – assuming that someone staggering home after a fourteen hour day even has the energy to stop to shop.

At any rate, employees are doing nothing that many executives haven’t done for years. Despite all the pep talks about the importance of leadership, the average manager works far less strenuously that the average employee. The exceptions are those who have a hands-on approach, and lend a hand in anything that needs doing, and they are usually in a startup. The average manager thinks nothing of doing exactly the sort of thing that annoys them when employees do them.

And perhaps that’s the problem, Maybe the executives who worry about productivity are simply irked that average employees are claiming perqs that used to be reserved for them alone.

When companies pay overtime or don’t cajole and threaten free work out of their employees, and managers set an example of dedication, then they will have a right to complain about what is done on company time. Until then, so long as employees put in the number of productive hours listed in their contract, they have every right to reclaim some of their free time.

So far as I’m concerned, the employees aren’t the ones who are stealing.

Read Full Post »

Today, I was interviewing someone who stated that any company or free software needed a leader who was passionate about the work.

The idea was that, being a leader, they could quickly make the decisions necessary for the smooth running of the company, and that, being passionate about the work, they would make desirable decisions – or, at the very least, spare their subordinates the problem of making no decision at all, which the interviewee saw as often worse than making a wrong decision.

Given what I know of the interviewee, I wasn’t surprised to hear this belief expressed. All the same, I was amused that, shortly before the interview, I had read a new release announcing that a former employer, who also believed in being a passionate leader (perhaps he reads the same books on management as the interviewee) had just sold 95% of his company after five years of trying to make it consistently profitable. And if that is not a sign of bad leadership, what is?

As the interviewee expounded his theory, I couldn’t help thinking that you can passionately make the wrong decision at least as often as the right one. If anything, if you push logic aside in favor of inspiration, you’re probably more inclined to make wrong decisions.

Also, although I kept silent – interviews not being about me, I strongly believe – I couldn’t help thinking that, nine times out of ten, when people talk about leadership, they are viewing themselves as the leaders in question. What other people might think of the arrangement they are expounding hardly enters into their consideration. The assumption always seems to be that non-leaders will automatically follow.

I suppose that some people might exist who want a leader to make decisions for them. Or, at least, if they do exist, such people might explain neo-conservatism. But, I’ve never met them. The most apathetic and most obedient alike always seem jaded or cynical about their situation, if you can get them talking in a place where they feel safe.

For the most part, I suspect that people are not looking for a leader so much as a sense that their input into a decision matters. Nothing can be more irritating to someone with specialized knowledge than to find that their experience has been ignored in the decision-making.

I remember one long, hot summer when I was working on a design and writing project with a company. Whenever we held meetings, the CEO would arrive forty minutes late. He would then spend the next twenty minutes vetoing all the decisions the rest of us had made before his arrival – so far as I can see, simply because he felt like asserting his authority. Those of us who were consultants soon got into the habit of being late ourselves, and of not talking about anything to do with the project until the CEO arrived.

Needless to say, we were fuming, partly about the waste of time, but partly because our suggestions, which we believed were in the best interest of the company, were being ignored.

Very likely, we were sometimes wrong n our decisions, but, given our experience, we were almost certainly right more often than the CEO, who had no relevant expertise in the project – only a passion to have things his own way.

Such experiences explain why, whenever someone talks about visionary leadership, I start getting very apprehensive (at least when I have to endure it; when I don’t, I just shake my head). Somehow, business in the twenty-first century has got hold of the idea that leadership is some sort of natural trait or at least something that is an end in itself.

The idea reminds me of people who believe that a writer simply needs to know how to write, and has no need for expertise on their subject – in both cases, the odds of poor performance increase to near certainty, probably because so much time is spent disguising ignorance and inability.

Personally, I think leadership is simpler than that. These days, I tend to avoid situations where leadership arise, having decided that I have no particular wish to lead, and that I most definitely do not want to led.

However, in the past, leadership roles continually came my way – probably due the wrong-headed belief that if you are skilled in one area, you are somehow fit to lead. When I could not avoid such roles, however, I quickly learned that they were not about me, or making me feel good.

To me, leadership decisions were simply a matter of problem solving: I gathered what information I could in the time allotted, consulting people when I needed to, made a decision, then moved on to the next matter needing my attention. But, then, I’ve never thought that any leadership that wasn’t hands-on was worth a damn, anyway.

To this day, I have no idea how effective a leader I was. Nor am I likely to find out now. But it seems to me that there is far less to the role than those who aspire to it like to pretend.

Passion? Vision? So far as I am concerned, passion is for martyrs, and visions are for saints. I’ve always been aware that I wasn’t so exalted, and that I had a job to do.

Read Full Post »

(This is an article that originally appeared on the IT Manager’s site. Since the site has shut down, I’m reprinting the article here to give it a more permanent home)

Books about management techniques rarely mention how to lead computer programmers. The few that do sooner or later reach for a cliché and compare the effort to herding cats — J. Hank Rainwater, for instance, uses the phrase as his title. Partly, the comparison reflects how much the topic is outside the corporate mainstream. However, the comparison also reflects the conflicting nature of the job. The typical IT department represents a separate culture within a company, and a successful manager must both understand that culture and stand between it and the rest of the company, trying to explain each to the other.

I’ve seen dozens of managers — including me — approach this conflict, each with varying degrees of success. My observations here summarize what I believe are the basic facts that managers needs to know to manage programmers. They apply to any programmers, but especially those involved in free and open source software (FOSS), many of whom develop typical programmer attitudes to an extreme. Although some of the points seem obvious to those familiar with programmers, let me assure you: To outsiders, if their mistakes are any indication, the points still need to be emphasized.

You’re in a meritocracy. Prove yourself.

Management gurus usually focus on the characteristics of natural leaders and how you can imitate them. They give ambitious managers heroic images of themselves as samurai warriors, Antarctic explorers, or Henry V. However, neither the discussion nor the image is much use when you manage geeks, because developers, regardless of whether they are involved with FOSS or not, are more concerned with results than any real or artificially generated charisma. Before you can even start to lead a group of geeks effectively, you have to prove yourself to them — either by showing your competence in their area of expertise or by demonstrating that you have useful expertise that they lack. To become truly effective, you need to go further and prove that your expertise helps the group and everyone in it towards their goals, and that you have at least a high-level understanding of what everyone else is doing.

Until you prove yourself, you can expect to be tested, even if you’re a former programmer yourself. The probing can be aggravating, but the good news is that, if you prove yourself, you can quickly become accepted. At one company where I worked, the CTO had an impressive programming background, but it was some years in his past. The developers questioned his decisions constantly, right up to the time that he started delivering tough but accurate critiques of their code. The questioning stopped overnight.

Just because you’re in charge doesn’t mean you’re better

Watch how people spend their free time with family and friends, and you’ll soon notice a preference for informal structures. Given anything resembling a choice, people choose not to be in formal hierarchies, especially if they’re near the bottom of it. A hierarchy may be efficient, but, by being its local representative, you automatically become the focus of resentment.

This natural anarchism is stronger in developers than in most people. If you think for a moment, a meritocracy implies a constant shifting of status that depends on who has done what recently. Add this political instability to a widespread feeling of being different and misunderstood, and the resentment of leaders becomes stronger still. Moreover, in FOSS, where status is still one of the main coins with which programmers are paid for their efforts, these attitudes may be taken to a further extreme.

Neither being in a position of authority nor being older — as managers often are — is going to command automatic respect in the IT department. You might assume that your position reflects some superior qualities such as intelligence or ambition, but the development team probably doesn’t. Management consultant Tim Bryce insists that most programmers are no smarter than anyone else in a company, but that’s not what they believe.

Rather than relying on any natural or structural authority, IT managers need to see themselves as coordinators or problem solvers, working within the culture of their department whenever possible rather than against it. Nobody has ever shown the causality, but there’s probably a connection between the fact the era in which the corporate hierarchy has flattened corresponds to the rise of the IT industry. Because of the economic important of the computer industry, its values are spreading through the rest of the business world.

What motivates you doesn’t motivate your staff

A few management books, such as Beverly L. Kaye and Sharon Jordan-Evans’ Love ‘Em or Lose ‘Em
emphasize that one management style doesn’t fit everybody. However, many gurus and the managers who listen to them continue to assume that what motivates them — promotion, money, perks — also motivates programmers. For those unfamiliar with programmers’ culture, the process of realizing they are wrong can be disconcerting.

“Leading programmers is different from leading most employees,” career expert Tag Goulet says. “At one of my previous jobs at a startup, I was the vice-president of production, and led a team of three programmers. One of the guys posted Dilbert cartoons by his desk that poked fun at Dilbert’s pointy-haired boss and were quite possibly references to me. I’d never seen cartoons like that in more corporate workplaces. Instead, everyone was always careful to have political decor that implied that they were all team players.” In fact, such cartoons, like the popular Demotivator posters that satirize inspirational corporate art, are often the first indicators that many programmers are skeptical, even dismissive of the values that many managers take for granted.

The trouble is, managers usually have backgrounds in business or marketing, and are outgoing people who prefer to work with others. By contrast, most programmers are the academics of the business world, inwardly focused and preferring to work with inanimate objects. If they’re FOSS-oriented, they may also have a strong streak of anti-corporate sentiment. While they won’t turn down money, for them job satisfaction is more likely to lie in greater challenges or responsibilities, and, especially for those involved in FOSS, credit for their efforts.

Impromptu bowling in the hall may motivate your sales force and marketers, but, chances are that programmers will only feel like they’re being spirited away into a nightmare of frivolity. A weekly pizza night or an evening at a night club to celebrate the successful completion of a project might be satisfying to a human resources team, but your programmers will either resist being dragged away from their projects or, if they’ve just come off a coding spree, resent losing time they could spend with their families. Instead of being events to anticipate, such efforts are more apt to be seen as annoying obligations.

Instead of trying to make such by-the-book motivators work for programmers, think about you can implement the intrinsic awards that actually mean something to them. Reward those who meet their deadlines with greater autonomy in a project, or by giving them the chance to become project leaders or to telecommute so long as they meet their responsibilities. Let FOSS participants have time to work on free projects once they’ve met their deadlines; even if the projects have no immediate use to the company, they may become useful later, and, meanwhile, your sponsorship gives the company a good reputation among potential future employees.

Credit is the most important motivators, especially for FOSS participants, but don’t forget the cultural differences. Most developers are only going to be embarrassed by being singled out for praise or an employee-of-the-month award at a meeting. Instead, let people know that you’ve noticed their efforts and given them credit elsewhere in the company.

Learn when to keep hands-off

Shortly after I became a product manager, I discovered a major bug in a commercial product that was just at the plant and ready to be assembled. Put in charge of disaster recovery, I asked the team to assemble every hour so I could report to the company officers on the state of their efforts. After the disaster had passed, I found that I had left resentment in my wake. Not only did the programmers dislike meetings, but, by keeping such a close eye on events, I was questioning their competence and taking responsibility away from them. The emergency was real, but I was hampering their efforts to resolve it, not helping.

This kind of situation can’t always be avoided, but experienced managers will give all members of a programming teams as much autonomy as they have proven themselves capable of using responsibly. Partly, that means mediating between programmers and the demands of executives, but it also means only making an appearance among the cubicles when absolutely necessary. Instead of calling everyone together, I would have done better to send email requests or appoint a programmer to provide status checks. Better yet, I could have asked the team for a firm deadline and not interrupted anyone until that deadline while explaining to the company officers that the solution was being worked on — which was all they wanted to know anyway.

Minimize meetings

For managers, meetings are times when work gets done. For programmers, however, attending a meeting usually means time away from their work. Sometimes, especially at the start of a project or at a crisis, a meeting is unavoidable, but managers need to accept that programmers are likely to resent meetings and become more impatient with every minute that passes in the board room. The fewer and shorter the meetings, the more easily the developers will accept them.

Beware of fads in programming languages

Every couple of years, programmers become excited by a new programming language such as Java, .NET and Mono, or Ruby. Inevitably, whenever a project begins, some of your team will argue strenuously that it needs to be done in the latest fashionable language. Sometimes, this argument may be justified, but it is more likely to represent intellectual curiosity than sound design practice.

Almost always, the argument is a recipe for chaos. At one company where I worked, so many different languages were represented in its product suite that individual modules only communicated with difficulty. Several attempts to rewrite the suite in a single language only added to the complexity because they were never completed, and legacy support remained an issue. This trap is easier to avoid if you have a programming background yourself, but any manager should be wary of adding another language to the stack.

Learn when corporate values have to take precedence over geek values

Not being interested in business, many developers tend to ignore necessities like deadlines. Many become skilled at dodging them. The problem isn’t that most developers can’t be trusted to work responsibly by themselves, so much as the fact that they can be almost guaranteed to tinker as much as the schedule allows. In such cases, for all that successful management of geeks means understanding their culture, it also means recognizing when moving to achieve corporate goals are more important. At times, understanding needs to take second place to necessity, even at the cost of resentment. Skilled managers minimize conflicts with their staff, but they also recognize that some conflicts are unavoidable.


Managing programmers — especially FOSS ones — is an extreme version of the balancing act that any manager must do. On the one hand, managers need to understand the culture of their departments and how to work within them. On the other hand, they also need to act as intermediaries between that culture and the rest of the company. Combining these goals means adjusting your concept of management to the department. Sometimes, it means interpreting programmers to non-programmers,or shielding programmers from the misunderstanding of executives in order to achieve corporate goals. At other times, it means awakening programmers to the larger goals of the company. It’s a precarious balance, but knowing what to expect as you go into the position can leave you with more time to handle the challenges that arise without being distracted by cleaning up your mistakes or a lack of cooperation from your team.

Read Full Post »

(This article was originally published on the IT Managers Journal site. Now that the site is no longer active, many of the articles are no longer available, so I’m reprinting some of the ones I wrote to give them a more permanent home)

Everyone knows that Napoleon’s invasion of Russia failed because of the winter, right? But the truth is, saying that is as incomplete as saying that the cause of every death is heart failure. The winter may have been the final blow to Napoleon’s grand design, but it need not have been.

The more you look at Napoleon’s Russian campaign, the more you realize that it ran into trouble long before the first snowfall. The campaign actually failed because of difficulties in scaling, combined with poor management by Napoleon himself. His example provides a case study of the pitfalls when planning any project, especially large ones, making it an object lesson for the modern corporate world.

A bigger team isn’t always a better one

To invade Russia, in 1812, Napoleon assembled an army of 700,000 — probably the largest army up until that time. It contained some elite forces, but it was never an efficient fighting force. For one thing, its members spoke too many different languages to communicate well. Many parts of the army were traditional enemies of other parts, or had been fighting them recently. As a result, the army never cohered into a whole.

Also, its size meant that provisioning it was difficult. It could not even live off the land, as other French armies under Napoleon had done, because no area contained enough food for so many people. Instead, it had to keep moving, so quickly that its members were always well ahead of any supply wagons and frequently starving.

Ask yourself if you have the right resources and preparation

Contrary to a popular misconception, Napoleon did not go into Russian completely blind. He had maps, and he made considerable effort to stockpile food, resources, and horses. His instincts were sound, but he had no firsthand knowledge of what he was about to face.

On a map, it looked perfectly sensible to plan to use particular roads. But what Napoleon couldn’t see was that many of the roads in Russia were too narrow for the quick movement of large numbers of troops, and too muddy for artillery and supplies to pass. Nor could he see how foraging in a country as poor as Russia would be next to impossible.

Similarly, the far-sightedness of gathering supplies meant nothing if they weren’t the right ones. Napoleon gathered countless pieces of small-bore artillery, but these were a nuisance to haul, and useless in sieges like the one at Smolensk or artillery duels like the one at Borodino. Nor did he consider stockpiling pointed horseshoes suitable for travel in snow or winter clothing.

Still, even if he had gathered the right resources, the effort would have been largely useless, because among the things he neglected was any plan for delivering supplies to where they were needed. The one efficient piece of transport he arranged was his personal mail service, which could deliver a letter from Paris to Moscow in 14 days — and that luxury was unimportant in the campaign.

Decide on a goal and focus

Despite all his preparation and the size of his army, for once in his life Napoleon was uncertain what he wanted to do when he invaded Russia. Did he mean to occupy Moscow and Saint Petersburg? Carve up Russia between Sweden, Turkey, and a revived Poland? Force Tsar Alexander into a truce and go on to take India from the British? In the early months of the campaign, Napoleon considered all these goals. Unable to make up his mind, he could not act with his usual decisiveness, and failed to followup on his initial victories until after he had lost the initiative.

This oscillation continued throughout the entire campaign. Days, if not hours, before he retreated, he remained uncertain whether he would leave Moscow or winter there. Even when he abandoned Moscow, he first moved south as if planning to face the main Russian arm — then abruptly veered west to begin the long trek home. Not knowing what he wanted to do, he was, not unexpectedly, unable to do much of anything, or to do what he did do effectively.

Keep in touch with your team

Part of Napoleon’s leadership ability was his rapport with his troops. By moving among them, Napoleon could always get a first-hand feel for their morale and combat-readiness, and sense when punishment or a gesture of concern could improve the mood of his troops. Often, his appearance alone could inspire troops.

However, during the Russian campaign, this hands-on approach was rarely possible. At times, Napoleon was too ill. Yet, even when he was healthy, the size of the army and its dispersal meant that he could only use his personal touch on a minority of his troops. Too often, the only troops he saw were the Imperial Guard, those with the most loyalty and highest morale who, because of their proximity to him, were also the best-fed and supplied. Judging the rest of the army by the Guard, he assumed all was well as the rest of his army steadily sickened and dwindled away.

Don’t force subordinates to misrepresent or lie

Early in the campaign, Napoleon told his generals and field marshals that he wanted accurate reports about their troops. The trouble is, when they told him about the lack of supplies and the problems with desertions, Napoleon was prone to abuse them, sometimes publicly. At times, these tirades were followed by demotions or reassignment to difficult duties.

Faced with such consequences, Napoleon’s management soon realized that, for their own sakes, the last thing they should do is tell him the truth. Early in the campaign, they began exaggerating the strength and readiness of the forces they commanded. These exaggerations prevented proper planning and caused Napoleon to under-estimate the extent of the campaign’s difficulties until they were far advanced.

Choose substance over PR or positive thinking

All his life, Napoleon believed in his destiny, trusting it to carry him through times of trouble and upwards to future greatness. For much of life, this belief served him well, possibly because the bravado that it produced constantly took his opponents by surprise.

But in Russia, where geography, weather, and distances were as much a problem as the opposing armies, there was too much reality for a positive attitude to conquer. Napoleon did his best to assert his will and frequently issued proclamations that pretended all was well or about to be so, but this stance became harder and harder to maintain — especially since Napoleon was intelligent and observant enough to be unable to deny the increasingly obvious truth. Still, for a long time, he persisted in believing that will would triumph over circumstance. Unfortunately, by the time he admitted what was happening, his army was crumbling and in an exposed position cut off from supplies. At that point, he had nothing to do except retreat.

Listen to experts and subordinates

Napoleon’s entourage included people whose knowledge could have countered many of the difficulties listed above. For instance, Caulaincourt, the former ambassador to the Tsar, warned him about the conditions of the roads, the poverty that eliminated the possibility of foraging, and the political situation that made it likely that the Russians would continue to fight, despite constant retreats and uninspired field leaders. But these were not opinions that Napoleon wanted to hear, so he ignored them until it was too late. It was only on the retreat, when Caulaincourt advised Napoleon to return home ahead of the army that he listened to him — and then, the main reason was probably that Caulaincourt was saying what Napoleon wanted to hear.

Have a fallback plan

For several weeks beforehand, Napoleon knew that a retreat was a strong possibility. The alternative was to winter in hostile, barren territory. Yet, perhaps because of his reluctance to admit failure, Napoleon made no plans to prepare for the retreat. New conscripts arriving from the rest of Europe were still hurried up the line to Moscow, the farthest point of the French advance, rather than being assigned to secure possible routes. Similarly, no supplies were stored along the way. Nor were any scouts sent along the possible routes. When Napoleon made his sudden decision to retreat, he had made no preparations for it, which undoubtedly worsened the disaster of the march.

Sometimes, resources have to be abandoned before they become a liability

As the French army advanced into Russia, it carried a variety of unsuitable equipment, including hundreds of light field guns and carts that were unsuitable for the roads. Instead of destroying this equipment or abandoning it, Napoleon insisted on dragging it along. This stubbornness served only to slow his advance.

Even worse, on the retreat, the army was carrying as much of the loot from Moscow as possible. Not only did the loot encumber soldiers by filling their pockets and weighing down their belts with the objects hanging from them, but it also encumbered the army’s various vehicles, making them harder to move. The path of the retreat was soon littered with abandoned riches, but the determination to hang on to their spoils killed thousands of soldiers as they tried unsuccessfully to dodge marauding Cossacks or to hurry on to the next outpost where they might hope finally to get a meal.

You can lose by winning

Napoleon never lost a battle in Russia, although many, like Borodino, were indecisive. By traditional standards, he should have won, since he occupied Moscow, the old capital and still the largest and most important city, and his troops started home with fabulous riches. Yet he found his soldiers, horses and supplies steadily whittled away by disease, desertion, starvation, and exposure. After despoiling Moscow, he had to retreat, constantly harried by an enemy he no longer had the cavalry to close with. Unable to grasp fully the kind of war he was in or to adjust his tactics, he abandoned his army to rush home to France. In the end, only 22,000 — a little over three percent of his original force — survived to do the same.


Napoleon was a brilliant leader, one of the most outstanding ones of all time. But the fact that even someone of his caliber could make such mistakes only emphasizes that anyone can falter. Lack of preparation and focus, a belief in his own infallibility, a refusal to assess the situation objectively, a failure to follow the leadership techniques that had served him so well in the past — all these things led to the greatest catastrophe of his career.

Napoleon took another three years and one exile and a return before he was finished for good. But his Russian invasion had drained the fighting strength of France and destroyed his reputation for invulnerability. After his Russian campaign, his rule was a constant struggle for survival against continually increasing odds. Finally, at Waterloo in Belgium, he met the Duke of Wellington — a man famous for his clear headed planning and lack of nonsense — and lost his position once and for all. But the beginning of the end was his lack of proper planning when he invaded Russia.

Read Full Post »