SVForum Engineering Leadership

Steve Jobs Dead at 56 [Michael Emens]

2011-10-06T08:00:00.000-07:00

This week (in fact today and just now) I heard some news I did not expect and I heard it from someone I did not expect it to hear it from… my son. You see my son is 15 years old (and a sophomore in high school) and the news he gave me rocked my world as I did not expect it. He said, “Steve Jobs died”.

At that moment just like someone experiencing those last moments of life (like in the movies) I immediately transported to my sophomore year of high school.

It was 1982… I was a sophomore in a new high school and little to no friends to speak of. News of a “computer” on campus soon caught my ear. I quickly hunted down these two “computers”. Apparently they were donated to the school from a company called “Apple”.

Before I knew it I was spending endless lunch and after school hours at this computer. At the time having a computer in high schools was a new concept to everyone (including the staff and teachers)… they simply did not know what to do with these things.

These two computers were placed in a library closet (yes a real closet) and typing room closet… yes I said “typing room”. Ok for those under 45’ish I’ll explain… in 1982 typing was an actual class to teach you how to type on a keyboard… and it was not typing on a computer it was on a typewriter and if you ask me what a typewriter is I’m going to send you to your room and ask you to Google it.

As much as I hate to saying it today “Apple I” was my first true love… and yes my wife is OK with it.

I spent endless (I really mean endless) hours reverse engineering that Apple computer. I “peeked” and “poked” the memory to understand everything about this puppy (again Google it). I recall one day the typing teacher came up to me and said… “Why are you spending so much time at this ‘Computer’? It’s a big waste of time”. I’m very happy to say I ignored that teacher.

Come senior year of high school (1984) I applied to college and to my pleasant surprise “Computer Science” was an actual major. The rest is history as far as I’m concerned.

In truth… over the years my loyalties were with Microsoft. I was a Microsoft believer and an Apple hater. Today however I can say my Microsoft/Apple religious beliefs are actively changing… and that’s a good topic for another day.

Today however my thoughts and admiration are with Steve Jobs… Not because I was a loyalist to his cause, but rather (and in fact and in truth) he was a true adversary in my personal computer revolution. He (and Steve Wozniak) introduced me to computers. They both gave me something to feel passionate about and at age when I needed it the most.

Thank you Steve Jobs…

Although we did not play on the same team, you made every game something to look forward to.

On a final note…

My son (interestingly a sophomore in high school this year) has a class in “Computer Science” using a Mac and Microsoft Windows emulation… The revolution continues.

Cheers.

Michael Emens

This Blog is Moving! [Robert Lasater]

2011-09-08T12:54:00.000-07:00

In connection with the Software Developer's Forum renaming itself the Silicon Valley Forum, we are moving this blog to svforumelsig.blogspot.com. Current entries on this blog will remain, so any bookmarks or search keys that lead you to entries on this blog will stay valid.

Be sure to start visiting svforumelsig.blogspot.com for the latest postings on Engineering Leadership.

Announcing the Next EL SIG Meeting, September 15 [Robert Lasater]

2011-09-06T08:17:00.001-07:00

The next meeting of the Engineering Leadership SIG will be held on September 15 in SAP Building 2 (3412 Hillview Avenue, Palo Alto, CA), starting at 7:00 PM. Doors open at 6:30 PM. Title of the main presentation, "Problems, Big Problems, and Damn Problems: Solving the problems that keep you awake at night", by Jerry L. Talley.

Jerry says "The topic of the talk is a discovery from my 30+ years in organizational development work. I believe there are only 6 types of problems. Each type poses a unique challenge. The most critical decision in problem solving is not 'What's the best solution?', but rather it is 'What type of problem is this?' Once you identify the type you have a clear sense of the critical features that must be explored, what strategy to use in solving the problem, and what a solution would look like...at least in outline form.

"It turns out that strategies that work well for some types are disastrous when applied to other types. And some of the types are easy to confuse for each other. So typing the problem is not always simple; it's just always essential.

"The talk outlines the 6 types and briefly describes the strategy unique to each type. It is a dramatic departure from the classical model of problem solving which has been around since the 1950's and altered very little since then."

Jerry Talley has over 20 years of organizational consulting. Prior to that career, he was an adjunct professor at Stanford University teaching in the Sociology Department for 18 years. Coincident with that experience, he had a practice as a Marriage and Family Therapist for about ten years. Starting in the late 1970's, he moved into organizational development consulting, accumulating over 250 client engagements since that time. His clients included companies in high tech R&D, hospitality, health care, the military, manufacturing, banking and credit unions, education, publishing, mental health, city and county government, not-for-profits, and large consulting houses...and one organic grocery store.

Throughout all these experiences, the common focus was on how people think about and manage complex situations, how they attempt to solve the problems in their world, and how they form relationships with others in that effort.

For more information, go here.

SNACK SPONSOR: Brian Lawley, 280Group - The 280 Group™ provides Product Marketing and Product Management Consultants, Contractors, Training, Books,Certification, and Templates to help companies world wide to define, launch and market breakthrough new products.

SNACK & BEVERAGE NOTES: SVForum provides some pizzas, and SAP welcomes us to help ourselves to soft drinks that we may encounter in the vicinity of our events.

As of August we won't be providing alcoholic beverages in the future so we can spend more money on food.

