Get out of the way

Tips on managing product development and engineering by John Levy, consultant, expert and author of "Get Out of the Way!, An executive’s guide to creating timely, innovative and relevant products."

My Photo
Name:John Levy
Location:Point Reyes Station, California, United States

John Levy is a consultant focused on managing product development and innovation in high-tech companies. As a strategic thinker, he helps make R&D and product development organizations a key competitive advantage for their companies. He has over 30 years of experience in the computer, software and storage industries. His publications include articles on managing software development, and he is currently completing a book on management, titled “Get Out of the Way.” Dr. Levy holds patents in computer design and is a regular expert in patent litigation. He has advised U.S. District Court judges on technology, and he teaches technology courses at the University of San Francisco Fromm Institute. A regular speaker, he has also produced a weekly show on technology for a local public radio station.

Tuesday, February 20, 2007

Technologist or Manager?

Who is helping you to become a better manager?

If you're lucky enough to be employed at a larger company with a long-term view, like IBM and HP, you may actually be getting training and coaching that helps you grow in your job as a manager. But most of the rest of us -- particularly technical people who have come up through the ranks -- are learning on the job, mostly by making mistakes.

In startups and smaller companies, there are no resources for helping managers get better at managing. The executives are satisfied if you simply get the job done, such as getting the product out the door. If the consequences are burnout -- by you or by your team -- that's just collateral damage.

Besides, managing is just good project management, isn't it? If you can fill in the data in Microsoft Project, print the charts every week, and make forward progress on your timeline, everyone will think you're in control and doing what's needed. Won't they?

I don't buy it. Managing is an art. Just because you came into the job with great technical skills and a lot of experience as a project leader, you don't necessarily find yourself as successful as you imagine you could be. There could be better ways to keep the teams aligned on the projects. There could be better ways to coach the managers under you on dealing with "people issues." And you could be inspiring your management team with more innovative ways to develop products.

If you're struggling with being a manager or an executive responsible for high-tech development, you may be part of the collateral damage. It could be time to look for ways to learn about the art of management. First you have to believe that managing is a profession, and that you can be good at it; that it's worthwhile becoming a professional at managing; and that the manager's role goes far beyond being a technology leader.

One of my talks last year was titled, "What does management have to do with innovation." You can get a copy of the outline at - Mgt & innovation.pdf

You have to put yourself out there to become a good manager, to keep your teams from burning out, and to enjoy the role. Make the effort, it's worth it.

Monday, October 23, 2006

Loss Leader

My colleague Joel Harrison is good at encapsulating learnings from his experience. A few weeks ago, while I was visiting him at his startup company, Abrevity, he said, "You can't justify a new product based on a cost analysis of the first-generation product. You have to have a vision."

Joel and I had experienced the frustration of trying to create new products at a company that was in a high-volume, low-margin business -- hard disk drives. On the one hand, Joel had prototyped a product that could have been the first available Ethernet-interfaced free-standing disk storage unit. I had been involved with defining a disk drive that stores and plays back video streams without a computer attached. While our company had funded the early prototyping of these products, it did not make the investment needed to launch them as consumer or end-user products.

Joel's explanation, as I understand it, is that the company did an analysis of the cost of the first products in each case and concluded that the product cost too much to be priced reasonably in the marketplace. Now here's where "vision" comes in. When you're introducing a radical new product, you have to price it not based on the initial product's cost, but based on a combination of the needs of the market and the expected cost curve as volume increases.

Companies selling services, such as cell phone service, do this all the time. To make the service workable, they have to invest a large amount of capital in infrastructure, such as cell phone towers, switching equipment, and so on. But pricing of the phone service must chosen both to make it attractive to the consumer and, when the number of subscribers reaches a reasonable target, to make a reasonable return on the investment.

The same thing is true with new products. The barrier to radical innovation and new product introduction in companies that have been operating in a low-margin high-volume environment for years is primarily a failure of imagination. They need the vision to see that (a) there is a market to be created or captured, (b) the product they have conceived is viable, and (c) initial pricing will lead to losses during the early stages of market development. Venture capital is based on selecting and funding this sort of innovation. But old companies have trouble thinking outside the low-margin, pay-for-itself-or-die product box.

That's what Joel was telling me. If we could have planned the new businesses beyond the first product, and had got a commitment to fund the initial losses, we could have made history in disk drive marketing.

Monday, September 11, 2006

Shifting the focus to longer term

