Wednesday, December 9, 2009

Comments Are No Longer Moderated [Robert Lasater]

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.

Sunday, December 6, 2009

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

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


Friday, November 27, 2009

Finding the Problem-Solving Super Highway [Matt Schlegel]

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.


Wednesday, October 21, 2009

Managing Risk in IT organizations [John Levy]

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

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


Tuesday, October 20, 2009

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

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.


Saturday, October 17, 2009

Introducing Myself [Robert Lasater]

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.


Monday, October 12, 2009

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

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?


Friday, October 2, 2009

You Say “Later”, They Hear “Never” [Tanya Berezin]

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 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


Saturday, September 26, 2009

Problem Solving Tool - Step 7: Git’er Done [Matt Schlegel]

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.”


Sunday, September 6, 2009

Problem Solving Tool - Step 6: Tapping your Inner Medieval Salesperson [Matt Schlegel]

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.


Wednesday, September 2, 2009

Say No in a Delightful Way [Tanya Berezin]

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


Saturday, August 8, 2009

The Artist Engineer and the Bottom Line [Courtney Behm]

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 (, 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.


Sunday, August 2, 2009

Investing in People [David Skyberg]

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.


Sunday, July 19, 2009

New Tool: The Path of Least Danger [Matt Schlegel]

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.


Saturday, July 11, 2009

Zoom with Joomla or Drupal [Steve Mezak]

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.


Thursday, July 2, 2009

Leading What [Jane Divinski]

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


Sunday, June 21, 2009

Be a (Part Time) Rock Star VP of Engineering [Steve Mezak]

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.


Monday, June 15, 2009

IT Dilemmas [John Levy]

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


Tuesday, June 9, 2009

New Tool: Analysis, no Paralysis [Matt Schlegel]

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.’”


Tuesday, June 2, 2009

Reviewing Up - Revenge? [Philippe Habib]

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


Thursday, May 28, 2009

Managing the Creative Process [Courtney Behm]

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 (, 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.


Thursday, May 21, 2009

New Tool: Exploring the Idea Space [Matt Schlegel]

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.


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.


Saturday, May 16, 2009

Will complexity overwhelm us? [ John Levy ]

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


Saturday, May 9, 2009

A PM with a Different Approach [Philippe Habib]

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


Tuesday, May 5, 2009

New Tool: Building your problem-solving team [Matt Schlegel]

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.


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.