MANAGEMENT RESOURCES SPONSOR: ProjectConnections.com supports EL SIG members with a wide range of resources for managing organizations, projects, and people. Members can access links to templates, checklists, articles, and more from the ProjectConnections.com Premium library. All this is available to ELSIG members at no charge, at the ELSIG page onProjectConnetions.com (Open Enrollment is offered twice a year for this benefit. It's that time of year! We'll be sending a notice shortly and you can sign up if you haven't already.)

Cost: $20 at the door for non-SDForum members, No charge for SDForum members

BOOK SWAP - Every month! Bring books to share.

JOB SWAP - Check out our Yahoo! Group here: http://tech.groups.yahoo.com/group/SDForum_EL_SIG_JobSwap/

PEER-to-PEER Roundtable - Every month! Join us to share insights and advice with peers each month prior to the 7 PM event.

Living the Symbolic Life: Metaphors from Yosemite [Elizabeth Agnew]

2011-08-09T07:55:00.000-07:00

One consistent way to improve your leadership is to find symbolic meaning in areas of your life where you might not be looking. Take something that’s happening to you, make an abstract summary of it, and see where else the metaphor applies in your life.

Five of my good friends and I went on a backpacking trip to Yosemite National Park over the July fourth holiday. There were many good lessons buried in the three days we spent roughing it in the wilderness. Here are three powerful metaphors I took from the trip that I think you will find helpful, too.

1. When you can no longer see the path ahead, stop, take a load off, and look around in a new way.

On day 1 of our hike, the snow cover was still so deep in some areas that we’d be walking along and then the person in the front would realize they lost track of where the trail went. Conversations would pause and we’d all stop and look around. Sometimes we even had to set our packs down and send one or two people off to scout out the trail. We were looking for clues – large cut logs were a very good sign because it means that the park service had cut a trail through a fallen tree.

Sometimes when you’re already in motion, going along not really paying attention to where you’re headed, you’re realize you’ve lost your way. Release yourself of the weight you’re carrying, take your time, and the path will become clear again.

2. If you push through at the end, you might just end up farther than you thought you would.

On day two, we hiked a large elevation change and several miles. It was late and everyone was ready to be at camp, but we still had two miles to go. The pace was fast so that we could make it to camp by dark. People were silent, managing their own fatigue and pain levels. When we got to our camp, we realize we’d estimated incorrectly where it was, and had hiked a mile more than we had planned!

The element of focus that comes at the end of a project, just when you want to quit, is so essential to a strong finish. Your “second wind” at this point in your progress can give you more momentum than you realize. Power through your finishes!

3. There are greater forces at work beyond our control.

On the drive home, we were headed west on a country highway, almost at the interstate. We slowed down because we saw a car slam on its breaks in the eastbound lane. Two cars behind it, a car was trying to avoid the car that stopped, and pulled out into oncoming traffic – right in front of us. We swerved to avoid it, but the driver was in reaction mode and had turned left into us. We collided hard. Luckily everyone was ok and walked away, but the experience shook us up, especially when we thought about how there was nothing we could have done to avoid it.
I was surprised at the sense of calm surrender I felt when I saw we were about to hit the other car. If, like me, you often feel the most afraid when you feel out of control, take note. This acute instance of knowing I was out of control led to a divine feeling of surrender and calm. The trick now, is for us to learn to apply that same feeling to other areas of our life and work where we are also out of control.

The symbolic life is one where we take meaning in moments that we would otherwise simply log in the memory bank. Leverage all of your experiences so that your future ones may be even richer.

Elizabeth Agnew works with individuals and organizations in technical fields needing tailored leadership development that speaks their language. Liz has logged hundreds of hours coaching individuals from companies such as Jet Propulsion Laboratories, Google, HP, SETI, Lockheed Martin, VNUS and Sun Microsystems. Her background includes experience in adult education, team facilitation, and public speaking. She offers complimentary coaching consultations – call or email today to schedule yours.

Announcing the Next EL SIG Meeting, August 18 [Robert Lasater]

2011-08-06T09:28:00.000-07:00

The next meeting of the Engineering Leadership SIG will be held on August 18 in the SAP Cafeteria (3410 Hillview Avenue, Palo Alto, CA), starting at 7:00 PM. Doors open at 6:30 PM. Notice the location is different, on the same street, Hillview, but in the neighboring SAP building. Title of the main presentation is "Rapid Rapport: Creating Influence On Demand", by Bernie Maloney.

TOPIC: Rapid Rapport: Creating Influence On Demand

SPEAKER: Bernie Maloney, PE http://www.linkedin.com/in/berniemaloney

More info: http://www.SVForum.org/elsig

LOCATION: SAP CAFETERIA (not our normal location)

(DIFFERENT THIS TIME because we're combining with another SIG this month)

SAP Labs Cafeteria
3410 Hillview Ave
Palo Alto, California 94304
United States

http://www.saplabs.com

Description: SAP Labs Palo Alto

From 280: exit Page Mill, go east, downhill. Turn right at Coyote Hill, turn right on Hillview and then right again up the hill into the SAP campus.

From 101: exit Oregon Expressway west, uphill. Follow Oregon, Page Mill until you hit Coyote Hill. turn right on Hillview and then right again up the hill into the SAP campus.
=================================================

Snacks and Beverage Sponsor: PMI SV - Julie Godon http://www.pmisv.org/ The Silicon Valley Chapter is a regional component of PMI and a resource for all aspects of project management leadership and information in California's Silicon Valley (southern end of San Francisco Bay). The chapter’s 2,000 plus members enjoy over 200+ yearly local activities supported by an all volunteer staff. In addition, Project Management Professional (PMP) certification has been achieved by over 60% of its members. The Chapter’s mission is to support the interests and needs of its members by providing the leadership and forums for expanding and sharing the knowledge of Project Management.

. . . next month it could be YOU for $100! Please contact Sue Shreve: msshreve 'at' sbcglobal.net

Management Resources Sponsor: ProjectConnections.com supports EL SIG members with a wide range of resources for managing organizations, projects, and people. Members can access links to templates, checklists, articles, and more from the ProjectConnections.com Premium library. All this is available to ELSIG members at no charge, at the ELSIG page on ProjectConnetions.com (Open Enrollment is offered twice a year for this benefit. It's that time of year! We'll be sending a notice shortly and you can sign up if you haven't already.)

BOOK SWAP - Every month! Bring books to share.

JOB SWAP - Check out our Yahoo! Group here:
http://tech.groups.yahoo.com/group/SVForum_EL_SIG_JobSwap/

PEER-to-PEER Roundtable - Every month! Join us to share insights and advice with peers each month prior to the 7 PM event.

BLOG Write or read EL SIG blog posts here: http://sdforumelsig.blogspot.com/

Cost: $20 at the door for non-SVForum members, No charge for SVForum members

For more information, go here.

July 21 Meeting Notes - Kimberly Wiefling on Leadership [Robert Lasater]

2011-08-04T13:19:00.000-07:00

On July 21, Kimberly Wiefling gave a presentation on leadership - "Why Would Anyone Follow You?" - in her usual energetic and inimitable style. Here is a summary.

Kimberly started by reminding the audience how low retention rates are usually after a presentation or talk. Within a few days the typical participant has forgotten 50%; this rises to 80% after two months. She worked to counter this trend by having the audience participate in several exercises. The first was done in pairs: describe to your partner what you had for lunch today - with enthusiasm.

A leader needs to infect the organization with this kind of great enthusiasm.

You need to be willing to be uncomfortable to accomplish your goal. [Getting people out of their comfort zone was another goal of her exercises.]

Kimberly Wiefling works with mid-level management in Japan. "I use a lot of shock tactics" to get her clients out of their comfort zone.

The next exercise had people get into small groups - two or three people - to list and discuss the characteristics and languages of the worst leaders in the world. Afterword, she polled the audience for their responses:

· Know-it-all
· Lack of focus
· Not able to apologize
· Jeopardizing the team for personal reasons.
· Micromanagement
· Taking credit for others
· Lack of integrity
· Unethical
· Abdication of responsibility
· Fear

Now leaders have only three tools:

· Action
· Communication
· Thinking

-but the last tool is not visible.

And leadership is not on the org chart. Some missing items are:

· Vendors
· Customers
· Venture capitalists
· Competitors
· Government and other regulatory authorities

Five characteristics of people in power:

· Receive more positive feedback
· Have less control over their impulses
· Think about their own needs more
· Have less empathy
· Thinks the rules don't apply to them

Question: do people become more unpleasant when they achieve power over other people, or is it their unpleasantness that causes them to achieve power? Which leads to another exercise: discuss how to avoid the trap of unpleasantness if you have power over people. One strategy to achieve that goal is to lead with questions - listening is the lost leadership skill.

Another exercise (again for pairs): plan an EL SIG holiday party, with your partner responding with "yes, but". (Tip: "yes, but" actually means No.) Next, try with your partner responding with "yes, and".

The final discussion topic was to provide examples of language of an admired and influential leader.

· "Thank you"
· nothing - let the followers take charge of discussions
· "Job well done" - but more detail about why it was well done is always appreciated.
· "What obstacles do you have?"
· "I love that idea."
· "What do you think?"
· "The real credit goes to ..."
· "What do you think it will take to make it happen?"
· "I'm sorry."
· "I don't know."
· "I need help."

Kimberly Wiefling is the author of Scrappy Project Management, one of the top-ranked project management books on Amazon in the US, published in Japanese, and growing in popularity around the world. She splits her work time between the US and Japan.

Even if You’re Wrong, You’re Right - So choose your beliefs carefully! [Elizabeth Agnew]

2011-07-13T13:40:00.000-07:00

Everyone lives from their own perspective. Everyone likes to be right. These are both facts about human nature.

Your belief system is the backbone to how you experience the world. Your paradigm, or the lens through which you see the world, is driven by this belief system. It’s just what you know.

When you live from your perspective, you experience the world with your own slant, and how you experience and respond to the world drives your future actions. Your actions reflect what you believe, and so in the end, your beliefs will ultimately become your reality. If you believe something that hinders you, well, what can I say – you’ll be hindered. If you believe you will be successful and flourish, well, what can I say – you’ll flourish.

Your beliefs are the ultimate gatekeeper to your success. If you say “I could never run faster than a 7-minute mile”, it is highly unlikely that you will ever run faster than a 7-minute mile, even if you have the physical talent.

Beliefs that prevent you from taking action that could result in your growth and success are called limiting beliefs. They cap your potential. Because you limit yourself, you won’t see positive results. A lack of good results will reinforce the negative belief that limited you in the first place, and there you go down the negative spiral. Even though you were probably wrong about your limiting belief in the first place, you made yourself right because your actions reflected, and thus reinforced, your beliefs.

Take Jake, for instance, who is afraid he isn’t good in social situations. He fears being the one to speak when there are more than two people in the room because he doesn’t think he has anything worthwhile to say. This belief causes him to stay at home more often, and to stammer and cut short his opinion when asked of it by others. Staying home means he is exposed less and less to the situation he fears, and getting nervous when he has the floor means he does end up having awkward social experiences. Even though Jake is wrong about his potential, he ends up verifying the belief that he is socially awkward. Jake was wrong, but in the end, he made himself right.

This cycle is how your beliefs can easily become self-fulfilling prophecies. “I could never do that.” Even if you’re wrong about the fact that you “could never do that”, you will in the end, be right, because your belief will stop you from ever trying. You make up a story in your head, and the act of choosing to believe that story is what helps it become a fact.

Since this is the case, why not choose beliefs that align with qualities you admire, and the lifestyle that you dream of? Find a way to believe the positive things that you want to be true in your life. If your new beliefs are too much of a stretch from what you’re used to telling yourself, then you won’t really believe them, and then they won’t ever be true for you. Find a way, through delicate phrasing or evidence from the past, to believe the things you want for yourself.

What if Jake said: “You know, I’m okay in social situations, I really am.” This is a modest statement that he can honestly believe in, and a first step to reshaping his belief system. Because he believes this, he will be less likely to turn down an invitation due to nervousness, and less likely to squirm and judge himself on the way he acted in a social group. In the end, again, he will be right.

No matter what, your actions are a product of your thoughts. So even if you’re wrong about your human potential or about your relationship with the world, you’ll be right, because you will live out that belief.

Even if you’re wrong, you’re right, so remember that when you decide what you want to be true for yourself. The thing always happens that you really believe in; and the belief in a thing makes it happen. What do you want to make happen for yourself?

Elizabeth J. Agnew, MS, ACC
Integrative Leadership Strategies
415-401-7822
liz@integrative-leadership.com
www.integrative-leadership.com
P.O. Box 460515, San Francisco, CA 94110

------------------------------------------------------------------------
Liz works with individuals and organizations in technical fields needing tailored leadership development that speaks their language. Liz has logged hundreds of hours coaching individuals from companies such as Jet Propulsion Laboratories, Google, HP, SETI, Lockheed Martin, VNUS and Sun Microsystems. Her background includes experience in adult education, team facilitation, and public speaking. She offers complimentary coaching consultations – call or email today to schedule yours.

Announcing the Next EL SIG Meeting, July 21 [Robert Lasater]

2011-06-24T12:55:00.000-07:00

The next meeting of the Engineering Leadership SIG will be held on July 21 in SAP Building 2 (3412 Hillview Avenue, Palo Alto, CA), starting at 7:00 PM. Doors open at 6:30 PM. Topic of the main presentation, Why Would Anyone Follow You? The Language and Behaviors of the Most Admired (and Despised) Leaders, by EL SIG's own Kimberly Wiefling.

Attend. Find out. Practice. Change.

Leadership is not a position in an organization chart or a title on a business card. Leadership is a way of thinking, behaving, and communicating. Leaders have only 3 tools at their disposal: A.C.T.

• Actions

• Communication (both talking and listening)

• Thinking

Of course followers can only directly experience 2 of those tools. Followers judge the effectiveness of leaders by their actions and communication.

The pitfalls of poor leadership are well known, as are the practices of the most admired leaders in the world. But knowing how to do something has never been enough in itself to assure success. (If knowing how were enough we'd all be rich and thin!)

This event is NOT about telling you how to be a great leader. This highly engaging and interactive session will give you an opportunity to practice acting and communicating like a great leader.

Come curious and prepared to participate, and leave more the kind of leader you admire.

Kimberly Wiefling is the author of Scrappy Project Management, currently ranked #1 on Amazon Kindle US in Total Quality Management. She splits her work time between the US and Japan.

Cost: $20 at the door for non-SDForum members, No charge for SDForum members

BOOK SWAP - Every month! Bring books to share.

JOB SWAP - Check out our Yahoo! Group here: http://tech.groups.yahoo.com/group/SDForum_EL_SIG_JobSwap/

PEER-to-PEER Roundtable - Every month! Join us to share insights and advice with peers each month prior to the 7 PM event.

BLOG Write or read EL SIG blog posts here: http://sdforumelsig.blogspot.com/

For more information, go here.

SNACK & BEVERAGE SPONSOR: LongView International is a innovative Silicon Valley consulting company specializing in semantic technology and software architecture. Together with our clients we achieve success through understanding business goals, formulating the strategy to execution, and building the right solution.

PROJECT CONNECTIONS ONGOING MANAGEMENT SPONSOR: Project Connections is our EL SIG Management Sponsor. ProjectConnections.com is dedicated to practically and affordably supporting individuals as they do their jobs day-to-day and helping them grow their management abilities and careers. We also provide management development and support resources to organizations, through group subscriptions, methodology content licenses, on-demand virtual training programs, virtual coaching, and more - all to help managers improve how critical project work gets done, and to help grow the capabilities of everyone on their staffs and teams.

Meet my Leadership Coach, The Jigsaw Puzzle [Elizabeth Agnew]

2011-06-20T16:21:00.000-07:00

As my dad and I poured over our 1500-piece sailboat jigsaw puzzle one holiday break, the metaphors between what we were doing and true leadership ran continuously through my mind. I’m amazed at what paying attention to these metaphors can teach us about our own leadership qualities and how to run a team or business.

Here are four concepts integral to leadership that I found buried in that puzzle box.

1. Accepting impermanence

At any moment, a 3-year-old could come on by and, while thinking she’s helping, systematically dismantle the border of your puzzle, like my niece Grace Anna did. It’s amazing how long it took us to put together the first time, and how quickly we reassembled it the second time.

Impermanence also shows up when the puzzle has been completed. You may leave it around for a day or two to admire your production, but after that you destroy it, only to shelve and forget about it for long enough that would be a challenge to reassemble.

We tend to get attached and want things to stay how they are, or bogged down by wanting to stay on top of all possible information. Comfort overtakes creativity and growth. We can counteract this by accepting – even embracing – the impermanence of our relationships, projects, business, and ultimately our lives. This act, paradoxically, is what fosters growth, creativity, and love.

2. A perfect fit comes with a satisfying click

This is my favorite analogy. As my dad and I were working, he kept finding pieces that were so close to fitting but were not quite a perfect match. In a mock I’m-so-fed-up-with-this voice, he’d bark “get me my hammer!” ostensibly so that he could make it fit. Thing is, that would just cause more misfit pieces later on.
Needless to say, my dad doesn’t stand alone in his desire to force things to work out when they clearly aren’t.

Sometimes the opposite happened; I would be 90% sure the piece fit, but I held it up to the light just to make sure there weren’t any gaps. Sometimes a perfect fit leaves us skeptical and requires closer inspection.

However, most times, the pieces fell into place with an easy yet tangible, all-too-satisfying click.

Some relationships and connections clearly don’t fit and we’ve been known to think that as leaders it’s our job to get out our proverbial hammers and make things work. Yeah, and we’ve seen how well THAT works. Other situations warrant closer inspection under a bright light. And when the connections are right, we’ll notice our own version of the ‘click’ – that is, if we’re paying attention.

3. The ability to scope and focus

It was hard to choose an area of the puzzle to work on, especially when we were just getting started. There was too much to do! But as you can imagine, when we tried, out of hasty overwhelm, to work on the whole puzzle at once, our rate of connecting pieces dwindled greatly compared to when we each committed to a certain area.

Part of the hesitation for committing was the initial time investment of gathering all of those like-colored pieces from the bottomless pile, half of which were upside down! Focusing on a project or area of your business requires the same initial investment.

I naturally chose the easiest areas first and saved the fine-patterned areas like skies, mountains, and trees until the end. It’s funny, because as the easier areas came together, the harder ones then didn’t seem so hard, as if I was more ready for them, or understood them better in the context of the completed areas.

It’s harder to make the critical leadership decision to scope your business or project and focus in on just one part at a time, especially when things are just getting started because there’s so much to think about. Doing so, though, forces you to choose the most relevant from an endless pile of information (half of which is upside down, remember).

This also enables you to progress faster, and perhaps more importantly, to feel the progress you’re making so that your momentum continues. Start on the easier, more attainable areas and see how they come to inform the vaguer, less-defined areas as progress unfolds.

4. Pieces as parts of the whole

As my dad and I worked, each piece (especially the nondescript ones) seemed so insignificant. But even if one piece was missing among the 1500 of them, it would have resulted in an incomplete product. Each piece was individually hand-laid to produce the final product and so each piece was critical. Yet at the same time, each piece was nothing without the context brought by its surrounding pieces.

As leaders, we take action every day to achieve our vision, laying in one or two seemingly insignificant puzzle pieces. Without consideration of the final product and how our small step fits into it, we can become discouraged by a feeling of not having done enough at the end of each day. In other words, each action, devoid of its place in the bigger picture, may not seem to make a difference. Over time though, what a picture you will have constructed with all those tiny pieces!
Puzzles are relaxing and meditative. We maintain a trance-like interest, yet without the urge to rush. We desire the end state of having a completed picture, and that pulls us forward. Ironic, because it’s the means to the end that we relish in.
Leadership, on the other hand, usually isn’t quite so relaxing and meditative. Does that mean it can’t be? Why don’t we relish in the means to the end? Why do we fixate on the end and berate ourselves for not being there sooner?

If we weren’t so attached then maybe the means would be as rewarding as the end. If we looked for and tolerated only perfect fits, we wouldn’t waste our time on the wrong stuff. If we took the effort to scope our projects and focus on one thing at a time, we’d get the right stuff done. If we saw the pieces as parts of the whole, maybe we’d have more perspective.

Maybe leadership could actually be as therapeutic as a jigsaw puzzle.

Elizabeth J. Agnew, MS, ACC
Integrative Leadership Strategies
415-401-7822
liz@integrative-leadership.com
www.integrative-leadership.com
P.O. Box 460515, San Francisco, CA 94110

------------------------------------------------------------------------
Liz works with individuals and organizations in technical fields needing tailored leadership development that speaks their language. Liz has logged hundreds of hours coaching individuals from companies such as Jet Propulsion Laboratories, Google, HP, SETI, Lockheed Martin, VNUS and Sun Microsystems. Her background includes experience in adult education, team facilitation, and public speaking. She offers complimentary coaching consultations – call or email today to schedule yours.

Avoiding Stone Age Practices in the Age of the Internet [Kimberly Wiefling]

2011-05-17T09:01:00.000-07:00

Albert Einstein has been widely quoted as saying “There are two things that are infinite, the universe, and human stupidity – and I’m not sure about the universe.” Like most people, I usually write this off as an amusing, sarcastic quip he made on a bad day. I mean, it can't possibly be taken literally, right?

Then I wander across a news item or business situation that make me wonder if maybe he was on to something. In spite of common sense, again and again I encounter companies repeating tragically avoidable mistakes, hamstringing themselves with the same ludicrous errors their competitors (fortunately) are also making.

Abandon Hope, All Ye Who Enter Here

Although Steven McConnell clearly mapped out a step-by-step recipe for successful software product development projects over a decade ago in “Software Project Survival Guide – How to Be Sure Your First Important Project Isn’t Your Last”, a surprising level of ignorance seems to prevail in some software development organizations. Here are a few real-world examples that I have encountered in the past year:

· In spite of the availability of free bug tracking software like Bugzilla, one software organization that has been in business for over a decade still didn’t have a bug tracking system. No, I’m not kidding.
· Another, similar decade-old organization pushed changes in the source code directly to the live production server, upon which their customers depended. Really, they did this.
· One software product development team in a Fortune 100 company reported that their schedule had slipped due to the fact that, during the quality testing phase, they’d unexpectedly found bugs that needed to be fixed before shipment. Yes, unexpectedly.

Using one of my favorite thinking tools, called API (Assumption of Positive Intent), I searched my mind for an explanation of why smart, well-educated, experienced people would behave in such seemingly less-than-brilliant ways. I’m sorry to be negative, but I came up empty at that particular moment. Stick with me – by the end of the article all shall be revealed. But until then, more mayhem!

We Can Send a Man to the Moon, and Yet . . .
The widespread availability of inexpensive, even free, internet-based collaboration tools has made working with people scattered around the planet relatively easy compared to even a few years ago. (In the not-so-distant past I was sending memory sticks of big files to Japan through the physical mail!) Today, wikis, Skype, and shared document services such as Sharefile, Dropbox or Box.net have given even small companies like mine the ability to do business around the globe almost effortlessly – at least from an IT standpoint. And yet I’m personally aware of large, so-called global businesses that are still hampered by the following:

· No ability to videoconference from work (although Skyping from a nearby Starbuck’s is a no problem!).
· No storage location where a file can be stored, where every employee in the world can access it (but placing it unofficially on Dropbox is easy as pie!).
· No cross-divisional team collaboration website that can serve as a project dashboard, collaboration space, and team memory for projects (but for $100 you can set up one heck of a collaboration system on sites.google.com).

Naturally my suggestions to explore using commonly available tools like Google Sites (Google’s version of a wiki), Skype (free videoconferencing), and cloud file storage tools are met with the standard retort: “Our IT group won’t let us use that due to security issues.” Point well taken. Security is certainly a valid consideration. But so is getting our work done, eh? And if email were invented today, I am quite sure it would be forbidden by IT departments worldwide due to similar concerns, as would credit cards (they track everything we do!) and cell phones (and they know where we are!).

Any one of these 21st century super-cool tools won’t necessarily work for a particular environment, but it’s up to the project manager and the IT people to work together to figure out what will work. The question we should be asking is “What WILL make it possible to efficiently, effectively, and securely share files, documents, and other critical project information in today’s global business environment?” I’m truly stymied by encountering the brick wall of “It’s not possible.” year after year with various clients. No worries, I’m not tired, and I’m not giving up, I’m just puzzled. Perhaps I’ll be deluged by responses full of cautionary notes, but I personally would prefer an onslaught of email answering the question “What would make it possible?”

Tortured by the Demons of Excessive Workload and Aversion to Planning

As I write it’s starting to dawn on me that stupidity can’t possibly be the explanation for the bewildering examples of worst practices above. But what is at the root of all of this, or at least the largest of the many tendrils?

Last time I checked everyone I know who had a job was more overworked than ever, with at least a half-dozen important tasks or projects on their plate at once, all of which were prioritized either HOT, VERY HOT, RED HOT, or DO IT NOW! The necessity of taking the time to plan - not just what we do, but how we do it - has been understandably put on the backburner. If you haven’t read Chapter 5 of my Scrappy Project Management book recently, you might want to check out this chapter, available free on ProjectConnections.com, for more insights into this “tyranny of the urgent”.

Working faster, “doing more with less”, and the all-too-common firefighting, heroics, and diving catches can feel like an enlivening experience, even as you’re digging your own project grave. An aversion to planning is characteristic of many human beings (especially engineers), and it never feels like there’s enough time to plan. In a way it’s actually quite a relief not to have the time to do any long-term strategic thinking, especially when the world sometimes seems to be changing so rapidly that any such plans will be obsolete long before they’re implemented. We can just come in to work everyday, sort through what’s piled up in our email inbox, and respond to the crisis de jour, adrenaline coursing through our veins the whole time. Wahoo!

Corporate Culture Trumps All, and Yet is Neglected
Peter Drucker is credited with saying “Culture eats strategy for breakfast.”, meaning that if you can’t get the company culture right it won’t much matter what kind of bug-tracking software you implement, or whether you have a wiki or a place to share files. In spite of a wide array of research, books, and articles on exactly what works with millions of people worldwide, I still find that most work environments fail to implement even the most basic elements required of healthy, vibrant, work environments: corporate cultures capable of fostering and enhancing business results. (See my previous article on this topic if you want more on this rant.) The project leader is the source of culture in the immediate project environment, so we’re responsible for what Mr. Druker claims is even more high leverage than business strategy. What an awesome opportunity and responsibility! Most of the changes required to create a best-in-class culture cost absolutely nothing, except the time to plan and implement practices such as:

· Making sure that everyone who’s working together gets to know each other face-to-face
· Making sure each individual knows what’s expected of them, and has the tools and skills to do it.
· Providing a clear line-of-sight from individual goals to organizational goals, mission, and purpose.

But we’re all still burdened with the fact that we’re human beings, and our nature is to succumb to the overwhelm of extremely demanding work environments. Even I need a reminder now and then that I’m venturing far outside the zone of common sense. Let’s help each other stay out of that well-traveled area, shall we? Make a pact with your teammates early in the project that you’ll raise a red flag when reason recedes.

A Beacon of Light in the Darkness

My friend and former colleague Jateen Parekh is the founder and CTO of Jelli, a company that’s re-inventing radio. I heard him give a talk recently where he shared what he’d learned on the journey from being an engineer to a company founder, people leader, and business manager. He’s a dyed-in-the-wool technologist by background, passion, and profession, and yet in his role as the leader of a very techno-centric company he’s embraced pretty much every one of the business management, process excellence, and people-focused practices referred to above.

Listening to Jateen reminded me that working ON the business – on the WAY we conduct ourselves while doing business - is just as important as working IN the business, especially when it is OUR business. Ignoring best practices proven to work better than chaos, lacking discipline to follow processes that we know make sense, pretending common sense doesn’t apply to our work environment because “our business is different” … these choices are inexcusable for today’s project managers. Surely this is one of the most important roles of a project leader. We have a responsibility to step back and question the processes and practices in use, and ask if there is a better way to achieve our business results, find answers to this question, and thoughtfully implement solutions that enjoy the buy-in, commitment, and support of all key stakeholders.

If you haven’t got time for that, then at least pause and reflect on this bit of advice from Dr. Eli Goldratt, author of—among many books—the bestseller The Goal:. “Just stop doing the stupid stuff! The rest is genius!”

Kimberly Wiefling is the author of Scrappy Project Management, currently ranked #1 on Amazon Kindle US in Total Quality Management. She splits her work time between the US and Japan.

Announcing the Next EL SIG Meeting, May 19 [Robert Lasater]

2011-05-15T21:39:00.000-07:00

The next meeting of the Engineering Leadership SIG will be held on May 19 in SAP Building 2 (3412 Hillview Avenue, Palo Alto, CA), starting at 7:00 PM. Doors open at 6:30 PM. Topic of the main presentation, Energetic Communication for Engineering Leaders, by Tia Turnbull.

Energetic Communication for Engineering Leaders

The energy of a leader is critical to generating results. How do you impact the energy of your team and other colleagues? Explore the four ways we drain energy and the four ways we lift people’s energy in communication. Become someone who lifts the energy of any environment in the first five minutes of showing up.

Whether at home or at work communication difficulties can interfere with ones ability to concentrate at the task at hand. You will have an opportunity for question and answers.

Attending this talk will help you to:

· Create more uplifting communication that builds rapport, trust, a safer environment and more effective results.

· Stay present and think clearly in the moment.

· Not have your energy drained while you are working in a draining situation with people who need your help.

· Be aware of subtle choices in communication that could be causing conflict.

· Improve listening skills.

· Stay focused, decide and take new and effective actions.

· Question assumptions and make more empowering choices.

· Confidently enter into communication to resolve any issues.

What you will learn:

· The four simple ways to drain energy that encompasses all communication problems.

· The four ways to lift energy in communication.

· The six mental entities that show up in every conversation between two people.

· The most powerful and rewarding way to really listen to what someone else is saying.

· A quick script using non-violent communication that can help you to take responsibility and resolve communication issues quickly.

Learning these skills will help you to:

· Create more uplifting communication that builds rapport, trust, a safer environment and more effective results.

· Stay present and think clearly in the moment.

· Not have your energy drained while you are working in a draining situation with people who need your help.

· Be aware of subtle choices in communication that could be causing conflict.

· Improve listening skills.

· Stay focused, decide and take new and effective actions.

· Question assumptions and make more empowering choices.

Learn a quick process to help people to question assumptions and make more empowering choices.

Tia Turnbull is a professional life coach who has worked with thousands of people to help them get where they want to be in their lives. Today she will be presenting Energetic Environments. Communication tools and skills for empowering yourself while lifting others. How particular communication choices can lead you away from your goals with your clients, and in any relationship, and how to make choices that have you get what you want more often.

Cost: $20 at the door for non-SDForum members, No charge for SDForum members

BOOK SWAP - Every month! Bring books to share.

JOB SWAP - Check out our Yahoo! Group here: http://tech.groups.yahoo.com/group/SDForum_EL_SIG_JobSwap/

PEER-to-PEER Roundtable - Every month! Join us to share insights and advice with peers each month prior to the 7 PM event.

BLOG Write or read EL SIG blog posts here: http://sdforumelsig.blogspot.com/

For more information, go here.

SNACK & BEVERAGE SPONSOR: LongView International is a innovative Silicon Valley consulting company specializing in semantic technology and software architecture. Together with our clients we achieve success through understanding business goals, formulating the strategy to execution, and building the right solution.

PROJECT CONNECTIONS ONGOING MANAGEMENT SPONSOR: Project Connections is our EL SIG Management Sponsor. ProjectConnections.com is dedicated to practically and affordably supporting individuals as they do their jobs day-to-day and helping them grow their management abilities and careers. We also provide management development and support resources to organizations, through group subscriptions, methodology content licenses, on-demand virtual training programs, virtual coaching, and more - all to help managers improve how critical project work gets done, and to help grow the capabilities of everyone on their staffs and teams.

April 21 Meeting Notes - Product Management [Robert Lasater]

2011-05-05T22:09:00.000-07:00

The April 21 meeting of the Engineering Leadership SIG of the SD Forum featured a talk on Product Management by Rich Mironov. His presentation was outstanding, one of the best I have seen at an Engineering Leadership SIG event. Here is a summary of Mironov’s talk.

Overview of Product Managment

Mironov began by stating Product Management engages in four areas:
· Product
· People and Organization
· Process
· Technical Knowledge

and an effective Product Manager must have some knowledge and background in all four areas.

Before proceeding further with his actual talk, Mironov asked the audience to take a few minutes and list some good and some bad experiences with Product Management.

Examples from the audience of good experiences with Product Management:
· Focus
· Good technical knowledge
· Made decisive product decisions
· Infectious enthusiasm
· Good financial analysis
· Voice of the customer

Examples of bad experiences:
· No business plan
· Senior management undercut product management
· Undefined product management role
· Threw specification over the fence
· Feature du jour
· Old product preconception
· Product management thinks they have good technical knowledge
· “I know what the customer wants.”
· No view of competitive product

Not all bad experiences were the result of product management.

What Does a Product Manger Do?
· Drives delivery and market acceptance
· Targets market segments, not individual customers
· Resolves competing priorities
· Drives acceptance and adaptation
· Makes money
· Even internal projects need to have willing customers

How Does Product Management Interact with the Rest of the Organization?

Product Management works with:
· Developers
· Executives
· Marketing and Sales – more broadly, markets and customers.

Product Management provides some specific inputs to developers:
· Market information
· Priorities
· Requirements
· User stories
· Roadmaps

And the developers provide Product Management a working product.

Product Management provides a different set of inputs to marketing and sales:
· Segments
· Benefits and features
· Prices
· Qualification
· Demonstrations

And Marketing and Sales provides Product Management with field input and market feedback.

It is essential for product managers to talk with actual customers. Ideally, one-third of their time they should be engaged with customers. A more realistic goal is one-fifth of their time with customers.

Product Management provides a third set of inputs to executives:
· Strategy
· Forecasts
· Competitive intelligence

And the executive team provides Product Management a Yes/No decision on a particular product or project, along with budgets, staffing and funding.

Mironov noted engineers become product managers as a path to becoming part of the senior executive team.

Planning Horizons and the Agile SW Process

From the Agile framework comes the hierarchy Daily – Sprint – Release – Product portfolio – Strategy. Product managers start in the center of this hierarchy – Release and Product Portfolio – but will find themselves from time to time engaged at all levels of the hierarchy.

The Nature of Product Management’s Role

There is no rational sequence for Product Management.
· All aspects must be worked in parallel.
· It is interrupt driven.
· Bottom-up shapes top-down and top-down shapes bottoms-up.
· Product Management must provide strategy, judgment and integration as well as execution.
· Every Product Manager should spend a significant amount of time with customers.

Good Product Managers drive decisions despite uncertainties and contradictory goals.

Since Product Management is a collection of people-related skills, it requires mentoring; difficult to get it on your own without strong role models. And one the most valuable aspects of Mironov’s presentation was his emphasis on how Product Management can fail. Knowing what can go wrong can be much more helpful than merely learning about successes.

Example Product Management Failure Modes

The first set of examples show how a Product Manager can fail when working with an Agile team:
· Product Manager only works part-time on Product Management.
· Lack of detail on stories (e.g. why the product is superior, or what are customers looking for in the product line)
· Hand waving and bluster.
· Best of intentions but pulled in too many directions
· “Build what I meant”
The second set of examples show how a Product Manager can fail in the market:
· Weak on the real world – pricing, discounts, upgrades and packaging
· Disconnected from other teams.
· Belief in rational users
· Trade off company-wide product strategy for product level features.
· Assume a few customers represent the market.

Mironov closed on a very positive theme, how you can help Product Management.

Seven Ways to Help Product Management
· Ask about Use Cases and customer problems
· Do not demand that Product Managers be as technical as engineers.
· Not every user story becomes a feature
· Expect Product Managers to translate features into customer-relevant benefits
· Ask about forecasts, shipments and revenue
· Quietly sit in on some customer meetings
· Channel your Inner Product Manager

Project Leadership Lessons from a Heart-wrenching Tragedy [Kimberly Wiefling]

2011-05-02T20:42:00.000-07:00

As you may know, Kimberly Wiefling has extensive business and personal contacts in Japan. Here she discusses her reaction to the recent earthquake and tsunami disaster, and finds some lessons for product management and engineering leadership.

Pardon me if I’m not my normally humorous self. I’m obsessing on disaster these days after the recent quake, tsunami, and nuclear power plant tragedies in Japan. While there have been plenty of tragedies in the past that could have consumed my emotional bandwidth (see the complete list on Wikipedia if you don’t already feel like self-medicating with tequila), this is much more personal. Just about every month for the last five years I’ve flown to Japan to work for a couple of weeks. From my home in the Silicon Valley, Japan seemed a long way off. Until now, that is.

On March 11 at 4:00 AM the iPhone on my bed table rang. It was my dad calling from my parents' home in Florida. “Get up! Your friends are in trouble.” he said. I don’t know what he thought I could do about a natural disaster occurring over 5,000 miles away, but that’s my dad -- no matter how dire the circumstances, he always thinks there’s something a person can do to make a positive difference.

Through my work with global Japanese companies I’ve met thousands of people who live in Japan. Many I consider friends, and some are as precious to me as my dear ol’ dad. I had just returned from Asia two days ago, and I was in Tokyo only five days before the quake struck. So up I got, and immediately scoured the internet for news from Nippon. Needless to say, what I saw was tragic beyond comprehension.

As the disaster unfolded before my eyes, I watched a tsunami wash away an entire village. At that moment, any illusion of separateness I may have felt was washed away with that village and those lives. This was not an event that I perceived as happening to “strangers,” people distant from me. No, at that moment, with so many ties to people living in Japan, I strongly felt that this was happening to “us.”

Shared Pain Focuses the Mind

Immediately I felt an overwhelming urge to help. Figuring out how to help took a while, but there was no question that I needed to be a part of the solution. I could fill this article with the personal stories of people I know, and how they are carrying on in the face of a continuing series of threats and disasters, but there are plenty of places you can read about that. Instead, let’s honor the memory of those who have suffered and died by exploring what this experience can teach us about being better project leaders. I’ve boiled it down to the following three insights for starters, though there are surely more lessons to be learned:

· “We-centric thinking” clarifies the goal and focuses people on finding solutions.
· The human mind has a limited ability to imagine risks. There is no bottom to “worse.”
· “Possibility thinking” is effective even in tragic and seemingly impossible situations.

Crisis Creates Clarity

The moment I grasped the situation in Japan (thanks to horrifyingly vivid videos on the web and graphic descriptions of events from my friends living there), I was immediately willing to do whatever necessary. The overarching goal was so clear, and the need so immediate and compelling, that I was willing to do whatever I could to help. I started contacting people on both sides of the Pacific to see what could be done, and so did many others. Perhaps most inspiringly, the people of Japan reached out to help each other with a depth of compassion and selflessness that left the world in awe. One American woman living near the affected region wrote us that, in this time of food shortages, she returns home each night to find that someone has left food on her doorstep. Heck, after forgetting to pack my lunch for a recent university alumni picnic, I sat, foodless, with a couple who never even offered me so much as an olive.

Imagine if everyone involved in a challenging project first and foremost had an attitude of “What can I do to help?” What if each of the people involved on your project – teammates, sponsors, executives, suppliers, and customers – brought that attitude to every meeting and discussion? Don’t get me wrong, I believe that most people intend to help, even if that intention is buried deep within their psyche. But it gets obscured by time pressures, differing perceptions of the goals, and competition for resources, not to mention pride, turf wars, and ego.

Over the years I’ve noticed a sort of fragmentation that occurs in some project ecosystems that can be summed up as “us vs. them.” In stressful project environments (which is basically all of them, but who's counting?) I’ve noticed a variety of different schisms:

· Our company vs. the customer
· Our project team vs. the execs
· Me vs. “the others”

When I facilitate team effectiveness workshops, I sometimes divide the participants into two groups and locate them in opposite corners of the room, giving both groups the same instructions: get the other group to come to their corner of the room. Then I sit back and watch. Even when the entire group is comprised of people from the same company, even the same division – people who know each other, for crying out loud – successfully completing the task by simply having the groups switch positions is a solution that eludes them for as long as 23 minutes. (Yes, that’s the world record, but I’m sworn to secrecy which company it was.) Separating people by as little as 4 meters is enough to cause the “us vs. them” syndrome.

On projects, as long as the illusion of separateness persists we can find ourselves working at cross-purposes with the very people needed to achieve the project goals. When instead we view ourselves as “we,” we’re unencumbered by the obstacles of ego, hierarchy and competition. Adrift on the same iceberg, we’re instantly united in helping each other find solutions that enable us to step safely onto the shore of success. When we create this sense of unity among the various stakeholders in our projects (ideally without the presence of an external hazard, natural or man-made) we get everyone involved and focused on making a positive difference.

There Is No Bottom to Worse

In view of the fact that multiple layers of backup systems failed in the Fukushima nuclear power plants, I’m of the opinion that human beings have no imagination for disaster.

In “Scrappy Business Contingency Planning” the author (and my friend), Michael Seese, admonishes those doing disaster planning not to focus on what kind of disaster might interrupt power – only on what to do when that power is interrupted, as it will surely be. Michael has a talent for gloom and doom thinking, but I doubt that even he could have imagined all of the ways things could go badly wrong at the power plants. When I asked him to comment on the unfolding nuclear nightmare he said “In some sense, I see the Japanese response to the events at Fukushima as being like our Y2K preparation efforts. I worked on several Y2K remediation projects. I couldn't help but smile when – after the clock struck midnight and our world didn't grind to a halt – people said, "Nothing happened! Look at all that money that was wasted." Of course, nothing happened – because we spent that time, effort, and money. It's the same thing in Japan. Who could say what would have happened had they not pumped in sea water, and dumped more water in by helicopter?

One takeaway from this disaster is that business contingency plans need to tested, and re-tested. Of course, it's not practical to test a nuclear meltdown. But hopefully the lessons learned at Fukushima Daiichi will enable Japan – and other countries – to make their nuclear power plants safer.”

Yes, let’s all hope so. I know some people think “dilution is the solution to pollution”; our vast oceans can only absorb so much radioactivity.
The human mind has a limited ability to imagine risk. Even in Japan, where risk aversion, attention detail, and avoidance of failure are legendary (almost a national pastime), engineers failed to imagine the recent catastrophic string of events and design around them. In my experience, no amount of risk assessment and planning captures all possibilities. Things can always be worse than we imagined.

The Best Is Always Yet to Come

“We are continually faced with a series of great opportunities brilliantly disguised as insoluble problems.” John W. Gardner, US administrator (1912 - 2002)

Faced with the choice to either give up hope or trudge on in a hopeless cause, I'm prone to choose trudging. Why? Because if I’ve learned anything in 20 years of leading, and working on, all kinds of projects with varying degrees of impossibility, it’s that human beings – myself included – are notoriously poor judges of when something is hopeless.

Even in the most dire circumstances, asking “What does this make possible that wasn’t possible before?” helps open the mind to creative ideas and breakthrough thinking. I’ve been pondering this in relationship to the quake/tsunami/nuclear triple tragedy, and so far I’ve come up with a few possibilities:

This will bring the world closer to Japan. People all over the world have voiced their admiration of the dignity, compassion and selflessness of the people of Japan. My friends in Japan are a bit amused by how much attention the press is giving to the headline “There’s no looting!” To them, they can’t imagine why anyone would loot. While some cynics say it’s just that negative events aren’t being reported, I disagree. I can personally testify to getting my wallet back with over 30,000 yen in it after leaving it in a Tokyo taxi. The driver delivered it to my hotel for free, left it at the front desk, and it was returned to me the next morning.

This will bring Japan closer to their neighbors. After years of icy relationships, Korea and China sent help to Japan . . . and Japan accepted.

This will bring the people of Japan closer to each other. Disasters have a way of recalibrating us about what’s important. In a country where avoiding risk is almost a national pastime, living with the daily threat of aftershocks and longer-term consequences of nuclear contamination are likely to shift thinking about risk. Now that daily life is risky, perhaps other kinds of risk-taking, like innovation and breakthrough thinking, won’t seem quite as dangerous by comparison. As Helen Keller said, “Avoiding danger is no safer in the long run than outright exposure. The fearful are caught as often as the bold.”

I think it’s pretty safe to say that any project you or I may be working on can’t be nearly as dreadful as the situation unfolding in Japan. Consequently, I’m quite certain that we can find some “great opportunities brilliantly disguised as insoluble problems” in whatever project currently stymies us. Even if it’s true that the situation is hopeless, the illusion that we can make a difference can inspire us to build capabilities that make the next situation less so. There are advantages to leading your team as if the best is yet to come while dealing with the current reality. Jim Collins labeled this “The Stockdale Paradox”:

“You must never confuse faith that you will prevail in the end—which you can never afford to lose—with the discipline to confront the most brutal facts of your current reality, whatever they might be.” - Rear Admiral James B. Stockdale

The New Normal

Some of my colleagues at ALC Education in Tokyo slept on the 19th floor of their office building the night of the quake as they waited for trains to resume operation. Others – parents with stranded children – walked for six hours or more to get home to them. In the weeks that followed they weathered power shortages, devastating news of the missing and the dead, and ongoing scares from aftershocks and radiation. Through it all the people of Japan are inspiring the entire world through their stunning examples of selflessness and compassion—two ingredients that I feel quite sure I can use to improve my next project. I hope we’ll all emerge committed to applying these and the other lessons learned to our projects and our lives as life on Earth returns to the “new normal.”

If you’d like to donate to the Japan Relief Fund, one option is through the American Red Cross:
https://american.redcross.org/site/SPageServer?pagename=ntld_main

Kimberly Wiefling is the author of Scrappy Project Management, one of the top-ranked project management books on Amazon in the US, published in Japanese, and growing in popularity around the world. She splits her work time between the US and Japan.

Announcing the Next EL SIG Meeting, Apr 21 [Robert Lasater]

2011-04-05T12:47:00.000-07:00

The next meeting of the Engineering Leadership SIG will be held on April 21 in SAP Building 2 (3412 Hillview Avenue, Palo Alto, CA), starting at 7:00 PM. Doors open at 6:30 PM. Topic of the main presentation, How can we (Engineering) work better with our Product Managers -- and what do Product Managers do, anyway?, by Rich Mironov.

TITLE: How can we (Engineering) work better with our Product Managers -- and what do Product Managers do, anyway

Product Management is a poorly understood role that varies widely between companies. In addition, technical teams see only one part of the product management challenge: critical interactions with sales/marketing and executives are not visible to them. In this talk our speaker will outline the product management role, how it fits with engineering (including agile teams), and ways that engineering and PM can help each other to get great products to market.

SPEAKER: Rich Mironov http://www.mironov.com/

Rich Mironov is a serial entrepreneur, seasoned VP Product Management/ VP Marketing, go-to-market strategist and agile “product guy”. He's currently CEO of a stealth startup, and is a veteran of four earlier software tech start-ups and dozens of consulting engagements.

Rich earned his software stripes writing COBOL at HP, then spent six years in product management at Tandem Computers, launching the company’s first TCP/IP stack. At Sybase, he oversaw database connectivity to more than 40 operating systems, and shipped the first commercial solution for dynamic linking of web pages with databases (web.sql). He was the first “product guy” at four networking-related start-ups, including iPass (NASDAQ: IPAS) and AirMagnet (acquired by Flunk Networks), where he was VP Marketing/Product Management. From 2007 to 2009, he was CMO of Enthiosys, an agile product management consultancy.

Rich’s 2008 book, “The Art of Product Management” captures the best of his Product Bytes blog (2001 to 2008), and represents the scrappy entrepreneur in all of us. Rich serves on the board of SVPMA, has taught in Haas’ executive education program, and produced (chaired) the product manager/product owner track for Agile Alliance’s 2009 and 2010 conferences.

Rich has a BS Physics from Yale with a thesis on dinosaur extinction theories, and an MBA from Stanford.

Cost: $20 at the door for non-SDForum members, No charge for SDForum members

BOOK SWAP - Every month! Bring books to share.

JOB SWAP - Check out our Yahoo! Group here: http://tech.groups.yahoo.com/group/SDForum_EL_SIG_JobSwap/

PEER-to-PEER Roundtable - Every month! Join us to share insights and advice with peers each month prior to the 7 PM event.

For more information, go here.

Announcing the Next EL SIG Meeting, Mar 17 [Robert Lasater]

2011-03-15T21:16:00.000-07:00

The next meeting of the Engineering Leadership SIG will be held on March 17 in SAP Building 2 (3412 Hillview Avenue, Palo Alto, CA), starting at 7:00 PM. Doors open at 6:30 PM. Topic of the main presentation, The Human Dimension in Leadership to Fast, Effective and Scalable Product Development, by Corinne Rattay.

Time: March 17, 2011 | 6:30 PM - 9:00 PM
Place: SAP - Baltic/Caribbean rooms in Building 2 (NEW BUILDING THIS YEAR!)
3412 Hillview Avenue
Palo Alto, CA 94304

Topic: The Human Dimension in Leadership to Fast, Effective and Scalable Product Development

Most Engineering teams never get a chance to show their full potential. Leaders in fast-growing companies have learned to accept average team results, day-to-day stress and constant last-minute surprises in their deadline struggles. Why is this the way most high-tech companies approach software or product development? Why live with organizational tension and eventual team burnout when there are proven ways to get better products out faster and create a culture of happy teams? In this interactive and stimulating talk, engineering leaders at all levels will experience a paradigm shift in their level of thinking, which is the first step towards needed transformational change in R&D organizations so they can scale from successful start-ups to efficient, mature, market-leading companies. Corinne Rattay is an expert in R&D Transformation leveraging her engineering leadership experience at Juniper Networks. She will share exciting, personal insights and experiences she has gained in over a decade as engineering leader and director, explaining the crucial foundation of the human dimension in leadership combined with key product lifecycle processes that truly work.

About the Speaker

Corinne Rattay is an accomplished, passionate and thought-stimulating executive with 15 years of success in engineering leadership, product development, global team building & remote team management, off-shoring, business coaching and management consulting.

She has gained a well-rounded industry experience at Juniper Networks, Alcatel France and successful start-up companies holding positions such as Director of Engineering, Director of System Test & Product Validation, Product Manager, Program Management, Process Design, and reaching all the way to hands-on customer field trials, System Integration, real-time Software Development & radio frequency Microchip Design.

As a Breakthrough Leadership Consultant she helps high-tech executives achieve extraordinary results with:
- Product Development, overcoming barriers to innovation, better products, faster cycles
- Change Acceleration, shifting paradigms and beliefs to create new possibilities
- Leadership Transformation, elevating the client's thinking quality and leadership focus

Corinne Rattay has written for our blog.

She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com

Agenda
6:30 - 7:00 Registration, Free wine, beer, snacks, pizza, soda and networking
6:31 - 6:59 Engineering Leadership Roundtable (New and Expanded!)
7:00 - 7:10 Introduction and brief announcements
7:10 - 8:20 Keynote and Q&A
8:20 - 8:30 Other announcements (next month's topic & speaker, jobs, blogs ...)
8:30 - 8:45 Informal networking
8:45 - 8:50 Clean up and have a safe trip home!

COOL FEATURES OF OUR EVENTS AND SIG:
• BOOK SWAP - Every month! Bring books to share.
• JOB SWAP - Check out our Yahoo! Group here: http://tech.groups.yahoo.com/group/SDForum_EL_SIG_JobSwap/
• PEER-to-PEER Roundtable - Every month! Join us to share insights and advice with peers each month prior to the 7 PM event.
• BLOG: Write or read EL SIG blog posts here: http://sdforumelsig.blogspot.com/

Snack and Beverage Sponsor: Matt Perez of Nearsoft
ONGOING MANAGEMENT SPONSOR: Project Connections is our EL SIG Management Sponsor.
Location: SAP -Baltic/Caribbean rooms in Building 2
3412 Hillview Avenue
Palo Alto, CA 94304

Cost:
$20 at the door for non-SDForum members
No charge for SDForum members

For more information, go here.

February 17 Meeting Notes [Robert Lasater]

2011-02-28T21:48:00.000-08:00

On February 17, 2011, the Engineering Leadership SIG of the SD Forum met at SAP headquarters in Palo Alto, California. Featured was a presentation, “Keys to Collaborative Leadership”, given by Mark Voorsanger and Liz Agnew. Both are Certified Coaches.

The presentation was organized as a meal in a fine restaurant, with three “courses”, an appetizer, a main dish and dessert. Each “course” came with a challenge and a goal. The first part, an introduction, was designed to whet the audience’s appetite. The overall goal of the presentation was to inspire new thinking.

Mark V acknowledged that “collaborative leadership” might seem to be an oxymoron, and responded with a quote from Albert Einstein: “if an idea is not absurd, it is not worth pursuing.”

Whetting Your Appetite

To demonstrate the need for collaborative leadership, Mark V quoted two sets of statistics from a recent survey of American employees. The first divided employees into three groups:

Engaged 29%
Not Engaged 54%
Actively disengaged 17%

They then asked the participants in the survey if their current job brings out my most creative ideas. The results were broken down among the three categories:

Engaged 59%
Not Engaged 17%
Actively disengaged 3%

Not surprisingly, most of those who were not engaged or actively disengaged felt their job did not bring out their most creative ideas.

Now the current paradigm for leadership is Hierarchy. Decisions are made at the top. The currencies are power and authority. Mark V characterized hierarchy as working well when:
· People at the top have all required information.
· People being managed are doing rote tasks.
· People being managed are easily replaced

This of course does not characterized modern engineering organizations. Mark V though did stress that hierarchy has its place, especially when decisions need to be made quickly.

At this point, Mark V asked the audience to participate in an exercise. Gather in small groups and discuss how ineffective collaboration is costing you and your organization. Afterwards, several members of the audience shared their responses. They included:
· If you don’t do it my way, you are not collaborating
· Decisions are made without adequate information.
· Software is not reusable.
· There is no safe environment for unusual ideas.

Appetizer: Defining Key Terms

Challenge: No common language
Goal: Define key terms for a collaborative process

Mark V spent several minutes defining some key terms.

Collaboration: All relevant stakeholders have ownership and alignment around what we are going to do and how we are going to do it.

Relevant Stakeholder:
· People with the power to make a decision.
· People with the power to block a decision.
· People affected by a decision
· People with relevant information and expertise.

Ownership: the extent to which people feel or believe that a process, decision or outcome is theirs.

Alignment: The extent to which people see and understand a problem or decision.

Here is a metaphor for ownership vs. alignment:
Ownership: get everyone on the boat.
Alignment: get everyone rowing in the same direction.

And he provided this insight regarding Content vs Process: Content gets attention; process, not so much. Content is What; process is How.

And finally: a Collaborative Leader is someone who leads according to the principle of ownership and alignment.

Regarding introducing the principles of Collaborative Leadership, Mark V pointed out that one needs to be careful with change. Organizations tend to reject change the way one’s immune system rejects a foreign microbe. A suggestion: think small.

Main Dish: Problem Solving Template

Challenge: No common process
Goal: find a common process

A Problem is any situation that you want to change.

There are three obstacles to solving problems:

1. Groups don’t know how to (or don’t even think to) align around the problem that they want to solve. No agreement on the problem = No agreement on the solution + infinite arguing about solutions

2. Groups use implicit processes to do their work. Collaborative problem solving relies on explicit win/win processes.

3. People solve problems iteratively – so that nothing is transparent.

Mark V presented a structured process with a 5-step problem solving template
1. Context (what effect is the problem having; what happens if it is not addressed?)
2. Problem statement – a one sentence statement
3. Intent
4. Desired outcomes
5. Action plan

Mark V cautioned against “baking a solution” into the statement or intent. And one should build ownership and alignment at each step.

Finally there is the question of time. One of the advantages of hierarchical decision making is it is faster; collaborative problem solving takes longer. So it is necessary to concede that hierarchical decision making sometimes is required. But beware of creating a false sense of crisis. This will only work a limited number of times.

At this point, Mark V opened the floor for questions.

Q: How do you deal with the fact that not all stakeholders are equal?
A: Those who are less important are gently and politely informed of this.

Q: How do you avoid “baking the solution” into the problem statement?
A: By actively blocking these attempts. By reminding everyone of the importance of ownership and alignment.

Dessert: The Number One Missing Ingredient in Meetings

Challenge: Unproductive meetings
Goal: More productive meetings

The number one missing ingredient in meetings is the Process – the How. Make it explicit.

One final question:

Q: How to decide on decisions without a hierarchy
A: Some suggestions:
· Vote
· Consensus
· Unanimous consent
Be explicit about the process.

Mark Voorsanger is the Founder of Skyward Coaching (www.SkywardCoaching.com), 415-606-2101. His emal address is Mark@SkywardCoaching.com

Liz Agnew is president of Integrative Leadership Strategies (www.Integrative-Leadership.com), 415.401.7822. Her email address is: liz@integrative-leadership.com

---------------------------------------------------------------
Robert Lasater maintains this blog for the Engineering Leadership Special Interest Group of the SD Forum.

One’s Feminine Side Can Still Hurt One’s Career [Robert Lasater]

2011-02-21T20:01:00.000-08:00

A few months ago, Kimberly Wiefling wrote about the advantages a woman’s feminine side can bring to the workplace. Unfortunately a recent study shows those same characteristics can hurt a woman starting her career.

Before proceeding, some background is helpful. When someone receives a PhD in the sciences or mathematics, a typical next step is to take a post-doctorate, a one or two year assignment, a chance to continue research and get work published. Often one takes two or three of these temporary positions before starting a (presumably) more permanent position in the academy or industry. And key to this process are the letters of recommendation, from one’s PhD advisor or post-doctorate supervisor, or other professional mentors.

Recently Professors Randi Martin and Michelle Hebl of my alma mater, Rice University, reviewed several hundred of these letters of recommendation, written for both men and women candidates. They found the ones for men typically described the candidate using terms such as “confident”, “aggressive” and “daring”, while the letters for women uses terms such as “affectionate”, “nurturing” and “tactful” – the kinds of qualities Kimberly point out add value in the engineering workplace.

And when they took their collection of letters, took out names and personal pronouns (“he”, “she”, etc.), and then asked other faculty members to evaluate the (now anonymous) candidates, those written for men got significantly better rankings than the ones written for women. The candidates described as “confident”, “aggressive” and “daring” were more likely to be hired than those described as “affectionate”, “nurturing” and “tactful”. This despite the fact they had taken out all references to gender, and had insured the candidates described with feminine qualities had as much professional success - papers published, lead author, recognition and awards – as those described with masculine qualities.

It is unfortunate that the quick lesson from this work is likely to be to suppress terms like affectionate, nurturing and tactful, even though such people – men and women both – help make the workplace a less contentious and more productive place. But women too can be confident, aggressive and daring, and mentors do need to look for these qualities in the women they are guiding and advising.

I just want to add that in the sciences and mathematics, the most important qualities one looks for are originality and – yes it is masculine – daring. They describe Richard Feynman – and Barbara McClintock, who eventually won the Nobel Prize for her work in genetics. Oh, and persistence. It took 30 years for the scientific community to recognize the importance of McClintock’s work.

---------------------------------------------------------------------

Robert Lasater maintains this blog for the Engineering Leadership Special Interest Group of the SD Forum.

Announcing the Next EL SIG Meeting, Feb 17 [Robert Lasater]

2011-02-05T09:14:00.000-08:00

The next meeting of the Engineering Leadership SIG will be held on February 17 in SAP Building 2 (3412 Hillview Avenue, Palo Alto, CA), starting at 7:00 PM. Doors open at 6:30 PM.

TITLE: The Keys to Collaborative Leadership

SPEAKERS: Mark Voorsanger and Elizabeth Agnew

About the Speakers:

Mark Voorsanger is an executive coach and consultant with over 25 years working with and managing high technology teams. His experience as a business entrepreneur, senior corporate manager overseeing globally distributed production units, and executive coach and consultant focusing on leadership development and collaboration make him uniquely qualified to work with leaders in high tech.

As the founder of Skyward Coaching, Mark brings the COS and his collaborative facilitation skills to literally every client engagement, from individual coaching to the facilitation of corporate strategic planning. Mark's client list includes Electronic Arts, Sega, DreamWorks, CompuShare and Kaiser Permanente.

Liz Agnew is a certified coach specializing in leadership development and collaboration. Liz earned a bachelor's degree in engineering from Cornell University and a master's degree from Stanford. As president of Integrative Leadership Strategies, LLC, Liz's mission is to bring the world together by making the workplace a sanctuary for learning and truth. She transforms one team at a time, teaching them to work transparently and heal the pain of poor work relationships. Liz's previous clients include Genentech, Hewlett Packard, The City of Atlanta, Sun Microsystems, Lockheed Martin, and Jet Propulsion Laboratories.

Liz Agnew has written previously for our blog.

Details of talk:

Nearly every organization we know operates according to some version of the hierarchical system, which uses power and authority to accomplish things.

Although many have attempted to democratize their workplace by getting “flatter” and working in teams, power and authority remain the primary “currency” being traded. If you can accumulate enough power and authority in a hierarchical system, you can “win.” But as we know, a hierarchy concentrates power and authority in a few people at the very top. This prevents the rest of the organization from having the currency required to solve problems and accomplish goals. It makes working across the silos nearly impossible. And it makes the “leader” with the most power and authority essential.

Moreover, the degree of complexity in today’s fast-moving, global marketplace is simply beyond the capacity of the hierarchical approach. The interdependent, multi-faceted problems and opportunities facing leaders and organizations require a new system: one that engages workers by connecting the people with the information to those who make the decisions, and the people who make the decisions to those who implement them. The leader who can help their organizations make the journey to this new paradigm will predominate.

In this talk, Mark Voorsanger & Liz Agnew will introduce and explore the fundamental principles that drive Collaborative Leadership in organizations, principles that have the capacity to transform how we get work done. Join Mark & Liz for this fun and interactive session on The Keys to Collaborative Leadership.

For more information, including a detailed schedule, go here.

Company Wide Process Definition [Chris Bryant]

2011-01-26T13:04:00.000-08:00

So, you have a small company that has grown from a startup with nice growth over the last few years. Now suddenly you are beginning to feel like you are losing touch with what is going on. You don’t know what is happening with customers. You hear about issues but can’t track down the history of how they came up. You’ve hired several new people in various departments but they don’t know what to do and are causing problems by doing the wrong thing or aren’t getting the right things done. You absolutely need to hire a dozen new people for various departments but are afraid that you’ll just end up with more people running around not knowing what to do or spending all their time trying to find out whom to ask the right questions of.

You are questioning what customers are buying what and what the prospects are for the next quarter. However, your head of Sales and Marketing are both traveling or out sick and can’t be contacted. Your field service techs are spending all their time putting out fires instead of helping with new installations.

You are looking at absolutely needing to get your next version of a product or a new product underway but the “indispensable” person that knows how everything is put together just left for a competitor.

Any of these sound familiar? If not, they may soon…

Congratulations, your startup is successful and is now evolving from a single department into an organization with multiple departments and multiple responsibilities. How do you facilitate communications? How do you determine what’s going on? How do you avoid the trap of the indispensable” employee?

The answer is complex but primarily involves determining how your company operates. In one word: PROCESS

Many view process as a straight jacket that large companies use to inhibit free thinking and keep the company from changing. It’s the primary source of red tape to keep things running in well worn ruts. Unfortunately this is true in many companies.

Process is neither an end product nor a tool. It is a skeleton used to facilitate communication and capture of critical company information. It is the framework on which tools and company interactions are hung. It should never be an inhibitor and must always be an enabler. It needs to be constantly reviewed and adapted as your company changes.

A company process is by no means simple. At the highest view it should be simple enough to be contained on a single sheet of paper. This would be a company model that shows clearly what your customer and supplier interactions are and who and when communication occurs. This outlines the scope of the company and how its products and/or services are created, sold, delivered and serviced. This really involves creating a model of the company. This should never be an “ideal” model as it must reflect how things are really done instead of how they should be done. However, while creating this model all the “it would be nice if” and “we could do better if” comments should be recorded. Also, when creating this model, talk with the people actually doing the work in addition to the department leads. It is the people in the trenches that often know more about how things are really done. Not to say that a manager is clueless. Far from it, however the undocumented steps and “just in case” things to do are often viewed as not important enough to mention. This allows you to capture those little details that have been painstakingly learned over time but are not obvious to new employees. This will enable each new employee from repeating the same mistakes and “learning the hard way”.

Determine how and what information is captured at the various interaction points. The view is to make this information capture as easy and adaptable as possible. If it is ever viewed as too complex, customers will be encouraged to weigh the effort of interaction against the possible gain and unless the gain far outweighs the effort, they won’t bother. Also, procedures that aren’t followed are far worse than no procedure at all. Even cursory information about a prospect or issue can be followed up on. However, if the potential customer or issue information is never captured then it is less than worthless as it could have cost you a customer.

Next is to drill down internally on what departments/organizations are responsible for what. This should model what is currently done as well as what information they really need and how it is currently captured, if at all. The view here is to begin to look for easy improvements that could facilitate communications, data flow, and information capture. Again, the goal is to determine how to facilitate each person’s job and eliminate redundancies and source of miscommunications. This section of the model also provides a necessary framework on which training for new employees can be created.

At this point you have a basic model of how things currently are done; now the real work begins to look at how to optimize interactions between departments to make sure that required artifacts are captured and necessary information is available.

------------------------------------------------------

Chris Bryant has extensive experience in managing software development teams as well as in general business operation. He has held numerous governing board positions from Treasurer to Chairman. He has a Masters in Computer Engineering from Santa Clajavascript:void(0)ra University and has dealt with hardware, firmware, applications, GUI and overall product design.

November 18 Meeting Notes [John Levy]

2010-12-05T21:50:00.000-08:00

Notes from the recent Engineering Leadership SIG Meeting, November 18, 2010.

Tools for Team: A Panel Discussion on Collaborative Tools for Product Development

Co-Moderators: Ron Lichty & Tam Nguyen

Panelists: Sasha Ovsankin, Sandeep Jain, Chris Lunt, David Etheridge

Introduction by Tam Nguyen

Short presentation by Steve of Agile Learning Labs – note that there is a CSM course this weekend – with Chris Sims

Panel (see full names above)

Sasha is with a medical imaging startup

Chris is VP-Engineering with ReadyForce, his 8th startup

Sandeep’s focus is on productivity

David is working on Enterprise rollout

Ron: It’s hard not to be regretful after acquiring a tool and rolling it out, isn’t it?

Poll of audience: tools of interest?

Requirements management; project management, bug tracking, document management, lifecycle management, Agile support tools, defect/requirements tracking (customer-facing), adoption analytics, compliance (quality/conformance), wireframing, code review tools / 3-way merge tool, architecture / design patterns, code metrics, web conferencing

Question A: Creating Requirements and Selection Criteria

How do you know what you’re looking for?
Chris: ask peers, people I trust
Sandeep: it varies by stage (of the development group & company)
Sasha: transparency – “it just works”; allows everyone to see all the data;
Enjoyable to use
Sandeep: minimize overhead for developer
Sasha: input should be where the information happens
[discussion of whether these tools are “collaborative” tools]

Requirements-related tools ---
David: written requirements … Engineering response to PRD – the manager or leader has to break it down into sentences, then link tasks to each one;
It requires a human to understand the requirements!
Sasha: … and requires agreement by multiple groups
Selection: consensus – try it out; find an advocate who sells it to the team
The panel is generally in favor of SAAS, rather than on-premises servers/services

Question B: Adoption – How does adoption fail?
Chris: need cross-functional support (e.g., Product Management)
What are key success factors?
David: no greater burden than today (for users)
Ron: intersection between team & company vs. tools? Q: a lot of contractors with backgrounds using different tools – how to deal with this?
Sasha: has to be easy to learn / use
Chris: assign a peer to help the contractor get integrated with team & tools
Sandeep: embed the process in the tools
David: (regarding “resistance”) I make an agreement with my engineers: you enter (task) data, and I will deal with the upper management demands [on your time]

Question C: Favorite tools / recommended tools
Sasha: Pivotal Tracker; Freemind (mind mapping);
Tam: Xmind (mind mapping)
Chris: TRAC – wiki / source browser; (Redmine – not as good); GIT (but it doesn’t move back in time so well); Selenium (web testing)
Sandeep: SWplanner / HP Quality Center; Perforce; TeamTrack
David: Jira + Subversion, Bamboo, Crucible, Fisheye, Bugzilla + Yahoo Sprint Mgr

Audience questions
(Note: the audience had no major users of Rally Agile tools, Sprint 360)
(Cooperation tools, like wikis, blogs: wiki – about 50% use them; blogs – about 6 people out of 50 in the audience)
Sasha: continuous integration – an important part of Agile;
[unknown]: get Product Managers to write acceptance criteria
David: described using a Plan of Record (vs. PRD and Engineering response); tell executives “let them [engineers] solve puzzles” and get out of the way; if the PRD is too detailed, they will get passive-aggressive on you.
Much agreement from the audience on having seen PRDs that said too much about what to build (and how), rather than what function is to be delivered

--------------------------------------------------------------
John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way, was published in May 2010. http://bit.ly/9pX1wS

For more information, please visit his website at http://johnlevyconsulting.com ,
Email him at info@johnlevyconsulting.com , or call 415 663-1818.

Action is what manifests a choice amongst infinite possibilities [Corinne Rattay]

2010-11-18T23:03:00.000-08:00

I listen a lot to people in leadership positions, many of them being senior management in high-tech companies. What they tell me are stories of lack of empowerment, of how they "felt stuck" between "too clear" directions from a powerful GM, CTO or CEO and, on the other side, their Engineering organizations, remote or local. I'm borrowing some of their words here.

In fact, these senior Engineering leaders knew what wasn't working and what needed to happen to move their teams out of burnout, general frustration or acceptance of mediocrity. I'm sure you have experienced or seen situations such as this one. Their main problem was the same as what we see in nature all the time. Things remain as they are for usually a very long time until, one day, something new happens. A different idea, a new concept, a quantum leap. Who knows what I'm talking about?

We've noticed that quantum leaps happen as soon as a "catalyst" comes into play. I won't go into the details whether the catalyst is purely passive (as in a chemical reaction) or on the contrary very active inside the company into which he or she was brought in by the senior Engineering leader who finally has had the courage to step up and yell, at least in his or her imagination, "enough is enough, things have to change now!".

The truth is that action is what manifests a choice. Our world is a wonderful creation of infinite possibilities. As Albert Einstein had already taught us so well about the relativity of all things, even of time and space, I firmly believe that there is no absolute right or wrong. Everything must be seen from one or another perspective and it is futile to look for an absolute or so called "objective" perspective. Out of all the possibilities of how situations can evolve, humans have a tendency of wishing for a change in one way or another. Let's call it a "desire".

There's nothing wrong with having desires, actually this is a good thing since doing so drives imagination. And "imagination is more important than knowledge", as was adequately remarked by Albert Einstein also a long time ago.

So what is the key message to understand here? It is that action, yes, even a simple little action, done consistently from this moment onward, is the first step of manifesting a choice and moving towards a desire which we have. It's that simple: nothing changes from knowledge or imagination alone, but it is action that sets things apart.

The moment that we decide to act despite fear rather than waiting for the fear to go away or for the right moment to come (trust me it never will), this is when we set change into motion. What is it that you as a leader would like to change, specifically, and what are you waiting for?

------------------------------------------------------

Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com

Soliciting Engineering Leadership Horror Stories [Robert Lasater]

2010-10-31T19:42:00.000-07:00

Today being Halloween, we are soliciting Engineering Leadership Horror Stories. We'd like your scariest, most frightening experiences as an engineering leader.

There are several caveats. Your story must have some edifying or redeeming quality. We are not soliciting gripe fests or posts that just slam coworkers.

Here are some suggestions for what we would like to see. Maybe you were able to take that terrifying situation and transform it into something at least somewhat positive. Or maybe the situation was too far gone to salvage, but you have insights into how to recognize (and prevent) something similar.

Also, because your story may be sensitive, we would welcome anonymous posting. However an anonymous posting will require a lengthier review process. So if you request anonymity, give us a few days to post your submission.

Please email your Engineering Leadership Horror Stories to rlasater@hotmail.com. We accept Word documents, HTML text and simple text files.

And as always, we reserve the right to edit, modify or even not accept proposed posts.
---------------------------------------------------------------
Robert Lasater maintains the blog for theEngineering Leadership Special Interest Group of the SD Forum.

True Win-Win Commitment [Corinne Rattay]

2010-10-12T22:04:00.000-07:00

In business, people often claim their willingness to offer win-win deals. Whether you're in the market for buying a new car as a consumer as I did last week, or whether you're interested in a specific solution or service from a preferred vendor when you're acting in your professional role, the words of "win-win" sound pretty good, even reassuring in a way. But let me ask you, what is a true win-win commitment according to you, really?

Maybe the question to ask ourselves first is why would anyone want to pursue anything else, such as win-lose or even lose-lose alternatives. I've seen many cases like these and I'm sure so have you. And, in all sincerity, I've probably occasionally acted in such less noble ways, unconsciously or even consciously. We are all on a path towards continual improvement and growth, aren't we after all?

I'd like to get concrete at this point. With our focus on Engineering Leadership what could this situation look like, if I may borrow a real-life case?

Let's say a company's executive team has the dilemma of needing to please a major customer generating $500 million of revenue this year and being requested to add a few vital software features into its current software release due next month. The release without those features is eagerly expected by a large percentage of the company's customer base and is on schedule to function according to expectations. The account team has just informed the GM and EVP that this major customer can only effectively deploy the release with these client-specific features due to certain late discoveries. Furthermore a significant portion of the projected revenue can only be recognized with general-availability software releases which are accepted as functional by the major customer. Sounds familiar?

If you have lived or are living in this kind of environment, some first thoughts may storm through your mind right now.

As a Product Manager your focus will be on initial software requirements coming from the customer and the account team. As VP of Engineering you are worried about the impact of last-minute code additions in sensitive parts of the software and the inability to perform full screening on the modified code. As Regional VP of Sales your concern is your major customer's success and continued business if the features don't make it into this release or if the software turns out to be defective with the additional features. As VP of Operations you are getting headaches but are willing to accommodate within your means regarding the logistical aspects of software distribution. As Program Manager you are seeing an equation now with last minute variables that don't add up with success unless someone puts together a miracle.

If you are a member of the Executive team a few scenarios may come to your mind immediately:
(1) accommodate the major customer, impair all other customers by delaying the release, maintain release quality & predictability of quality
(2) accommodate the major customer, keep the release on time, stretch the Engineering organization, accept reduced predictability of SW quality
(3) release official software on-time, maintain release quality & predictability of quality, work with major customer using additional beta releases in parallel containing these required changes while possibly deferring large revenue projections for your own company to the next fiscal year
(…) and there are more creative ones with the firm understanding that this may only be a one-time exception to the standard process and policies.

Reality, or life in itself, isn't simple. Add to it the wisdom that there is no such thing as a "one-time-only exception" because it will invariably set a new standard for the future inside the company.

So what can this real-life scenario teach us about the topic of a win-win commitment? Why is this concept so crucial in business and even beyond in our personal lives? What is so powerful about the concept of true win-win commitment that people get so attracted to working with other people who make it a habit of practicing this concept? Why does business and money flow so much better in this way?

Over the past eighteen months I've focused extensively on understanding human psychology and leadership in much more advanced and accelerated ways than my previous hi-tech industry leadership experience may have offered me. Healthy humans want to trust and want the other person to be trustworthy. And we would all live in harmony with this idea if many of us hadn't been deceived and over time had derived a world model of scarcity and survival of the fittest. Consider how society in general defines "winning". Whether you look at sports games where we all want to see one team win, this does infer that the other one may need to lose. Isn't this how most people, maybe not you or me, approach life?

Let's come back to our hi-tech company example: should the company's current quarter bottom line win and the executive team decide to implement the custom changes in a rush to keep the projected revenue while shielding obvious process shortcuts from the major customer and everyone else? How may this decision affect the company's reputation once software stability issues are discovered by most customers and they turn out to lose? Should the shareholders lose in the end once the company's reputation has been affected? Should the major customer lose and be blamed for not having specified these additional requirements explicitly? Should the company lose the projected revenue this quarter? Is there really a way that everyone can win in this case?

How do most people make decisions when a win-win deal isn't obvious to all involved parties? May they get emotional and be driven by fear of missing out on a possible gain? What is your personal experience with people you've worked with so far? Some may say "you can't please everybody" and they are certainly right. Some may state that "it would all have been easier if someone had done a better job discovering the issues earlier", effectively pushing responsibility away with blame.

The truth is that there is never an absolute beginning for the appearance of a specific problem. Don't things just unfold naturally until they reach an arbitrary threshold for someone to call it a problem? In life is there really such a thing as perfection? It is my belief that there are just opportunities to grow for the conscious executive and to maintain integrity and hard-earned trust with every single customer, with the various internal teams inside the company and indirectly with the long-term shareholders. His or her role is to be creative while involving true teamwork and openness with the major customer in this case and seek the best for all parties over time.

The readiness to put a significant portion of the projected quarterly revenue at stake when openly approaching the major customer may be the very key ingredient for actually both securing short-term revenue while also gaining incredible future business not even imagined. Add to this the continued trust gained from all customers over the past as well as the long-term gains for the company's shareholders when the executive team continuously meets and exceeds its previously established standards.

If I wanted to summarize I'd say "treat all other people the way you want to be treated even if it may seem at a cost to you. It takes courage, but in the end we all win."

------------------------------------------------------

Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com

Magical Thinking and the Zero-Sum Roadmap [Rich Mironov]

2010-10-10T18:54:00.000-07:00

Recent conversations at several clients highlight an often-repeated set of magical thinking: beliefs by internal clients that development resources are infinite, and beliefs by product managers that prioritization can convince anyone otherwise. Both are wrong, but seductive. Here goes…

The starting point for this conversation is the typical product roadmap: crammed full of prioritized work and heavily negotiated with the development team. Almost every optional item has been postponed, and there’s still some risk of delay. This is a product plan with no “white space,” no large chunks of unallocated engineering capacity, no slop or slush funds or hidden treasure.

That gives us Mironov’s Roadmap Theorem #1: you can’t put something new into the current development plan without taking out something of equal or larger size. When stated this plainly, it should be as obvious as the law of gravity. Hand slapped against forehead. Doh!

(Agile translation: this backlog is very deep, already prioritized, and all of the upcoming iterations are strategic. New items can’t jump to the top without pushing something down that’s more critical.)

But internal customers (Marketing, Sales, Support, Channels, executive staff) always approach this with some form of disbelief or negotiating position or magical thinking: that 10 pounds of development can fit into a 5 pound iteration. I’ve heard all of these in the last week:

“But it’s really important.”

“We already promised it to a customer. (Oops)”

“We’ve been talking about this for more than a year (so we *must* have assigned resources to get it done).”

“Engineering should be more productive.”

“We’ve gone agile (which should give us infinite capacity).”

“Your priorities must be wrong.”

“How hard could it be? A tiny fix, a few lines of code.”

“It’s small enough to fit into one iteration.”

“I’m sure your boss agrees how important this is.”

All of these are valid in an emotional sense. Many represent good negotiating positions, assuming that product management is hiding extra engineering capacity under a basket somewhere. That we assign resources based on the most incentive requests. That “asking” immediately translates into “getting.” That a convincing argument creates technical resources.

Would that it were so. See theorem #1 above, though. Product managers know that the list of demands is infinite, and the vast majority will never be addressed.

Here are two kinds of product management responses:

[1] Soft-pedaling the actual situation, avoiding conflict by being polite.

We often respond to requests with coded language, mush and euphemisms. Instead of clear communication (“there’s no way this will get done in 2010” or “we have decent work-arounds” or “that channel partner doesn’t rate special treatment”), we waffle with:

“I need to prioritize that against the plan (and hope you forget it later)”

“Let me run that past engineering (who will tell me it’s huge)”

“It’s in the backlog (which will take decades to work through)”

FYI, our internal counterparts are smart. They quickly figure out if our kissy noises are just air, or if we really mean what we say.

Another approach…

[2] We keep some overflow engineering capacity for emergencies.

This looks like a better approach, since surprises and disasters always appear. We can secretly conspire with development managers to pad schedules, or explicitly set aside 10-15% of engineering time for unplanned items. Seems only prudent.

Which brings us to Mironov’s Roadmap Theorem #2: Everyone will find out about your emergency capacity. There are no secrets. In practice, that means all of the above arguments are suddenly very valid. Every sales rep has a strategic account, every unauthorized commitment must be met, and every channel partner has special needs. This puts product managers squarely back into the political process: deciding which arguments rate serious consideration.

Emergency set-asides have the potential to derail your entire product planning process. As “specials” and “one-offs” consume more and more engineering resources, your long-term projects get less attention. (Don’t ever go above 20%.) Your constituents may decide that emergency requests are the only route to satisfaction. If that happens, your roadmap becomes a quarterly CYA exercise.

Our internal customers are not interested in why their requests are low-priority, only in how they can get things addressed sooner. Clear communication about what’s really important, together with solid roadmaps and carefully managed overflow capacity, can ease the pain a little.

Crossposted at http://www.mironov.com/magical_thinking/

----------------------------------------------------------------

Rich Mironov is a serial entrepreneur, product management thought leader, and agile “product guy.” He’s the author of The Art of Product Management, and writes about software, startups, organizations and technology customers at www.mironov.com.

How to become a successful Leader, and how to get started from where I am right now? [Corinne Rattay]

2010-10-04T12:51:00.000-07:00

Humans admire successful leaders. From the well-known names of history to specific people in our industry, or maybe even inside the company we are currently working for, there are people we simply admire. If I asked you who holds such a special place for you, at least one person’s name would pop up in your mind within the first 10 seconds, wouldn’t it?

This is the Engineering Leadership Special Interest Group (ELSIG) of the Software Development Forum (SDForum). So I’ve decided to write about leadership, a topic which is very dear to my heart. You’ll understand more once you get to know me.

In my managerial hi-tech career I’ve had to lead teams of over 100 engineers across Silicon Valley, US East Coast and India towards putting out the best possible version of Network Operating Systems under tremendous time and budget pressure. Those of you who are at VP or director level can relate to this. What had never been done before needed to be approached boldly. And I’m sure your responsibilities may even be more challenging and exciting. Yes, excitement is an important driver isn’t it?

Maybe you have dreamed of engaging into a bigger leadership role at your present level in your career, wanting to become a little bit more like some of the inspiring leaders you’ve observed in your industry or company. I have at least, to be completely honest with you. I’ve wanted to become a successful leader myself for a long time. Not necessarily to play at the same level as the ones I admired, but at least become a better leader than I considered myself to be at that time. And I’ve struggled, as you can imagine. So, did that mean that true leadership wasn’t for me?

With your permission let me make in innocent guess here: I could assume that the people who have become successful leaders in our surrounding environment (i.e. company, industry, personal sphere, …) have all had a clear vision, clear goals and somehow were either incredibly skilled or fortunate to be on a path filled with success after success. It somehow looks like it, doesn’t it?

If you’re like me, you may object intellectually that this assumption isn’t reality. So how did these successful leaders get to where they are today? What is it that you or I had to or have to do differently compared to before this moment of decision?

Maybe you are an influential leader already and are merely reading this out of curiosity (which successful leaders typically do) or you are experiencing some resistance at this point in your life and I may simply share with you what I have learned over time which would have made life so much easier for me back then.

The first thing you should know about me is that I’ve made many mistakes and learned greatly from them. The truth is that I didn’t even have a clear vision of what successful leadership was really about. I’m not embarrassed to say today that a few years back I equated “successful” with “me” being successful, with “me” being “significant” (yes, let me cut right to it) in just the ways I saw successful leaders as being people “significant” to me in my eyes.

If I could only share one key insight with you, it would be that I’ve learned that successful leaders don’t focus on their own significance but on the significance and success of what they stand for. What they envision is so much bigger than their individuality in their own eyes. That’s why they succeed in making things so much better for everyone.

Ok, but let’s get back to where you and I may be right now. So can we grow towards the character, charisma and passion that come with the role of a successful leader? Yes, you probably know intellectually that this is indeed a possibility. How to get started though when one doesn’t have a clear vision, clear goals and the necessary skills (yet)?

I’ve learned a few crucial insights through personal experience, which I’d like to share with you in order to assist in whatever way may be useful on your journey if you choose so. In summary the most crucial ones I believe are below:

a clear direction you feel compelled moving into will do perfectly in the absence of a fully developed vision; you can refine and make things concrete along the path.

get in touch with the person you want to become; catch yourself acting like him/her every once in a while and rejoice yourself; be passionate about it.

getting started is not a matter of skills but of clarity of the path you want to pursue and the level of motivation for yourself; have absolute clarity of why you want to be on this path and what you’ll need to give up if you don’t.

take one step at a time instead of overwhelming yourself; don’t try to swallow the entire mountain or elephant in one bite; let things unfold, make one thing better than it is today through your own action and keep doing it consistently.

adopt a “responsibility vs. victim” attitude; whatever happens around you, understand that you still have the freedom of choice of how to respond.

cultivate your value system; develop integrity, trust and passion for what you do and for the people you’re interacting with

Skills of course are important also to become a successful leader. The key to really understand here is that they are not what is needed first on this journey. Speaking in front of a large audience, speaking up in a tense meeting and disagreeing for the sake of something bigger at stake, you name it. The truth is that you’ll acquire all the needed skills along your path as I have and am still doing.

In fact, this is a never-ending journey of personal and professional fulfillment once we’ve understood what life really is about.

----------------------------------------------------------------------

Corinne Rattay works with senior hi-tech executives on strategic leadership, breakthrough communication and effective execution, helping her clients to achieve extraordinary results. She can be reached at crattay@crexecutiveconsulting.com or at www.CRexecutiveconsulting.com

Whose English is it Anyway? [Kimberly Wiefling]

2010-09-26T18:21:00.000-07:00

My work takes me from my home in the San Francisco Bay Area, where more than 50% of the people living here don’t speak English at home, to Japan and elsewhere around the world nearly every month. I have the distinct honor and pleasure of working with people from all over the world, and recently had an incredible adventure with 37 people from 12 different countries who all came together as a global team to propose the future direction of their company. It’s an incredible experience to work with such a diverse group, and a heck of a challenge due to the most basic of reasons – we all speak different languages.

Even though all members usually speak some version of “English”, it might as well be Klingon. There’s the traditional British English, and many more, including Australian English, New Zealand English, South African English, Canadian English, English of “the islands”, African English, Singapore English, East Indian English, as well as heavily accented versions of Spanish English, German English, French English, and the worst of the worst – American. Without modifications, or an interpreter, no sustained meaningful communication is possible among these disparate groups.

If you’re a native English speaker, working in a global team, you need to stop speaking English. Stop speaking YOUR English, that is – if you want to understand, and be understood by your colleagues. Delving a bit more deeply into the various versions of the so-called “shared language” called English based on my own personal experience:

Americans – Strictly speaking you don’t speak “English”. You speak “American”. It’s different. Just listen to someone from New Zealand speaking English and you’ll know exactly what I mean. Or catch a couple of idiom-laden blurbs of British English from a person from the UK. You won’t understand what they’re saying, and they’ll be horrified when you start talking about your“fanny pack”.

UK People – For people who didn’t grow up with British English as their native language, no one will have a clue what you mean when you start complaining about the “tallback” that delayed your arrival at work.

East Indian Colleagues – As an American Native English speaker, I reluctantly admit that I can’t understand more than 70% of “Hinglish” because the emPHAsis is on a difFERent sylLAble than I am accustomed to.

Singapore – “Singlish” is musical and beautiful, but – unless I watch your lips every moment, and assure that my attention doesn’t drift in the least – I can only understand about 50% of what you are saying.

Australians – It’s not as bad as listening to someone from Texas or Georgia, but it’s pretty tough to understand you, mates!

New Zealand Colleagues – Really, I get such a headache focusing on what you are saying that it makes the Australian accent seem almost easy to understand. As I mentioned previously, listening to you is not quite as challenging as understanding people from my own country who hail from Texas or Georgia, but it’s pretty darn demanding.

There are other examples, but you get the idea. I don’t want to beat a dead horse (sorry, I couldn’t resist).

The former CEO of ABB, Percy Barnevik, stated that the official language of the company was “bad English”. I almost agree, but I reject the negative connotations of “bad English” in favor of “Global English”. And a CEO of a Korean company advised his people that it’s more important to speak badEnglish than good Korean.

Although I’m sure that most people assume that they are perfectly understandable to others when they speak English (especially my American colleagues!) in my experience they all might as well be speaking entirely different languages. The solution is not to speak English. The solution is for ALL of us to STOP speaking English and START speaking GLOBAL English.

I’m not a linguist, but here’s a few things I’ve learned about effective communications among global teams:

- Do your L.A.P.S.s.s.s!

Loud – Speak loudly so people can at least receive the soundwaves.

Attention – Make sure you visually make contact with the person you’re talking with before starting to speak to them. Eye contact varies greatly across cultures, and can be uncomfortable, but is critical to beginning a conversation.

Pause – Many non-native English speakers are “translating in their head”. Although not ideal, it’s a reality that they will need a few seconds to grock (sorry!) what you said.

Slow – Speak slowly . . . painfully slowly. Imagine you are speaking in molasses, then slow down even more.

Simple – Use simple words. Native English speakers use over 5000 different works, but non-native speakers use something like 500 – 1500. Don’t go showing off your vocabulary if you want to be understood.

Short – Short sentences. No long-winded phraseology, with obscure references to previous clauses.

Smile – If they can’t understand you, at least they’ll like you!

- No idioms, slang, obscure references.

- Don’t never use no double negatives!

In my experience, it’s not just European, Asian, South American or African people who need to change how they communicate. EVERYONE needs to adopt Global English in order to assure that 21^st century global company teams can understand each other.

STOP speaking English. If you are a so-called “native” English speaker, DEFINITELY stop speaking English! START speaking GLOBAL ENGLISH. It’s better for you, it’s better for your colleagues, it’s better for your company, and it’s better for your business profitability.

If we truly are going to realize the dream of a global economy where we collaborate across time zones and cultural boundaries for mutual benefit, we ALL need to change the way we communicate. Let’s not wait for “other people” to change so that it’s easier for us to communicate. Let’s all share the responsibility for improving communication and moving toward a truly global economy.

It’s in ALL of our best interests to make the pie bigger instead of arguing over who gets the crumbs. That win-win scenario begins with speaking a common language, and it's not as easy as just saying "English". It's GLOBAL English. Give it a shot (sorry again!).

Originally published on CareerShorts.com where Kimberly has been invited to contribute blogs periodically on global leadership and project management.

Project Manager Meets The Steering Committee [Glen Gage]

2010-09-21T13:01:00.000-07:00

Situation: You, the project manager, have just been called to represent your project at the next IT Steering Committee meeting, a meeting that includes the CEO and is held once every three months.

It can be daunting to be called before a group of 'C' levels, VPs and other executives when you aren't used to it. When you are used to it it's even worse because any naive thoughts you may have had of a group making reasoned business decisions based on open dialog and fact have long since evaporated. Steering Committees are some percentage true to their charters and the other percentage a hot bed of corporate politics. The percentages vary from company to company and within companies, from month to month.

Your first thoughts upon receiving the invitation were mixed--pride and fear. Good. Appropriate. The devil on your left shoulder whispered in your ear "Don't worry, it's no big deal. You know what's going on in the project, just relax and go to the meeting. They just want to tell you what a good job you're doing." The angel on your right shoulder whispered "This is a big deal. Get prepared, thoroughly prepared."

The first thing you did right when your manager told you your presence was expected at the next IT Steering Committee meeting was to ask why. When the answer was vague (your manager isn't on the committee) you did the second right thing, you arranged a few minutes with the project's sponsor (who is on the committee) to find out why and ask a number of other questions.

The answer to 'why' might range from "Project Managers are invited randomly so that they get the experience of executive level dialog and exposure to the management team. It is all a part of our employee development program" (not likely) to "This is a critical project and not everyone feels they have a handle on it." (whoops, is your communication plan not working?) to any number of reasons. The important thing is to find out why they want you there so that once you are there you can satisfy them.

I'll tell you now that you performed well because you listened to the angel on your right shoulder and because you knew in advance not only why you were invited, but what senior executives want in general.

What do they (Executives) want in general? They want the project finished and the benefits on which it was sold accruing. You and others may want the project for the project itself, after all its your job for the moment. They don't, it's a means to an end, full stop. What they want from you: competence, in control, working to achieve the benefits for the company promised by the project (vs. the details of the project.) Be aware that they look at project managers as commodities. One PM isn't working swap another in. It can't be that hard to learn MS Project, right? I don't think this way but most of them do.

Let's look back on your performance and see why it went well...

The sponsor told you you were invited because Sales was questioning the importance of the project, especially in light of the recent three month delay. You also found out where you were in the agenda, who else would be there, what they thought of the project, how to dress, how early to show up, the fact that it would be a good idea to have a few slides to show and a hand-out, and that your sponsor was a good guy and would support you. Then you were on your own.

You prepared your message and you visualized the end result. You practiced over and over in your mind driving to work. You did a dry run with your spouse. You prepared simple materials to hand out--bullet points and pictures, the detailed information planned for verbal delivery, detailed documentation written in case you had to distribute something. You made sure your project binder was up-to-date and indexed and you brought it to the meeting.

During the meeting you kept your cool and always appeared attentive and interested, but never cock-sure. You watched the body language.

Here is what happened:

You were introduced by the chair, the CIO. You had barely started when the VP of Sales interrupted. "These damn IT projects are like the pork and barrel Congress. Full of fat and low on delivery. For example, look at functions 12.1.4.5 and 12.1.4.6, if I can navigate this requirements spec properly! Where the hell did they come from?" You wanted to say "Then why did you sign off on the requirements document, you monkey?" but you didn't. Instead, you went to your project binder, found the data, and were able to say "Those functions were proposed by Mr. Bell A. Whistle at the user workshop held in Atlanta last month. The full group approved them as items with significant business benefit but not essential for version one. The development cost was estimated as low so they were included in the User Requirements Document for version 1." Then you stopped talking. Good, you answered his question. Everyone knows the Sales VP signed off and everyone knows he was represented at the workshop.

You continued with your presentation. The delay in your project was due to a change request from Sales that took several weeks to clarify, and this was your next topic. Your sponsor had coached you on how to phrase this part of your presentation. After your brought up the delay and why, the room went nuts--finger pointing, accusations, red faces. You did your job, you stayed out of it. As project manager you need to navigate politics, but it is not your job to resolve it, certainly not at the level you saw being played out before your eyes. You soaked it all in and kept an expression that communicated interest and professional concern. In fact the argument had little to do with your project.

When the dust settled you had an action item to modify the functionality of the software slightly and the direction that if the supplier gave you a hard time you should refer them to the sponsor. You began to finish your presentation but it was clear from the expressions in the room that the reason you'd been invited had been taken care of. You asked if there were any questions. There weren't. You thanked everyone and went back to work.

End note:

This little tale had a happy ending. Sometimes it doesn't, and sometimes there isn't anything you can do about it. In my tale there is an assumption that your project was approved because the steering committee 'power field' leaned toward supporting it. Sometimes, very rarely, but in my experience, projects are approved to discredit the sponsor. If that had been the case in my tale above you would still have survived because everyone (who counts) would know why your project was crushed, and everyone would respect the fact that you kept your cool and professionalism.

-------------------------------------------------------------------

Mr. Gage is an independent consultant with extensive international and cross-industry consulting and line management experience. Getting the highly unlikely done is the hallmark of his career.

Mr. Gage teaches a variety of project management classes in partnership with Fog City Consulting. These classes count toward Personal Development Units (PDUs) with the Project Management Institute (PMI). Links to these classes can be found on his web site https://sites.google.com/site/gageinnovation

I would love to hear from you. If you found an article interesting or not, please comment. Thanks in advance!

Contact information for Mr. Gage can be found on http://www.linkedin.com/in/glengage

Article Source: http://EzineArticles.com/?expert=Glen_Gage

A Journey of 1000 Miles is Still 1000 Miles Long [Rich Mironov]

2010-09-06T14:15:00.000-07:00

It's easy to confuse actual progress with intentions to make progress.

Why point out the obvious? I've just come out of another agile conversation where prospective clients confused "we want to build better software faster" with "we hope that some new processes will instantly catch us up on years of slipped deadlines and missing features."

So paraphrasing Confucius, "A journey of a thousand miles begins with a single step, but is still a thousand miles long. Even at twice your normal walking speed, be prepared for a very long slog."

For context, nearly every software development team would like to be more productive, ship better product, and be innovative. Almost by definition, though, those with the biggest productivity issues are the furthest behind - with months (years) of unmet customer requirements and technical debt. Shovelfuls of postponed promises piled in a heap. Which means that calls for better development processes are usually in the context of big, ugly backlogs and long-suffering customers.

So the unstated question in these meetings is "how do we catch up to where we were already supposed to be? Can a better process (in the future) also erase our previous shortfalls?" Stated that baldly, it seems naive. Yet the emotional logic is very real. Everyone wants a fresh start, a reset, a mulligan. Surely an outside expert or shiny new process will catch us up. Or not.

So What Do We Do Now?

Consider a hypothetical software team that sporadically ships product, has run up a stack of technical debts, missed some customer commitments, and needs a series of process improvements. Business needs are pressing, so there's no option to halt development for a radical retooling.

You might try some combination of these:

Pick one small thing as a demonstration, and make it successful. For example, if we're having trouble planning and estimating, then identify one very small project for careful planning and estimation. Focus the team on completing just that - mostly on time and reasonably on spec. This becomes our existence proof for improvement: having done a better job once on something small, we can do it again. (After all, a journey of a thousand miles...)

Ruthlessly prioritize. There are years of backlogs to address, and our newly hopeful development team can still only handle a few items at a time. Make sure that the next handful of small improvements are truly the most important. For everything else, 'nice to have' translates to 'not this year.'

Don't confuse small with big. As soon as a few tiny things start arriving on schedule, internal stakeholders will be lobbying for massive overhauls. ("If the engineering team can rewrite a report in a week, can't they re-architect all of our business processes in a month?")

Be transparent. Explain your 'do one small thing right' strategy to all internal stakeholders. (To be fashionable, you can call it 'agile.') Remind everyone that we still have 998 miles to go, but we're picking up the pace.

Share small improvements with customers. They are likely to be hungry for any good news, and eager for you to succeed. Gather some applause for your team. Customers don't really expect you to fix everything at once, but need some sense of progress.

Do your math. If we have two years of backlogs to work through, and we double our development speed, then it may take a year to catch up. Avoid magical thinking.

Celebrate the positive. Regardless of the starting point, your teams need a sense of progress and optimism. Highlight small triumphs, applaud people who are doing the right things, divert attention from yourself.

And wear comfortable shoes. There's a lot of walking to do. Because Confucius also said that "no matter where you go, there you are.

SoundByte

Find some improvements that you can make now, and establish a trend. Most long-term issues are solved with incremental changes and successes, not through one big fix.

Crossposted at http://www.mironov.com/1000miles/

Rich Mironov is a serial entrepreneur, product management thought leader, and agile “product guy.” He’s the author of The Art of Product Management, and writes about software, startups, organizations and technology customers at www.mironov.com .

Suppressing Your Feminine Side May Be Bad for Business [Kimberly Wiefling]

2010-08-16T12:23:00.000-07:00

About 15 years ago a woman I barely knew, the wife of a coworker, was listening to me describe the challenges I faced as a project manager at Hewlett Packard. “You’re not using your feminine power!” she suddenly pronounced, as if she’d just discovered the cause of some mysterious chronic illness I’d been suffering from for a lifetime. My first reaction was, “Use my feminine power? I sure hope not!” Since I was obviously perplexed, she further explained that this included nurturing behaviors like bringing food and drinks to meetings, and expressing other characteristics that I’ve heard described as “soft skills” by HR pros. I guessed I missed that in the job description.

You see, I was working in high-tech, and for over a decade I’d painstakingly stamped out any semblance of femininity in my work. After earning a masters degree in physics, a field in which women are almost as scarce as on-time schedules, I’d entered the high-tech engineering world, a profession with an equally abysmal track record of attracting women. Why on earth would I want to associate myself - in any way - with anything female in my work? I was sure I would appear weak and ineffective to my colleagues, and quite possibly my salary would decrease.
Maybe I was being a little paranoid, but until recently, I have done my best to ignore the gender issue in my career. I've steered clear of “radical feminism,” and I most certainly didn’t want to be perceived as “nurturing.” However, this past year I’ve been working on a book project, Scrappy Women in Business, which prompted me to reflect on the role of women in the workplace, and my own experience as a female in a predominantly male work environment. As a result of this, and the changing nature of the work environment, I’ve come to value what my wife’s colleague called my "feminine power." But my initial hesitancy wasn't completely unfounded, given the research on women in the workplace.

Even If I’m Not Nurturing, Chances Are People Will Think I Am

It turns out that it might not matter whether I am nurturing or not – being a woman, it’s likely that I will be perceived as nurturing by CEOs and other top executives. Catalyst, the leading global nonprofit dedicated to expanding opportunities for women in business, published a study in 2005 under the intriguing title Women "Take Care," Men "Take Charge:" Stereotyping of U.S. Business Leaders Exposed. Their research demonstrated that, although women and men often lead in similar ways, they are perceived very differently by both male and female senior executives. Regardless of the reality, women are perceived to be better at supporting and rewarding while men are perceived to be better at delegating and influencing upward.

Unfortunately, these unconscious biases impact the perception of competence and fitness for promotion, though with the growing emphasis on teamwork and collaboration these days, I’m not sure in which direction. We can, however, measure the results by observing the difference in participation of women and men at various levels in the professional world, and in the relative compensation of women and men.

Justice is Blind

Back in the 1970’s women represented only 10% of the musicians in an orchestra. That number has risen over the years to over 35%, and a Princeton University study in the year 2000 found that a big chunk of that gain was due to the switch to blind auditions. When the decision-makers can’t see whether the musician is a women or a man, more women are hired. And a study by The Anita Borg Institute on the recruitment, retention, and advancement of technical women found that women are sometimes preferentially eliminated during the resume review process, even if the interview process is unbiased. Another study specifically comparing evaluations of resumes by randomly assigning a woman’s name found that resumes bearing a woman’s name were rated lower by both women and men. (Perhaps women should use initials instead of first names on resumes, or hiring managers should have the names masked before reviewing them.)

Of course we’re all biased in many ways. All human beings are. Our assumptions and beliefs unconsciously influence our decisions, and our brains are clever enough to keep this process hidden from us so that we think we are making rational decisions based on the facts. Don’t think you’re biased? You can find out in about 15 minutes. Harvard University’s “Project Implicit®” provides a test in exchange for using your data in their studies. You will be randomly assigned one of a variety of bias studies, but you can repeat the process to experience them all. Based on experimenting with this several years ago, I found that I have a slight tendency to associate technical topics with women. Go figure!

Just Because You’re Paranoid Doesn’t Mean People Aren't Out to Get You

According to US Department of Labor statistics, only 10% of employed engineers were women at the turn of the century (2001). And while the salary differential in engineering has largely disappeared, the employment differential remains large in all but the life sciences. Even project management remains a profession with some degree of gender disparity—in both employment and pay. The 2010 PMI Salary Survey suggests that only 40% of US project managers are women (based on survey responders), and that the salaries of women project managers are “considerably lower” than that typical for men (about 10%). Karen Klein’s 2005 article “It’s a Women’s World, Too” does make the point that women are entering the project management profession at rates around double that of men, but still acknowledges that female project managers face barriers to success that are peculiar to women, such as excessive humility and a tendency towards self-criticism.

In spite of the possible risk, and because I’m past typical childbearing age (something executives admit is a real barrier for women in hiring and promotion in off-the-record true confessions), I’m less inclined to eschew my feminine qualities in my work these days. I’ve found that these qualities have become increasingly valued for their importance in delivering extraordinary business results. The incredible diversity of teams, increased focus on alliances and partnerships, the growth of open innovation, crowd-sourcing, and collaboration on a massive scale (facilitated by the internet), have all made people keenly aware of the power of group genius and the importance of a more collaborative style of leadership. I’ve noticed that the work I do as a project manager increasingly involves facilitating interaction rather than giving direction; perhaps it was always about that and I just didn’t notice because I was suppressing my nurturing side.

It turns out that female versions of leadership improve bottom line business results. Companies with higher proportion of women on their top management teams enjoyed 35% greater ROE (Return on Equity) than those with the lowest. Although I’m wary of the trap of stereotypes, in the past couple of years I began to wonder if maybe women and men really do lead in some fundamentally different way. And, with more profit at stake, I hope it’s something that can be learned by anyone, even nurturing-averse me.

There are plenty of pop psychology discussions about gender differences, including the somewhat unimaginatively titled “Are Women Better Project Managers Than Men” on the Toolbox for IT Project and Program Management Blog. Puh-LEESE! This kind of conversation is similar to my Japanese friends asking me to describe Americans. “Which one?” I ask. Like all simplistic questions, the answer to whether men or women are better project managers is, “It depends.” It depends on which woman, or which man, and which project, and in which situation. While statistics can help us understand trends in the aggregate, it’s foolish to apply that data to any specific individual or situation. Those who carelessly apply averages to individuals do both parties an injustice. Let’s not deepen the gender divide by participating in these kinds of debates. Instead, let’s look at facts.

The Road to the Top Winds Uphill All the Way

Is there gender bias at work in project management, and the business world in general? In my project leadership role I make it a practice to focus on the results produced, not the intentions of my team. Customers care about results, not intentions. I think the same approach may work well in this situation. I have no real way of knowing whether there is bias in the process, but I do know that there is a difference in the outcome – the participation and compensation of women relative to men. The measurable data from Catalyst certainly demonstrate a disparity:

• Percentage of women in the U.S. labor force: 46.3%
• Percentage of women in management, professional and related occupations: 50.6%
• Percentage of female Fortune 500 corporate officers: 15.4%
• Percentage of female Fortune 500 board seats: 14.8%
• Percentage of female Fortune 500 top earners: 6.7%
• Percentage of female Fortune 500 CEOs: 2.4%

Of course, root cause analysis is important, but the root cause of being overweight has been well known for years and still I can’t lose 5 kilograms. I personally don’t care whether the remaining disparities between women and men in project management—and the business world in general—are a result of accident, unconscious bias, or a devious plot. The causes no longer interest me. Making and measuring progress does. What’s measured tends to get attention, and frequently improves.
Good intentions or accidental bias can no longer be acceptable as a defense for inequitable results. After all, if I accidentally run you over and land you in the hospital, you’re just as injured as if I’d driven purposely in your direction with intent to harm.

The Coming Shortfall in Working Age Population in the Developed World

Based on a report by the Stanford Center on Longevity, (PDF) it looks to me like it’s in all of our best interests to make workplaces more attractive to human beings in general, and—in fields where they are under-represented—to women in particular. In a decade or two, the shortage of working-age people will be an economic crisis in some parts of the world. Japan and Germany in particular will face at least a 20 percent shortage in the coming decades (That’s why I don’t worry about women’s equality in the workplace in Japan – it’s coming!). We'll need everyone's participation if businesses are going to successfully meet the challenges facing humanity.

The Anita Borg Institute found that technical women leave their companies in mid-career at twice the rate of men. (Read more about this and the reasons why if you like.) Companies are losing women, especially at the mid-career stage. Catalyst reported that women cite four major reasons why companies lose female talent: “lack of flexibility (51%); glass ceiling issues (29%); unhappiness with work environment (28%); and feeling unchallenged in their jobs (22%). Only 5% report being downsized and only 3% say they were victims of sexual harassment.”

Of course, the workplace isn’t all that hospitable to men either. A Gallup Institute study on wellbeing concluded that 77% of all workers hate their jobs. HATE! Wow. That’s much worse than being unhappy with the work environment or feeling unchallenged in a job. I’m no expert at organizational development or the link between worker satisfaction and profit, but I’m guessing this is NOT good for project success or bottom line profits. A little more nurturing probably wouldn’t hurt any of us, or our chances for project success either.

If Being More Nurturing Will Increase Project Success, Bring on the Nurturing!

I was educated as a scientist, and if I were just looking at past data I’d conclude that expressing my so-called feminine side in the high-tech business world would put me at a bit of a disadvantage. But that’s kind of like driving while only gazing into the rearview mirror. With almost everyone hating their jobs, increased emphasis on collaboration, and the coming shortfall in skilled workers, I’m thinking that a more nurturing work environment is going to be a competitive advantage.

In fact, I’ve been experimenting with a more nurturing approach in my work in Japan, and it’s yielding excellent results: noticeably improved performance in various individuals, faster response to my requests, and more enjoyable working relationships. It’s working so well that I’m tempted to try it out on this continent. My only concern is whether it’s possible to be both scrappy and nurturing at the same time. Considering the potential 35% higher ROE, I’ll have to give it a go purely for financial reasons.

Nurturingly yours, - Kimberly

P.S. Scrappy Women in Business – Living Proof that Bending the Rules Isn’t Breaking the Law, will be available in July 2010. This book, and the associated website invite women to draw inspiration from each other’s stories. It’s just a small drop in the bucket, but it is one drop.

©2010 Kimberly M. Wiefling. All Rights Reserved. Published on the SD Forum Engineering Leadership Blog by permission of the author.

Guy Kawasaki on Entreprenuership 2.0 [Shriram Natarajan]

2010-07-19T13:46:00.000-07:00

Guy Kawasaki speaks about his mind altering experiences; holds forth on entrepreneurship and marketing in the social age.

Guy Kawasaki talked about "Entreprenuership 2.0" at UCSC extension in Santa Clara on Wednesday, July 7th. Guy Kawasaki is a managing director of Garage Technology Ventures, an early-stage venture capital firm and a columnist for Entrepreneur Magazine. Previously, he was an Apple Fellow at Apple Computer, Inc. Guy is the author of nine books including The Art of the Start, Rules for Revolutionaries, , and The Macintosh Way. He has a BA from Stanford University and an MBA from UCLA as well as an honorary doctorate from Babson College.

Alison van Diggelen of Fresh Dialogues collected the questions that the participants had enterred beforehand and asked them of Guy.

It was a wide ranging talk on Guy's opinions on various topics.

On Apple

Seeing the Mactinosh was one of the three all time (legal) highs he has experienced. Other highs were: meeting his wife and playing hockey (in no particular order).

Microsoft or Nokia could have made the iPhone. They should hire the right people and use their almost infinite cash to build products that people actually want. Microsoft or Nokia could have been the iPad maker -- had they just gotten their act together after seeing the iPhone.

Apple is a company that is dedicated to making the coolest products around. The company culture is decidedly inclined towards creating nifty, awe inspiring industrial designs. HP (to bash another company, he said) was built on two guys building oscilloscopes. They would gravitate towards stodgy businesses with safe markets. Apple's founders on the other hand could barely stay out of jail during their salad days.

On Marketing

The best way to market anything is to make sure that you have a great product. It is easy to market good stuff. It is draining to market "crap". Example: It does not take a genius to market the iPad; on the other hand marketing the "Kin" would be an uphill battle.

For a marketer today, social media awareness and presence is key. If you do not do social media today, you are not marketing. Guy opines that this is a fundamental way to do business today and in the future; to the exclusion of traditional marketing tools of focus groups and user surveys. The people are talking to you and about your company/products in various forums. All a marketer has to do is to plug into them to be successful.

On failure

Guy listed his various failures.

His job was to evangelize the Mac way of life to developers and thereby secure the market share for the better product. However Apple lost that battle overwhelmingly to Microsoft.

He does not have a net worth greater than $100 million. He has failed in terms of the movers and shakers of the valley.

He does not own a professional sports team (say the Sharks).

Despite his failure on behalf of Apple, he is best known for his role there. He went on to say that the valley is very forgiving of good faith errors/failures. There are no dynasties (continued success) or pariahs (continued failures). For entrepreneurs, the message is: there will be failures. It will not be the end as long as you learn and stay in the fight.

On investing

He would much rather invest in a couple of engineering graduates that build a product that they would like to use instead of a couple of MBAs from an A-list school with a snazzy slide deck.

He would invest in people that are hungry (living on soy sauce and rice) rather than first-25 employee/VP level person of a highly successful company. His thinking is that if you are a senior employee in a highly successful company you are accustomed to certain comforts and a certain size of bank roll. Also if you are said senior employee, you should be able to fund your ideas and not rely on venture capital.

On success

He is living proof that you can fool most people most of the time. He had no formal training in hardware or programming or computers. He was not even the earliest or most passionate Apple fanatics. He mostly got into Apple via nepotism or his familiarity with the original Mac Evangelist. He considers his key to success is his ability to grind it out. Hard work and passion. As an example, he built his twitter fan base from the ground up and by persistently posting good links.

In another context, he facetiously mentioned that the top five criteria for success were: "luck, luck, luck, luck, luck".

On Steve Jobs

Steve is one of a kind person across all time. The combination of perfectionism, sense of style and hunger to change the world is not possible. Guy would have been worth a couple of billion today had he stuck with Apple over the years. He would have to to put up with Steve for 25 years in the bargain.

In response to someone's questions about Steve Jobs' recent emails about the new iPhone's antenna: Guy thinks that this is probably just to indulge in the pleasure of seeing the response that these actions garner.

On twitter

Twitter occupied a disproportionate amount of time in the chat. He has added a quarter of million subscribers the old fashioned way: one at a time.

The rules of normal interaction seems to apply in twitter (or other social media as well):

- do not take "crap" from anyone (use tweetdeck to filter out and twitter itself to block people you do not like)
- if someone talks to you, talk back
- provide value in your interactions (good links in tweets/updates)
- provide content that is compelling to folks beyond your immediate earshot (measure content quality by the number of retweets)
- if you have provided considerable value over time, it is then kosher to do a little self promotion.

One aspect to his twitter toolkit is taken from the 24 hour news/sports channels: if you watch long enough, you will see the same stories repeat. That is an indication that you are spending too much time on the channel. It also is a tool for Guy to maximise the reach of his message.

Another axiom he has is: if you are not irritating a few people, you are not doing it right.

The only rule on twitter usage is quite simply this: if it works for you, it is right.

On entrepreneurship

Guy's advice to entrepreneurs is:

1) "Ask a woman."

Present your idea to women. They are not predisposed to destruction and could give you constructive ideas on your plan.

2) Build it and you will be funded.

A working prototype is more powerful than any powerpoint slides that you present. Any revenue stream is more powerful than spreadsheets about future monetisation. This goes for securing other funding as well.

3) Market yourself and your ideas

Establish yourself as a goto person in a niche. Build a network of people that look to you for the latest and greatest in a particular area.

4) The time is now:

This is a great time to be an entrepreneur: software is free, marketing is free and limited only by your imagination, labour is cheap, costs are low.

The silicon valley's entrepreneurial spirit is only due to the Stanford engineering department. So if any area that wants to reproduce the SiValley magic, he asks them to focus on their engineering school(s).

You can get more snippets and video at the Fresh dialogues page.
-------------------------------------------------------------------
Shriram Natarajan blogs at http://words.sangram.info/.

How a Failure in Engineering Leadership Caused the Deep Horizon Oil Spill [Elizabeth J. Agnew]

2010-06-14T12:58:00.001-07:00

Mike Williams survived the blowout on The Deepwater Horizon and he shared his story on 60 Minutes in May. What I found fascinating, in addition to how he survived, was his description of a catalyzing moment in the board room, just one of the many leadership mistakes that led to the disaster.

The rig had been working for seven years, and was just finishing up the largest drilling project to have ever been completed. The crew was preparing to close the cap of the oil well. Managers from BP were on site to celebrate a successful completion.

Here’s an excerpt from the 60 Minutes interview explaining what happened the morning of the accident:

Williams says, that during a safety meeting, the manager for the rig owner, Transocean, was explaining how they were going to close the well when the manager from BP interrupted.

"I had the BP company man sitting directly beside me. And he literally perked up and said 'Well my process is different. And I think we're gonna do it this way.' And they kind of lined out how he thought it should go that day. So there was short of a chest-bumping kind of deal. The communication seemed to break down as to who was ultimately in charge," Williams said.

The largest environmental disaster in US history starts because of chest bumping! This may not be surprising, but it certainly is ridiculous, disappointing, and embarrassing.

This highlights the importance of communication in the engineering world. I was told that the technical communications course I took senior year at Cornell would be the most important course I took. And I’ve found that to be true. What if there was a way (and there is) for those two men to have seen themselves on the same team, to have put their different ideas in a pile, then agreed on a way discuss the project that would result in the best all-around process? What if they were trained in how to maintain sight on the bigger picture, on all the forces at play, and not just on being “right”? What if the system was set up so that “being right” was the same thing as “finding the right answer together”?

Later in the segment we learn that if BP hadn’t won the argument, there probably wouldn’t have been a blowout:

In finishing the well, the plan was to … place three concrete plugs, like corks, in the column. The Transocean manager wanted to do this with the column full of heavy drilling fluid - what drillers call "mud" - to keep the pressure down below contained. But the BP manager wanted to begin to remove the "mud" before the last plug was set. That would reduce the pressure controlling the well before the plugs were finished.

"If the 'mud' had been left in the column, would there have been a blowout?" Pelley [the CBS interviewer] asked.

"It doesn't look like it," Bea [the expert; a UC Berkeley engineering professor] replied.

In all the cleanup work and ongoing efforts to stop the leaking, let’s not forget how this clusterf*** started. The way we’re working together IS. NOT. WORKING.

We need to:

Bring real leadership and communication training to all ruff-n-tuff engineering leaders out there

Teach leaders how to deepen their identity to Self so they get their egos out of the damn way when solving technical problems that have widespread, multifaceted implications.

Provide technical tools and processes for the skill of communicating so that when differing ideas are put on the table there is a reliable, impersonal way to choose the best one.

We NEED to change the way we solve problems together if we are ever going to a) avoid the next mega-disaster and b) fix all the mega-disasters that are already ruining our planet.

Source: http://www.cbsnews.com/stories/2010/05/16/60minutes/main6490197.shtml

About: Elizabeth J. "Liz" Agnew works with individuals and teams of technical professionals on leadership development, collaboration, and strategic planning. She offers complimentary consultations with no obligation. Visit www.integrative-leadership.com or email liz@integrative-leadership.com to learn more.

The Strong Boss [Matt Schlegel]

2010-05-28T06:42:00.000-07:00

One of my clients is a strong leader. She is a strategic thinker and as smart as they come. She guides herself and her team to deliver consistently great results. Yet, she complains to me that her team fails to think for themselves. As such, she has to maintain a hands-on approach and monitor the team continuously. She finds this tiring and aggravating and wishes she could delegate more. What is happening here?

As I began to interact with my client’s team, I discovered that the team was very good at reacting to direction from the boss. The team understood that the boss highly valued action; therefore, they took direction from the boss and turned that into action as quickly as possible. There was very little need to highlight problems since the boss set the agenda on the important problems to address. Also, the team minimized analysis and planning activities since these activities took time and slowed progress toward action-oriented results.

The figure illustrates the problem-solving dynamics of this organization. The leadership style of the boss created a strong tendency towards action – Git ‘er Done (step 7). The team members attracted to this type of organization are those that respond well to that leadership style. For instance, once the boss set the direction, the team found little need for further conversation about the problem (step 1). By moving directly to step 2, people would organize and figure out how they would respond to the boss’s direction. Ideas would be generated (step 3), but the team would find there was little value in analyzing the ideas (step 4) and building plans (step 5) around those ideas. Rather, the team would present a promising idea (step 6) to the boss for review and approval. The boss, being the smart strategic person that she is, would be able to quickly assess the idea and approve it, modify it or send the team back to the drawing board. In that way, the team would quickly move into the Execution Phase (step 7.)

This action-oriented problem-solving style is very effective in that it produces results quickly. One way to characterize this method is as an iterative method. Another description is “Fail Fast.” This is a great methodology to try different approaches and quickly iterate to a successful solution. And, because the leader in this case was as talented as she is, the probability was high that the ideas she directed the team to pursue would be successful. The cost of this approach is that she had to spend a tremendous amount of energy setting direction, reviewing ideas and monitoring results.

In working with this team, I found that I had to start at the end with the neglected Debrief Step (step 8), reviewing with the team how they solve problems, and determine what was working well and what not so well. Out of this discussion came a list of potential problems (step 1) that the team considered important to address. Reviewing this list with the strong leader, we quickly came into agreement on the important problems. The big difference was that the problems were now the team’s problems, not the boss’s problems – the team was highly vested in solving these problems.

Working with the team, I had them spend more time on analyzing different ideas for solutions and putting together a well-thought-out plan before presenting the plan to the boss. The team put together a terrific proposal in which they genuinely held pride. They presented that to the boss who was equally pleased and gave the team permission to move forward, which the team did with considerable enthusiasm.

The strong boss learned how her personal leadership style was impacting the performance of the team. The problems she experienced with her team were as much the result of her own behavior as that of her team. By allowing the team some say in choosing the problems to solve, the team delivered great results and took far less oversight from the boss, which made the strong boss happy.

-------------------------------------------------------------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.

Automate As Much As You Can [Rino Jose]

2010-05-02T11:36:00.000-07:00

Automation is the ultimate delegation

One of the classic traits of an effective leader and manager is that they delegate work. They find ways to offload work to others so that they can focus on activities that have higher value to the organization. If the work that's delegated is challenging because it requires intelligence and insight, then this provides junior executives and managers with an opportunity to develop their skills. If, on the other hand, the work is doesn't require insight and thought, it becomes a distraction that prevents people from working on things that matter more. When this happens, the work should be delegated further.

Of course, the ultimate delegation is to simply automate the work. If you can automate any of your work, you should. Having people do work that can be done for them is a waste of time, effort, and money..

Capture what you've learned

Automation enables you to capture and use what you've learned. It's a way of documenting the lessons your team and organization have learned over time. It lets you leverage your project retrospectives, postmortems, and brainstorming meetings. It helps puts into practice what you've decided to do.

People are overloaded today. It's hard to find anyone who has the spare time to shepherd change through an organization. If, however, change can be automated -- at least in part -- the effort of realizing change can be greatly reduced.

Don't keep reinventing the wheel

If you haven't automated how you do typical tasks or how you collect status or how you manage projects, then your organization will reinvent these things differently each time. If you have multiple teams within your organization, each team will develop their own way of doing things. There won't be consistency in how anything is done.

Not only will people be wasting their time reinventing new ways for doing the same thing, but they will multiply the effort it takes you to understand the status of anything. You won't know where your team is at any given time. You won't have a clear view of where projects will land or where the bottlenecks are. Some people will give you spreadsheets. Some people will give you subjective reports with lots of handwaving. You'll have information fragments that don't fit together. When things go wrong, you'll be surprised. When you ask why, people will externalize blame. It might not be anyone's fault -- lacking consistency is really to blame.

Automate to get into a rhythm

Stop doing things differently each time. Use templates for your meetings. Document your workflows (more in an upcoming post). Use tools to automate as much as you can.

Automation helps you get into a rhythm. It provides the infrastructure for your work. It enables you to apply your skills and insight directly to your problems instead of wasting effort on figuring out how to apply them.

When you automate things, people know what to expect. Each time you perform a certain type of work, it becomes easier to do. Every team starts executing consistently. Your teams will find their rhythm and their pace. Your teams will develop organizational momentum.

Keep questioning what you automate

Building organizational momentum is great. Teams are more effective. People have greater impact. Everything runs better. However, don't forget to question what you automate.

When we learn new lessons or when the environment in which we work changes, we need to ask if we're still automating the right things. If something is no longer necessary, we should drop it. If we're missing something, we should add it. If what we're automating isn't working, we need to fix it.

We automate to make ourselves more effective, not to stop thinking. It's ok to create and use cogs to make our jobs easier; it's not ok to become one.

(originally posted on Management Revolution)

_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.

All in the Family [Matt Schlegel]

2010-04-28T14:53:00.000-07:00

One of my clients is a small-sized, innovative technology company that has been in business for over 20 years. It is a self-funded, privately held company with no venture backing. The company is like a family; it is not uncommon for an employee to say they have been with the company over 15 years. At no other technology company have I felt that the company is as much a family as it is a corporation. Working with such a close-knit group can be a double-edged sword. That is why they asked me to help.

People who work together for many years come to know each other’s strengths and weaknesses very well. They come to accept one another and resolve to work with each other through any situation. This resolution often requires being sensitive to other’s feelings and needs and taking an approach that minimizes conflict and drama in order to keep focused on getting the job done. The downside of this approach is that people will tend to downplay problems for the sake of maintaining group harmony.

My client is a group of some of the kindest, most helpful people I have ever had the pleasure to work with. Some of the adjectives that I would use to describe this group are helpful, creative, analytical, cautious and enthusiastic. Two adjectives that I would not use to describe this group are perfectionist and assertive. Yes, this group appears to have weeded out anyone who would be unwilling to put up with the problems of others and anyone who would be assertive to the point of ruffling feathers. Not that this does not happen from time to time, but this is the exception rather than the rule.

The figure shows the problem-solving dynamic that tends to occur at the company. First, there is a great reluctance to acknowledge that there is a problem in the first place. There are no systems in place to identify and report problems to the group in a systematic way. As such, most problems are raised via the squeaky-wheel method. (Cliché: Squeaky wheel gets the grease.) Once someone has a big enough problem and shares that with the right person at the company, the helpful nature of the team kicks in. They want to solve the problem for that person. The company has great strength in creativity and analysis. They bend over backwards and find a creative solution to solve that particular problem. The team will get the thrill of moving towards solving the problem. If the problem is easy enough, it will get addressed. However, if solving the problem requires any transformative change to the way the team has historically worked, there is no one there assertive enough to move the team through that transformation. The problem is addressed to the point that the squeak stops, and the team moves on to the next squeak.

With this client, my two main jobs have been to fill the role of the perfectionist and the asserter. I have helped the company put in place the tools for collecting data, analyzing the data and reporting problems. As the data reveal the problems, the helpful nature of the team kicks in and moves the team smoothly through the problem-solving process. Then, it is my role to serve as the asserter to nudge the team through any transformative changes that will help them resolve their longer term, systematic problems.

This problem-solving framework gives me the tools to understand both the steps of effective problem solving and the interpersonal dynamics that will influence the team’s progression through those steps. It also gives me the tools to explain to my client what may be missing in their skill set that is impeding them from becoming effective problem solvers.

---------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.

Meetings as Performance [Rino Jose]

2010-04-24T11:16:00.000-07:00

When you view meetings as a performance, you're practicing something similar to servant-leadership. Instead of demanding people's attention, you earn it. Instead of holding court, you're on stage. It's still your show, but you want people to enjoy it.

When your meeting is a performance, you'll approach it differently. You'll spend time preparing for it. You'll work to make sure everyone's engaged. You'll discuss things that matter. You'll become more animated. You'll think through what you're going to say. Your meetings will have life and energy. Your meetings will have an arc and a story. Your meetings will have a point.

When you play the role of someone on stage, the attendees play the role of the audience. Certain expectations are established naturally. You are there to inspire, entertain, elucidate; they are there to watch, listen, participate -- no cell phones or e-mail during the performance. When you perform well, no one will be bored, and people (including yourself) will look forward to each meeting.

Looking at meetings this way gives you a chance to hone your presentation skills and to practice public speaking. Weekly meetings, in particular, give you a great venue to experiment with different styles and approaches. Vary what you do each week. See what works best for you. Build up your repertoire.

Another benefit to viewing meetings as a performance: it helps you lead change. When you deliver a solid performance, you connect with your audience at an emotional level. You'll find it easier to deliver tough messages and convince people to try something new. When people decide to change, it's usually based on emotion first and then rationalized afterwards. If you can get people to laugh, you can get them to change.

(originally posted on Management Revolution)

_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.

Bumps and Dips on the Path to Solving your Problem [Matt Schlegel]

2010-04-15T07:24:00.000-07:00

In past blogs I have described a problem-solving process. When I describe it, it is a nice smooth process flowing from one step to the next. Funny thing is, when you use the process in practice, it may not be so smooth. What if we could look down the path to anticipate likely bumps and dips in the process. We may not be able to avoid those obstacles, but we can brace ourselves to move through them. In this blog I will describe a method to let my fellow problem solvers identify in advance those bumps and dips.

People tend to play to their strengths and avoid their weaknesses. Your problem-solving team is comprised of people and their various strengths and weaknesses. Depending on where you are in the problem-solving process, your team members will resonate or not with the phase at hand. If the phase requires a strength that is absent in your team, the team can get stuck and have trouble moving to the next phase. If the team is overrepresented by a particular strength, again the team can get stuck or repeatedly go back to the overrepresented step.

The figure illustrates a team that is generally well represented by team members with various strengths, but has an underrepresentation in the Get It Done Step (step 7) and over representation in the Identify the Problem Step (step 1). What can happen in this case is that team would move around the process to the point of underrepresentation, get stuck, and then move back to the overrepresented step, a discussion about what is wrong, without ever taking the action to solve the problem.

This is just one example. You can see that depending on your team make-up, there can be any number of bumps and dips encountered as you move around the process. It is important for the facilitator of process to understand the team make-up, anticipate the trouble spots, and ensure that the team can move through the obstacle. In the example above, the facilitator needs to clearly identify the Driver role in step 7 and ensure that that role is filled with a willing and able team member. Also, when the team restarts the discussion about the problem, the facilitator needs pull the team back on track by reminding the team that a problem statement already exists.

As I work with teams and see how the strengths and weaknesses influence progress, I realize that there are many well-known clichés that describe these bumps and dips. To name a few: paralysis by analysis, half baked idea, heart in the right place, look before you leap, etc. On your problem-solving teams, what bumps and dips have you encountered and what clichés have come to mind?

_______________________________________________________
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.

The Knowing-Doing Gap [Kimberly Wiefling]

2010-04-14T22:22:00.000-07:00

If knowing “HOW” to do something were enough we’d all be rich and thin. There’s always some reason why well-intentioned, educated, experienced professionals are doing the opposite of what they know makes sense. Frequently it’s because they are really busy, and can’t possibly do what needs to be done until someone ELSE changes first, usually their boss, or someone in a different department. “If only” someone or something else would change then THEY would be able to do what they need to do to accomplish the goals.

A whole book on “The Knowing-Doing Gap” was written on this by two professors of Stanford University when they realized that their colleagues at the Stanford Business School didn’t follow the principles that they taught when they themselves were leading companies. It happens in engineering teams, too. If you want an example of the knowing-doing gap in engineering teams, just consider numerous studies that indicate that the top reason that teams fail is for lack of clear goals. What could possibly be more important for an engineering manager than clarifying goals and communicating them to the team?

Alas, common sense is NOT common practice. What is the source of the Knowing-Doing Gap?
FAIL – The 4 legs on the stool causing the knowing-doing gap and preventing people from crossing it are:

· Fear of Failure – If you’re not allowed to fail you must be careful what you start!
· Aversion to Planning – Studies have proven that, given a choice, people prefer not to plan. At the same time, we also know that planning dramatically improves results.
· Instinct for Competition – The win-lose frame is the first assumption for many people in any situation involving another person. Fear of losing, tied into #1, prevents people from even playing the game.
· Learned Helplessness – “It’s not my fault!”, and “They are doing it to me” thinking. The research on this is absolutely shocking.

The difference between someone occupying an engineering leadership position and a true engineering leader is that the pros do what is required whether they feel like it or not, whether they think they have time or not – no excuses! Winston Churchill is one of my favorite leadership role models and he said “Sometimes doing your best is not enough. Sometimes you must do what is required!” Yeah, that’s right, Winston.

Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.

Getting Really Good at Agile [Ron Lichty]

2010-04-08T13:27:00.000-07:00

From the speaker at the next Engineering Leadership SIG event, April 15, 2010:

The first half of Mike Cohn's book, "Succeeding with Agile: Software Development Using Scrum", isn't so much about how to be successful with agile as how to be successful replacing non-agile with agile, selling agile, and transitioning to agile.Mike Cohn is neither a wild-eyed dogmatist professing the one true way nor an ivory-tower philosopher; he's a pragmatist. He devotes entire chapters to helping scrum evangelists decide whether to start with a pilot or go all-in across the organization, whether to pilot publicly or in stealth, what factors might prevent success, how to swing things your way, how to approach a transition in steps, picking the right first project and first team, and how soon to adopt agile technical practices like simple design, pair programming, TDD, continuous builds, refactoring, and automated testing. He notes from the first chapter that agile implementations are hard and don't always "take" - and explains why. He recommends solutions to the many conundrums and traps that agile teams face.

About midway through the book, as you're reading insights into teamwork, you realize that this book is not just about transitioning to agile but about getting really good at agile - and that you're going to need to read it not just once but come back to it for new insights again and again. The fact is it's stuffed with tips, guides, data, approaches, failures, successes, and helpful hints of every kind.

Part of what makes this book important for me is repeatedly reading observations consistent with my own experience, but drawing on so many more experiences with agile that it results in emergent patterns, as well as in truths that are too often left unsaid. Then there are the surprises that come from reading an author who is remarkably well-read across genres. He does us all the favor of reviewing and summarizing scads of studies and surveys that demonstrate why agile is worth the effort, with data on productivity gains, lower costs, improved employee engagement and job satisfaction, faster time to market, higher quality and, importantly, stakeholder satisfaction gains.

What's the role of a manager of a self-organizing team? One of them, agile gurus seem to agree, is exercising subtle control (as opposed to command-and-control) and Mike provides an entire framework for debugging team problems and influencing their success. This will be one of those chapters I know I'll revisit repeatedly.

In another example, Mike remarkably provides what in essence is a crash course in change, and that chapter alone, while loaded with specifics about making a change to agile, could be used by any technical leader making a technology-and-culture change of any kind. Know why shopping carts were introduced and how shoppers were convinced to use them? Mike does, and effectively uses the example to teach change leadership. How does a leader deal with the skeptics and the saboteurs, the diehards and the followers certain to show up on your teams? How do you sway the uncertain to get on board?

Cohn is practical right down to the challenges from facilities and h.r., the likelihood agile transitions will face waterfall-driven expectations, and strategies for coexisting with other approaches, regulatory standards and processes. Importantly, he provides helpful anecdotes and examples from companies large and small. He's familiar enough with other process changes your company may have attempted to be able to compare and contrast and differentiate the substance and style of scrum from everything that came before.

While Cohn is sometimes unsatisfying - drilling down not quite far enough in sharing what's worked - in its 400-plus pages, it's remarkable how few of these unsatisfying examples there are.

Finally, I should point out that though it may not be immediately obvious, there's one more group of readers for whom this book has enormous value: Agile wannabes who know their current process isn't working. They frequently have heard of agile but have no idea what it looks like or how to sell it. If you're one of those, you also need to read this book. Mike Cohn over and over offers advice and examples and data that will give you aha after aha as you build a picture of what a truly effective process can look like - and how yours could become functional like his.

If you're interested, there's a longer version of this review at:

http://ronlichty.blogspot.com/2010/04/book-review-succeeding-with-agile.html
_________________________________________
Ron Lichty is a "VPE of Fix-It," providing interim and on-demand VP Engineering services to optimize software organizations and efforts. He specializes in solving problems like painfully slow product development, past-due estimates with no delivery in sight, snafus from geographically dispersed teams, scalability stymied by sluggish data integration, productivity bridled by uncertainty, an "order-taking mentality" from teams that should be proactive, and teams unable to break out of research and move on to development and delivery. He also untangles organizational knots, creates roadmaps everyone can follow, builds communications with other parts of the organization, coaches and trains organizations in agile and scrum, and gets teams productive and focused on delivery, quality and customers. Small tweaks, dramatic impacts. He'll be presenting the SDForum's April 15 Engineering Leadership SIG topic on how agile changes the development manager role group in Palo Alto: "If Agile Teams Are Self-Directing, What Do Managers Do?" His book on managing software developers and software development teams, "Managing the Unmanageable: Rules, Tools, and Wisdom for Managing Software People and Projects", is forthcoming.

Corporations are People, Too! [Matt Schlegel]

2010-04-07T14:22:00.000-07:00

A US Supreme Court decision on January 21, 2010 has re-ignited buzz about the rights (and responsibilities) of corporations. When this buzz happens, and it periodically does (here is an example from 1886), I wonder why it is that we humans are inclined to organize ourselves into ever larger groups? What do those groups afford us? And, what can we learn from this behavior about how organizations solve problems?

When I think about these questions, I first think about what it means to be an individual. The brain is a good place to start thinking about this (literally!) Each of our brains (and I am including all vertebrates here) detects our individual needs and communicates those needs to us in the form of feelings or actions. Satisfying those needs is the problem that the brain is constantly endeavoring to solve. A big part of the brain is dedicated to understanding the problems of one part of the body, and then translating and transferring that information to other parts of the body to help solve the various problems. Our individual brains enable us to be good at solving some problems and not so good at solving others.

Some of the needs identified by our individual brains are best met in collaboration with other individuals and their brains. (2 heads are better than 1!) Our brains figure out what other individuals are good at, and we tend to collaborate with other individuals that help us meet our needs. In that way, collectively we are able to accomplish more and meet each other’s needs better than if we worked individually by ourselves. And, this characteristic is scalable. As the collection of neurons in our brains grows more numerous, and those neurons communicate better with each other, the better the brain becomes at solving problems (fish, reptiles and birds, mammals, culminating in the human brain.) And, this appears to be true for collections of those brains (schools of fish, flocks of birds, herds of animals, organizations of people.) I suppose it is not surprising that brains will tend to use the same successful formula for both internal scaling and external scaling.

When, as individuals, we join a larger group, we create an identity associated with that group. In a sense, as we become part of it, it becomes part of us. As the organization takes on members, it starts to reflect the traits of the individuals. Often, like-minded individuals attract one another, and these individuals may share similar characteristics, including similar strengths and weaknesses. Those strengths and weaknesses can be reflected as strengths and weaknesses of the organization. In the coming blogs, I will share with you some of my experiences about the strengths and weaknesses of organizations for whom I have consulted and show how those strengths and weaknesses affected the organization’s ability to solve problems. Remarkably, the tools that I use for analyzing individuals seem to work very well for analyzing larger collections people. Maybe corporations really are people.

___________________________________________________________________
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use this methodology to help companies solve big challenges, and he folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at http://www.sakinoconsulting.com/.

Think Outside the Tool [Rino Jose]

2010-04-04T13:28:00.000-07:00

Remember this one?

In the figure below, find a way to draw four straight lines through the nine points without lifting your pen from the page.

The answer, of course, is to allow the lines to extend beyond the boundaries of the implied box:

This puzzle gave rise to one of the biggest business cliches ever: "Think Outside the Box".

The next logical challenge then is, can you find a way to draw two straight lines through the nine points without lifting your pen from the page? Not possible, you say? Can't make the box big enough? Here's a hint: "Think Outside the Tool".

What if you used a pen with a really wide diameter? Then you could do something like this:

This is a better tool for the job. Less work for you. Faster results.

Every tool has built in assumptions

When you use a fine-tipped pen, it's assumed that you want thin strokes so you can draw or write with fine detail. You wouldn't want to use this type of pen to paint a wall. Likewise, a paint roller is great for painting walls, but you wouldn't want to use it to sign a contract.

Assumptions aren't necessarily bad things. A more generic tool designed with fewer assumptions often requires more effort to use for a particular job. For instance, spreadsheet applications are great for summarizing tabular data and doing quick computations, but using them to manage projects requires a lot of thought and work (and rework) to set up -- and ongoing effort to keep updated.

Specialized tools make specific assumptions about how they will be used. If you use them as they were intended, they can make your job a lot simpler and easier.

When you start using a tool, understand what assumptions it's making and how these assumptions relate to the work at hand.

Learn Your Tools

If you find yourself using a tool every day, it's probably worth blocking off an hour this week so you can browse the documentation. Skim the table of contents or the index and jot down the features you're not familiar with. Do a websearch on the tips and tricks for the tool so you can get an idea of what others have found useful.

If any of these are relevant to your work right now, figure out how to use them today. If not, keep them in the back of your mind for when the time is right. Investing an hour to learn the tools you use every day can pay for itself many times over down the road.

When all you have is a hammer...

When your tools aren't working well, or when you and your team seem to be spending too much time fighting them, even after you've taken the time to learn them, you might need a different tool.

Take a good hard look at your current tools. What assumptions are built into them? Do they help you do your job, or do you need to hire someone just to keep them running? If you're not using the right tool for the job, find (or build) a better one.

Don't just get by with the tools you have. What if you could save 4 days of effort per week with the right tool? Wouldn't that have a huge impact on your organization? There are tools like this (I've built one). Use them.
(originally posted on Management Revolution)

_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.

Self-inflicted Project Wounds [Kimberly Wiefling]

2010-04-01T22:19:00.000-07:00

There is a group of forensic chemists who gather periodically for something called “The Bite-mark Breakfast”, where they are treated to a slide show of various bite marks, which they attempt to identify while enjoying their eggs, sausage and toast. (This popped into my head this morning as I was feeding my cat. She was in a nasty mood, and I made the mistake of picking her up to give her a little rub before heading off for a 3 week business trip.) In this same vein (pun intended!) I thought it would be fun to take a spirited look at the wounds incurred by engineering projects, in particular those of the self-inflicted kind. While there are endless challenges rained down upon any product development project, the most regrettable are those we bring upon ourselves. These acts of self-mutilation and attempted suicide are largely avoidable, and it’s a pity to have any hard-working team suffer the consequences of such behavior on the part of an engineering project leader.

The single-most hideous self-induced risk to life and limb of any project is to for an inexperienced and unqualified project manager to take the lead. Just because project management seems easy when it’s done properly is no reason to believe that anyone with half a brain can do it. Technical geniuses who can figure out how to launch the space shuttle from their iPods can’t necessarily hammer out a shared vision among the divergent views of a bunch of clamoring stakeholders. Process gurus sporting black belts in the latest incarnation of statistical process control and the Plan-Do-Check-Act cycle created by Shewhart and popularized by Dr. Deming in the last century aren’t automatically gifted at motivating, coaching and inspiring individuals to contribute their very best in the pursuit of a worthy cause. And don’t EVEN get me started about what a person who is able to study the PMBOK (PMI’s Project Management Body of Knowledge) and remember what they read long enough to answer multiple choice questions on a test may or may not be capable of!

A qualified and experienced project manager knows enough about the product and technology to facilitate sensible decisions among the project team, and detect total nonsense when they hear it. They are capable of employing a variety of problem-solving methods that assure that all relevant information and viewpoints are considered, not just chairing a round table swapping of opinions. And, far beyond dishing out tasks and checking on status, they are committed to bringing out the best in each of the individuals on their team through a combination of appropriately matching the person to the task, encouragement and course-correcting feedback. These are the essential “3 Ps” that produce business results: Product/Process/People.

Yeah, but . . . what if you are the unqualified and inexperienced project manager who is currently leading a project that is way above your capacity? Run, don’t walk, to the nearest highly experienced and capable person you can find and beg them to help you and your team avoid the self-inflicted damage toward which you are surely tottering. Get them to “shadow manage” the project by coaching and mentoring you every step of the way. Meet with them at length on a weekly basis, and talk with them informally frequently throughout the week. This is exactly how I managed my first project, which I was assigned to lead after I complained bitterly about the inadequacies of the current project manager. I was fortunate to have a manager who was willing and able to guide me through my first project leadership experience. You may not be so lucky, in which case you may need to find a mentor, or even hire someone to help you. That’s right, if you can’t get your company to provide you what you need, pay good money out of your own pocket if necessary to get the kind of support that you need to do a great job on your project. I’ve hired professional coaches from time to time in my career, usually when I stepped into a role that felt 5 sizes too big for me. There’s nothing like having someone with 20 years of experience showing you the way. Reading books, taking classes and passing exams are no substitute for decades of experience. Consider it an investment in your continued employment! And you can usually write it off on your taxes.

Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.

Transparency [Rino Jose]

2010-03-27T16:11:00.000-07:00

We say we want transparency in decision-making, transparency within our organizations...but do we really mean it?

Transparency is a Sign of Efficiency

Transparency within organizations is a good thing. It means that teams and functions are communicating freely. It's a sign that decisions are being made with more information and more scrutiny. It indicates that the organization is executing efficiently.

When problems arise in transparent organizations, people can see them immediately and from different perspectives. The organization can respond quickly to unexpected events and save valuable time. Organizational goals can be modified, and the people can quickly realign their activities.

Why Aren't Organizations More Transparent?

There are three main reasons that keep organizations from being transparent. The first is that most organizations have unintentionally developed a "culture of opacity". You can see this when people say their information needs to be filtered and controlled because others can't understand it out of context. You can also see this when people don't trust their own teams to report information. Some organizationl roles exist simply to filter and throttle information.

A second reason is that it can take a lot of effort to be transparent. There may not be an easy way to communicate what's happening or why. People may not even be able to track all of the information that's being generated by their teams, creating a kind of opacity by default. Technology, however, has advanced to the point where this should no longer be an issue. There are tools that can reduce the effort of tracking and presenting information so it's less than negligible (i.e., they actually cut the effort of what you're doing today as they provide transparency for your team).

The third main reason is that...

Transparency Requires Trust

One of the things I said about breaking a "cycle of distrust" was that someone had to go first, to make the first gesture. Transparency is a perfect example of this. We can't say we want transparency within our organizations if we ourselves are not willing to reveal how we make our own decisions. Someone must take the first step.

Why is it so hard to do this? If we feel the need to hide something, we should question that. If it's because we don't trust others in the organization, we should question that, too. Get to the root of distrust and eliminate it. If it's beyond your authority, find someone with more clout. There are always people with influence that want the organization to run well. It's likely that they aren't able to see where the problems are. Build a window into your team so they can see for themselves.

(originally posted on Management Revolution)
_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.

Commitment – Inspiration that Never Fails [Kimberly Wiefling]

2010-03-25T13:03:00.000-07:00

Inspiration is important to effective engineering leadership, and every kind of leadership in fact. But we can’t depend on it showing up when needed.It comes and goes, like a feral cat that roams about looking for a bite to eat. We can feel inspiration waxing and waning within us, and the inspiration from the outside world can’t be counted upon to show up on a regular basis. However the important work that we need to do in our projects, and in life in general, remains – independent of whether we happen to be inspired to do it. That’s why I have chosen to be inspired by my commitments. The commitments of a person of integrity are solid, powerful and lasting. These kinds of commitments carry the weight of reputation and intention. They are ever present. If you lead inspired by your commitments it doesn’t matter whether we’re tired, feeling disheartened, low on energy, unappreciated, or frustrated by circumstances. The commitments that we have made call us to action. This is mighty handy when we can’t afford to wait for inspiration!

When we rely solely on external sources of inspiration, such as other people, positive feedback, the positive results of our work, we give away our power. If you’re a gifted painter and no one wants to buy your works, should you stop painting? If you’re a talented musician and no one wants to pay you for your music, should you stop writing or singing? And if you are a dedicated project leader working on a project that truly matters, but that people do not acknowledge, support or appreciate, should you do a crappy job, give up hope, and leave gesturing wildly into the air with one particular finger? I don’t think so. (OK, if the project DOESN’T matter, maybe go with the finger thing.)

Mother Theresa was this kind of leader. A couple of the sayings purported to be among her favorites (and I think useful for today’s engineering leaders!) are “Despite giving your best to the world, you may be kicked in the teeth. Give the best you’ve got anyway.” and “Years of your hard work may be destroyed overnight. That should not deter you from building upon your hard work.” Mother Theresa was not relying on inspiration to get her out of bed in the morning, and she wasn’t relying on positive feedback, encouragement or support. Nope, she knew who she was and what she was committed to doing, and she got up every day and did it. Period.

What kind of leader are you? What are you committed to more than your comfort or the approval of your colleagues, friends, or the world in general? And what’s your commitment worth? If you’re only committed when you’re inspired, well, that’s a bit dicey. But if you are wholeheartedly committed when you give your word, and your word is tightly bound up with your integrity, then you have a chance of living up to your commitments whether or not you happen to have a source of inspiration in your life.

And here’s a bit of a kōan for you . . . what if you are ‘committed to being inspiring’ whether you feel like it or not? (I guess that’s kinda like saying that you are living vicariously through yourself.) If you are committed to being truly and authentically inspiring then your team can depend on you to inspire them when they need it, whether or not you yourself feel inspired. Now that’s something a great leader should ASPIRE to!

Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.

The Endless Journey-Becoming the Kind of Leader You Admire [Kimberly Wiefling]

2010-03-20T15:58:00.000-07:00

The process of becoming a great engineering leader, or any kind of leader for that matter, is a perpetual quest. It is an endless journey of self-discovery. Just like going to church, you can never be “done”. There will be successes along the way, but no failures, only feedback from which you can choose to learn and grow. Sometimes the challenges you face will seem too enormous for you, but you will benefit more from the difficult parts of your travels than the easy roads. When Nelson Mandela was asked what changed about him during years in prison he said he matured in prison (an environment not totally unlike some corporate environments). In my experience, age definitely helps improve leadership wisdom, especially since it brings more patience!

There will never be a convenient time for you to invest in developing yourself as a leader. It will never be the most urgent or pressing task on your “to do” list. But it will certainly be the most important thing that you can do to increase your ability to make a positive difference in your work and enhance your overall career success.

You may be fortunate enough to have help: a mentor, coach or guide who provides valuable advice or support in your quest to become a great leader: but no one can give you what you deny yourself. A mentor can help you make best use of the opportunities that you have before you if you are willing to listen openly to their advice.

Leadership is not a position in an org chart or a title on your business card. It’s a mindset, it’s behavior, a way of communicating, especially listening. Do not wait until you are given a position of leadership to become a great leader. Commit today to becoming the kind of leader you admire regardless of your role or title in your organization. Set goals for your leadership development that extend far into the future, clearly imagining yourself as the leader you admire and then taking steps to become more like that leader every day. As you look back on your journey from the far future you will be amazed at your progress and the positive difference that one person can make in your company and in the world.

Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.

Next EL SIG Meeting: "Bust The Silos" [Robert Lasater]

2010-03-14T13:04:00.000-07:00

The next meeting of the Engineering Leadership SIG of the SD Forum is this coming Thursday evening, March 18. The program starts at 6:30 PM, with the featured talk, "Bust The Silos: How to Improve Groups and Organizations Working Together" by Jeff Saperstein starting about 7:10 PM.

Summary of the Presentation

If you experience difficulties with group collaboration because of job description and functional department silos, lack of time for people to provide guidance to each other, and a mismatch between rewards and encouragement of group outcomes, then you are not alone.

Demand Creation orientation and practices can improve collaboration—based on new business processes supported by technology—to enable an organization to be more customer centric and responsive resulting in increased productivity and sustained, profitable growth.

In this session we will explore what hold us back from collaborating better and Jeff Saperstein will speak about what he has learned in his research to write Bust the Silos: Opening Your Organization for Growth.

About Jeff Saperstein:

Jeff Saperstein is an author, teacher, and consultant. His books and case studies focus on best practices for innovation. He has worked with governments, corporations and non-governmental organizations to use marketing to increase growth. Mr. Saperstein teaches at San Francisco State University College of Business, at Cisco, and other corporations, He teaches seminars on Tech Clusters and Innovation at the European School of Management in Paris and hosts International MBA groups for immersion tours in Silicon Valley. In addition he leads technology bloggers on writing trips to regional centers of innovation excellence including Israel and London/Cambridge. He is also co-founder of "Traveling Geeks".

Location

SAP
3410 Hillview Avenue, Building 1
Palo Alto, CA
94304

In the Palo Alto hills above the Foothill Expressway, between Page Mill Road and Arastradero.

Agenda

6:30 - 7:00 Registration, Free wine, beer, snacks, pizza, soda and networking
6:33 - 6:58 Engineering Leadership Roundtable (New and Expanded!)
7:00 - 7:10 Introduction and brief announcements
7:10 - 8:20 Keynote and Q&A
8:20 - 8:30 Other announcements (next month's topic & speaker, jobs, blogs ...)
8:30 - 8:45 Informal networking
8:45 - 8:50 Clean up and have a safe trip home!

Engineering Leadership SIG events are primarily about Engineering Leadership, and are not restricted to software development. Audience reaction tends to be overwhelming positive, with participants giving recent presentations 4 or more on a scale of 1 to 5.

SNACK and BEVERAGE Sponsor for this Month: ProjectConnections

ProjectConnections.com provides practical project management know-how to the people who are leading and managing projects, teams, and people. Our goal is to help you save time, avoid or solve problems, and ultimately be successful on your business-critical projects. The site provides practical just-in-time tips, techniques, tools, and advice through a broad set of online project-related resources, with support for new and experienced managers alike, and both individual and organizational plans available to support everyone who's depended on for the success of your projects.

We would like to thank ProjectConnections for their sponsorship!

Cross Posting on the EL SIG Blog [Robert Lasater]

2010-03-13T14:46:00.000-08:00

Crossposting is an old and established tradition in the Blogosphere, and I am happy to announce the blog of the Engineering Leadership SIG of the SD Forum is adopting it.

Kimberly Wiefling is a key person to making this Engineering Leadership SIG work. Her energy and enthusiasm are truly remarkable. She has agreed to cross post some of her work from SV Project Management on this blog. One of her postings has already appeared and some more will be appearing over the next few days.

If you have a blog you would like to have cross posted here, or have selected postings you would like to contribute to this blog, please send email to elsigblog@gmail.com or rlasater@hotmail.com.

Problem Solving and the Black Swan [Matt Schlegel]

2010-03-09T13:12:00.000-08:00

In past blogs I have described the importance of creating a clear statement of the problem before you jump into a problem-solving project. The challenge with creating this problem statement is that not everyone has the same problem. In fact, during good times the types of problems that people have grow diverse and less severe. Then, in flies the Black Swan, a disruptive event that impacts a great number of people. This event presses the problem-solving reset button.

In The Black Swan, Nassim Nicholas Taleb describes the impact of infrequent events. Taleb calls such an infrequent event, “a Black Swan.” In terms of problem solving, the impact of a Black Swan event is clear – a large number of people come to share a common problem. Whatever smaller issues those people may have faced before, there is a huge problem in front of them that many must address.

In the corporate world, a Black Swan event may be any number of situations: the departure of an important leader, customer or vendor; the restructuring of a division; a merger or acquisition of another company. The list goes on and on. Any of these events gets the attention of everyone in the company and creates a natural urge to want to help solve the problem.

The great news about a Black Swan event is that it gets everyone focused and working together. In large organizations this is hard to do, but when it does happen, seemingly miraculous accomplishments can occur. For instance, once Apple was at the brink of bankruptcy in the 1990’s, the company became very focused on its “core” values and has thrived every since.

When people share a common problem, they are naturally compelled to work together to solve that problem. The important first step of any problem-solving process is the creation of a clear problem statement. Black Swan events grab everyone’s attention and help create a common problem for all. As if a reset button were pressed, it brings everyone to the first step in the problem-solving process. As organizations get larger and larger, these Black Swans can perform an important function in re-aligning people and creating a common problem statement. With that common problem, people focus their energy and overcome even the most difficult challenges. Today, as I reflect on the US and how divided the nation has become and remains, I wonder what Black Swan will cause us to focus our energies again.
_________________________________________
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.

Manage Cows, but LEAD People [Kimberly Wiefling]

2010-03-07T11:03:00.000-08:00

Lately I have trouble saying “project management” because, when I do, I always have the urge to blurt out “You can manage cows, but you must LEAD people!” So I’m going to dedicate this week’s blogs to exploring leadership with no apologies to leaving out “management”, and even “project”, every now and then.

Most of the experiences that have increased my cynicism over the years are due to failures of leadership, both my own and others. I spent the first 10 years of my career naively expecting people in official leadership positions to step up, do the right thing and lead courageously, even at great possible cost to their own livelihood and career. (OK, I said I was naive.) From the perspective of my minuscule position of relative powerlessness, my organizations were steaming heaps of dysfunctional behavior and inefficiency, and what our official leaders needed to do seemed blindingly obvious. I just couldn’t understand why they were standing around smiling and slapping each other on the back about meeting monthly numbers while smoldering embers of inevitable corporate downfall were poised to burst into flames all around us.

It never occurred to me that things looked different from the top of the totem pole. It wasn’t until years later that someone told me that the hierarchy in companies is like a bunch of monkeys sitting in a tall tree. When you look down you just see a bunch of smiling faces, but when you look up . . . well, you get the picture. The guys at the top didn’t even perceive the gaping holes in our business fabric, while I saw tattered remnants resembling the effect of acid rain on clothing.

In those days I found myself constantly looking for help to descend from above, but help was not coming, at least not from that direction. The big whack on the side of my head that brought enlightenment was that I had a responsibility to lead no matter what my rank in the company. Leadership is not a position in a company org chart or a title on a business card. Leaders exist at all levels of an organization. They come in all shapes and sizes, from all kinds of backgrounds and different sorts of education. Leaders can be identified by the way they talk and the way they act.

Great leaders do not see themselves as victims of their circumstances. They do not lament their lack of formal authority, and they do not wait for others to come to their rescue. They accept responsibility for their contribution to the situation, and they are committed to making a positive difference.

What is leadership? Leadership is not the same as management. What’s the difference? In spite of the bovine reference, both are essential to successful businesses, but many organizations are over-managed and under-led. Budgets and schedules, while easy to measure and track, do not occupy the center of a great leader’s attention. Leadership is far different from management, and just as important. According to HBS’s Kotter, managers plan, budget, organize, staff, control and correct, while leaders set direction, align people, motivate and inspire.

Leadership is an inside-out job. I think of it as 5 concentric circles that build upon one another. It starts within through becoming consciously aware of ourselves, who we are, what we stand for, what we care about more than the next raise, promotion or the approval of those around us. Awareness enables choice, and is at the core of self-leadership. Once we can lead ourselves then we can reach out to lead others one-on-one. Aside from the example we set, the only way we have to lead other people is through communication, both talking and listening. Once we are capable of leading one person through effective communication we can tackle the more complex social dynamics involved in leading a team – keeping everyone rowing in the same direction. Beyond team leadership lays the challenge of leading a cross-functional organization, which is more like being the captain of a super-tanker. You can’t just grab the wheel and make a quick turn, and it can take a very long time to get your direction to turn into changes in where the ship is headed and how quickly. Beyond is the ultimate test of a leader, where culture, currency exchange rates and chronological obstacles plunge you into the truly Olympic sport of global leadership.

While leaders perform many valuable functions, the areas where they can provide the most practical benefit are:
- to help their people avoid two of the most common causes of failure: lack of clear goals and poor communication.
- to inspire people to overcome their inherent fear of failure and have the courage to set bold and challenging goals that may initially seem nearly impossible.

Many people occupy the position of leadership without demonstrating the qualities of leadership. Truly great leaders enable ordinary people to work together to accomplish extraordinary results out of reach of any one person’s grasp. Leadership is a journey to future possibilities that frequently seem impossible. Leadership unleashes the greatest potential of people in support of making a positive difference. And on a daily basis leadership is behaving in a way that inspires and sets an admirable example for other people. The purpose of leadership is to achieve what we cannot accomplish alone, to tackle dreams and possibilities that we can only fulfill together. Right now this planet is facing quite a few threats that could benefit from the collective genius of the human population. Based on watching the news (a big mistake: people who watch the news have been statistically proven to be more depressed), I’m thinking we’d better not wait for the official leaders of the world to solve these problems. Perhaps it’s time for a consciousness conspiracy? Wanna join?

Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.

Borrowing Borrowing Brilliance [Matt Schlegel]

2010-02-16T12:36:00.000-08:00

In my previous blogs I have described a problem-solving process. By no means am I the first to describe a problem-solving process; there are many, many examples. In fact, I have recently come across David Murray’s book, Borrowing Brilliance, in which he describes a 6-step process. What is the same about Murray’s process and the one I have described in previous blogs? What is different? Why?

Murray provokes his readers by asserting that creativity is, in large part, simply borrowing ideas from others. He says that if you and your team allow yourselves to do this, you will enjoy much better solutions arrived at more quickly. Murray describes the first steps in this process by a series of four meetings:

So here’s how to incorporate the creative thinking process into the daily practices of your organization. Separate the concept development process into four different meetings, each with a different goal and different set of rules. These are:
1) a problem-definition meeting;
2) a borrowing-ideas meeting;
3) a new-idea meeting;
4) the judgment of these ideas at a separate time.

