Why should we be Agile or Lean?

September 17, 2010

Today’s my birthday, but instead of staying home and celebrating, I’m on a plane destined for a city a couple of thousand miles away from home. The combination of the birthday milestone and the time away from phones and email allow me some reflection on what I’m doing and why. And one of the things I’m doing is advocating adoption of Agile development methods and Lean management principles.

There is a lot of pushback on these principles from consultants and managers who have not lived with them in real projects. And a certain amount of skepticism from business managers who don’t want to embrace a new “method of the decade” fad just because it is becoming more widespread. I don’t blame them. There are some good reasons for skepticism.

First of all, any movement that has passionate followers and promoters tends to acquire a fringe element that pushes everyone to follow the trend, to get on board. And we all know that not 100% of projects, environments or companies a suitable candidates for an Agile conversion. Why? Sometimes they have extensive requirements-definition phases imposed on them from a contractor (such as the Federal government or the military). Sometimes they simply do not have the support of top management to revamp their operations in a way that requires changes in management style or procedures.

Second, some operations have far-flung operations including offshore units, making effective implementation of Agile methods much more difficult. Rather than going through the motions of Agile or Scrum teams with vast timezone differences and incompatible local management style, they are better off using traditional project management tools and methods.

Finally, it is threatening for some technical managers, project managers, or business managers to have to change their management activities and open them up for inspection by self-directed development teams. For example, one IT Director I worked with at a client company was known by his colleagues as “The Hammer” because of his management style. He was not a candidate for participatory decision-making in a team.

And yet, Agile and Lean transformations are worthwhile endeavors. How do I know? I’ve seen development teams move from ordinary results into higher productivity; business managers move from fear of the new into embracing Agile because of the greater confidence they had in getting results on a predictable schedule; and companies move from asking what the heck is Agile to committing tens of millions in development money to Agile projects.

I also recommend Agile transformations because of my own frustration with the failure of software development on the whole to improve significantly over the past 30 years. Sometimes, you have to make your own predictions about what is going to work, what is going to make things change for the better. I predict that ten years from now, we won’t be discussing whether to go Agile or Lean, because everyone will be practicing them to some extent, and no one will have any doubts about the payoff.

_______________________________________________________________________

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

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

For more information, please visit his website at https://johnlevyconsulting.com ,

Email him at info@johnlevyconsulting.com, or call 415 663-1818.

Filed Under: Agile Management

What does Agile mean for Business Managers?

August 25, 2010

There’s a lot of talk these days about Agile methods. They may be called Scrum or XP or a number of other names. And a lot of companies and institutions are trying to make a transition to Agile methods. You may be wondering what the big fuss is over Agile Software Development, which is where the Agile movement began. Let’s review a couple of key things about Agile:

1. It’s not a new technology that came down from an academic institution or from a commercial enterprise. Agile is a set of principles and practices that were codified in 2001 by a group of practicing software professionals with a lot of experience making software products. This alone makes Agile unique, because it is what I call a “grass-roots” movement, coming from the people to whom the methods apply.

I like to say that they got together and said to themselves, “we’ve been so badly managed for so long, surely we can do better ourselves.” Of course they didn’t say that, but I believe they were motivated by the desire to have more productive and happier development teams. And from the business point of view, we can’t deny that software development has a poor track record – most large-scale projects do not deliver working software within the time, budget or quality constraints that were set out at the beginning.

2. To do Agile properly, the development team has to include someone who is in the role of customer or user. By “include,” I mean that a person in that role must be accessible to the software developers all the time – or at least every day for most of the day. The reason for this is to be able to have conversations about what is meant by certain requirements or functions or uses of the software. And conversations are key to the whole process, because we have learned over the years that written specifications and requirements never (NEVER) fully explain the actual requirement for the product. Why? Because often the customer herself doesn’t know what is needed until a working prototype is demonstrated.

3. Working prototypes are also key to the Agile processes. If the team cannot demonstrate a working prototype of the software at least every 3 weeks, then it is not doing Agile. And when the prototype is shown (to the customer on the team), the customer gets to say whether it meets the “story” or specification that was given to the team a few weeks ago. The customer also gets to participate in setting the priorities for the next 3-week development session.

What does Agile development mean for a business person who is contracting for or paying for software development? It means all of the following:

a. You are responsible for designating an authoritative & knowledgeable “customer” to the development team, and making that person responsive to the team on a daily basis. You also have to be willing to accept that person’s decisions on what goes into the product and what is left out.

