When NOT to talk about Agile [John Levy]

Sometimes you have to lay low.

I know of a company where the IT department calls its monthly code releases “Agile” because they occur regularly. This confuses the rest of the IT department, because it has several teams doing Scrum, one of the best-known set of Agile software practices. The Scrum teams have been trained and know that key practices of Scrum include the following:

· A co-located team with team-managed processes
· The team includes QA & a business sponsor (called the Product Owner)
· Work is done in short iterations (usually 2 weeks) with demonstration of working software at the end of each iteration
· There is daily (or more frequent) integration of all code
· Automated test suites run at every integration

There are other practices, but that covers the essentials.

Now, why would the IT department want to call their monthly releases “Agile”? I can imagine several reasons. 1. Management wants to be seen as being on top of a current trend called Agile. 2. Doing monthly releases stresses the system enough that it makes sense to call the people running the releases Agile. 3. It forestalls the imposition of real Agile frameworks on the IT department, which would really change things.

A company has to decide to take the heat of change when it decides to go Agile in its software development. And by “company”, I mean the top management. Anything less than full commitment by at least one of the C-suite officers and a full chain of management command all the way down to a functioning team will not get the job done. And what is the job? Implementation of a framework for software development that will embrace change as it happens, be productive, and create a satisfying workplace for software developers.

We’re talking about serious productivity changes here. The studies I’ve seen show that poorly implemented Agile teams achieve only a doubling of results compared with a classic waterfall framework. The well-implemented ones achieve 9 times the productivity.

So if you’re in a large enterprise that has launched at least one Agile team, look around. If you find management support, good tools, and respect for the changing environment needed for Agile, then go ahead and lobby to join an Agile team.

If you don’t find those things, it may be best to lay low – and just start adopting Agile practices quietly, without calling attention to what you’re doing.

__________________________________
John Levy consults on Agile development and is an expert witness in computer & software patent cases. He has 30 years’ experience as a technology manager at Quantum, Apple, Tandem and DEC. His book on managing technology, Get Out of the Way, is due out in 2009. Check him out at http://johnlevyconsulting.com

More...

Layoffs and Firing [Jane Divinski]

The current economic situation with the resulting corporate downsizings has unfortunately given engineering leaders and people at all levels of engineering management increased experience preparing for and implementing layoffs. It’s not enjoyable, for anyone involved…

I’ve recently had informal discussion on this topic with various engineering management colleagues as we caught up over coffee (well, chai tea latte for me – NF, XH, no H20) or a meal. One person lamented the fact that in his company several of the engineers who were laid off were definitely not top performers and some should actually have been previously fired. Another person felt very sad that everyone laid off in her engineering organization were definitely contributing and that there was no “dead wood” so to speak; the loss of talent was severe.

The current times are definitely painful and the layoffs unfortunate both for solid performers and for the weak links. For the former, it is distressing that their life is suddenly more stressful and not due to their own performance as an individual contributor, whether in a hands-on or management role. For the weak links it is problematic because being part of a layoff does not necessarily provide the wake-up call that a firing for bad performance should have/ would have/ might have inspired.

Years ago I took the time and energy to go through the steps required to fire an engineer and he subsequently thanked me (not immediately but later.) It is a hassle and awkward to put a professional employee on a performance plan with weekly monitoring; sometimes it’s easier to just put up with the less than stellar performance. In the case of this person he was a smart, talented software engineer who had gotten in a rut and he’d started (prematurely) resting on his laurels. Subtle hints, followed by frank discussions didn’t result in change so after a while I took more drastic steps. Not enjoyable, for anyone involved…

__________________________________________
Jane Divinski has enjoyed the challenges of engineering management consulting since 1994. Most of her gigs are as interim VPE but Jane's also tackled other interim roles including CTO or program manager. Her background is at www.jadski.com

More...

New Tool: Reinventing the Wheel [Matt Schlegel]

