Sin-Yaw @ Juniper

How do you make a large number of people to change at the same time?

Note the operating words. How implies a methodology that can be learned and practiced. Make signifies the intent. Large so that this is non-trivial. Lastly, same time means the degree of control.

Military perfected this art long time ago. Recruits go through a process that strips individuality and imprints discipline and obedience. After that, rigid structures guarantee the clarity and efficiency of the communication. When the commander gives the order, a massive number of people turn on a dime, at least when they are well-trained.

The fashion industry has a different approach. They have mastered human’s innate tension between novelty and conformity. With clever messaging, the industry seduces society to change voluntarily, quickly, and predictably.

Companies change too, some successfully, like GE, Intel, HP, and several others commonly studied and written about. Countries sometime change at stunning speed. Look at the transformation of China. No one visited 10 years ago would recognize its current state.

But how? To effect changes for a large number of people, the change agent must first understand those very people and execute with a methodology. People change twice: once internally and the 2nd time in behavior with their group. In the beginning of the process, people look for reasons not to change. Once the tipping point has been reached, they embrace it and the change accelerates. The challenge becomes keeping the balance of fast proliferation and the lost of control.

Of course, there is the traditional corporate-style change management: get senior executive endorsement, socialize with stakeholders, build early successes, prepare for communication, etc. We are in the era of blurred line between employees and community. New change management must embrace both approaches: the tipping point style and the corporate style.

A manager well-versed on both change styles will be rich rewarded in his/her career path.

The bus fare is $1.75 one way, gasoline costs about $3 per gallon, the vehicle costs about 50 cents per mile to operate, in terms of wear and tear, how long the commute must be to justify riding bus, or not driving? Or what will be the MPG (miles per gallon) threshold of the car to make it work?

If your car is a Prius (45 MPG) and your commute is longer than 3 miles, you save money. If an SUV (15 MPG), 2.5 miles will do. If we ignore the vehicle’s wear and tear, it takes 26 miles for Prius and 8.75 miles for the SUV.

EcoPass reduces the fare to zero and takes economy out of the consideration. Good job.

Cross posted

You have everything planned. Strategy is brilliant, wheels are turning, projects are in motion, future is unrolling. You feel good and can almost taste success. Unexpectedly, something big happened: two big buildings collapsed, a hurricane wreaked havoc, an earthquake shook a romote place, something called sub-prime is disturbing the US financial institutes. The event has no direct effect on what you are doing, but everyone is talking about it. Should you change your course or stand firm to ride out the storm? Since there is no data to support either decision, it is essentially a gut call, wrenchingly.

Guts are quite a rare commodity these days.

The question is whether the event has fundamentally changed the course of the world, or it is merely a ripple to be forgotten.
Sequoia advised their portfolio companies to change. In fact, to jump immediately.

If the event altered the landscape. Companies that reacted quickly also recovered quicker. Companies that tried to ride it out experienced painful cut-backs and frequently never recovered. There are many examples. Studious readers have already listed both columns. The million dollar question is, “How soon will this economy recover?”

You know Sequoia’s answer by now, “Not soon enough for you to just do nothing.”

I found myself preaching. Maybe I do it all the time, but rarely I was self-aware of that fact. I must have delivered the same sermon enough times already.

What separate professional software development and amateur? The ratio of effort devoted on quality. Amateurs make it work. Professional show evidences. The amount of efforts in professional software houses devoted to quality and verification easily dwarfs standard definition of development effort.

The verification takes place in phases. First is the effort to make sure the software works as designed. This is most commonly done by the same person who designs the software, but more effective if by someone who sits close to him/her and watches over his/her shoulders as he/she codes. The goal is to make sure the software behaves well for all ranges of inputs.

Next is the effort to verify that software meets the requirements. Most likely, someone who understands the requirements will come up with methods to verify such, without giving too much concerns on how the software was designed.

After these two steps, the developer confidently declares his/her software works. He/she now must prove the new does not break the old. This is simple enough. Just run all those previously developed tests in the first 2 steps.

Imagine many of such teams following the same process. When they all come together, they do not work together. There could be misunderstanding of the interfaces or inadvertent changes that affect other parties. This is why we need integration tests.

At the end, companies frequently will “try run” on their best customers’ environments. Sometimes, the best effort “in the labs” does not discover problems “in the real.” This is the attempt to be as “real” as possible. It also ensure the satisfaction of the best customers.

Some requirements are hard to verify. Specifically, performance requirements demand benchmarking, reliability needs stress testing, security needs attacks. None of these come “naturally,” and software houses frequently use simulators. They create un-natural but concentrated faults to put the software under duress. The most common simulator is for new hardware platforms that are still in development.

