Philosophy: Life is what happens to you while you’re busy making other plans. | ||
| --John Lennon, The Beatles | ||
Many books and papers have been written on changing a corporate culture. What I would like to share in this chapter is a “David versus Goliath” approach. David in this case is the builder, build manager, or any employee, and Goliath is the corporate bureaucracy that every company has. All companies have specific cultures, and at larger companies such as Microsoft, subcultures exist in different product groups. This is evident as soon as you walk into a building on Microsoft’s Redmond, Washington campus that is occupied by a specific division such as MSN or Office. From the way the walls and offices are decorated to the people buzzing around, you can feel how the ambience and group of people working in that building are different from that of other buildings with other product teams.
Of all the topics in this book, this might be the most difficult to change in a company or group. This is mostly because changing any culture is an evolutionary, not a revolutionary, process. Sometimes you might witness a radical change, such as a new CEO or group manager, but even after that change occurs, it can take weeks or months before you feel all the new fallout. Usually, if a company doesn’t notice an improvement in cultural changes after about two years, the executive in charge gets a nice “going-away party.”
As pointed out in an earlier chapter, the development tools used in a group help drive behaviors. These behaviors tend to shape the culture of your company or group. In this chapter, I would like to give an approach that builders, build management, testers, or developers can use to make a change to the culture of their group or company—essentially an engineer’s approach.
Some contributing parts of a company culture take a long time to change, whereas others can be changed overnight. For example, switching to a daily build process can take weeks or months, but switching the time you build code to during the day instead of during the night can happen the next day. Everyone can adjust to that new schedule fairly quickly. Still, it’s important to realize that even small tweaks to tools, processes, and people can affect a company culture.
More specifically, software development teams have their own culture, even if it is not explicitly defined. I often use the terms culture, philosophy, or religion interchangeably. If you plan to grow a development team, you need to establish the culture to accomplish the following things:
Common way of evaluating designs, making tradeoffs, and so on
Common way of developing code and reacting to problems (build breaks, critical bugs, and so on)
Common way of establishing ownership of problems
Goal-setting process that should be the foundation for the culture
Method of keeping a culture alive as the team grows (the biggest challenge)
This book has already covered all of these topics. This chapter discusses how to balance these goals and tie them all together to create a cohesive corporate culture in your organization.
The best definition I could find for corporate culture is from the 1000ventures.com Web site:
Culture refers to an organization’s values, beliefs, and behaviors. In general, it is concerned with beliefs and values on the basis of which people interpret experiences and behave, individually and in groups. Cultural statements become operationalized when executives articulate and publish the values of their firm, which provide patterns for how employees should behave. Firms with strong cultures achieve higher results because employees sustain focus both on what to do and how to do it.
Anyone who has worked in a corporation can relate to this definition of culture. It is obvious that if a company is going to succeed, it had better be competitive. I always liked it when Steve Ballmer would say, “We are not going to apologize for being competitive” or Bill Gates would say, “I never said that Microsoft would be a zero-profit company.”
So let’s borrow another definition from 1000ventures.com. This one is based on The Art of War by Sun Tzu, approximately 500 B.C.
Competitive philosophy is described as “The Way” or “The Path.” In business, it is called “corporate culture” or, as a focus, the “company mission.” Your core as competitor is your competitive philosophy. A clear philosophy makes decision making easier. Philosophy guides everything else you do in competition. Nothing is as important as having the right way of thinking. A competitor who has a strong philosophy is a strong competitor. Understanding your competitor’s philosophy allows you to predict him.
Sun Tzu’s two main issues regarding competitive philosophy are as follows:
A philosophy of people—Your philosophy must be centered on people. Your goal must be to serve the people’s needs. Every competitor’s strength depends on the support of people.
Unity and focus—Your philosophy is the source of your competitive focus and unity. Philosophy brings people together, uniting them into an effective group. Philosophy also provides your focus that tells you what is important now. Having people united and focused is the source of all strength.
Ideas of changing cultures have been around probably as long as humans. What worked in 500 B.C. probably still works today, or at least the definition applies. Note that both definitions talk about focusing the company in order to succeed.
Now that we have clarified what we are talking about, to understand how you can change the culture of your corporation or group, you must first understand who is shaping the corporate culture.
After working in different groups at Microsoft and spending time with employees at other companies, I think I understand why executives are important and why Wall Street seems to react quickly to changes in executive management. If you have weak leadership at the top, you will most likely have a weak company. Not everyone has a direct channel to executive management, so the trick is to try to influence the executives technically without upsetting all the layers of management in between.
In other words, to borrow a military phrase, “Don’t break the chain of command,” but escalate when needed. Microsoft, like most companies in the new millennium, prides itself as being an open-door company— meaning that you can stop by anyone’s office or e-mail anyone as you wish. However, there is a second part to this philosophy that people sometimes forget: Make sure you have a good reason for dropping by or e-mailing, and do your homework before approaching the person. If there is an obvious or easy answer to your question or suggestion, you will probably not be welcomed back, even if that person is your mentor or trainer.
I have seven suggestions that seem to have worked well at Microsoft and other companies I’ve consulted with when trying to change or influence corporate or group culture. The suggestions are not listed in any particular order. You can use the suggestions together or independently. I can say from personal experience that I have used all of these to successfully make changes to a group. Whether I used one suggestion or a combination depended on the complexity of the change that I wanted to happen. This should become clearer as you read on.
Suggestion #1: Involve as high a level of management as you can when rolling out new processes or tools. In fact, have the executive send the e-mail on the new announcement.
As you saw in the Microsoft sidenote “Examples of Cultural Shifts at Microsoft,” sometimes it’s good to smash an ant with a 10-pound sledgehammer. When you’re rolling out a new process or tool that will affect a lot of people, it’s best to let the highest level of management available send the announcement. In contrast, don’t hide behind a generic e-mail alias to make an announcement or change. IT departments are notorious for doing this. Someone should always sign the e-mail and own what it says. This builds trust and respect between groups and discourages e-mail abuse. People are more likely to think things through and be thoughtful before sending an e-mail if they are signing their name rather than a generic alias.
Suggestion #2: Hire a consulting firm to come in and do an analysis.
This should be a regular practice at any company. Consulting firms are available for any technology or business topic, so you can customize this suggestion to fit whatever you are doing. For example, you might have questions about your application architecture, e-commerce structure, or database designs. For the right price, I am sure you can find a company that has people who specialize in any of these topics.
Following are some good reasons for using a consulting firm:
They are objective because they are not politically involved with your company.
Although consulting firms might be expensive, they are usually cheaper than hiring a person with the equivalent knowledge and experience.
They allow access to industry experts.
Suggestion #3: Match company values to what you are trying to accomplish.
The best way to demonstrate this suggestion is to show how it’s done at Microsoft.
Microsoft publishes its mission and values on the company intranet and extranet. They are explained to new hires during orientation. The following is just a snippet of what is taught. Microsoft also publishes its definitions of integrity and accountability, which I believe are the cornerstones of success.
Jack Welch hits it right on the head when he says this (his leadership secret number 6):
Nurture the employees who share the company’s values: Deliver on commitments and share the company’s values.
Microsoft follows the same rule as Jack, as most companies probably do. Because Microsoft publishes these missions and values, it is easy to get behind the executives and know when you are doing the right thing.
Suggestion #4: Do the math.
It is strictly my own observation, but it seems that the higher up the management ladder you go, the more concern about success strategies and bottom-line dollars you will find. Thus, to convince the upper managers that builds are important and have corporate-wide financial effects, I have done some calculations that you can use to help people understand the financial impact of breaking a build.
Say that you have a build that is released at 2 PM every day. You have 20 developers and 20 testers waiting to pick up this build to test. Furthermore, you have 10 people waiting to look at the build, including project managers, marketing, and program managers, to see if some new features are there.
Let’s say that the average salary you are paying all 50 people waiting for the build is $50,000 per year, which is about $25 an hour. The real average is probably much higher.
So for every hour that the build is delayed or not functional, it is costing the company $25.00 × 50 = $1,250 per hour. This number does not even include the benefits cost of the employees, which could add another 50 percent, or about $1,875 per hour.
This is with a small software shop that has 20 developers/testers. Imagine a larger company with hundreds or thousands of people waiting for a build. This is real money we’re talking about.
Suggestion #5: Not worrying about getting fired gives you incredible power.
A college friend of mine used to say this to me all the time, and it took several years before I really understood what he meant. The way that I understand the statement is
if your integrity and values are in line with the company,
if you are accountable and work hard,
if you have done your research and see that something the company is doing is wrong,
if you have followed the correct processes to fix it...
and nobody is listening to you, stand up and fight for what’s right! If you meet all the previous points and get fired for trying to help the company, you should consider it a blessing that you were fired because something is wrong with the company, not you. Remember the Chief Crazy Horse quote at the beginning of Chapter 14: “It’s a good day to die...” Be the change you wish to see.
Suggestion #6: Never take no from someone who does not have the power to say yes.
This suggestion says it all. Basically, escalate your issue until you get to someone at a level that can take the risk responsibility of what you are trying to make happen. A VP at Microsoft once told me that Bill Gates is the only person at Microsoft who really has the power to say yes. Everyone else is just spending his money. Well, I don’t think that’s true. It might have been that way in the early days, but the power is spread out a little more today, and it is just a matter of finding that upper-management or executive who is willing to take a “yes” risk.
Suggestion #7: Publish policies, processes, and tools on the intranet!
As discussed in detail in Chapter 3, “Daily, Not Nightly, Builds,” the build intranet page should be the collection point for all information concerning your product. This not only includes build information, but also policies, processes, tools, and so on. Even if the information is spread among different sites, the build page should include links to everything. It should be the one-stop shopping place.
...Leave the company or group that you are in for one that you can get 100 percent behind.
If you have wholeheartedly tried any or all of the seven suggestions and you are continuously frustrated or unhappy with your career, you have two options left.
The first option is to take a deep look at yourself and see if there is a mindset that you can change that will help you be more successful. Point the finger back at yourself and make sure your reality is aligned with the company’s.
The second option is to work for someone else. I have heard since my first day at Microsoft that “Working for Microsoft is not for everybody.” This does not mean that if you do not work at Microsoft, there is something wrong with you; it just means that some people like the culture and can adapt to it, and others cannot. Apparently, a lot of people still think Microsoft is a good place to work. According to human resources records, 300,000 people applied for a job at Microsoft in 2004.
Have you heard of the “Win one for the Gipper” speech by Knute Rockne, legendary football coach of Notre Dame? At halftime in a game against Army, Knute told his players the story of the tragic death of one of the greatest players at the University of Notre Dame. The players were so inspired that they cheered and stood up and ran out the locker door to defeat Army.
Although this is a wonderful story, it is not how businesses are run. “Don’t go Gipper” and expect to get work done by telling a tragic story. Instead, lead by hard work and setting good examples. The point here is that people do not want to hear personal excuses for not getting work done. If you give a date that you will have something done and several people are counting on you to finish it, you had better get it done. Sure, once in a while there is a personal tragedy that might delay things, but biting off more than you can chew or saying that you are understaffed or lacking resources is unacceptable. This is another example of “Come on, feel sorry for me” or “Win one for the Gipper.”
I have been a big fan of NASA since I was in grade school. When I was in college studying physics, I used to dream about working at the Jet Propulsion Laboratory (JPL) in California. It is one of my big “side interests” to keep up with what the latest cool things that they are doing. Most people would probably agree that NASA has some deep financial pockets and extremely smart, hard-working people. So, although it’s tragic, it is interesting to see how the organizational culture or shortcomings contributed to the two space shuttle disasters. My heart goes out to the family and friends of the incredible people who perished—we really lost some good ones.
This brief summary of what happened at NASA shows the importance of suggestion 5—Not worrying about getting fired gives you incredible power, and suggestion 6—Never take no from someone who does not have the power to say yes. It also shows how a high-profile, good intentioned, and financially backed organization can have problems that seem unlikely or that you might think can only occur in smaller organizations. I’d like to point out that I am not blaming any specific person or group for the tragedies. This example is given here to see if there are some parallels with what happened at NASA and what might be happening in your company.
Allow me to clarify what I am talking about: In 1986, the space shuttle Challenger exploded about 60 seconds after take-off due to a failure of the O-ring seal. In 2003, the space shuttle Columbia broke up during re-entry just 16 minutes before landing because of tile damage to the left wing caused by a stray piece of foam during take-off.
If you would like more details on these accidents, check out http://library.sau.edu/bestinfo/Hot/space.htm.
Because of large public attention to these accidents, a lot of investigations were done to make sure that these incidents never happen again. In both cases, an engineer somewhere in the organization raised a red flag about the possibilities of a disaster but was somehow ignored. With Challenger, the engineer sent several memos, but upper-management pulled rank and decided to launch despite the warnings. With Columbia, an engineer who was monitoring the erratic behavior of the computer sensors on the left wing sent e-mails while the shuttle was still in orbit. Once again, management ignored the e-mails and made the decision to return the space shuttle to earth.
NASA can be better understood by examining the culture that arises from the inevitable—and (sometimes) healthy—tension among scientists, managers, and engineers.
In his book, What Do You Care What Other People Think?, Nobel Prize-winning physicist Richard P. Feynman writes that while he was on the committee to investigate the Challenger explosion, he came up with the following theory of why every time he talked to high-level managers at NASA, they said they “didn’t know anything about the problems below them:”
Because of the exaggeration at the top being inconsistent with the reality at the bottom, communication got slowed up and ultimately jammed. That’s how it’s possible that the higher-ups didn’t know. Or the other possibility is that the higher-ups did know, and they just “said” they didn’t know.
I think it’s safe to assume that the high-level managers are telling the truth. I’d like to think that people rise to higher positions because of their ability to maintain their integrity and honesty in the toughest positions. Furthermore, we are talking about NASA. If you have seen the movie Apollo 11 or The Right Stuff, you know that NASA must have one of the toughest weed-out programs in existence.
Feynman’s observation can be seen at many corporations.
Joseph Lorenzo Hall of the astronomy department at the University of California at Berkeley says it best:
There is a strong need for leadership in NASA that is favorable to and capable of organizational change. The NASA leadership has shown a self-interested reluctance in the past to advocate and execute extensive organizational overhaul. Until NASA itself sees that its best interests lie in organizational-level change, the “echoes of Challenger’’ will continue to reverberate.
I also like what Dr. Diane Vaughan of the Columbia Accident Investigation Board said in April 2003:
What we find out from a comparison between Columbia and Challenger is that NASA as an organization did not learn from its previous mistakes, and it did not properly address all of the factors that the presidential commission [in 1986] identified.
I have seen managers at Microsoft pull rank or just plain ignore an engineer’s view of a problem, but the difference between us and NASA is that Microsoft does not have upper managers answering questions with “I never heard of that” or “I don’t know.” If managers do give that answer, you will have the answer from another source shortly.
An important point here is that if you are 100 percent sure that the information you have is vital to the organization you work for, do not hold back—even if it means you might lose your job. (Remember Suggestion #5.) Also, if you are in a position to influence culture, keep the NASA lessons in mind.
After reading this chapter, you should have a better idea of some of the tactics that I have found successful in influencing the culture of a group, company, or organization. I could write an entire book on this topic, but what’s important here is to realize that this culture does exist and is influenced by the tools and processes that are present in your business. Try to figure out what the culture is at your workplace, and then grow, thrive, and succeed in it.
As this chapter detailed:
Follow the seven suggestions to change or create a successful culture:
Involve as high a level of management as you can when rolling out new processes or tools. In fact, have the executive send the e-mail on the new announcement.
Hire a consulting firm to come in and perform an analysis.
Match company values to what you are trying to accomplish.
Do the math.
Not worrying about getting fired gives you incredible power.
Never take no from someone who does not have the power to say yes.
Publish policies, processes, and tools on the intranet!
If you can’t get 100 percent behind what you are doing, you should find something else to do or somewhere else to do it.