To a person holding a hammer, everything looks like a nail. This great cliché, in a backwards kind of way, says that there are many different tools and many ways to solve problems. Here, I will describe a tool that I have used successfully to solve complex problems in cross functional organizations. Perhaps my analog electronics engineering background compels me to formulate an analogous tool to aid me in describing this tool.

The analogous tool that I propose to use is the wheel. Like the wheel, this tool is an efficient way to move teams forward. Once the team is in motion, it wants to stay in motion. Conversely, once it gets stuck, it takes effort to get it rolling again. It requires balance for smooth operation: once out of balance, the ride can get bumpy. You get the idea. The wheel will be a good way to describe both the pros and cons of this approach.This wheel tool is a methodology consisting of 8 steps or phases. Each step is critical to smoothly getting to the next step. The steps must be done in sequence in order to keep the wheel moving forward. And, each step allows the opportunity for team members to contribute in different ways, some steps will resonate with certain team members’ strengths. Those resonances will provide opportunities for those members to play to those strengths, providing leadership during that phase. Without further ado, here are the steps:

1. Problem – Goal: List the problems, define the goals
2. Team: Build a balanced team
3. Ideas: Brainstorm ideas for solutions
4. Analysis: Analyze the ideas
5. Proposal: Prepare a promising plan
6. Advocate: Present the promising proposal
7. Implementation: Implement the plan
8. Debrief: What worked? What didn’t? Start again.

Does this look familiar? I would expect most to say it does. That simply may speak to the natural way we humans solve problems. The magic, if I may use that word, of taking this systematic approach is that the solution the team chooses to implement has buy-in from all, everyone has a vested interest, and solutions are effective and lasting. Magic indeed.

Ah, yes. And, my favorite part about the wheel analogy is that the beginning and the end are at the same point.

________________________________
Matt Schlegel is a rare native to the Bay Area having grown up in Pleasanton and having gone to high school at Mission San Jose in Fremont. He went south to study engineering at Harvey Mudd College as an undergraduate and UC San Diego as a grad student. Perhaps his favorite education has been at the poker table, where he there learned about another kind of wheel – a five card hand consisting of A-2-3-4-5.

More...

Have you ever tried to introduce an Agile methodology into a company? [Nancy Dirgo]

I've done this a few times in my career. The first time it took about a year and a half. If you want to do this company-wide, you first need to get buy-in from the top. The CEO needs to understand it and needs to understand how it can save the company time and money. You then need to get the other stake holders involved. They need understand why it is important because they are your advocates. After that, it's all about tailoring it for your company.

From there, I built a internal website. The website defined each phase and provided an explanation of the deliverables of each phase along with templates of those deliverables. The templates provided people with something to start with; plus, it gets everyone using the same format, speaking the same language, walking the same walk.

I then took it one step further! I developed a 1-hour training session. I taught this session 13 times. I traveled to all of our offices (west coast and east coast). Every person from the CEO to the Admins had to take this training. This was an excellent way to get everyone to understand the process. The first 30 minutes of the session went through an explanation of each phase and their deliverables (just like the website). In order make this meaningful from a hands-on standpoint, I wanted to come up with something that everyone could relate to. I took the deliverables from "building a house" and wrote them on sets of index cards. The group broke into small teams and their assignment was to take those deliverables and organize them into the proper phases. At the end of the session, everyone walked away with a good understanding of the process.

Now that training was complete, we still had one more task to perform in order to drive it home: a test case. We took a small project and ran it through the process. We took that same project and did the old way. What do you think we found out? We would have saved $200K on this one project by working it through our methodology.

This was a very rewarding experience which has allowed me to continue to roll out Agile, company-tailored methodologies to several companies.

____________________
Nancy Dirgo has held several technology management positions in companies from start ups to large-size companies. She now is pursuing her interests in the Medical and Healthcare industries with Medical Devices and software. She also enjoys consulting for companies in the areas of engineering leadership, program/project management and software development.

More...