Holy smokes, these are exactly the same first four steps in the process that I have been describing! Coincidence? I hardly think so. If there truly is a fundamental method in the way that humans solve problems, and that method is somehow connected to the way the human brain works, then we would expect to see similarities in any problem-solving process described by a human. And, I think we do.

Here are the steps that Murray uses to describe his entire process:

The Six Steps to Business Innovation
Step 1: Defining ➜ Define the problem you’re trying to solve.
Step 2: Borrowing ➜ Borrow ideas from places with a similar problem.
Step 3: Combining ➜ Connect and combine these borrowed ideas.
Step 4: Incubating ➜ Allow the combinations to incubate into a solution.
Step 5 Judging ➜ Identify the strength and weakness of the solution.
Step 6: Enhancing ➜ Eliminate the weak points while enhancing the strong ones.

While Murray’s process gets off to a great start, it seems to get stuck in the latter steps. Incubating, Judging and Enhancing all seem very much part of the analysis process. Where is the part that the team makes a decision about the solution? Where is the part where the team sells that decision to management? Where is the part where solution is implemented and delivered? Murray’s process seems like a great methodology for an R&D department that is not required to deliver a final result but only well-formed ideas. The great clarity of vision with which Murray describes the first part of the process and the lack of clarity in the delivery part tells me much about Murray and what is important to him. It also provides me with clues about the part of the problem-solving process in which Murray excels – we all like to play to our strengths.