b. You may set the budget and the time line (deadline for delivery) for the product, and you can make a list of the features or functions you want, in priority order, but you must not insist that all features on your list be included for any one deadline (at the price). Or you can set the features required and the budget, but then you can’t set a deadline for their completion. Why? Because making software – real working software – requires experimentation and trial and error. And that makes the job of predicting the complexity of a particular feature very uncertain. So as the process goes along, you can’t tell how long it will take to make any one feature. In compensation, you get to re-prioritize the features to be built next every 3 weeks or so.

c. Your project managers will probably have to learn that their roles will change with Agile development. They must accept the two new views (a and b) and learn to monitor the development progress without having the control they are used to with traditional project management. Why? Because software development is not like constructing a car or a building. The steps are known, but the “trial and error” part is still needed to find a satisfactory solution to the complex problems posed by software.

I recommend that you accept this, and learn to live with Agile processes. Because the satisfaction that comes from having real working software demonstrated to you every few weeks, along with the higher success rate for overall projects will amply compensate you for learning this new method of working with developers.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

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

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

For more information, please visit his website at https://johnlevyconsulting.com ,

Email him at info@johnlevyconsulting.com , or call 415 663-1818.

Filed Under: Agile Management

Business, Academia, Government – do we have the same problems?

August 10, 2010

Every one of us is dealing in one way or another with high technology. Whether it is by trying to develop a product, trying to deliver a service, or just preparing our slides for a presentation, we all deal with the high-tech world.  This usually means that we must communicate with high-tech people, and typically the results we get are dependent to some extent on how well the high-tech people do their work.

Communicating with high-tech people is a challenge. Not only do they speak their own brand of jargon, they also tend to be very literal.  Like the literalness of the computer itself, high-tech people seem to think that if you ask for a three-pronged left-handed widget (or a thingumbob, if you like), then if they deliver a three-pronged left-handed widget to you, you should be happy.

Unfortunately, it doesn’t work that way. With software, for example, the requirements are never completely known.  Typically, when the first working model of a new software system is shown to the people who asked for it, their reaction is: “Oh.  I see what you have here, but what I really want is something different.”

This can be frustrating for the technologists who worked for a long time on the development.  One of their countermeasures now is using Agile development practices, in which a working prototype is shown to the “customer” early and often.  This allows the developers to correct their course early and gain confidence that they are building something that will actually be useful.

But why is it so hard to specify what we want in advance? Is it because we don’t speak the same language as the techies?  Or is there something inherent in high-tech that obscures the simple outcomes that we know we want and we think we have asked for?

I believe it is both. Not knowing how high-tech stuff is constructed, we don’t know which jobs are hard to do and which are easy.  We also don’t know how elaborate the underlying structure has to be in order to get what looks like a simple result.  So we ask for things that we want and find ourselves puzzled by the groans from the technologists who see years of work ahead of them to satisfy the request.

We also don’t really know what we want when it comes to interactions with a computer-based system, because the possibilities are endless and the examples we’ve seen in the past color our view of what we think the interactions should be.  For example, if you’ve used Word Perfect for years to do your word processing work, you will not find it easy to switch to Microsoft Word, because the interactions and functions are different.

There’s a new discipline in computer systems development called user interaction (UX) design.  It calls on specialized skills ranging from graphical design, human perception and interaction protocol design, to database design and web programming.  But even as this new discipline is helping to make systems easier to interact with, no one can substitute for you, the user or customer, in defining what the system should do.

Sometimes you have to say, “I want it to be easier to use than this,” when you see how a system works, even when you don’t know how to make it easier.  If you challenge the development team to try different ways to make it easier, you will usually get something better.

But this poses a problem. If they are experimenting with various ways to make the system easier to use, how long will it take to get to the finish line?  How much will it cost?  The fact is that doing engineering and design requires creativity and experimentation.  And you can’t schedule a breakthrough.

So you have to settle for setting a limit on how long or how costly the project is to be.  An entrepreneur may run out of money before delivering a satisfactory system. But if you are constrained to actually get a working system, you want the best you can get within the constraints.

This comes back to the Agile approach. If you ask to be shown a working prototype often, you can do course-corrections frequently while you also gain confidence that the developers are meeting the most important criteria for your project, because you make them show you how the system meets those criteria first.

The Agile Management Bottom Line

Give up trying to specify everything at the start.  Begin by prioritizing the key features or results you need, and ask for frequent demonstrations of a working system.  You’ll end up with a lot more confidence in your high-tech developers, and they will be less frustrated with you.

