Feeds:
Posts
Comments

Posts Tagged ‘management theory’

On company time

Posted in Bruce Byfield, Business, careers, corporatelife, ethics, hypocrisy, leadership, management, management theory, officework, Personal, work, writing, tagged , , , , , , , , , , , , on October 9, 2008| Leave a Comment »

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 »

Seven tips for leading free and open source software programmers

Posted in Bruce Byfield, careers, employment, Free Software, freesoftware, management, management theory, open source, Personal, Uncategorized, work, tagged , , , , , , , , , , on August 7, 2008| 8 Comments »

(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.

Conclusion

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 »

Napoleon’s invasion of Russia and the challenges of managing large projects

Posted in Bruce Byfield, Business, management, management theory, Napoleon, Personal, Uncategorized, tagged , , , , , , on July 4, 2008| 3 Comments »

(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.


Conclusion

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 »