Every problem-solving process has its strengths and weaknesses (including the one that I have described.) In many cases, it is simply because the process is trying to solve only a very specific problem and not a general problem. In many cases, those strengths and weaknesses are attributable to the world view of the author. I love to analyze different problem-solving methods as I attempt to discover fundamental truths about human problem solving. Maybe you can help me? What is your favorite problem-solving method? The Scientific Method? A Bug Resolution Process? The Six-Sigma Method? Please share your methodology here and let’s discuss the similarities and differences between the different methods.
_________________________________________

Matt Schlegel has been developing his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process

The Fractal Geometry of Problem Solving: how chaos becomes progress [Matt Schlegel]

2010-01-18T13:38:00.000-08:00

I remember reading “The Fractal Geometry of Nature” by Benoit Mandelbrot many years ago. Mandelbrot made chaos cool. Since then the term “chaos” has been picked up by many disciplines, not the least of which is software product development. Often, chaos is the term we use to describe a messy, complex situation that we do not fully understand but that is required for creativity. Perhaps our perception of chaos is simply a lack of understanding of the fundamental geometric shape that can elegantly describe that creative process. Is there a fundamental geometry for problem solving and the creativity that comes with it?

Prior to Mandelbrot’s work on fractals, generating interesting graphical images by computer was extraordinarily processor intensive. Taking inspiration from Mandelbrot, Loren Carpenter realized he could create complex and realistic graphical simulations of nature using mere triangles, thereby greatly reducing the computation requirements. If you have not seen the movie he presented at SIGGRAPH in 1980, check it out here. Imagine creating all that from just triangles! This breakthrough was a turning point in the computer industry.