Can I Get Back to You on That? [Courtney Behm]

It seems to me that our daily responsiveness is decreasing in spite of the increase in the number of tools we have to stay in touch. We use email, voicemail, smart phones, audio-conferencing, video-conferencing, online presentations, LinkedIn, Facebook, Twitter, and sometimes we actually sit down and look each other in the eye, though this may be an endangered activity. I have meetings where we all sit at our cubicles, a hand’s breadth from each other and join the meeting by conference call. What is that about???

With all these great toys, and the assumption that no one is all that far from a transmission medium, why is it that I still need to send email after email, leave voicemail after voicemail, have meeting after meeting and sometimes just grab people by the collar in the hallway before something gets done? I can think of lots of reasons why it’s so difficult. Crazy busy. Slipped my mind. Something came up. Boss called a meeting. Flat tire. YaddaYadda. I can’t argue with any of these, I’ve been there myself.

But I think it’s a bit more complicated than that. I think the looming reality of so many ways to connect seduces us into thinking we are actually communicating. And the absence of the requirement to actually show up for a meeting means we are listening with one ear while we doing something else. We fool ourselves that we are paying attention, but we would probably be hard pressed to repeat what was said in the past 5 sentences. So action items go unexecuted, and decisions are forgotten, and people don’t follow through on their commitments.

Let’s take this one step further, past the operational aspects of how you title an email, or leave a voice message, or make use of the alarm function in your smartphone to get people’s attention. Let’s talk about personal responsibility, and the struggle most of us have when it comes to taking it. We have unfortunately confused the taking of responsibility with accepting blame, and our survival instincts militate against it. Blame means punishment, pain, embarrassment, rejection, and avoiding it starts early. Toddlers who can barely talk will point vaguely out the window at an invisible perpetrator when Mom comes in and says, “Who threw the spaghetti on the floor?”

Unfortunately, being effective at whatever we do requires that we accept personal responsibility. Making excuses is all well and good, but at the end of the day, we either do or we don’t do.Unfortunately, the more lines of communication we have running, the more our electronic tentacles will bind us, and the more commitments we will be asked to make. We want to be good corporate citizens, so we end up taking on more than we can handle, and dancing as fast as we can, hoping that the impossible commitment we just made will magically come out all right. Or we simply fail to respond, as we can’t be held accountable for something we never agreed to in the first place.

It’s not an easy proposition, but we must learn to take this glut of messages and information and slow down the information transfer to a speed we can handle if we are going to thrive in today’s communication overload. When I take a few moments to reflect on my breadth of commitments, and triage my incoming requests, I create a sorting process that allows me to function at my most productive. If I try to be in too many places at once, or go on radio silence, I continue to disappoint myself and my stakeholders. To create, build, deliver and prosper, I need to be as consistently reliable as I am accessible, and remain accountable for my actions. So in that spirit…Mom? The spaghetti? I guess you could say that was… me.

____________________
Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.

More...

The Softer Stuff [Gretchen Sand]

Jane Divinski and I walk occasionally and, recently, while on a hilltop in Rancho San Antonio, she asked if I would consider writing a piece for this blog. I was a bit perplexed as I am not an engineer and said as much. Jane's reply was something like this – “Your recruiting specialty is engineers. You know a lot of technical leaders and have to evaluate their strengths every day.” OK. I got it. Here goes....

Engineering leadership is a huge domain, one that expands and contracts appropriate to each situation. It includes technical knowledge, management competencies, and the softer behavioral leadership stuff which we can call leadership style. It's often the softer stuff that trips up professionals on their career journey. The candidate who does not make a personal connection, demonstrating an attractive leadership style during an interview will lose to the one who does. Finely tuned competencies in planning for the future, communicating graciously, behaving consistently, and inspiring others to their greatness are hallmarks of leadership. Leadership style is developed and comes from practice, learning, correcting and retuning the big and little things that matter in our behaviors.