This whole system is under the supervision of a general test harness that automates everything, supplemented with as little manual tasks as possible, for maximum execution speed. This harness handles test sequencing, failure management, metrics of progress, report generation, and even provisioning of resources.

People asked why do I come to Juniper. “Because the way I watch TV now.”

Just a few months ago, I routinely fired up BitTorrent at night to download episodes of my favorite programs (House, Heroes, Grey’s Anatomy). I had no choice. Those programs are not aired in China. When I moved back to the US, I don’t wait anymore. I watch those programs from the official web sites: fox.com, nbc.com, etc. I will hook up my laptop to the new 52″ 1080p HDTV. Many programs play in full-screen mode (Fox is better) and I will soon forget that’s not live TV. I laughed so hard on Tina Fey’s SNL performance on my laptop, displayed on my TV set, Sunday afternoon — no need to stay up Saturday night.

Internet never busted. Many Internet companies went under, but the net kept on growing. Billions of people around the world are waiting to get online. Internet these days are several times larger than the bubble days and sees no sign of slowing down.

And which companies are to ride the wave? The one that produce the biggest, meanest, and fastest routers for the mass. There are other players, but Juniper is at the center of this stage.

Juniper is large enough to make a difference and small enough to experience explosive growth. Juniper’s executives are all on-board for this vision. Everyone focuses on the customers, the market, the revenue, the products: not on internal politics.

When I watched SNL, I noticed the page said more than a million viewings and counting. This is main-street behavior now. It takes lots of networking to deliver millions of viewings.

Can’t think of another company that is readier.

Few years ago, I read this book by Larry Bossidy and Ram Charan. Like most management books, they distilled common senses into operational principles and thought guidelines. This book has profound influence on my managerial style and even career choices. It is one of the books I kept on my shelf. (My standard practice is to donate them to friends or library.)

Over the years, I gradually developed my own execution skills, much of them based on Larry Bossidy’s book. I wrote two blog entries on this topic: Management 101 and Management 102.

Most worthy changes involve many people. As a general rule, people do not want to change themselves, they just want others to change. Almost all people will flatly deny their resistance to change, yet their behaviors betray them. The best, and sometime the only, way to change people is to convince them to change by themselves. Once people understand the needs and benefits, and they have accepted the stress, they change willingly.

The tricks are simple: after designing the change, allocate sufficient time to socialize and communicate. When doing so, put yourself in their positions. Focus on explanation. If things make sense, people embrace the change. Otherwise, they stonewall.

Socialization and communication is more effectively done in person. There are many modern ways of communication. Almost all of them remove personal contacts to certain degree. Supplement your socialization and communication with those tools. Avoid using them as primary channels.

What if you are in a hurry and there are too many people to visit? You will be surprised how much difference a voicemail would make. Rehearse and practice your voicemail. Keep it short, keep it personal, stay on point.

Give people time to internalize and express their thoughts. There are two benefits: being heard speeds up the acceptance, you may also learn something valuable.

Next topic? Managing time. (Not time management)

I sought advices from Mark for working at Juniper. He thought for a moment and said, “Listen first.” Mike Harding told me the same. They alerted me that I have not been following my own rules.

No sudden moves: it is almost never a good idea to surprise anyone. Plan for communication delays. Pull trigger only after everyone is expecting a loud bang.

I am not smarter: Jumping in to deploy an obvious solution, without understanding why it wasn’t done already, will frequently yield unpleasant surprises. If I am not smarter, then they must have good reasons doing things “obviously” wrongly.

Of course, all rules have exceptions. Emergencies demand swift actions. But Sin-Yaw, follow your own rules!

I am one of those security enthusiasts. You know, we get excited, and guarded, when someone brings up a topic related to security. As years go by, I learned not to chime in until I am certain that the audience are also professionals. It is best for normal people not knowing this part of myself.

I am also an engineering manager. When I have a goal, I lay down plans to optimize the probability of achieving said goal. These days, the plans always have a large socialization element: the part to obtain support and agreement from certain groups of people. Yes, the plans must also get resources and time element right. I have seen, and experienced, too many failures that root caused to poor socialization. Call it the tipping point requirement.

It is easy for enthusiasts to effect change via scare tactic, not much different from one from any insurance salesperson. “You are not protected.” What follow are usually a list of scary vulnerabilities and a broad request for money. They response from senior management is usually grave concerns and the approval for further studies. Teams get formed, people get busy, time passes, a thick report and a slide deck materialize.