Startup organizations are typically unsustainable and barely stable, because:

1. The pressures to develop and market a first product require taking some expedient shortcuts, such as hiring the most capable, but not necessarily the most team-oriented individuals; placing all priority on getting a workable product out the door, rather than building the product for maintainability and growth; putting in the most features rather than the best-tested features.

2. The top management habitually focuses on the race between funds running out and product delivery, rather than on internal communications, employee satisfaction (except with the potential value of their options), and leadership style. The command-and-control management style is workable for the first few years, but typically fails to inspire the organization to build itself into a self-renewing structure.

3. Having a focus on delivering a product using already-developed technology, the company does not need to invest in longer-term development of underlying technologies, or in the people who will bring in a steady stream of new technology.

The short-term focus of a startup must change soon after the deliver of the first few products. Companies that fail to incorporate longer-term thinking around their third year find themselves living from crisis to crisis. This makes the company unattractive to good managers and good technologists who don't necessarily get their jolllies from living in a startup environment, where "startup" means short-term thinking.

What sort of changes does your organization need, now that the product has been delivered? A new CEO who actually allows the organization to function as if there were competence at all levels? A seasoned technology executive who knows what to do to make the organization attractive to innovative people? A shift in emphasis to listening to customer feedback and involving existing customers in product decisions? Addition of a Quality department that actually has the teeth to delay a product introduction?

Whatever the changes needed, don't be surprised by the shift. Two reactions to the shift are typical:
(1) "What happened to my adrenaline rush?" -- the people who need crises to keep up their energy should pursue another startup.
(2) "I didn't know that a company could actually plan and execute with the future (beyond 1 month) in mind!" -- the people who are stressed by the company's failure to plan and execute for the long term grow into steady, reliable contributors.

Monday, August 28, 2006

Is your software on fire?

The spectacle of Dell laptops on fire due to Sony battery problems has prodded me to think about product failures. There is nothing so attention-getting as a fire in a conference room. Few people who see this sort of failure will forget what they have seen.

Software failures may not be so spectacular, but they can be just as memorable to the people who witness them.

Examples from large-scale software systems: if you were waiting for your baggage in the new Denver airport a few years ago, you may have waited until human intervention delivered your bags, because the bag sorting system failed. And what if you dialed 911 and the call did not go through?

Examples from embedded systems: your cell phone drops a call due to a software glitch in the phone; your hard disk loses track of its position and takes an extra several seconds to recover.

Examples from everyday use of an operating system: Windows gets confused while processing interrupts from the web browser, and the browser hangs until you reboot; Outlook misses a beat and an email doesn't appear on the screen when you expect it to.

If the computer or phone were to catch fire when any one of these failures occurs, you can bet that the manufacturer would do a massive recall the way Dell has done. But they didn't. Instead, they let the users keep on running with a piece of software that "catches fire" regularly. If you're like most users, you have become accustomed to seeing these fires and dealing with them. But do you like them? Of course not.

What are the consequences? Word of mouth travels quickly, and these failures have created a large population of users who resent having to use devices and software that fail. Resentment leads users to search for a better alternative. This is good for competitors who offer a better, unfailing solution.

But the whole world of software (and digital devices that depend on software) suffers from a bad image because of these failures. From consumer devices to mission-critical industrial control systems, everyone who has to deal with modern digital devices is gun-shy about failures. And rightfully so.

Is your software on fire?

There are known methods to assure that the software-dependent devices you make will not catch fire. If you're not certain what these methods are, or who can implement them for you, you need to find someone who can help. But before you call in a consultant, be sure that you're willing to pay the price: It takes time and money to make software reliable, just as it does in batteries and laptops. Are you ready to buy in?

Friday, June 30, 2006

Development Process Stability

After shipping a first product, successful companies face a number of challenging problems in product development, including lack of development process stability as development work scales up. Here are some responses that have worked well in the computer, software, storage and consumer electronics industries.

Why process selection matters now

As Product Development scales up to involve multiple concurrent projects, three things happen to stress the development environment and to threaten its results:
1. The informal processes used at startup no longer work reliably to get quality products produced on time.
2. More managers are needed as the development department becomes too large for one person to manage directly.
3. Supporting customers and manufacturing takes time away from development but offers opportunities for feedback that must not be ignored.

This is an opportunity to choose good processes for the next 5 years. There will never be time to reconsider process selections. The cost of change only goes up.

Managing multiple projects is more complex. Engineering and Product Marketing must cooperate in new ways to assure that the next generation of products is successful.