Below, we'll take a brief look at just a few elements leadership style and ask a few provocative questions about how these elements could manifest. Some of these observations come from some recent conversations with industry leaders; others were inspired by a book I've read more than once: The Leadership Challenge by Jim Kouzes and Barry Posner. They are real life heroes for me.

Communication skills. How well do you engage with people? Do you make eye contact? Are you approachable? Do you cut people off in mid sentence to get your point verbalized? Take notes so as to not lose an important point vs. interrupting. What is your style of asking questions? Do you come off as the grand inquisitor or as someone sincerely, generously asking a question. Then, how well do you listen to the answers? Would your team say you demonstrate the ability to listen and to ask questions that matter? Can you convey a highly technical concept clearly to decision makers in the non-technical community? How well do you communicate what is truly important in the moment?

Presence. This is how you show up - are you on time, appropriately dressed, attentive, ready for the meeting, with your research done in advance? You only get ONE chance to make a good first impression. Would you like your team to emulate your behavior? When interviewing for a new situation, ask what success will look like - what will it do for the organization? Learn who the stakeholders are - ask to interview with them so you can best understand what is needed and wanted. Learn what is missing in the organization that will make a difference. Then, present what you can do in alignment with that. Are you truly a good fit for the team? Is the team a good fit for you?

Charisma – You have an attracting style with a healthy dose of humility. People are inspired by your presence on the project. You get calls from people wanting to learn your opinion. You listen to what is asked and are responsive vs. bowling over the audience with all the great things you've done or would do. You remember to check your ego at the door. You ask for help. You know it is perfectly OK to say "I don't know" if that's really your answer to a question. How would you boss describe your ability to attract talent to your organization? Would you hire you?

Curiosity. You have a breadth of curiosity and knowledge about your company and your industry. You learned about its history, competitors, performance, management team, and its potential for growth – sometimes by consulting other leaders. This will truly help with your decision-making (see decisiveness, below). Knowing what matters will keep your work and your team moving forward. You consult with your team on how they would solve a problem. You know what your peer's specialties are and call on them for advice. Thinking about a really tough technical challenge you helped solve last year, who did you call on for help? Did you give them credit? Thank them? (see charisma and humility, above) Do you surround yourself with people who help you look at the bigger picture?

Competence and Vision. When articulating the future of your organization, you present a crisp forward-looking plan. It is actionable and includes a road map to success with measurable milestones. Your vision inspires people to bring their passion to work. They own the project with you. As an engineering leader, you are aware of the big picture, the world outside of the technical domain. Your plans acknowledge where the technology or science fits in the big scheme of things. Your style is to pursue a technology path for the good of the organization not because it’s a fun and really thorny problem to work. You acknowledge when you need help getting the work done and get it in a timely manner.

Decisiveness. You have just a few filters you use to make decisions quickly. Leaders listen, decide and act based on the current situation and knowledge. Leaders are hired not because they never make a mistake, but because they learn from mistakes and succeed in spite of them. Leaders have the power of their convictions and are not easily influenced by the issue du jour.

Integrity. Honesty is everything. Everything you do should be publishable on this blog or the front page of a newspaper. You give others' a good reputation to live up to. You are good for your word. You admit to making a mistake. It’s easy for you to say why you left your last position or are looking for a new situation – and – you have a strong bridge to your past.

There a whole lot more to write about here. I’ve barely scratched the surface. I'm wool gathering about a piece that speaks to the traits of the engineering leader as the hiring authority.... There are schools, books, and organizations devoted to the study of Engineering Leadership and its importance to our work universe. Read a book on leadership at least once a year. Our valley is an extraordinary tribute to the work and dedication of engineering leaders. We really do have rocket scientists working nearby. There are really smart people making very difficult decisions daily about the future of technology just down the road from you. Take the time to get to know a leader outside of you immediate milieu. Explore what engineering leadership means to them. Look at what it means to you. Write a blog piece about it.