Isn’t problem solving another artifact of nature just like natural landscapes? Might not there be a fundamental fractal geometry for problem solving as well? In previous blogs, I have described an 8-step problem-solving process (9-steps by Enneagram count.) I often invoke an 8-section wheel to describe the process. I imagine that there is another 8- section wheel connected to each section of the main wheel, and another to each section of that, and so on in recursive fashion. This structure might form a problem-solving fractal.

Take the simple example of starting with step 1, defining the problem. At step 1, the problem is that “the Problem” is not yet defined. We need to find someone to clearly articulate that problem. We need to consider various ideas for how we might articulate the problem. We need to understand the impact of any articulation and the pros/cons of such articulation. We need to settle on one articulation and to make sure that everyone is in agreement with that articulation. We need to move on and use that articulation to drive the problem-solving process. And, we need to review that articulation periodically in order to ensure that it remains the correct articulation in light of any new data. In this fashion, we just used the entire problem-solving process to describe one section of the overall process.

Having an awareness of the scalability of the problem-solving process helps us better understand the ebbs and flows of the process and helps keep the team moving forward through the process. And, like using triangles for graphical simulation, it can be used to efficiently address the current problem confronting you, your team or your company, regardless of scale.
_________________________________________

Matt Schlegel remains a fan of Benoit Mandelbrot and recently enjoyed reading Mandelbrot’s book on markets entitled, The (Mis)behavior of Markets.