Founders and early employees who are technologists have been crucial to success, but they may not be willing or able to make the transition into a development environment that is sustainable for the long run.

Development processes

Development must move out of crisis mode, so that projects can be completed on a predictable schedule.
There may have to be changes clarifying who is responsible for setting project goals.
Project management tools need to be used to manage schedules and feature lists without overloading the development team with overhead tasks.
When a milestone is missed, rapid analysis and decision-making is critical to staying on track for product introductions. Certain metrics are useful here, and project teams need feedback about how they’re doing.

Development tools

Who is responsible for Quality? The Development department must get serious about product quality, even if QA is managed from Operations or elsewhere.
Bring in hardware and software tools for testing, establish disciplined procedures for release, and stay in the issue/correction feedback loop.
In addition, Development can provide useful input to product direction in the next cycle through interaction with customers and field staff.

If you would like more information about how we assist growing companies with managing product development for the long term, please call 415 663-1818 or email

Tuesday, June 20, 2006

What is Product Marketing's role in development?

A colleague asked, "Do you believe Product Marketing could be the bridge between the Engineering and R&D organizations? It seems to me that market requirements are the other piece to incorporate there and Product Marketing could add that to R&D’s specs before working with Engineering to determine what’s feasible and on what time schedule… What do you think?"

It works at the front end to have an Advanced Development group build prototypes and conceptual specs/models, with specs or requirements added by Product Marketing before giving them to Engineering. But the problems (below) don’t come out until the crunch — when you’re waiting for the next milestone in actual product development.

The problem is that Product Marketing and Engineering (the responsible department for developing products delivered to customers) have a natural tension: they have to arbitrate between what’s feasible within the time/dollar/featureset constraints; Product Marketing should have the customer deliveries in mind, and should interpret “what the customer wants,” while Engineering is responsible for determining which (and how many) features can be delivered within the cost and time constraints.

As a product is developed, Engineering will naturally come back now and then to renegotiate features vs. schedule (and sometimes $) as they uncover problems (or opportunities) that impact schedule. Product Marketing cannot act as the arbiter for this negotiation — Engineering must participate as a fully-responsible party, determining what can be delivered when. When Product Marketing has all the power in this negotiation, you either get emasculated Engineering, which won’t take any chances because they’re being second-guessed; or you get promises that can’t be kept, because Engineering isn’t really running the development process.

Friday, May 19, 2006

A + B + C ≠ D (The game changes at the fourth round of financing)

When a startup company reaches a certain size, a number of changes have to occur to allow it to survive. Here are some of them:

1. The founders have to choose new roles for themselves. Having been key idea-people or leaders of a particular part of the business process, they may have trouble envisioning themselves in a role that meshes with a larger company. This is OK -- particularly if they are willing to go off and found another company. Where it's not OK is in a company that desperately needs to establish processes that work for the long term, and a founder is standing in the way of moving in that direction. The impetus to change things may come from the venture investors, from other key executives in the company, or -- rarely -- from a founder him- or herself. 'Tis a wise founder who knows his/her own limitations.

2. Product development has to become more predictable. While at this stage of growth a company often is launching multiple development projects at the same time, the need to know when the process will complete becomes more important as the customer base grows and Marketing starts implementing more sophisticated product introductions. In addition, the engineers who have survived the startup environment are often close to burnout, accustomed to an unstructured work environment, and unwilling to consider that in a larger company, risk has to be reduced. What kind of risk? Things like making sure that software backups are made, versions of code are archived, drawings are in fire-safe locations, and that the website is not offering free access to proprietary design information.

3. Knowing how long it will take to implement certain features, whether software or hardware implemented, is key to becoming predictable. Predictablity can be helped by agile development methods, which emphasize frequent demonstrations of working models, making regular estimates of output over the next few weeks and refining one's ability to predict that output. This gives the developers a lot of say in the process, while also getting realistic "customer" feedback on features and functions on a regular basis.

4. The company management may have to pay attention to issues that aren't so prominent during the early startup phase, such as infrastructure (development tools, website and equipment maintenance), retention & professional development, trade associations & standards, and intellectual property protection.

5. Scaling up the company is not just a matter of cloning the existing projects and production lines. As a new layer of management is brought in to allow expansion of the operating departments, the top management must examine its way of working, including values, culture, communications, and transparency. Plotting strategy without considering these factors can leave them wondering why the workforce isn't following management's lead.