____________________________
Gretchen Sand is Senior Partner and co-founder of Skyline Recruiting Corporation solving staffing challenges for Silicon Valley high-tech companies since 2001. Gretchen's focus is placement of senior individual contributors and executives in the engineering and product management domains. Prior to founding Skyline in September 2001, Gretchen served as Vice President, Business Development and COO for Lloyd-Ritter Consulting where she got her start as an engineering recruiter in 1996. Prior to 1996, Gretchen worked for Lockheed Corporation in many functions of the product development value chain: program planning and management, operations management, new business development, and systems engineering. More about Skyline Recruiting Corporation can be learned at: http://www.skylinerecruiting.com

More...

New Tool: When you need to repair your Cross Functional Product Delivery Engine [Matt Schlegel]

As a smart, young engineer, it may have crossed your mind, as you toiled away on projects, how things would be different if you were in charge. Perhaps these thoughts inspired you to pursue a management position. As a manager, you imagined, you would have more influence over how things got done.
You became a manager. You enjoyed the influence you now had over your group’s business. Your team performed well, and you were successful in the position. Yet, you remained unsatisfied. Business within the entire engineering group was not run as smoothly as you imagined it could be. And, again, you aspired to a position of overall engineering leadership.

You became the engineering leader that you imagined. Engineering runs well, and you have a great, productive team. Yet, you still remain unsatisfied. The overall product delivery engine still does not run as smoothly as it could. You speak to your peers, the leaders of marketing, sales, operations, in the company and they would agree. Ideas are bandied about. Few are tried, and fewer are seen to successful conclusion. The CEO asks you to figure it out and get the entire cross functional product delivery engine to work as well as your engineering group works. Now, what do you do?

Any engineer worth their salt loves tools. They maintain a full tool box. They are on the search for tools to better perform a task. When a tool does not exist to perform the task, they will fashion a new one. In the next few submissions, I will describe a tool that I fashioned to help solve organizational and operational issues both within an engineering group and within the cross functional organization as a whole.

_____________________
Matt Schlegel has held management positions in engineering, product development and program management at a number of Silicon Valley start up companies. Now, Matt enjoys consulting for companies in the areas of engineering leadership, product delivery, joint development with Japanese and Asian partners, and telecommunications. Before he started working on product delivery engines, he cut his teeth (and hands) on Chevrolet engines.

More...

Hands-On Leadership or Not? [Peter M. Allen]

I speak with many startups who are looking for hands-on managers. I am wondering how others in Engineering Leadership feel about this trend.

I personally programmed for 20 years here in Silicon Valley before becoming a manager (Director and VPE). I can understand today’s trends in a tight market that everyone needs to contribute to the product, yet I see many cases of management being spread too thin and not doing well at any discipline. Do we need to be masters of leadership and management as well as hands-on coders, and if so which technologies (OS, Server, Database, and Language)?

The rigors of management are different from those of hands-on engineering. Management is about leading people, processes, and technology. It requires the ability to multi-task and be graceful under constant interruption. I found this challenging while programming - I always appreciate those in leadership who give me the tools and time to focus on coding instead of dealing with program/project management, meetings, and politics.

Is it true that the best leaders do so by example, or is the gift that they bring to their teams inspiration and focus? I’ve always enjoyed the Scrum approach to leadership – remove all obstacles, which is in itself a full time job. While I enjoy code reviews and extreme debugging, as a manager I often feel that my team is in trouble if I must code with them. How successful can a hands-on leader be at planning, managing, and communicating?

Must the conductor of the orchestra also play an instrument? Sure, the conductor needs to deeply understand music, but must s/he be able to play the piano, violin, percussion, and wind instruments in order to be a great conductor? And are we talking about a chamber quartet (where the pianist is the defacto conductor) or a larger symphony? Your thoughts?

___________________________
Peter M. Allen is a Software Executive in Silicon Valley who leads passionate teams delivering secure and scalable services at firms like Napster and PayPal.