Problem Solving, the Brain, and the Enneagram [Matt Schlegel]

2010-01-09T17:10:00.000-08:00

On the topic of problem solving and the brain, I want to bring to your attention a fascinating book called Personality and the Brain written by a local computer scientist and entrepreneur, Peter Savich. Peter became interested in the Enneagram and realized that there must be a link between how the brain operates and the core modality described by the Enneagram. His book makes a very compelling case for this link.

Peter asserts that there are two parts of the brain that drive personality, an old brain component, the amygdala, and a new brain component, the prefrontal cortex (PFC). The amygdala is in essence the fear processor, and the PFC is the optimism/pessimism processor. He goes on to describe how each of these brain components has a right side and a left side, corresponding with the right side and left side of your brain. And, each half invokes dominant characteristics. For instance, one side of your amygdala is your fear-aware processor (the flight processor) and the other is your fear-unaware processor (the fight processor). Likewise, one side of the PFC is your optimism processor (glass half full) and one side is your pessimism processor (glass half empty).

Just like there are 3 states of handedness, right-handed, left-handed or ambidextrous, Peter asserts that both the amygdala and the PFC have three dominant modal states, and it is the combination of these states that give us the 9 states of the Enneagram. How cool is that! He goes on to examine studies from the body of neuroscience literature to show how pathologies in these brain components accentuate or diminish the behaviors that map to the behaviors described by the Enneagram, thereby making a very compelling case for connecting the dots between the brain and the Enneagram. I cannot thank Peter enough for developing and publishing this fascinating thesis.

With the help of this understanding, we are able to connect the dots from 1) a problem-solving process described by the Enneagram, to 2) the behaviors and capabilities important for each phase of that problem-solving process, to 3) our own unique set of behaviors and capabilities and, finally, to 4) our brain which governs those behaviors and capabilities. Just like the brain determines whether we end up being right-handed or left-handed, it also plays an important role in how we contribute to the problem-solving process.
____________________________________
According to Peter Savich’s framework, Matt Schlegel has an amygdala that is fear-aware dominant and a prefrontal cortex that is pessimistic processor dominant. This makes Matt uniquely suited for that part of the problem-solving process he characterizes as “finding the path of least danger.”

Take stock of your problem-solving talents [Matt Schlegel]

2010-01-02T10:06:00.000-08:00

In the last blog, I wrote about a talented right-handed pitcher. When it comes to throwing a ball, it is pretty easy for most of us to figure out which arm throws best. But what about problem solving? Each of us has a style that lends itself to contributing to the problem-solving process. How do we figure out what that style is and how we best contribute?

As you have read through the previous blogs describing the problem-solving process (and I hope that if you are reading this you will have done that), you may have been thinking to yourself about how you contribute at each phase in the process. You may have recognized those areas in which you feel you are strong or which you enjoy the most. Those are important clues in understanding where your personal talents lie when it comes to solving problems.

If we accept the 8 steps of the problem-solving process and acknowledge that as individuals we are strong in a few of the steps but perhaps not all of them, what happens when as individuals we attempt to solve problems? I can tell you from personal experience, I will focus on the steps in which I am strong and minimize or skip over the steps where I am weak. Here is how I would characterize myself: Firstly, I am not one to even make a big deal about problems. I may ignore them, live with them or tough them out. On the other hand, occasionally I get a “brilliant” idea that I want to try out. This idea will be a solution to a problem that I may or may not actually have. Yet, I will be so enthused about the idea that I will move forward and implement it, and I will be tenacious in doing so. After implementation, I will take steps to measure how effective the idea is in order to determine if it performs as I envisioned. At this point I usually stop and move on to the next thing.

So, which steps of the problem-solving process are my strengths and which are the weaknesses? Let’s start with weaknesses. I did not start off by having a clear problem statement, nor did I have any goals. I did not enlist the help of others. I did not consider many ideas, just the one that popped into my head. I did not explicitly analyze my idea, but there was the implicit analysis that my brain did to come up with the idea in the first place. I got very enthused about the idea, but I did not necessarily get others enthused about it. And, I worked hard to implement the idea and went back to see how well it worked. From this, you can see that I am personally weak in steps 1, 2, 3, 4, and 6 of the process. On the other hand, I tend to be strong on steps 5, 7 and 8. Good to know.

And, dear reader, in terms of the problem-solving process, which steps do you identify in yourself as strengths? I encourage each of you to take stock of your strengths and understand how you best contribute to the problem-solving process.

Matt Schlegel lives in a household of 5 people, each contributes differently to the problem-solving process and two are teenagers. Matt’s keen awareness of his own problem-solving inadequacies may come from the constant and frank reminders of these inadequacies voiced by these teenagers. Kindly, his wife reminds him of his strengths.

Comments Are No Longer Moderated [Robert Lasater]

2009-12-09T13:19:00.000-08:00

Comments are no longer moderated on this blog. That means you can enter a comment and it should appear immediately. You will have to pass a Turing Test (more accurately, a CAPTCHA test) to demonstrate you are indeed a human.

Newton’s 4th Law (of Meetings) [Tanya Berezin]

2009-12-06T16:10:00.000-08:00

Some time ago I was taking over for a project manager who was leaving. We had a couple of days for the transition and we talked about all the things you’d expect: the current state of things, upcoming milestones, strengths and weaknesses of the team, partner relationships, and so forth. And, of course, she forwarded me the invitations to all of the standing meetings for the project.

There were daily meetings (two), weekly meetings (three or four), and monthly meetings (who’s counting!). I couldn’t attend them all even if I wanted to. It was impossible to know which meetings were important, they mostly sounded alike. I knew I had to clear my own and the team’s calendars so we could get work done.

I created a spreadsheet listing all meetings I knew about. For each, I asked the team to fill out several pieces of information:

1. What is the objective of the meeting?
2. What is the typical agenda?
3. Who runs the meeting? Who attends?
4. What is the frequency and duration of the meeting?

I saw three things, as I expected: more meetings got added to the spreadsheet – clearly, I didn’t catch every single one in my review; for many of the meetings no one could crisply state the objective; and the agendas and attendee lists tended to overlap quite heavily. Once I published the resulting list, it became clear to everyone that things needed to change.

I developed a proposal for the meeting structure going forward: removed obsolete meetings, consolidated repetitive ones, shortened the remaining ones, and trimmed the invitee lists. This, with some minor changes, was adopted by the team.

Newton’s first law of motion is: every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it. Substitute “meeting” for “object” and “recurring” for “state of uniform motion” and you get what I call Newton’s 4th law – a recurring meeting, once established, tends to go on forever, unless someone starts asking questions.

No one intends to create unnecessary or repetitive meetings – each one seems like a good idea at the time. After a while they outlive their usefulness but no one takes the trouble to notice and cancel them, so people continue to show up. If this is happening on your project, ask the questions above. You might gain a few hours to get something done.

Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin

Finding the Problem-Solving Super Highway [Matt Schlegel]

2009-11-27T13:30:00.000-08:00

Returning to Marcus Buckingham’s book “First, Break All the Rules,” I delighted in his analogy of people’s strengths and weaknesses as super highways and country lanes in the wiring of their brains. I subscribe to this line of thinking; however, it leaves me wanting for a way to identify predictably the super highways and bumpy country lanes of candidate team members, be they for a problem-solving initiative or a spot on a development team. So began a search for a navigation tool to find those super highways and avoid the country lanes.

Many people subscribe to the romantic notion that if you try hard enough you can do anything. I don’t. There are things you are naturally good at and things that you are not. Further, there are things that you are passionate about and things that you are not. The magic occurs when there is alignment of your passions and your natural talents.