—–

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

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

For more information, please visit his website at https://johnlevyconsulting.com ,

Email him at info@johnlevyconsulting.com , or call 415 663-1818.

Filed Under: Agile Management, Painless IT Tagged With: , , , ,

What’s the matter with IT?

July 27, 2010

Information Technology (IT) is a name that covers all the stuff (computers, networks, software) that makes businesses work.  As a key part of every business, IT has become a loved and hated department.  Loved because the capabilities of IT keep things humming in business.  Hated because there is something about IT that keeps it apart from the rest of the business.

Businesses keep IT separate for a number of good reasons.  IT needs technical specialists, and these specialists have to interact with each other.  IT has to maintain the systems and networks that keep things running, and these systems are often far from the home office.  Finally, managing IT people requires some kind of management specialists who know what makes technologists tick.

There are also some bad reasons for separating IT from the rest of the organization.  One is to keep business people at the operating level from having too much influence on what IT does.  After all, if you let a low level business manager ask for everything he or she wants from IT, IT might not have enough time to do the big projects planned by the top executives.  Another is the belief that IT doesn’t speak the language of business.

One of my client companies used to have the head of IT (the CIO) report to the head of Finance (the CFO).  This guaranteed that the CIO had a financial perspective on everything.  While that is the right perspective for a department that belongs under Operations (people who keep the buildings and the commuter buses running), it is not the best perspective for and IT department that is trying to contribute to the business bottom line by developing innovative software packages and better products.

This company had a large call center (people who answer the phone when you call for support) located 750 miles from the home office.  The whole IT operation, except for their offshore contractors, was located in the same building as the call center.  Upstairs from the call center were the software developers and managers who were implementing the latest web site upgrades and support software for their sales agents.

Software development is not Operations, it is Engineering.  If you treat software engineers the same way you treat call center operators, you discourage them, because they need a different working environment and a different set of criteria for their success.  Discouraged software engineers leave to find a better place to work.  The most experienced and most productive ones of them leave first.

IT needs to be integrated with the organization.  Not only does the management of IT have to be aware of and fully behind the strategic initiatives of the company, they should be actively proposing and executing projects that increase the competitiveness of the company.  The more that IT can sit side-by-side with their business-oriented peers in the company, the better the strategies and the results will be.

The Agile Management Bottom Line

Get IT out of its silo and into the main stream of your business.  If you don’t understand what IT does, start asking questions.  But don’t banish IT to the boondocks just because they’ve got a lot of funny-looking machinery in the closet.  You need them and they need you.  Start talking.

John Levy helps business managers who are frustrated because they are not getting what they need from their IT or Engineering organizations.  He helps them get predictable, consistent and innovative results from high-tech people in IT and product development.

John’s clients include companies in insurance and manufacturing, as well as software, computers and storage.

John’s book on management for technology executives, “Get Out of the Way,” was published in May, 2010.  His website is https://johnlevyconsulting.com and he can be reached at 415 663-1818 or info@johnlevyconsulting.com

Filed Under: Painless IT Tagged With: , ,

Metrics of Success in Development – Part 3

January 26, 2008

Today we’ll finish the list of ten questions that can give you a quick measure of your development group or department. The purpose is two-fold: to let you see how you measure up compared to other similar departments, and to suggest ways in which you can think about the stresses in your department.

Let’s launch into the final four questions, then we can total them up.

7. Viewed from other departments (outside of Development), how would managers rate your development managers and engineers in each of the following areas?
(a) Cooperativeness (with outside people)
Extremely cooperative – add 3 points
Very cooperative – add 2 points
Cooperative – add 1 point
Uncooperative or unavailable – add 0 points
(b) Flexibility (willing to work with and compromise with others outside the department)
Extremely flexible – add 3 points
Very flexible – add 2 points
Flexible – add 1 point
Inflexible – add 0 points
(c) Team-orientation (beyond the Development department teams)
Extremely team-oriented – add 3 points
Very team-oriented – add 2 points
Team-oriented – add 1 point
Not team-oriented – add 0 points

8. What percentage of the company’s gross revenues in the most recent year were allocated to Development (or R&D)? (If your company has no revenues, or if revenues are less than the Development budget, answer “over 10%”)
(a) over 8% – add 3 points
(b) 4 to 8% – add 2 points
(c) 2 to 4% – add 1 point
(d) less than 2% – add 0 points