More...

Technical Egotism: The Good, The Bad, The Ugly [Jane Divinski]

It’s no secret that many talented software engineers are supremely confident in their own technical abilities. Successful companies exploit this fact and constructively leverage the peer pressure to inspire creative innovation. At the various engineering management levels (manager, director, VP) we encounter professionals with a technical background who previously worked as hands-on engineers. So how does technical egotism factor into the role of management? Should someone’s technical opinion count for more, solely because he/she now has a management title? Major project decisions that factor in solely technical issues are rare since software development is a juggling act involving not only technical innovation but also resource constraints and target date pressures.

A good situation exists when technical managers at all levels stay on top of software technology as it continues to evolve. Often a first line manager is the technology expert among the group; many times a director or VP needs to be technically astute, knowledgeable and sharp, able to ask the right questions, assess the answers and drive decisions when no obvious conclusion exists.

Bad problems occur when people in an engineering management role don’t allocate time and energy to stay appropriately knowledgeable. The overall team needs to have confidence that not only can the leader positively influence the product development effort but he/she must be able to successfully represent the engineering team in cross-functional discussions and status reporting to senior management.

Ugly consequences result when the engineering manager (director or VP) insists on clearly and constantly establishing that he/she is the technical expert for the group and competes with the engineers to prove technical supremacy. It’s good to constructively challenge the engineering smarts of the group. It can be very destructive for the head of the group to consistently belittle technical ideas proposed by individual contributors. Brain-storming sessions should be creative discussions where half-baked ideas can be casually tossed out; many of these ideas won’t have merit but the group slicing and dicing of the concepts can be very productive, ultimately resulting in better products developed in a timely fashion.

Ideally a person now wearing an engineering management hat will have enough rapport with his/her team so that he/she can freely participate in nitty gritty technical discussions. All his/her ideas should not be taken seriously because of the management role but neither should they be summarily dismissed because of his/her management title. Either of these extremes occurring consistently is problematic and does not bode well for the success of the team.

______________________
Jane Divinski has, since 1994, provided software engineering management expertise on a temporary basis, leading Silicon Valley teams as interim VPE, director or program/project manager. For more background please see www.jadski.com.

More...

What's an agile manager? [John Levy]

Sometimes I sit back and think about management -- really! Yesterday I was reflecting on the hierarchy. You know, the President at the top, the Vice-Presidents, the Directors, the managers, and so on down the line. This is what we call line management, right? And we know that each one of them is responsible for something. The best analogy in Scrum is the "single wringable neck" that summarizes the Product Owner role.

But the Product Owner in Scrum is a member of a team -- the Scrum team that is self-organizing, self-improving, and collectively responsible for producing results. What if we organized the whole company that way. We could have a Departmental Scrum consisting of the Scrum Masters and Product Owners from each of the ongoing "projects" or functional groups, just like a Scrum of Scrums. And there could be -- but wouldn't have to be -- a Senior Scrum Master and a Senior Product Owner who participated in further Scrums of Scrums with broader scope.

Back in 1996, I was a member of an 8-person team charged with planning company strategy looking 10 years ahead. There was another 8-person team doing the same thing independently. (For a description of the process, see Prahalad & Hamel, Competing for the Future). We spent 9 weeks away from our normal jobs studying the world and composing a strategy. It was the best team-oriented process I have ever participated in. The reason I note it here is that when the team was asked to select a single spokesperson / leader, the team refused. We responded that we had confidence in each and every team member to represent the team (and to check back with the team if there were any questions).

What if a Department were run by a team that had that kind of confidence in each other? Imagine a group of former "managers" who are now team facilitators and/or team product owners who spend enough time together to know what's going on, and are able to deal with all of the Department business by designating a pro-tempore leader to represent the team and its interests. Even at the next level "up," even the "leader" could be a rotating role.

