Sin-Yaw @ Juniper

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.

Not that I am a novice to the networking world. I managed the networking part of an operating system development several years before. I got an advanced CS degree and befriended some of the best minds in the networking industry. But man, this is a place that everybody speaks RFC numbers and other 3- or 4-letter acronyms as part of a normal conversation.

So I dug out old Tanenbaum and Radia Perlman (whom I had the honor to work with at Sun). I reviewed the differences between a switch and a router. While I was on it, I also reviewed her minimum spanning tree algorithm. It feels like re-acquainting an old friend.

Reviewing old books stirred up memories. I remember the yellow monster Ethernet cable that crawls the ceiling, when it was CDMA/CA and not yet 802.11. And the debate over token-ring and ethernet was raging. How the world has changed to the ubiquitous RJ45s leading to small and big switches, and now even more ubiquitous WiFi and hotspots.

And so much has not changed. Computers are still in von Neumann architecture. For most parts, people are slugging away the same technological bottlenecks and processes inefficiencies, just in different settings and optimized for different economical incentives.

Learning a company requires a different approach. There is the mechanics of the company — IT, approval process, facility, etc. — that are probably the easiest to learn and best documented. And that’s a small fraction of a company.

I asked, “How does it work?” They will bestow me a monologue on the innard of the machine — as they observed it and frequently with added colors. This is similar to the story of a group of blind people describing an elephant by feeling it. Everyone tells a drastic different side — an elephant is like a big hose, a column, a flat wall, etc. — all depends on where was the person.

Then I asked, “How does it really work?” The response I got will either be a confused look or an understanding smile. This is when I make a list of people to buy beers for.

Like any living organism, a company changes but only when people inside want to. I believe I was hired as a change agent, not a steward to guard the current state. I am ready, almost.

I wrote that last week. I had no idea.

This week, I had a large-format meeting to introduce myself to all the managers and senior contributors. I talked about myself, my background, past jobs, and the general management style. Curious audience asked questions: some on personality (”What do you fear?”) and many hinted on the more pressing problems on their minds that I should fix.

Then the rumors started circulated on the net, we are getting someone senior from Microsoft. Thursday morning, oh my gosh, we have a new CEO, the 2nd week that I come onboard.

Last week, during a scheduled 1-on-1 with my boss. He dropped the bombshell, “Sin-Yaw, I am going to manage this group from Bangalore for a year starting next week.” I floored, flabbergasted. The emotions and thoughts mixed into a big glass of smoothie. I am to be separated with my boss for thousands of miles again. This time, I am here and he be there, almost by himself. This is the remake of the Beijing movie, with a slight twist. Is this karma that I and global engineering are meant to be together?

I met many new people and will still more next week. I studied up many 3- or 4-letter acronyms that people use in daily conversations as they are real words.

Dawn of great changes. Man!