9. Comparing this year’s Development budget to last year’s, how did it change?
(a) Increased by 20% or more – add 3 points
(b) Increased by 5 – 20% – add 2 points
(c) Stayed the same or changed by less than 5% – add 1 point
(d) Decreased by more than 5% – add 0 points

10. The number of concurrent development projects now in my department is
(a project is defined as an activity with a timeline and a goal which needs at least 1 full-time person to make progress towards the goal; if you have many small projects, you can count the number of project leaders instead)
(a) over 25 – add 0 points
(b) 15 to 25 – add 1 point
(c) 5 to 15 – add 2 points
(d) 1 to 4 – add 1 point
(e) none – add 0 points


If your total points add up to 52, you have a perfectly-performing development organization and have no need for improvement. For the rest of us, the points are probably in the following ranges:
Excellent: 37 to 52 points
Good: 22 to 36 points
Fair: 13 to 21 points
Poor: 12 points or fewer

How did you do? What does this mean? If you think about the stresses on your department, you can see that the point score is not as significant as the individual issues you’re facing. Are you having a lot of turnover? Slipped schedules? Complaints from other departments about your people? These can all be aggravated by declining budgets which are outside of your control.
Later we’ll examine some of these issues and how you can find ways to work around them. In the mean time, click on the Comment button and let us know how you scored.

Filed Under: Painless IT Tagged With: , , , , , , ,

Metrics of success in development – Part 2

January 26, 2008

Last time we listed the first three questions of a self-assessment questionnaire for Development managers. Those first three related to project completion, staff turnover, and how well the initial functional or feature list was met. If you are having problems delivering products, most likely you will experience problems in one or more of these initial three areas.

There is a less tangible measure that relates to suitability of the product to the customer. But I’m still trying to figure out how to ask about that in a way that leads to a consistent and useful measure. If you have any suggestions, please make a comment on this blog.

Here are the next three questions:

4. How many hours per week are put in by your project or program staff? This is to be answered in two parts: first for the average over the life of the project, and then for the peak of the project or program. Answer this for each of the most recent 3 projects or programs.

4a. Average over the project or program:
Over 60 hours/week (add 0 points per project)
50 to 60 hours / week (add 1 point per project)
40 to 50 hours / week (add 2 points per project)
less than 40 hours / week (add 0 points per project)

4b. Peak week during the project or program:
Over 80 hours / week (add 0 points per project)
70 to 80 hours / week (add 1 point per project)
60 to 70 hours / week (add 2 points per project)
40 to 60 hours / week (add 3 points per project)

5. How many direct reports do you have? (Direct reports include staff assistants, administrators, secretaries, project leaders, managers and interns)
Over 12 (add 0 points)
10 to 12 (add 1 point)
8 to 9 (add 2 points)
3 to 7 (add 3 points)
0 to 2 (add 0 points)

6. Of your direct reports, how many do you regards as “problem” employees (people you will replace when there is an opportunity)?
0 (add 3 points)
1 (add 1 points)
2 (add 0 points)

Questions 4 and 5 are searching for sustainability in your project loading. It’s OK to have peak weeks in which people are working 10 to 20 more hours than is typical during the project. But if you are driving everyone to work more than 60 hours per week on a long-term basis, you are not getting output that is sustainable. It may be time for you to institute metrics that measure results rather than inputs. Then you can experiment with different work schedules to see which ones result in the greatest output.

Sustainability applies to you and your management time, too. If you have more than 9 direct reports, the odds are that you are (a) not managing all of them as well as they could be managed, or (b) overloading yourself with management tasks that give you little time for planning and strategic analysis.

Next time we’ll complete the question list and tally the points for a complete score.

Filed Under: Painless IT Tagged With: , , , ,

Metrics of success in development – Part 1

January 26, 2008

How do you find out if your development organization is functioning well? Naturally, if you are getting products out on time, consistently, and the world around you is happy with the results, you have nothing to worry about.

But what if there ARE complaints? Can you determine whether you’re hearing gripes that have little to do with you? Or whether there really is room for improvement?

I’m working on a self-assessment tool, probably containing about 10 questions, that will help you evaluate whether you are on track. The way to use the tool is to answer the questions and then count the points at the end.

Here are the first three questions in my current working draft:

1. Counting only the past 3 projects and products under your management, how many have been completed on time? For each project/product not completed on time, how much later were they completed?

[4 points] for each project completed on or before the originally scheduled completion date
[3 points] for each project completed within 120% of the originally scheduled duration
[2 points] for each project completed within 150% of the originally scheduled duration
[1 point ] for each project completed after more than 150% of the originally scheduled duration
[0 points] for each project which is never completed