It goes against all the hierarchical thinking that we've been raised with, taught, and trained to accept as normal. But a business enterprise is not a military organization. And many of today's enterprises need to be Agile so that what they produce (whether product or service) is adapted to the current business environment. If we organized management as rings of teams with coaches and product owners, that would give us maximum flexibility, open up lots of lines of communication, and cross-train people in many roles.

First, of course, we have to give up some long-hallowed practices, such as the hierarchical organization chart. We'd also have to change the concept of managing from being a sense of control to one of responsibility -- and responsibility in this case means responsible for the way in which the team operates as well as what we as a team produce. This strengthens the idea of the manager as coach, and might even encourage a person in the leader/manager role to act as if the team knew more and was capable of more than the individual leader. What an idea!

____________________
John Levy consults on Agile development and is an expert witness in computer & software patent cases. He has 30 years’ experience as a technology manager at Quantum, Apple, Tandem and DEC. His book on managing technology, Get Out of the Way, is due out in 2009. Check him out at http://johnlevyconsulting.com

More...

Leading from a Higher Ground [Courtney Behm]

Over the course of my career, I’ve been in a great many situations where I didn’t like the way things were being done. Maybe it was my boss, or the executive team, or the engineering strategy, or the marketing positioning, or the decline in revenue, or…well, you get the picture. For reasons too numerous to count, things just weren’t all that great for me and/or for everyone. And here’s my true confession: when that happened, I was only too happy to join the malcontents, to hash over and discuss and criticize and complain. It seemed to relieve the tension, to clear the air. We got things off our chest. We said it like it was. We felt powerful and smart because we understood what was REALLY happening, we saw through the smoke screen, we couldn’t be fooled, and we knew the Emperor had no clothes.

Things began to change for me when I was working at Wang Labs during their precipitous decline in fortunes. Every day presented new opportunities for us anxious and disbelieving employees to kibitz and second guess every corporate decision. The clouds of misery were everywhere, and we tried to talk ourselves out of our frustration by over-analyzing every little event. Then one day my boss called me into her office. “Courtney,” she said, “you are unbelievably good at distilling the truth of a situation down to two or three well chosen phrases that allow everyone to see clearly what is actually going on.” As I was beginning to puff up a bit with pride, she continued, “And sometimes you just shouldn’t do it.” Ouch!

This gave me a lot to think about, and in the ensuing years I’ve spent a great deal of time working with this complex question: when is it appropriate to “tell it like it is” and when is it more valuable to find the possibility in the situation, to put ourselves in someone else’s shoes, to calm the waters? This question speaks directly to what kind of leader we want to be.

It’s pretty easy to gather people around you when you take the low road. We are a rather whiny species -- quick to blame, to cite grievance, to demand satisfaction. In my capacity as articulate complainer, I found lots of validation for my opinions. But those opinions, however well expressed, positioned me as a negative leader. I was unwittingly making myself and everyone around me more miserable by focusing on what was broken, by amplifying what we were afraid of or angry about, and as a cohort, we couldn’t go anywhere but down.

We may not always have control of the important influences in our lives. The economy, the demand for our product, the weather, the competition – these often arise to impact us from what seems like another universe. But we always have an opportunity to be calm and trustworthy. To listen quietly. To validate someone’s discomfort without throwing gasoline on the fire. To acknowledge difficulties and still offer a way out. To hold our ground. To give people the benefit of the doubt. To use language that strengthens, rather than fans dissatisfaction. I’m not talking about blind optimism here, that is about as effective as using a smile for your umbrella. I’m talking about focusing on what is possible, reminding us that we have the power to make things happen, and affirming our strength and courage.

No one is perfect, and no one leads perfectly. But when things are moving fast, and chaos reigns, and uncertainty is the order of the day, we need to offer leadership that inspires, that energizes, that motivates. This is the kind of leadership that brings us out of difficulties and back to prosperity. Every one of us has an opportunity every day to make great changes in our organizations and our lives by leading from a higher ground.

____________________
Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.

More...