And it usually gets no where. Frustration. Down morale. Team meetings become a venting venue. Gradually, it dwindles into bare existence. A couple years later, a new comer finds it, infuses some energies, and repeats the whole process.

There is a more practical approach: treat it as an engineering project and and manage it like one. Six-sigma world has a well defined methodology: DMAIC. It may sometime feels too heavy, but the spirit is pretty much good engineering common sense.

First, identify widely agreed and easy to implement IT security best practices and deploy them one at a time. Let me repeat: widely agreed, easily to implement, one at a time. The idea is to put the whole company on solid footing on the basics. While doing these, purchase several penetration tests. These are the steps for preventing inadvertent employee leakage and casual opportunistic thefts. When the barrier is just high enough, these petty attempts disappear.

With basic barriers in place and well-practiced, the company can move on to the next step: identifying the assets to protect. The normal ones are: engineering IPs, company planning documentation, company brands, personnel data, etc. Not only the assets must be known, the damages incurred when they are compromised also should be fairly assessed.

At the same time, agree on the villains: malicious employees, current competitors, future competitors, professional hackers, etc. An assumption on their organization and funding must be examined and documented.

These two steps essentially create a two-dimensional matrix: one axis being the assets and the other the villains. One can sort the rows and columns so that the most extreme cases converge at one corner and conceptually forming a ladder of value and vulnerability.

The next step is a function of resources and skill-sets: good engineering projects. That’s the easy part.

Every software house experiences crunch mode: everyone does whatever-it-takes to get through whatever. When it is over, everyone lets out a big sigh, take a few days off, and pick up where they were before. Managers, particularly senior ranked, usually dispense kudos, bonuses, or creative rewards.

Experienced software managers use crunch mode like scapels. It is sharp, intrusive, effective only in skilled hands, and cannot be used regularly or frequently on the same patient. Most importantly, use only with thorough planning and preparation.

Plan and prepare for crunch mode? You bet. Only amateurs let crunch mode happens. Pros train for it.

The flip side of whatever-it-takes is drop-everything. If something cannot be dropped, those resources must be protected. The manager should also plan for the picking up, after the crunch mode. If there is no plan for whatever dropped, they evolve into crisis later.

Essentially, crunch mode taps the reserved energy and probably adds toll and stress to the normal system. During the crunch mode, people cut corners and short-cut the normal processes in the name of expediency. Managers must know the extent of stretch his or her organization is capable of. It is also a good to examine those corners and short-cuts carefully. Are they innovations that will improve overall system efficiency or sometime not to be repeated, or used lightly.

People’s natural heroic pride will respond to the crunch mode. They work hard and enjoy the adrenaline rush. It is important to eliminate, at least minimize, any hurdle to slow them down. These are the pumped-up army ready to fight. Have them wait for logistics will dampen their spirits. Sharpen the focus, stock up the supplies, aim their targets, and let them roar. Prepare to let them rest afterward. No one can sprint for long.

It is also important to train for the crunch mode in “peace time” — the same concept as fire-drills. Where are the reserved resources? What skills are available? How to coordinate efforts? These need practicing and frequently too late to learn when crunch mode comes.

It is more important not to be addicted to it. The increased productivity feels good. The camaraderie feels better. But they are not real productivity or real team spirit. They are stimulated and not sustainable. Managers who depend on crunch mode are like addicts and will one day face painful consequences.

Of course, the shrewd will exploit the organization with abusive use then leave the damaged team behind. Only the lesser get caught.

This blog ends with sound effect of evil laughers [WA-HA-ha-ha-ha-ha-ha...]

Smart people thought of this question long and hard before. Companies after companies tackled it with years of patience and large amount of resources. Books and consultants profit from it for decades. There are even computer languages designed just for this environment.

So why would another company try to deal with it again? The same reason everyone must live through adolescence, even it has been experienced documented by many, many people. At the end of the process comes an adult that is unique yet the same at the same time.

Yet, like this society of Peter Pans, many companies do not want to grow up. Programming in the small, like childhood, is so much more fun. Unlike human beings, a company does not need to grow up. It will only when it wants to and has the resources to do so.

But companies are made of people who work there. A company wants to grow up only when its people want it so. Its people must be willing to deal with the equivalence of company adolescence, knowing full well that many did not survive the transition.

Are we parents to a teenager? Or are we the teenagers themselves not wanting to grow up?

Programming in the large means the capacity to develop something that is not possible otherwise. Accept that, it will not be possible otherwise. Do not try to achieve it with enhancements to programming in the small tricks; three-wheelers cannot travel across the country carrying large cargo. Learn to drive.