2. During the time that those 3 projects or products were being developed, how much turnover did you experience among your technical staff, including first-level supervisors and managers? Turnover means departed or transferred out from project teams or management without being invited to do so by you or your managers.

[3 points] less than 5%
[2 points] between 5% and 15%
[1 points] between 15% and 30%
[0 points] over 30%

3. In those 3 projects or products, how much of the planned functionality was delivered (at the completion date you used for question 1)?

[add 3 points] for each project in which you delivered all of the planned functionality, plus additional functionality defined after the start of the project.
[add 2 points] for each project in which you delivered all of the planned functionality
[add 1 point] for each project in which you delivered at least half of the planned functionality
[add 0 points] for each project in which you delivered less than half of the planned functionality

If your total points add up to 24, you have a perfectly-performing development organization and have no need for improvement. For the rest of us, the points are probably in the following ranges:
Excellent: 18 to 24 points
Good: 12 to 17 points
Fair: 6 to 11 points
Poor: 5 points or fewer

Shipping products on time is the key result that most of your stakeholders want. Shipping the product with the features and functions that they asked for — or expect — is next in line as a measure of your success. But if you are burning out your development crew — and causing turnover as a result — you won’t be able to sustain the results. Therefore, these are the first few measures that tell you whether the organization is successful and sustainable.

Next time we’ll begin looking at other measures that can tell you whether your management practices are helping you build a development organization that is consistent and successful for the long run.

Filed Under: Painless IT Tagged With: , , , , , , ,

Constant Reinvention = Survival

January 26, 2008
Nothing lasts forever. Even the best-conceived business strategies eventually become constraints on growth.

Consider Dell. “Dell succumbed to complacency in the belief that its business model would always keep it far ahead of the pack.” But the competitors got better while Dell failed “to invest in new business lines, talent, or innovation that could provide another competitive edge.” * [see Business Week citation below]

As a leader in technology or product development, you may think that your entire job is to execute well on the development plans laid out by Marketing or a strategic planning group. But you can do more. You can help the executive staff recognize that the business has other opportunities.

Consider what the Business Week authors went on to say: “Long-term success demands constant reinvention.” This means that while you’re turning out products that meet the current set of goals for functions, price and quality, the viability of the company may depend on your pointing out where innovative products or services could come from, using the brains you already have on your staff. Reinvention means re-thinking the orthodoxies everyone has accepted as the characteristics of the company. Do you have some independent thinkers on your staff who keep coming up with off-the-wall ideas? Maybe some of those ideas are actually your ticket to survival.

“Nurture the next growth platform long before it’s needed.” This means you have to carve out the budget to support the radical ideas from the operating budget you’re supposed to use for mainstream development. If you can’t convince your executive staff to fund a skunkworks operation, then you should look at having some of your key contributors doing some off-the-record investigations. Is this risky in your company? Then maybe the company needs some shaking up.

“Most [companies] don’t [nurture the next ideas]. Distracted by the demands of their current success, they re lulled into a false sense of security.” It’s easy to focus only on the tasks that will satisfy the demands of current customers and current ways of doing business. And while it’s not easy to perform on those tasks at extraordinary levels, you can get lost in gunning for the immediate satisfactions of meeting this quarter’s goals. Can you be a VP or Director of Engineering and still make time for thinking about next year’s products and the businesses that you haven’t entered yet? Consider this: who else is better positioned to view what’s possible, who is out there needing better functions or services, and what can be combined to make a new business?

I suggest taking an advocate’s role as part of your commitment to the long term success of your company. You don’t have to be a marketer or business analyst to know what’s exciting and feasible in the next generation of products and services. Carve out a niche as a visionary and a keeper of the wild ideas that can open up new busineses for your company. Do it regularly, and you’ll be twice as valuable as the person who only meets the usual goals of Development. Besides, it may help your company survive.

———-
* “Where Dell Went Wrong” by Nanette Byrnes and Peter Burrows in Business Week, February 19, 2007, pages 62-63.

http://www.businessweek.com/magazine/content/07_08/b4022074.htm?chan=search

Filed Under: Painless IT Tagged With: , , , , , , , , ,

Loss Leader

January 26, 2008

My colleague Joel Harrison is good at encapsulating learnings from his experience. In 2006, 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.

Filed Under: Painless IT Tagged With: , , , , , , , , ,

Shifting the focus to longer term

January 26, 2008

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.

Filed Under: Painless IT Tagged With: , , , , , ,