Is your software on fire?

The spectacle of Dell laptops on fire in the summer of 2006 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?

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 department responsible 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.

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 visit https://johnlevyconsulting.com, call 415 663-1818 or email info@johnlevyconsulting.com

Why is Engineering the last to call for help?

Engineering and the product development organization are critical to a company’s survival. In successful companies, they deal daily with a vast array of problems, from technology shifts to people loss. One of the key talents of successful technical managers is to deal with changing priorities and resource availability. They manage these dynamically whether by PERT charts or just seat-of-the-pants intuition.

So why is it that they don’t often ask for help?

I believe it has to do with two aspects of the occupation itself.

(1) When your daily life is filled with adaptation and improvisation, you have trouble imagining that there is anything anyone can do to help. Your talent as a technologist managing others is to be able to evaluate technical directions in an instant, moving people around to cover the top priorities of the day, and communicating to your bosses what is going on. How could a consultant or an internal mentor help this kind of activity?

(2) You are already in the midst of trying to improve the engineering process and the way your people accomplish projects. You have the credibility with them, so you can influence their work to improve a little at a time. It is inconceivable that an outsider, or a non-specialist insider, could have more influence on your staff.

The Marketing Department and even the Finance people know that Engineering is in trouble when products don’t get completed on schedule, turnover is high, or products need extensive tweaking to meet customer needs. But inside Product Development, life is normal: dynamically adapting to the shifting priorities, making quick decisions about fixes, and just getting the next product out the door.

The only way to get the processes to improve significantly is to get perspective. And perspective is the one thing that most Engineering departments don’t have. They’s too busy meeting their commitments. Perspective is what consultants and internal mentors have.

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.

Managing and listening

What makes management difficult for people who are technical experts? In a way, it’s like the reputation that medical doctors have when they are managing their investments — they are so accustomed to being the ones who “know” they have trouble taking advice from financial advisors. As a result, docs are reputed to be have the worst record as self-managed investors.

I can sympathize. As a technologist, I tried managing my own investments over a long period of time. Eventually, I realized that I “knew too much” about the technology and the companies as technology sources. So I would invest in companies that had great technology, but they would turn out to have poor businesses or inadequate marketing — things I didn’t recognize.

Moving from technical contributor
(engineer, programmer, analyst, etc.) to manager is another difficult transition in which the contributor is accustomed to “knowing.” As a resource for others on technology, we’re used to being the authority. So the first thing we have to learn as managers is humility.

Actually, the first thing we need to learn is that management is an honorable profession with its own set of objectives, methods and styles. Our training is in “hard” sciences and technology, so we’re rarely prepared to deal with the “soft” stuff of people interactions, influencing, leading, and communications. So let’s be clear: there are a lot of new things to learn about.

Since we tend to manage our interactions by intuition and by reference to our upbringing, most of what we do as managers is not conscious: we don’t see it as skills, but temperament. Believe me, however, you CAN change your interactions. The keys? Being interested in becoming effective as a manager. Becoming aware of the effect we are having on people. Being willing to listen to feedback. Being willing to listen.

Being a manager is all about dealing with non-quantitative stuff. Let the MBAs bring out their spreadsheets. When we need to do quantitative measurements, we’ll have plenty of expertise with the methods and the tools. What we need is a willingness to listen, learn and improve.

Improve what? How do we measure ourselves as managers?  We’ll address this question in a future blog post.

Trust and initiative

A client put his finger on the problem: The CEO doesn’t trust the people working for him.

This CEO is an excellent salesman, financier and manager of his Board of Directors. But when it comes to everyone else, he gets his way or … he gets his way. The client put it this way: Since he doesn’t trust people to do things the right way, he judges their performance on one criterion only: Are they doing exactly what I asked? As soon as one of them challenges his directions, that person becomes suspect and eventually gets discredited.

Lacking trust in people below him, the CEO judges them only on loyalty and conformance. The result: lack of commitment. As the client said, “If you know that your decisions are going to be second-guessed, you stop taking responsibility for making them.” It’s much easier to let things go until “the Word” comes down from the top. It saves a lot of stress — and removes intiative.