Let’s say that you are John Rittman, Head Coach for Stanford’s softball team. And, let’s say that your ace pitcher throws right handed. The problem is that the teams in your division hit much better against right-handed pitchers than against left-handed pitchers. What is the solution to this problem? Are you going to tell your right-handed ace to start practicing with her left hand because if she tries hard enough she can be as great with her left hand as she is with her right hand? Or, are you going to let your ace right hander continue to hone her skills as a right hander and go out and find some left-handed talent to round out the roster?

I am right handed, and last weekend I went out and practiced throwing with my left hand. It is remarkable to me how absolutely inept I am at throwing with my left hand compared with the right. Both accuracy and power suffer, as well as my whole body feels off balance. My brain definitely applies its resources to giving me some competence at throwing right handed while neglecting that capability with my left hand. My right hand definitely got the super highway to my left hand’s country lane.

What we need is a navigation device that can help our teams navigate the problem- solving process. This device needs to not only find the shortest path, but keep us on the super highways whenever possible. I will describe such a device in the next few blogs.

As an engineering manager, one of Matt Schlegel’s most satisfying roles was finding the alignment between people’s natural talents and their passions, and guiding them towards roles in which they could be fabulously successful.

Managing Risk in IT organizations [John Levy]

2009-10-21T12:57:00.000-07:00

Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy.

1. IT Operations and Development must be managed differently. Development is Engineering and must be managed as such. Outsourcing of Development does not convert it into Operations – it is still Engineering.

2. Measurements for IT Operations and Engineering (Development) are different: Development should be measured based on expected ROI plus certain strategic factors; Operations should be measured based on predictability of spending and certain Quality of Service measures, along with regular and consistent assessment of relevance of those measures to the business. [This is analogous to market risk in financial portfolios]

3. Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy. In addition, the probability of future failures remains undiminished so long as the management shortcomings are not addressed.

4. The cost of failure in IT Development always exceeds the allocated budget for the activity, because failure has consequences beyond the immediate failed project, both for people and for other projects. For example, one major factor of risk that increases when a development project fails is the loss of key people. It is rare to find IT management mitigating this risk immediately on learning of a development failure.

5. Failures and losses in IT Operations usually involve either directly managed operations centers or outsourced providers’ operations. Outsourced operations are inherently riskier because the providers’ operations are less visible, and therefore less known, to Operations managers. [Cf. Failure in Microsoft-provided services for Sidekick smart phones, Oct., 2009] [This is analogous to credit or counterparty risk in financial transactions]

6. IT management should be able to communicate to top management the nature of the tradeoffs in IT Operations and Development, so that strategic implications of decisions in IT are well understood at the top level. This means that financial factors must not be the exclusive determinants of IT decisions. The CIO should not report through the CFO.

7. Multi-year planning is essential for both IT Operations and Development. A roadmap for rationalization and integration of resources and services is necessary, even if it must be revised multiple times per year as new equipment and services are needed. Contingency planning and scenario analysis related to possible shortcomings of vendors and outsourced services must be part of the plans.

Above thoughts on IT management are based on my recent experiences at a client company and were triggered by a paper, “Risk Management Failures” by Prof. Rene Stultz, Fisher College of Business, Ohio State University, published by Cornerstone Research http://www.cornerstone.com/

John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on high-tech management, Get Out of the Way, is due out in 2009. More info is at http://johnlevyconsulting.com

Problem Solving, Shared Leadership and the Enneagram [Matt Schlegel]

2009-10-20T13:20:00.000-07:00

In recent blogs I have described the steps of a problem-solving methodology that I have found works extraordinarily well in helping teams solve complex problems. What I have also found is that different team members contribute in different ways, and their contributions are better aligned with some steps of the problem-solving process than others. Imagine if there were a way to understand how each team member best contributes to the problem solving. Imagine if you had a way to ensure that there were strong contributors at each step of the way through the problem-solving process. Also, imagine if you understood when there was too much or too little representation of a particular strength so that you could avoid some classic problem-solving mistakes (for instance, paralysis by analysis.) The next sequence of blogs will describe the connection between people’s strengths and weaknesses and the process itself.

The basic premise of this discussion is that we can find a method that does provide a link between each step in the problem-solving process and people’s strengths and weaknesses. I discovered such a link while studying the Enneagram. For those of you not familiar with the Enneagram, I recommend checking out this link. I find that this book is a great introduction to the Enneagram.

During an Enneagram workshop I attended, the question was raised as to why there are numbers to describe the different personality types. The instructor indicated that the numbers are arranged in the order that people solve problems. Voila! The Enneagram not only describes 9 basic personality types, but it also describes the order in which each type contributes to a way humans solve problems. Fascinating! It was based on this bit of inspiration that I started to develop the problem-solving process I have described in previous blogs. In using this process with teams, I did find that there is a strong correlation between a person’s Enneagram type and their ability to contribute to the problem-solving process. I used this correlation to promote leadership of those with particular strengths as the team needed those strengths during a particular phase. Asking people to do what they are naturally gifted to do yields remarkable results. I believe this is one of the most powerful aspects of this problem-solving process.

Matt Schlegel has studied the Enneagram since 2001. His introduction to the Enneagram came through his family. Over time, he found that it was a useful tool in helping resolve conflicts in the workplace and getting teams to work together more effectively. He also discovered its powerful use as a problem-solving tool. Matt continues to study the Enneagram, discovering something new and interesting with every encounter.

Introducing Myself [Robert Lasater]

2009-10-17T11:46:00.000-07:00

Hello everyone. My name is Robert Lasater. I am the engineer responsible for maintaining this blog.If you have issues, questions or comments, you can contact me at rlasater "at" hotmail . com

My goal for this blog is to provide a forum for people at all levels of engineering leadship. For example, as a software engineer I am an individual contributor, but I have led projects from initial requirements to full scale deployments, working with domain experts, quality assurance, and customer representatives. So I want this blog to be relevant and helpful to people like myself.

Obviously the blog should also be of help and interest to team leads - people who have one or more people reporting to them, most likely supervised by a manager or director - through managers, directors to vice presidents of engineering.

Anyway, I have been working this blog for a few weeks and look forward to working with the EL SIG team to make it a Must See site for engineering leaders in Silicon Valley and across the nation and the world.

Robert Lasater is a software developer with several years of experience leading projects to develop firmware for embedded systems.

Problem Solving Tool - Step 8: Smoothing the Feathers [Matt Schlegel]

2009-10-12T13:15:00.000-07:00

The problem-solving team has performed an apparent miracle. A transformative change has taken place in the organization. Results have been measured and confirmed – the goals that the team set out to achieve have been reached, and the problem has been solved. Is it time to celebrate? Well, hold on just a minute.

Whenever there is a transformative change within an organization, there will be perceived “winners” and “losers.” There will be those whose position in the company is apparently improved and those whose position is apparently diminished. Humans are great detectors of these types of changes – we cannot help ourselves, it is just what we do. The 8th and final step of this process (at least numerically speaking) is to reach out to all those people that are affected by the change, find out what is working well and what is not working well in the post-transformation organization.

The team is no longer selling the change. The most important skill at this point in the process is LISTENING. It is particularly important to listen to those who have undergone disruptive change in the way that they perform their function. Not only has this change been emotionally unsettling, there also may be new, unforeseen issues that are impeding workflow. It is important to capture these issues and concerns, address them as well as possible, and ensure that all workflows are moving effectively.

Continuous Improvement

Inevitably, there will be some issues raised during this final listening step of great enough magnitude as to require more than a quick and simple fix. Capture those issues. The interesting thing about this process is that it is not linear, but circular. After the change, new problems arise and can be addressed with the same process, back to step #1. In this manner, an organization can be continually evaluating its effectiveness and taking the steps necessary to improve itself in a never ending cycle, a cycle of continuous improvement.

Time to Celebrate

Okay, the team has taken the time to listen to those who have concerns. You have implemented quick fixes to address the simple concerns, and have recorded those concerns of greater magnitude for careful consideration later. Importantly, you have included all those affected and taken the time to smooth any ruffled feathers. Now, it is time to celebrate! The problem is solved, the metaphoric dragon slain. Take the time to enjoy your success as a team. You deserve it.

In the next series of blogs I will return to the idea of sharing leadership during the problem-solving process.

As an engineering manager, Matt Schlegel had the opportunity to organize/sponsor some memorable celebrations. His favorites to date are canoeing on the Russian River, kayaking in Elkhorn Slough, and cooking at Culinary Center of Monterey. What have been your most memorable team celebrations?

You Say “Later”, They Hear “Never” [Tanya Berezin]

2009-10-02T13:05:00.001-07:00

I don’t have a crystal ball but this I can see without one. If you manage software development projects, this will happen on your next one:

Customers (or Marketing or Product Management) will want more than your team can deliver.
It will be your job to tell them that.
They won’t be happy.

You’ll need to deal with the immediate issue of salvaging your release and the longer term need to reestablish your credibility with the customers.

The immediate problem usually is somewhat straightforward. If you cannot get more resources - time, people, money, tools, etc. - and you cannot compromise quality, you’ll have to work with your customers to cut some planned features. Once you agree on what gets cut, they’ll want to know when the cut features will make it into the product. And, sometimes silently and sometimes out loud, they’ll wonder if these features will ever make it in.

You can’t blame them for being suspicious: they’ve had to postpone features on other projects before and in many cases these features never got implemented at all. But you need to tackle this concern quickly and persuasively, or negotiating scope again in the future will be much, much harder.

I will assume the features you postponed are worth implementing. (See my previous post on how to artfully say “no” to unnecessary work.) How will you assure your customers that you are only delaying the work, not burying it permanently?

1. Show the backlog.

Use your project backlog, product roadmap, or another list that shows planned features in priority order. (You don’t have one? Put one together as soon as you can.) Your customers worked with you on it, so pull it out and remind them what you were thinking of when you prioritized the list. If the business context has changed, now is a very good time to review and change this list. If not, your customers will be reminded that you were planning all along to add features over time and that hasn’t changed.

2. Discuss risks.

Acknowledge that reality can intervene with your best intentions. Your project could lose the backing of your sponsor; a new competitor could show up and you’d have to change what you are doing; or any of hundreds of other things quite outside of your control could happen. (For a list of typical project risks go to www.construx.com and navigate to the Resources & Tools section.) Show your customer your top risks list (you have one, right?) and your contingency and prevention plans for each. This will reassure them that you are doing all you can to protect the planned features from being permanently on hold.

3. Deliver.

Of course, the best thing you can do to maintain your credibility is to deliver what you promise. So when you do cut scope for one release, don’t overpromise for the next one. Keep track of what you estimated your team could do and what they actually did and improve your estimates over time.

This way, next time you say “later” to a feature, your customers won’t hear “never!”

Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin

Problem Solving Tool - Step 7: Git’er Done [Matt Schlegel]

2009-09-26T12:40:00.002-07:00

Finally, finally, FINALLY! – finally, we are at the step in the process where we actually DO something. We have been talking, talking, talking – all we have done is talk in circles. Now, we finally get to the DOING. It is hard to believe that we have spent so much time thinking and talking. What a waste of time! Let’s get down to the business of solving the problem. Let’s git’er done.

Know anyone who might say that?

Well, they are correct. To this point I have described 6 steps, none of which have actually solved the problem. Furthermore, to describe those steps, I have written 9 blogs. In all that, we really haven’t “done” a thing to solve the problem itself. Can you imagine the time and patience a team would have to go through to get to this point without actually jumping in to solve the problem? It is very tough to imagine for the git’er-done person who spoke in the first paragraph. Well, what have we accomplished? This is a good time to summarize:

1. We have described the problem and established goals
2. We have built a team and defined the roles and responsibilities of its members
3. We have generated a rich set of creative ideas from which to draw
4. We have analyzed those ideas and uncovered the costs and benefits of each
5. We have built a plan around the best set of ideas that will meet the goals, solve the problem
6. And, we have obtained permission to execute that plan

So, yes, while that has been mostly talking, the team has laid the foundation upon which to successfully implement a solution to the problem, and that foundation has buy-in from the stakeholders who have committed the resources necessary to accomplish the goals.

Start Small

Practically speaking, the implementation step often takes the most time. In fact, depending on the goals the team has set out to accomplish, this phase could take more time than the first six steps combined. During this implementation phase, I have found that starting small and building on successes is a great recipe to keep up the momentum. For instance, when implementing solutions that will affect a company’s product development process, I advise the team to pick just one project and prototype the solution with only that one product development team. Working with that one team, you can learn what works and what doesn’t. You can develop the materials you will need to communicate the solutions to other teams. And you can demonstrate the positive effects that the solutions have on the product development outcome. All of this makes it just that much easier for each successive product development team to adopt the solution. After a while, all the teams are using the proposed solution, mitigating the problem and accomplishing the goal.

Git’er done

And, if you know someone who might say what I wrote in the first paragraph, they may be a good candidate to take the lead during this phase of the problem-solving process. This phase is about action and the ideal person is an action-oriented leader, perhaps a team stakeholder with a program management background, who will drive the implementation and not be afraid to ruffle a few feathers along the way if that is what it takes. And, whenever you try to accomplish something big and important, feathers will be ruffled. I will address this issue in the next blog.

Matt Schlegel has a bias toward actions and has been reminded, on occasion, that he is a human “being” not a human “doing.”

Problem Solving Tool - Step 6: Tapping your Inner Medieval Salesperson [Matt Schlegel]

2009-09-06T19:24:00.000-07:00

After a much too brief summer break, I pick up where I left off. In the last blog I wrote about Step 5, creating a plan to solve your team’s big problem. This step I affectionately referred to as “The Path of Least Danger.” Now that your team has constructed the path, it is time to start the journey down that path, right? Well, not quite yet. Your core, problem-solving team may be revved up and ready to charge down that path, but the wider group of stakeholders may not be there, yet. At this point, it is time to bring the wider group of stakeholders, including the executive sponsors, up to that same level of enthusiasm. It is time to sell your plan.

Folks in sales will understand this phase of the problem-solving process very well. When facilitating problem-solving groups at this phase, I recommend that the team create a presentation that tells a story. The first part of that story sets the stage: you remind your stakeholders of the pain that they are experiencing because of their very big problem. To make this more dramatic, let’s call the problem “the Dragon.” Then, you introduce your heroes, the highly credible team of talented folks that want to slay the Dragon. You may want to share some examples of havoc wreaked by the Dragon, and some stories of early, unsuccessful attempts to slay the Dragon. Then, you will want to share the insight that your heroes had that exposed the path to the Dragon’s weakness. Finally, your story will explain the careful preparation that the heroes have made to march down that path and destroy the Dragon once and for all. And, there you stop.

What do you think that your executive sponsor/decision maker will do at this point? In my experience, having facilitated this process over a dozen times, the response is unequivocally – Go Slay That Dragon! I have found that all reasonable requests for resources - people, capital and cash – are made available for the Dragon Slaying Quest. Also, there is a strong sense of empathy about the shared problem and anticipation of a world in which the Dragon is eliminated. That anticipation is infectious – certainly the executive sponsors feel it. Also, the broader organization will eagerly support our heroes in their quest. That wide-spread support is certainly important since killing this Dragon will not be easy and will require everyone’s cooperation.

I may have stretched the Dragon metaphor to the limits here, but I think it does highlight the important step of having the team get direct permission from the executive sponsors to proceed with expending company resources to solve the big problem. The manner in which this is done is very similar to a sales process. I recommend that the team enlist the help of an enthusiastic, people-oriented salesperson-type to assist the team in both creating and telling your compelling story. With that permission, we then arrive at Step 7 in which you solve your problem. I will describe this step in the next blog.

Growing up, Matt Schlegel was much more interested in riding dragons than slaying them and fondly recalls reading the Dragonriders of Pern by Anne McCaffrey.

Say No in a Delightful Way [Tanya Berezin]

2009-09-02T12:53:00.000-07:00

We’ve all been there: your product manager comes to you with a great feature idea. You – the engineering manager – know your team is already stretched implementing the other great features scheduled for the next release. You offer to prioritize the new feature against others already scheduled and the two of you agree on a reasonable scope for the release.

It’s all very logical but doesn’t feel good. The product manager is disappointed with you: you always seem to throw cold water on his ideas. And you are annoyed, too: you wish the product manager would let you focus on delivering what’s already agreed on. Time to try something different.

Do you know why the product manager is excited about the feature? Find out: have her walk you through her thinking – what customer need does the feature meet? How many customers might need it? Is the need urgent? Are we going to make more money from it?

As you think through these questions together, the PM begins to see that you both are genuinely interested in making the product better for your customers. All of a sudden, you seem a lot less rejecting – a win for your relationship. In addition, if your PM is inexperienced and has no answer to these questions, you’ve just taught her how to be a better product manager. And if this conversation leads you to conclude that the idea isn’t as hot as it seemed at first, the extra work for your team has been headed off, never to come back.

Let’s suppose you, too, are now a believer. Are you sure your customers will be as enthusiastic as the two of you? With a little ingenuity you can find a way to test the feature with customers without needing any engineering work upfront (think low fidelity prototypes, user surveys, etc.) Thus, you and your PM have moved forward with the idea while your engineers still haven’t been handed any extra work.

(This isn’t as much work as it may seem – many times, I’ve done both of these steps in a 30 minute meeting. Last time, as the PM left my office, eager to get started, she said: “I came to ask for engineering time and you just said ‘no’ to me, didn’t you? But I couldn’t be happier. How did you do that?”)

OK, you’ve tested the feature with customers and they seem really jazzed about it. Is now the time to have the re-prioritization discussion we started with? Not quite yet; instead, can you think of a different way to meet the customer need using the features you already have? All the research you’ve just done may give you ideas on how to do that. If you do, the extra work for the new feature may never need to be done.

If after all this you are still convinced that the new feature is worth the extra development effort, then you should put it in your backlog and prioritize. But this time, the prioritization discussion will feel very different: the product manager won’t feel thwarted and you won’t feel jerked around. In fact, you’ll be delighted with each other!

Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin

The Artist Engineer and the Bottom Line [Courtney Behm]

2009-08-08T13:51:00.000-07:00

I once worked for a software company where the developers were a tight, creative team so dedicated to the success of the product that many of them had been with the company for 8, 9, even 10 years…an unusual statistic in this era of 2 years here, 2 years there. Like many companies, it hit some tough times and there was a management change at the higher levels. This new group of managers believed that software developers were interchangeable -- that one was just as good as another; that they could be moved around from product area to product area, or replaced by offshore engineers; that this kind of movement would have no real impact on productivity or morale.

It shouldn’t be too hard to figure out what happened…the core group of engineers that developed the product were broken up, a few went to other product areas, most were laid off, and all future development was moved offshore at a vastly reduced cost. Bottom line, 1. Employees, 0.

I would like to say, as a great object lesson, that the company didn’t survive as a result, but it is still very much with us. What did happen, in the words of the remaining employees, was that the heart of the company went out of it. The extraordinary culture that inspired people to work long hours, to make themselves available at all times of the day and night, to collaborate and cooperate, and, most importantly, to trust their organization, evaporated. People put in only as much work as needed to meet minimum requirements. A culture that had been voted among the best places in Silicon Valley to work became a place where people punched a figurative clock, while they waited out the recession until they could find a more hospitable home. Pretty sad, I say.

To maintain the growth and vitality of our software industry, we need committed and talented software engineers. To retain their commitment and talent, we need to be aware that they are a special breed, with a quirky way of looking at the world, and an idiosyncratic strategy for solving the problems they are given and enabling the future most of us can’t imagine. They are artists of the mind, able to make magic happen with electronics, and they have profoundly changed our expectations of what is possible. They are not, as the company I highlighted believed, interchangeable, any more than you could walk into the Sistine Chapel one day and tell Michelangelo that you were replacing him with an art student. Failure to respect this unique contribution of innovative employees might not take a company down the first time, but eventually the air will leak out of the balloon, and you will have just another formerly great company with a “For Lease” sign on the corporate headquarters. I’ve been there more than once, and I expect you have too.

But there’s a dark side to allowing talent retention to drive business decisions. It’s possible to lean over too far to protect local talent. Pandering to the tyrannical demands of a software Nureyev can paint management into a corner, and make them dependent on one or two key employees to keep the company running. An organization needs balance to survive, and sometimes fresh air and tough love are necessary to free it from the cage into which it has locked itself in a vain attempt to keep key engineers from leaving and taking all that source code expertise with them.

Artists are not the easiest people to manage, and managing artist engineers asks a lot of us Engineering leaders. We need to acknowledge and value the uniqueness of their contribution without giving up our management discretion. We need to document and share the knowledge they have given us so that we are not held hostage to their expertise. We need to respect the necessity to turn a profit without throwing the wrong people out of the boat to achieve it. We need to remember the importance of culture as a motivator, and honor it as much as the situation allows. It won’t get easier, I’m sorry to say, so over time we will be challenged again and again, caught in the exquisite tension between profit and creativity. But we are learning organisms, so perhaps we will in our turn become, at least in small part, artist leaders, more and more flexible as we enable a future that only our artist engineers can make real.

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

Investing in People [David Skyberg]

2009-08-02T21:27:00.000-07:00

Here’s an old saw that I bet you recognize: “Our people are our most important asset.” Or how about this one: “Investing in our people is just good business.” Truer words…

Yet while we all chant the same hymn, do we actually perform as if these are closely held beliefs? I will challenge you to consider how you make these axioms actionable. I’ll wager that most of us measure up woefully short.

Here’s an easy tell that might give away your position: is your training budget actually used? Or do you plan big at budgeting time with the best intentions, but consistently lament at the end of the cycle, “We just didn’t have the time to send folks to training this year.” Kimberly ought to have a flag for that (if you didn’t get that reference, you really need to come to the EL SIG more often)!

What does investing in our people actually look like? I will submit that it doesn’t look all that different than any other business objective. We ought to be able to set SMART goals (Specific, Measurable, Actionable, Realistic, Time-oriented) and be held accountable for our performance against them, just like any other goal.

Now it starts to get interesting. If we are going to have real, actionable goals, how do we establish a vision to drive our goal setting? From my perspective, if you are looking internally for this vision, you may be a bit off target right from the start! If our people are the focus, then it is their vision that really needs to be paramount in the plan. But wait! What if their vision doesn’t sync up nicely with our needs? For instance, what if Janice, your ace tester, wants to become a developer? What if Johnny’s vision is to leave development altogether and become a product manager? What if Jane’s vision is to leave your enterprise app company and get into smart grid development?

The bottom line is that if you are really invested in your people, then it doesn’t matter what their career goals are. It only matters that you uphold them and honor the individual in the process. If you do this, then for the time that they are on your team, they will be better performers, and you will be creating an alluring culture.

So here’s my quick recipe for acting on the goal of truly cherishing your people, and raising them to be all that they can be.

·Routinely set aside 1 on 1 time with each direct report to focus specifically and ONLY on career planning (I target once a month). Be disciplined about this. Don’t allow this time to digress into project status meetings. Don’t let it be a feel good, “so how’s your life going” time. Drive toward the achievement of the next bullet.

·Take as a personal goal that every one of your direct reports has established a 5 year plan for which they are passionate. Commit to this goal with your manager. Be as committed to this as you are to achieving budget/revenue goals. Act on the belief that it is just as important.

·Ensure that each of your direct reports sets near term, actionable goals that advance their 5 year plan. Ensure there is commitment to these. Hold these up as being as important as any other commitment they make. Make them part of your standard review process, and hold them accountable for achievement.

·Participate in your direct reports’ growth by setting actionable goals for yourself that help them advance their 5 year plans. Commit to these and prove to your employees that you mean it when you say you are invested in their growth.

As high flying, star performer in your own right, you will be amazed at how creative you will become in helping your people achieve their dreams. You will be astounded at how good you feel about yourself as they check off their career milestones. And you will be dazzled at the positive impact this is having on your work culture and team morale. Hey, it’s just good business!

___________________________________
David Skyberg is a software team builder with over 10 years experience building and leading teams for some of the biggest names in software, such as Microsoft and RSA Security. davidskyberg@live.com
http://www.LinkedIn.com/in/davidskyberg

New Tool: The Path of Least Danger [Matt Schlegel]

2009-07-19T22:02:00.000-07:00

In the previous blog, I described the step in the problem-solving process of how a team will analyze the various ideas proposed to solve a problem. During that analysis, the team logically thinks through the pros and cons of each idea. The team will also want to consider peoples’ emotional reactions to each idea, as that will impact the overall acceptance of a proposed solution. Having done that, the team has equipped itself to formulate a plan to move forward. In order for the plan to be accepted, the costs must be reasonable and the risks must be balanced. In my experience, I have found that after bringing a team of people through the problem-solving process to this point, there is a remarkable amount of consensus around the solutions to use in order to solve the problems the team faces. Building on that consensus, the team at this point in the process decides on a plan to move forward. This plan I like to call the Path of Least Danger.

Fear is a remarkable thing. Each of us has a different reaction to fear. I will stretch myself here with my lay knowledge of how the brain processes fear. There is a part of the brain, the amygdala, that serves as the information processor that outputs the fear response to the rest of the brain. As with much of our bi-cameral brain, the amygdala has a right part and a left part. My understanding is that one side tells our brain that something is really scary and that we should avoid it if at all possible. The other side tells the brain that you should go and destroy the thing that is making you feel this way. And, just like people can be "right-brained" and "left-brained" or "right-handed" or "left-handed", some people will have a strong reaction to fight and some will have a strong reaction to flee. (Please correct me if I have misrepresented the function of the brain, this is a blog after all.)

Since we are not quite to the point in our problem-solving process where we need to fight (I will talk about that more in the implementation phase), we can tap into the thoughts of the more "run-for-your-life" types, and I put myself in this category, to help the team formulate the path to move forward. Since the team has collectively decided already to do something, they now need a plan to get them to a solution that solves their problem. And, since all the scary pitfalls and landmines have been laid out in the analysis phase, and by this I am referring to the resources that the team would need to implement each idea and the threats that would prevent an idea from being implemented, then it is a matter of finding that optimal path that minimizes both resource utilization and threats to failure. On that path the team can build the reasonable-cost, risk-balanced plan. In other words, we can use our fear response to empower the team to choose the Path of Least Danger.

Now that the team has decided on a path forward, it is time to acquire the resources you will need to take the team down the selected path. In the next blog, we will talk about the important step of advocating the plan not only to get the permission to proceed, but to get the resources, as well.

__________________________
Matt Schlegel categorizes himself as a "fear aware" type. He taps into that characteristic as he finds that it gives him the ability to create project plans, schedules, test plans and manage quality for products. He finds that he is a "natural" at worst-case analysis, and uses that natural ability to help teams avoid pitfalls, create reliable solutions, and build high-quality products.

Zoom with Joomla or Drupal [Steve Mezak]

2009-07-11T22:56:00.000-07:00

You can launch your web app faster when using a content management system (CMS) like Drupal or Joomla or other frameworks like CakePHP or CodeIgnitor – all written in PHP. These CMSs and frameworks contain built-in functionality that will accelerate you software development. But using them the wrong way, or in the wrong situation can be a disaster.

It is critical to get a web app launched as quickly as possible. No one wants to wait months (forget years) for a new web application to appear online. The promise of CMSs and Frameworks is they give you a jumpstart with pre-built functionality and an environment that makes your programmers more productive. But like most tools, they can also be misused causing more headaches than help.

These frameworks are open source and available at no cost but they have a steep learning curve. I got excited about using a CMS for a website I was creating last year. I bought a couple Drupal books and downloaded the software from the Acquia website. It installed easily and I had a working site in a day.

Customizing the site was a different matter. I was able to easily add in several contributed modules but I found it difficult to combine modules along with my custom code to create a decent looking functional application. I basically wasted a couple weeks to discover that I really needed experienced professional help.

If you are building a community website then you should consider using a CMS platform. A CMS has these features that community websites need:

• Access statistics and logging
• Advanced search functions
• Comments, forums, and polls
• Multi-level menu system
• Multi-user content create & edit
• OpenID & Facebook Connect
• RSS Feed Aggregator
• and many more . . .

CMSs and frameworks are extendable and it is common to add code to deliver your desired functionality. For example, Drupal has a list of user-contributed modules available to extend its functionality. And your programmers can create their own modules too using the Content Creation Kit or CCK.

The primary pitfall that inexperienced programmers fall into when using a CMS is adding functionality by changing the framework itself. If your programmers “hack the core” of your CMS directly they create a mess that is difficult if not impossible to fix.

Any new development team is not likely to be able to unwind the hacks. To fix any bugs they will only be hacking the core further. In this case you almost always have to start over.

First you should decide if CMS features are needed. Selecting a CMS may only add complexity if the features you need are simple or different that what the CMS delivers. A framework that enables rapid page creation and supports modern Ajax-based user interface features can be a better choice.

The look and feel of your web application is completely configurable with a CMS. Frameworks and CMSs have a way for you to deploy your design in a consistent way. In Drupal this is called Themes, in Joomla it’s called Templates.

Versions of Frameworks and CMSs change periodically. If you outsource, make sure the development team you hire has experience with the latest version, or at least the version you want to use. For example, Drupal had a major upgrade from version 5 to 6 last year. Many of the user-contributed modules did not work with the new version. It was months before most were development teams were experienced with version 6.

Experience with these modules is critical. Anyone can install a framework or CMS, but the basic functionality is not enough. Ask for examples of web apps your prospective development teams have created for other clients and the kinds of modules and custom development they employed.

Use a development team that has experience building web applications for other clients with the CMS or Framework you decide to use. You can wind up wasting your time attempting to make a sophisticated web application on your own by using one of these platforms right out of the box unless you have already gone up the learning curve. It takes professional help.

The only thing worse than wasting your own time, is wasting time and paying money to an inexperienced development team. Choose carefully and your use of a CMS can shave months off your development time line.