This is a disease often seen in large organizations. Top management does not delegate any real authority to the lower levels of management, so the managers stop trying to take initiative.

But this client’s firm has fewer than 100 employees.
Can you guess how long this enterprise will last without intiative coming from the ranks? The most creative and driven people will leave, and those who are left will not make the effort to distinguish this company from the competitors. Even if it survives, it will not be a fun place to work.

Are you languishing in a position without real authority? There’s only one way make things better for the long term. Put your job on the line and demand the authority that is needed for your initiatives to be effective. Keep demanding it until they throw you out or make you the CEO. Or something in between. If you fail, you’re better off somewhere else anyway.

Death by Mismanagement

I had breakfast recently with an old colleague who is a top-notch ASIC designer. Among the many stories he told me, the lessons of this one stand out:

One year when he had been a key player in designing a new interface that doubled the speed of the devices we made, he was nominated for “Inventor of the Year.” But he didn’t find out about this nomination from his boss. Instead, he was invited to the dinner event at which the award is given out (without anyone knowing in advance which of the nominees is to receive the award). Of course, he says, he didn’t receive the award; his boss, who had to attend the event with him, would not make eye contact with him during the event.

Later, at annual review time, he was ranked in the bottom 1/8th of the company’s contributors. Naturally, he was curious about how this could happen while he was being nominated for Inventor of the Year. He asked HR about it. “Is this consistent?” he asked. “Of course not,” they replied.   “Can you do anything about it?” he asked.   “No.”

When management is sending two extremely conflicting messages to individual contributors like my colleague, it is an indication of deep trouble at several levels in the company. First, the immediate boss was almost certainly acting out a personal aversion — if not vendetta — against this engineer. Second, the fact that no one from higher levels of management were willing to take action is a sign of serious sickness in the company.

How long would you expect a company to last which sends such messages to experienced and long-term contributors? In fact, the “boss” in the story above was eventually laid off. But the damage to the engineer’s morale and respect for the company was irreversible.

And so, no doubt, was the decline in the company’s competitiveness. The company’s sale to a former competitor was announced just a couple of months later.

Marketing takes over Engineering

What happens when Marketing takes over the Engineering function?

One of my current clients has a very strong VP/founder who knows a lot about engineering things.

As a startup, the company successfully introduced novel products because everyone worked on everything — the usual startup mode for a technology company. As products are turned (they are on their 8th product now), Engineering needs to get some predictability to its schedules and commitments. But Marketing continues to drive a lot of the Engineering operation simply by paying more attention to the detail than the Engineering VP does.

The situation doesn’t look bad from a technology point of view — there are good decisions made, even if they continue to be made (product features added) throughout the development cycle. But the recently hired senior managers in Engineering are going crazy, because they have two masters — the Engineering VP and the Marketing VP. Which one should they listen to?

My advice to them for now is to get their operations in order — write functional specs (or at least a prioritized list of features), meet schedules by biting off incremental pieces of the implementation at a time, report on exactly when changes were made to the requirements and how long it took to accomodate the change. Then press the two VPs to settle the issue of how Engineering is to be managed. It can’t be settled by the next level of management, so long as it is unsettled at the top.

How do you see competition?

Do you respect your competition? Not that it matters to them, but if you are worried about competition, you may want to change your attitude to one of “respectfully curious.” Why? Because competitors can be your best friends — if you are in the product development chain.

Competitors are looking at the same market data, trade magazines, professional society publications, and employment data that you are. And they hear the same rumors and tales of new products and ideas. How does that help you? By having a close look at what their strategy is (which you have to impute from seeing their products and announcements), you get a feel for how they interpret that data. Then you can look at your own interpretations and find the differences. What opportunities do you see that they don’t? How is your business model — or user interaction model — different from theirs?

Having found differences — or made them up on the fly — you can charge onward with your product strategy, with a little more confidence that your viewpoint is distinct from the competitors’ view.

What are key things to look for? Try these: frequency of product introductions; pricing, individual and quantity; free trials? service and support? characterization of the user or buyer of the product or service; objective for the product — how do they think the user/buyer will benefit from the product?

No two companies see markets and users in the same way. Cherish your own distinctness and develop it further by looking at the competition — with respect and curiosity, but not with envy.