_______________________
Steve Mezak, CEO of Accelerance, Inc. and author of the book, Software without Borders, has dabbled with Drupal. Use his free online Global Partner Network, containing the contact information for 40+ hand-selected and pre-qualified software development partners in over a dozen countries around the world, some of which are experts in Drupal and Joomla. http://www.accelerance.com/

Leading What [Jane Divinski]

2009-07-02T12:43:00.000-07:00

When people talk about engineering leadership they often are referring to leading human beings, specifically, engineers, but I think that it’s more accurate to realize that one is actually leading decision making. Some of these decisions are made unilaterally by the “engineering leader” but many are the result of input by multiple people in the organization. Regardless of who’s involved, the leader needs to make sure that decisions ARE made and made in an appropriately timely fashion.

Years ago my then boss informally confronted me with his concern that I might be making decisions too quickly. He pointed out that additional information is usually forthcoming and wondered if I might not be better off awaiting it’s availability before moving forward with a decision. We actually had a lengthy and enjoyable discussion about this topic.

I asked him for specific examples of such instances and he promptly cited three. I then proceeded to spell out all the information I had factored into the decision. In addition, I described other data I would like to have had to factor into my analysis and explained why such information wasn’t yet available and when I could reasonably expect said info.

We then chatted about the impact (aka cost) of delaying the decision; for these three examples he ended up agreeing with me that each involved instances where a timely decision, based on the available data was better than a delayed decision. Obviously this is not always the case.

__________________________________________
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

Be a (Part Time) Rock Star VP of Engineering [Steve Mezak]

2009-06-21T10:12:00.001-07:00

The phone rang in the meeting with the CEO. He said, “Sorry, I can’t talk now. I am in a meeting with my new VP of Engineering and he’s a rock star.”

The title “rock star” can mean different things. To this CEO it meant he finally had someone he could rely on to get the software product developed. The CEO had fumbled badly spending over $50,000 with a local web design firm with little to show for it.

Now he had hope.

A non-technical or business-oriented CEO must hire a competent VP of Engineering to take responsibility for on-time delivery of a high quality product. But what kind of person should our CEO hire? Should the VP be hands-on and contributing to the code? Or should the VP be a people manager and stay above the details of the daily builds?

Either way, you want to hire a rock star. But what is a rock star VP of Engineering?

Rock Star as a Technical Achiever. The CEO of a startup I spoke to recently wanted to hire a VP of Engineering to jump in and start doing hands-on work with Microsoft .NET. His rock star will have his or her own MSDN subscription and personally built several ASP.NET web applications.

Rock Star as a Mature Leader. Another company already had 20 software developers (and a small outsourced QA team in South America) all lead by a young but very smart programmer. He worked directly with his team to create the software.

The CEO wanted to add an experienced VP of Engineering that could harness the existing technical leadership and get some control over the software development process. With business growing, the programming team could increase to 40 people.

His rock star will be able to impose a predictable process, command the respect of a strong technical team while hiring more programmers.

Rock Star as a Global Leader. Some companies will have no internal programmers and rely completely on their offshore software development team. One Accelerance client had their own development team in Ukraine. It was a remnant of an outsourcing arrangement gone bad, which is another story.

But things were still not going smoothly. The CEO needs a rock star leader that keep a global team productive and can hop on a plane to Kiev once in a while to do so. A technical achiever with little concern for cultural issues, or a technical leader that is a good face-to-face manager will not manage a global software development team well.

It is important to understand your situation and hire a full time VPE rock star with the kind of experience that will meet your needs.

But there is an alternative.

The Part Time Rock Star. Instead of putting all your eggs in one basket with a full time VPE, a CEO can hire a part time or interim VP of Engineering to get things started. Part of the interim VP of Engineering role is to find their own replacement.

The CEO benefits by moving the programming work forward and extra experienced help with the recruiting process for a full time VP of Engineering. Otherwise a great deal of time and money can be wasted waiting for the right person to come along, or worse, if the wrong type of VPE is hired for the situation.

On the flip side, if you are looking for a full time VP of Engineering job then decide what kind of “rock star” you are. Consider only the kind of opportunities for which you are a fit. Don’t feel bad if a prospective employer is looking for a rock star of a different stripe. Focus on what you do best and the right job will come along.

But the economy being what it is, consider offering to be a part time VPE if you can’t close a full time opportunity with an employer that looks like a good fit. Working part time is a good way to get some cash flow and for both you and the employer to get started on a trial basis.

Be a part time rock star until a full time gig comes along.

____________________________________
Steve Mezak, CEO of Accelerance, Inc. and author of the book, Software without Borders, is a global software development rock star. Use his free online World Region Outsourcing Guide containing the contact information for 40+ hand-selected and pre-qualified software development partners in over a dozen countries around the world. http://www.Accelerance.com

IT Dilemmas [John Levy]

2009-06-15T19:29:00.000-07:00

As an organization grows, it has to increase the scale of IT activities, including software development. As a result, it faces these dilemmas:

1. Software development is engineering, but IT is an expense.

If your only management metric is level of expense, rather than return on investment, then you won’t be able to differentiate between winners and losers in software development. Some organizations have the CIO reporting to the CFO, because they are completely oriented to control of expenses, and IT is a large expense. But this misses the fact that investment in software, whether for internal use or for sale as a product, should be managed the way that R&D (Engineering) is managed – as an investment in development that must ultimately produce a return.

Engineering is not purely execution. R&D/Engineering involves a degree of creativity along with a professional sense of discipline about implementation. That’s why recruiting and retaining people who can balance innovation with execution is as important in Engineering as in, say, Marketing.

2. Outsourcing and offshoring work when the activities of software development can be broken into component parts and split across multiple organizations without loss of innovation or relevance of the product.

In forward-looking organizations, IT-implemented tools provide a strategic advantage to the business. To achieve this, IT strategy and architecture must be very close to the top decision makers. In this context, the question of outsourcing becomes, “can we succeed by having people we have not hired directly execute some part of our implementation?” To the extent that the impact of software or IT on the organization’s strategic goals is not considered, the decision to outsource can lead to failure in many ways.

3. If no one in top management understands how IT works, then all the IT decisions will be made based on financial reports. As organizations get big, they become more and more finance oriented. When someone at the VP level or higher has enough technical background to understand IT implementation, then IT strategy has a much better chance of being realistic. Of course, the CIO should have a basic knowledge of technology as well, because vendors will attempt to sell things which may not be appropriate to the organization. The main problem, however, goes back to item 1 above: managing Engineering is different from simply controlling expenses.

4. Traditional Project Management doesn’t fit well with Agile software development.

When we do software development in an Agile framework, we have fixed time & budget and variable functionality. Almost no one who has been doing traditional Project Management intuitively understands how to manage a project this way. Short Agile iteration cycles confound traditional PM tools and measurements. We need the PM world to come up with a new division: Agile Project Management, with a focus on projects that are not characterized by large sets of requirements up front, and have rapid fixed cycles with variable functionality.

5. It is difficult to overcome an addiction to short-term metrics.

IT managers prefer short-term pain-reduction (ship it!) over longer-term goals (is it what the users want?) every time. This leads to the never-ending cycle of code debt (code that needs to be cleaned up and/or re-written). To overcome this phenomenon we need to understand the psychology of addiction and to get top management to support a change to proper metrics. For further discussion of this, I recommend reading Gerry Weinberg’s Quality Software Management, Volume 3: Congruent Action (New York: Dorset House, 1994).

All 5 of these items also apply to software development in Engineering departments. But the effects are most widespread in IT organizations. How is your IT organization doing?

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

New Tool: Analysis, no Paralysis [Matt Schlegel]

2009-06-09T20:19:00.000-07:00

In my previous blog I described how the problem-solving team generated a rich set of ideas from which to draw candidate solutions to the challenges it faces. But, how does the team go about deciding which idea is the best one? Should they fight, bicker and argue about each?

Well, sure, in a controlled way. I call this phase the Analysis Phase of the problem-solving process, and it is part of a two step process, the second step being the Proposal Phase, in which the team arrives at a consensus regarding the path they will take going forward. In this phase, the analytical folks shine.

Every idea has its good points and bad points, its pros and cons. During this Analysis Phase, I present the problem-solving team with the list of the big ideas that have been generated. I will have taken the many ideas that were generated in the Idea Brainstorm and grouped them into a number of big ideas for the team to explore. Each big idea is allotted time for discussion and for generation of the strong points and the weak points.

It is important to move quickly through the collection of the pros and cons. For instance, if you have 100 minutes and 12 big ideas, keep the pro/con analysis of each idea down to 8 minutes apiece. You will find that you are able to collect the important points in those 8 minutes. And, you can avoid getting caught up in minutiae and falling into the proverbial rat hole. Remember, some folks will excel during the Analysis Phase and want to explore the nuances of each idea. On the other hand, some folks will find this detailed analysis a bore. You will want to strike a balance to ensure the analytical folks have a chance to show off their stuff, while keeping up the pace to get through all the ideas and, at the same time, keeping the entire team engaged.

During the Idea Brainstorming phase, you asked the team to set aside their negative reactions to the ideas aired. During the Analysis Phase, you take the opportunity to revisit those negative reactions. You will want to encourage those that feel strongly about each idea to voice their thoughts and feelings. What has happened in the roughly 7 days since they first had their reaction is that the emotional level will often have subsided and the person who feels strongly will be in a better state to explain calmly to the team the reaction that they had and why they think they had it. I have found that letting some time pass is an effective way to explore the emotional side of each idea without letting emotions rule the process.

So, after spending a few minutes on each idea, would you feel like you have done a proper analysis on the idea? Of course not! What will often happen is that the team will not have all the information that they need to adequately analyze a specific idea. In that case, I ask for volunteers, generally the biggest proponent and opponent of a given idea, to collect the information the team feels it needs to analyze the idea. If the need arises, I may call a separate meeting to review any new information, so the team has the chance to develop the pros and cons for the idea to the team’s satisfaction.
Your Problem-Solving team now has a rich set of ideas with the pros and cons for each idea. The analytical folks on the team have chimed in and provided the data and assessment that the team needs to move forward. That brings us to the topic for the next blog, the Proposal Phase, which I affectionately call, “The path of least danger.”
_______________________________________
Matt Schlegel enjoys data. During a recent presentation to a client, Matt noted that he had to pare back the amount of data in the presentation, saying that there was simply too much data. The client quickly quipped, “I never thought I would hear Matt Schlegel say the words ‘too much data.’”

Reviewing Up - Revenge? [Philippe Habib]

2009-06-02T16:53:00.000-07:00

At my first job, when the VP of engineering asked me if I could come to his office for a few minutes, I felt like I was 10 years old and called to the principal’s office. Things did not improve when he asked that I shut the door. This was my first job; I was trying my best to do good work. I mentally searched for what I could have done to be in this much trouble.

Instead, he asked for my opinion of my boss. In my previous work experience , sweeping an airplane hangar, or working in a factory, my opinion of my boss was neither important or solicited. I just had to do what the boss said, and do it quickly enough and well enough to keep my job. I had no idea of how the boss was evaluated, but I was sure that what I thought of the boss never entered the equation in any way.

I don’t remember exactly what I said. Probably something lame like “She’s fine.” or some such. This really wasn’t enough to satisfy him, so he asked me more detailed questions.

• Did my manager make it clear to me what I was expected to do?
• Did she provide me with relevant and useful feedback along the way?
• When I needed help, did she provide it?
• Did she give me too much guidance and try to control my every step?
• Did she have adequate technical skills to give me the help I needed?
• Did she act in a way that made me uncomfortable or afraid to ask for help?
• In areas where another person in the department had more knowledge, was she willing to defer to that person, or did she always need to act as the expert?
• When I did something wrong, did she tell me what I did wrong and explain what I should have done instead? Was this delivered in a constructive way that helped me learn and do a better job the next time?
• Did she give me guidance about what I could be doing to get myself ready for more responsibility in the future?

Once I got over shock of having the tables turned and being asked to evaluate the boss, I answered the questions as best I could.

After we were done, I had my own question. Since she was the manager of 6 or 8 engineers and I was the newly hired, zero-experience, source control person, what did it really matter what I thought of her? I would do what she said and get my work done, whether I liked her or not.

The VP explained to me that the manager’s job went beyond making sure that I had current listings of all software and that I could build the same executable each time. Her job was to make sure that I did my job in an efficient and effective way and that I was happy doing it, so that I would not look for another job. She was also to help me grow into a more skilled role. She wanted me to succeed and be able to relay my knowledge of the company's products and processes, so that they would not be lost when I was ready to do something else.

He explained that all he could evaluate from his position was that the work was getting done, (dust on the floor, finished machines on the rack). He also cared about the stuff that would keep people happy and productive long term, so that he wouldn’t have to hire a replacement for me or have schedules jeopardized by turnover. In order to get that kind of information, he had to solicit it from the people who report to the manager.

Looking back on it after more than 20 years in the work world I now see benefits for all involved in this kind of a review. The VP knew if productivity was the result of fear and intimidation and would vanish, when his people did, at the first upturn of the job market. My manager could be alerted to good and bad habits and become a better and more effective leader. As an individual contributor I was able to influence my work environment and to learn about the bigger picture of how a department is run.

I'm sorry to say that in over 20 years of industry experience I have never worked at another company that did that kind of a review. Lacking the explicit interest from upper management, most people don't take the risk and trouble to review their manager. They just vote with their feet.

______________________
Philippe Habib consults on embedded device design and firmware. Prior to consulting he has worked for Oracle, IBM (lotus/cc:Mail), Apple, and several startups. More information can be found at www.phenomasoft.com.

Managing the Creative Process [Courtney Behm]

2009-05-28T22:06:00.000-07:00

So…you have a product that is core to the success of your organization, and you’ve just realized that, though the titles of your team say Software ENGINEER or DEVELOPER, it should really be ARTIST. Add to that the challenge of software itself, a product that is often indistinguishable from magic, and you have a dilemma. How do you maintain the level of creativity you need to be cutting edge and still deliver on time?

Let’s talk about the planning process. Consider, for a moment, Microsoft Project. I know, I know…a fearsome thought. So many people have an antibody reaction to using Project; I’ve worked at companies who have refused to use it, relying instead on Excel spreadsheets and lots and lots of manual updates to manage complex development programs. Microsoft Project isn’t perfect, no question about it, but it’s not really that bad. Its biggest problem is that it isn’t flexible enough to track the work of artist developers. It’s an artifact of the waterfall methodology, symbolized by the horizontal Gantt charts with their slick interdependencies that adapt every time a date is changed. It assumes that the project is one monolithic whole with interconnected moving parts. You start with A and move to B and then to C, and before long, you intersect with D. Waterfall methodologies focus on maintaining these relationships to keep the project on track. For some applications, it works wonderfully – IT infrastructure projects, vendor evaluation, customer betas and product launches, to name but a few -- but waterfall, and therefore Project, isn’t the best tool to support the more fluid vision of the software developer.

In reaction to the restrictions posed by waterfall, we now have “Agile” programming, with its various manifestations…the one I’m most familiar with is Scrum. Agile is pretty much exactly what its name indicates. It’s a way of approaching software development that allows us to bob and weave, to take advantage of discovery, to place enough rigor around the process to know what is going on, but to keep options open. Agile says that the best results arise from small, iterative development chunks. You come together as a group, you meet every day, and you chart your progress with tools that can be easily adjusted as you discover more and more about what your product really needs. And within a short time, you have a usable, working piece of functionality. It changes the game.

But Agile programming seldom takes place in a vacuum. Inevitably, there are customers and deliverables, and we need to sell product to make money. So elements of waterfall creep in under the cover of darkness. How can we support the creativity of our software developers and still march to the corporate drumbeat of deadlines, release schedules and launches?

Eventually, common sense trumps methodology, and a hybrid scheme emerges…not as crisp and apparently predictable as waterfall, and not quite as free and creative as Agile. This is a compromise with which no one is completely happy, but which honors both the need for flexibility and the need for predictability. However, it isn’t easy. Knowing when to let the creative energy flow and when to rein it in is a dance that doesn’t come naturally to most of us. We are called to come out of our comfort zone and live in two worlds at once. And this management challenge has a tendency to change emphasis depending on the breadth of our responsibility to the organization. The closer we are to the development process itself, the more comfortable we will be with an Agile approach. The closer we are to the Boardroom, the more we will want things to be certain.

But to be successful in this volatile, ever-changing world of software, we have to listen to the development process as if it could talk, and let it tell us what it needs. When we consider it as a living organism, the combined DNA of marketing and engineering creativity, the offspring of a company that depends on it for survival, we can see more easily where the touch points are, where we can apply structure, when it’s time to let the ideas flow, when to say, “That feature won’t make the release” and when to say, “This feature is worth waiting for.” It may mean letting go of some old assumptions about how things work, but the final result will be the best of both worlds.

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

New Tool: Exploring the Idea Space [Matt Schlegel]

2009-05-21T17:50:00.000-07:00

In my previous blog I described how one goes about rounding out the team for your problem solving initiative. Now, we dedicate the team to dreaming up as many ideas as possible to solve the problem and achieve the goals. I call this the Idea Brainstorm.

What is an Idea?

An idea is any thought. It may be a big, complex thought. It may be a simple thought. It may have come up before. It may be a newly minted thought. It may be “good.” It may be “bad.” It may be funny, or serious, or even impossible. No matter – all thoughts and all ideas are welcome. The idea brainstorm is a chance for the group to flex its creative muscle. Encourage the team not just to explore boundaries but jump over them and run as far away as possible. My dear friend and mentor, Kimberly Wiefling, encouraged me to start each brainstorm with a warm up exercise. I will never forget when she had us brainstorm the similarities between a refrigerator and a cat. This is still my favorite warm-up theme. My favorite answer to date is that they are both endothermic, a property of both biological and physical systems (Thanks, Mike Plasterer!). Every time I conduct this warm-up, I enjoy hearing new ideas, which reminds me of the importance of including team members of varying backgrounds and experience.

After the warm-up, I have the team brainstorm ideas to solve each objective and its related problems. I try to have the team consider both the objective and the problem since each view may generate different ideas. I ensure that each problem/objective is allotted time for brainstorming. If there are 10 problems and 50 minutes, I will monitor to ensure that the team start the transition to the next brainstorm topic after 5 minutes. Intentionally, this session quickly becomes a high energy meeting with many ideas being bandied about. I will stand at the flip chart scribbling down each idea as it is aired – no filter. For instance, if multiple people say the same idea, I will write it down multiple times.

Some people will be natural contributors in this environment. Some will not. The Naturals will chime in without much prodding. Those that are quiet have important contributions that must also be aired. After the initial idea frenzy, I will go around the room and ensure that each person has had an opportunity to contribute a thought or two. I also remind people that some ideas may spring up after the meeting. In that case, I encourage the team to send me the ideas by email. The point is to get as many different ideas into the mix as possible.

Sugar!!!

In order to keep the energy high, I bring tasty, sugar laden treats for the team to enjoy. These treats provide the fuel to keep the team powered for the entire session. While I generally do not strictly prioritize the problems and the order in which each is brainstormed, I do try to leave the less difficult problems for later in the meeting, just in case the team starts to run out of steam. Of course, sugar can only take you so far, and the longest I would advise conducting this type of brainstorming session is 90 minutes.

First Reaction

A word of caution – what is the first thing that happens when you hear a new idea? You have an emotional reaction. That idea is great! Or, that idea sucks! It is inevitable that each person will have a reaction to each idea. I explain this phenomenon to the team and acknowledge that they will have these reactions. In the case of a negative reaction, I encourage the person with that reaction to think before they blurt, to think about why they are having that reaction, and then to think about how they might solve the problem in a manner more suitable to them. In other words, I encourage them to re-channel the negative energy from the reaction into a positive idea that they can share with the group. I assure them that we will have a chance to analyze the negative reaction at a later meeting, but not at this session. In this way, the team maintains a high energy level and a positive tone for the duration of the brainstorming session.

Idea Space

At the end of this session, you will have a rich set of ideas to work with. You will have allowed all the team members to contribute and to appreciate the contributions from each other. I have found at the end of this meeting, the team morale has increased. There is a sense of hope. The team sees possibilities for solving the problems and paths to reach the goals. In the next phase, the team will scrutinize each path and assess its viability relative to the others in what I call the Analysis phase.

_______________________________
Matt Schlegel’s fondness for the “Refrigerator and Cat” warm-up exercise comes from a deep-seated love/hate relationship with cats starting with his first pet cat “Fufu” and her fondness for gasoline to a more recent run-in with neighborhood cats and their propensity for fertilizing his front lawn. To address the “fertilizer” problem, Matt developed an alarm, uncleverly dubbed “Cataway,” that would direct ultrasonic sound into the “blast zone” when a cat would enter. Results: no more “fertilizer” on the lawn.

Will complexity overwhelm us? [ John Levy ]

2009-05-16T21:08:00.001-07:00

Should we worry about software being too complex?

I’ve been teaching a course to elders about how computers work – both hardware and software. The challenge in such a course is to make the content both true and accessible while keeping the presentation interesting.

Hardware is in some ways easy to teach. Once a student grasps that all computers involve the interaction of a processor with memory (both for instructions and for data), there is only the matter of input/output left to deal with. Well, OK, there’s bootstrapping and operating systems and a lot of other stuff in there, but knowing about the processor and memory is the only crucial step to understanding how it runs.

But what about software? First I explain that nobody writes in machine code; very few write in assembly language; and even procedural languages like C and Pascal are being abandoned for object-oriented languages. So I have to get across, first, that people who create software are thinking abstractly in terms of algorithms and procedures. Then the next level of abstraction is objects and messages. And finally, the tools of the trade include editors, compilers, linkers, loaders and program (and object) libraries being used in Integrated Development Environments (IDEs).

And I haven’t even touched on testing and QA yet. How is a layperson going to come to appreciate the difficulty of producing a properly-functioning program? Yet everyone knows war stories of how failing software caused lots of damage. Is our knowledge of testing methods inadequate, or are we just being poorly managed?

Gerald Weinberg, in his recent book, Perfect Software and other illusions about testing (Dorset House, 2008), does a brilliant job of explaining to non-experts why testing doesn’t – and can’t – produce the eponymous perfect software. I highly recommend reading Chapter 14 of his book, which starts off with a study of failed and successful projects at IBM. All of the projects had “bad luck” strike during the projects. His conclusion is that success was a function of good management, not avoidance of bad luck.

Fifty years of Moore’s Law has given us computing power in our pockets that is greater than the room-filling machines of the 1960s. And we have whole networks of tiny microcontrollers inhabiting our homes and our cars. How are we going to deal with the prevalence of bugs in these devices?

No one says the code has to be perfect. But it has to be structured in a way that keeps it from failing catastrophically. And it has to be adequately tested even as it gets larger and more complex. Are we up to the challenge?

I firmly believe that Agile software development frameworks give us the best path to developing decent software. But they are not enough. We have to manage ourselves and our organizations in ways that permit healthy development behavior. This is what Agile Management is about: giving up certain counter-productive behaviors and establishing new management patterns that encourage constant improvement in the face of increasing complexity.

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

A PM with a Different Approach [Philippe Habib]

2009-05-09T08:49:00.000-07:00

In the 20 plus years of writing software, I have acted as a project manager (PM), as well as having worked for a good number of PMs. A recent experience really made me re-evaluate what makes for a good project manager.

Most of the project managers I have worked with acted as the tie-breaker, or opinion of last resort when it came time to decide on features or schedule. They’d come up with a schedule, often guided by when the client wanted it done, and a list of features that the client desired, and keep tabs of progress during weekly meetings as time went on. Everyone on the development team always had a great relationship with them. Note: I mean client in the largest sense; either Marketing or an actual customer.

This all changed when I worked with a PM who had a very different approach. He started off with a list of features that the client requested, and asked each engineer to commit to the time required for every feature. Then, he turned that into a schedule and got the client’s approval.

Starting at that point, engineers were held to the schedules to which they had committed. A schedule slip was not treated as an inevitable part of the development process, but as a real problem that needed to be addressed and remedied. Engineers were asked to find ways to recover lost time without abandoning other commitments made to the client. This PM wasn’t a good buddy who drank coffee and ate doughnuts with us for an hour a week at project meetings. He was a tough taskmaster who pressed us to deliver what we had committed to.

During these same meetings, we’d often hear the client give feedback on the progress as they saw it, and maybe ask for feature changes or additions. This PM defended the original schedule just as doggedly in those instances. New features or changes would mean, at the very least, some time spent evaluating the impact on schedules and deliverables. Maybe it would mean more time, or dropping other features, or maybe even less time, but nothing got committed to without a thorough evaluation.

At the cost of losing a good buddy during project meetings, we gained a clear view of expectations and some strong protection from the feature creep that kills schedules, and make projects drag on, and rob everyone of the feeling of completion and a job well done. Besides, we could always be friends outside of the project meetings.

______________________
Philippe Habib consults on embedded device design and firmware. Prior to consulting he has worked for Oracle, IBM (lotus/cc:Mail), Apple, and several startups. More information can be found at www.phenomasoft.com.

New Tool: Building your problem-solving team [Matt Schlegel]

2009-05-05T13:35:00.000-07:00

My previous blog entry discussed the first step in a problem solving quest: the formulation of a problem and goal statement for the initiative. The next step is to pull together the team you will need to achieve those goals and solve those problems.

First, break all the rules

Marcus Buckingham, in his book “First, Break All the Rules,” describes the metaphor of people having super-highways or bumpy country lanes for executing a given task. His point is that not everyone is good at everything and assigning folks with super-highways to a task will get you there much faster than will the person with the country lane. I have found that this is true of problem solving as well. Some folks are great at describing the problem. Some folks are great at coming up with creative ideas. Some folks are great at analyzing the ideas. Some folks are great at building a plan to execute the idea. Some folks are great at selling the plan. And, some folks are great at driving the plan through to completion. And, while you can find people who can do more than one of these areas well, it is difficult to find one person who can do them all well. You will want to keep the strengths and weaknesses of your team members in mind as you construct your team.

Beyond the Stakeholders

In defining the problem, you have already pulled together a team of stakeholders. In addition to these folks, you will want to think about who else may need to be involved in the initiative. Were there other groups identified during the problem description meeting that contribute in some way to the problem? If so, you would want to consider including them. Is there certain expertise required to solve the problem? If so, enlist the help of an expert. Will there be an impact on the workflow of any group or groups in solving the problem? If so, make sure those groups are represented. How about systems and IT infrastructure? If yes, ensure an IT representative is part of your group. Simply put, ensure that the people who need to be involved in both designing the solution and living with the solution are represented on your team.

Roles and Responsibilities

Take the time to ensure that every member on your team understands his/her role in the initiative. Prior to meeting with the entire team, I tell all the participants that they will be expected to describe how they will contribute to the team. At the meeting, I document what each member says, and this document becomes the Roles and Responsibilities document for the team. Challenge the team to think about what other resources they think they will need to solve the problem. Also, challenge those with a clear vision of their role on the team as to whether they need to participate in the initiative at all. At the end, you should have a clear description of each team member’s role and how they plan to contribute to solving the problem.

Housekeeping

If you have added new members to the team since the original “Problem” meeting, then you will need to loop back with the new members and ensure that the problems from their perspective are aired and recorded. Once any new problems are captured, you will want to check to make sure that the goals will address the new problems. This is an important sidetrack to ensure that new team members feel vested in the process.

Check in with the Sponsor

Once you have identified your team members and each of their respective roles and responsibilities, you will want to check in with the sponsor. Brief the sponsor on the team you have assembled. Also, get feedback to make sure you have your super-highways in the best places. With your team in place you are ready to move on to the next step. In my next blog entry I describe the creative idea brainstorm.

________________________________
Matt Schlegel learns a great deal about teams by watching his children participate in team sports. He finds it fascinating to watch how children identify with their budding super-highways. He also finds it fascinating to watch how great coaches inspire kids with a positive attitude that carries over into their support for each other.

Software Evolution [John Levy]

2009-04-27T08:13:00.000-07:00

There are some principles of software development that were described by M. Lehman by observing large-scale development teams (such as IBM’s OS/360 development in the 1960s). When you put several of these principles together, it is not very encouraging for those of us who are concerned about software quality.

1. Early bug rate predicts late bug rate
You would think that if you fix a lot of bugs early in the project, you could expect to have a lot fewer bugs later. In fact, observation shows that projects that have (and fix) an above-average number of bugs early tend to have above-average bug rates later.

2. Software grows over time

As users demand more features and functions in their software, the size and complexity of a released software package tend to grow.

3. Bugs are introduced when bugs are fixed

No matter how careful we are, sometimes we introduce bugs while we are fixing others. As long as the ratio of bugs-introduced to bugs-fixed is low, working on bug-fixing is a productive enterprise.

When you combine these observations, things get stickier. For example, the ratio of bugs introduced to bugs fixed tends to get larger as the software package gets larger. As a result, bug-fixing gets less and less efficient as time goes on because of the growth of the software.

Also, we can imagine that putting a major push on early bug-fixing in project could drive up the introduced-to-fixed ratio, thereby keeping the first rule valid – we’ll find even more bugs later.

What’s an Agile manager to do?

First of all, pay attention to bug-find rate and system size and complexity. My guess is that having the software developers fix their own bugs before QA sees the software doesn’t fall into the domain of the first rule. In any case, it’s a good thing to have a designer/implementer see exactly what went wrong – it’s a good opportunity to correct one’s thinking. Of course, Agile principles suggest that pair-programming does exactly this at the earliest possible moment in the coding process.

Second, always strive to reduce complexity, whether by simplifying the model, partitioning the system, or adapting to existing services rather than inventing new ones.

Finally, make sure that your teams are relentlessly refactoring the code. The teams always learn better and better ways to streamline and simplify the functions they’ve already implemented, so don’t hold back on letting them express that knowledge.

If you want to read more on how software evolves over time, do a search on “Lehman software evolution” and see what’s been learned.

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