The Myth of Job Creation by Small Businesses

by Ken Rau, Senior Consultant

Last week I attended the monthly meeting of a local chapter of SIM (Society of Information Management), a professional society that I have belonged to for years. The after-dinner topic was “The 2010 Annual Report on Technology, Innovation and the Economy.” The last of the three panelists presented statistics and survey data showing that small businesses, particularly in the technology sector, were responsible for most, if not all, of the jobs created during previous recovery periods through innovation and, therefore, should be the recipient of all federal stimulus money targeted at job creation.

During the meeting I asked the speaker to explain his assertion that it was innovation by small businesses that led to their job creation ability. I offered that nothing in the numbers and analysis presented had demonstrated a linkage between the two. As is usually the case in these forums, I received an answer that skirted the question, but did not get to the heart of it. Repressing my inclination to press the apparent inconsistency further, I let the matter drop so my fellow attendees could get home in time to see the Duke/NC State basketball game that evening.

As I am sure you have experienced with similar exchanges, in the car on the way home I kept thinking, “If only I had said…”. By the time I got out of the shower the next morning, I had completed my thought process and was convinced the speaker was wrong in his contention in at least three ways. First, I was convinced that there was no clear correlation between job creation by small businesses and innovation; second, I was not sure that small business was that great a source of innovation anyway; and finally, I was not at all sure job growth by small business, though statistically verifiable, was truly meaningful.

In my experience (and everything that follows here should be prefaced with that caveat), the source of most meaningful innovation that gets translated into jobs comes from either University research (through funding by government or sometimes private sector grants) or R&D efforts by large corporations. It’s just that, in most cases, neither of these sources, because of policies or politics, is able or interested in pursuing the most promising of the innovations they try so hard to identify. Instead, it is up to an entrepreneur working in that environment to recognize the true potential of an innovation, leave the environment where it was created, and strike out on his or her own to pursue the innovation. The entrepreneur recognizes the worth of the innovation and, because of frustration with the bureaucracy, politics or getting cross-wise with management of the organization, decides to take the plunge and pursue the innovation on his/her own. Credit cards are maxed out, second mortgages taken, and sometimes, in the case of the experienced entrepreneur (more on this later), venture capital obtained. The innovation is adapted, applied, engineered and pursued. In so doing, jobs are created, revenue is generated, and, sometimes, even profits are made.

Note however, this scenario describes the application of an innovation, not its creation. A technicality? I don’t think so. Innovation is the product of universities and large corporations, not small businesses. Small businesses generate jobs based most often on the innovations they liberate from other sources.

And what of the jobs they create? Are they real, permanent and enduring or just transitional? First of all, the job of the entrepreneur and the cronies he takes with him from the source of the innovation are a job loss to the source and a job gain to small business. This on its own does not represent a net gain in jobs for the economy. Second, those people hired by the small business from the ranks of the unemployed can be tabulated as job gains to the economy, but for how long? The fate, or maybe even the purpose of most small business startups, is to prove an innovation’s merit and then, if successful, be acquired so the entrepreneur(s) become wealthy and can say, “I told you so.” (If the venture is unsuccessful, all jobs are lost.) Once the value of the innovation is proven, a feeding frenzy among large corporations ensues in an attempt to acquire the small business. The entrepreneur and most of the employees of the small business are amply rewarded for the risk they have taken, but at whose expense? Entrepreneur and employees are absorbed by the acquiring corporation who then most often proceed to squander the value of the innovation that has been acquired. Costs are cut, layoffs ensue, and often the quality of the acquired product diminished under the guise of improving efficiency. Discouraged and unable to fit into the inherited corporate culture, most of the remaining acquired employees who have not been laid off as part of the acquisition leave and appear as a net loss of jobs by the corporation.

So, what do the statistics say? Small businesses create jobs and large corporations are at best job-neutral or show a net loses in jobs. A few of the entrepreneurs, now richer, knowledgeable and more confident as a result, stay with the corporation only long enough to fulfill their contracts and identify new un- or under-appreciated innovations which they can exploit in their next small business startup. And so the cycle repeats. A bit cynical, I admit, but we have almost all seen or been a part of this innovation life-cycle process in our careers. If we are lucky, it’s from the vantage point of the successful entrepreneur.

The statistics show that jobs are created by small businesses, while large corporations appear to add little to the net national employment roles. Yet with the few exceptions of the truly successful startups that grow into giant corporations like HP, Microsoft and Cisco, I contend the vast majority of the oft-ballyhooed jobs created by small business are but transitional; vastly overrated in terms of performance, rewards, and productivity; and require the completion of the full product innovation cycle that involves acquisition to demonstrate whether they can truly be credited with having generated a net increase in jobs and, consequently, are worthy of vast investments of your and my stimulus money as their proponents advocate.

Understanding the Nature of Self-Organizing Teams

by Jim Highsmith, Director and Fellow

A spider is an eight-legged arachnid that has a head attached to a central body. Pull a leg off a spider and most can still walk, even if a little lopsided. Cut off the head, and the spider dies. Not so the starfish. While many people know that if you cut off a starfish’s leg, it will grow back, most don’t know that a starfish’s major organs are replicated throughout its body. One species, Linckia, can regenerate an entire starfish from each of its severed parts. A starfish is a decentralized network. A final interesting factoid — “for the starfish to move, one of the arms must convince the other arms that it’s a good idea to do so.” Talk about an excuse for uncoordination: “but I can’t get my limbs to work together.”

These facts about, and the first quote, come from a delightful little book titled The Starfish and Spider: The Unstoppable Power of Leaderless Organizations, by Ori Brafman and Rod Beckstrom. Agilists proclaim the power and desirability of self-organizing teams, and this book offers some insight into what decentralized (the term the authors use rather than self-organizing) teams can accomplish. One point they make is that decentralized teams may not make “better” decisions, but they will be “faster” decisions.

One fascinating part of the book lists 10 questions that are indicators of the degree of “starfish-ness.” While some of these indicators seem a little farfetched for the business world, others may help you decide how decentralized you are, or aren’t.

1. Is there a person in charge? Completely decentralized organisms have no head, as in there is no “head” of the Internet. They relate a funny story circa 1995, when a CEO looking for startup funding couldn’t convince a room of potential investors that there wasn’t an Internet president — the concept was beyond them.
2. Are there headquarters? Starfish organizations tend to be very distributed; they don’t have HQ.
3. If you thump it on the head will it die? Cut off a starfish leg (now where is that head anyway?), and it goes on its merry way. Loss of a centralized figure or a headquarters’ building can have a devastating effect on a spider organization.
4. Is there a clear division of roles? Clear, well-defined roles are indicators of centralization.
5. If you take out a unit, is the organization harmed? A great question in regard to the difference between functional teams and feature teams. Given a software development organization that is organized functionally, remove a function (say testing), and the effort is harmed. Given one that is organized by feature teams, removing a feature team reduces the productivity, but progress can still be made.

I won’t bother to give examples with the last five questions, as you can probably come up with your own examples, or read the book.

6. Are knowledge and power concentrated or distributed?
7. Is the organization flexible or rigid?
8. Can you count the employees or participants?
9. Are working groups funded by the organization, or are they self-funding?
10. Do working groups communicate directly or through intermediaries?

If we asked a yes/no response to each of these questions in looking at a well-constructed, self-organized team, there would be, in my opinion, four yes and six no responses (you can take the quiz yourself). So these questions aren’t all relevant for evaluating the degree of self-organization in a team, but they might form the basis for developing a relevant one. Anything that helps us understand the sometime fuzzy nature of self-organizing teams is appreciated.

Software Programming as Craft: The Impact of Agile Engineering Practices

by Christine Generali, Group Publisher

Update: Questions on Twitter about this post made us realize that more background from Jens’ call for papers would have clarified the issues in the debate over the current state of programming. In particular, on the bias that’s become entrenched over the past 40 years toward engineering that has created a “disregard for programming [that] has taken deeper and deeper roots in our professional culture”, and has contributed to the rise of the software craftsmanship movement. Please read the full call for papers and consider joining in on what’s shaping up to be a lively debate!

The upcoming April 2010 Cutter IT Journal, guest edited by Jens Coldewey, focuses on the current state of programming as a craft — both in agile and traditional programming environments. We’ll explore the ideas, concepts and implications of software craftsmanship on software development organizations. We invite anyone who is interested to send us an abstract for consideration.

TOPICS OF INTEREST MAY INCLUDE (but are certainly not limited to) one or a combination of the following:

• How has software craftsmanship been incorporated into training and education?
• What are the organizational implications of software craftsmanship?
• What kind of surveys /research are being done in the software craftsmanship arena?
• What are the “war stories” about organizations that embark on craftsmanship?
• What are the business effects of software craftsmanship?
• What are effects of craftsmanship on project success?
• What is the current state of the software craftsmanship community? Which route might it take in the future?

Cutter IT Journal Call for Papers

• Abstract Submission Date: 4 February 2010
• Articles Due: 12 March 2010
• Guidelines for Contributors

Meaning is a Double-Edged Sword

by Tom Welsh, Senior Consultant

I couldn’t agree more with Ken Orr’s remarks about the vague usage of terms that one might expect to have clearly-defined meanings. But this is what you must expect at the interface between the worlds of human enterprise and scientific precision.

There is a theory – which I find intuitively plausible – that natural language evolved largely to help people inspire and motivate others. Or, if you prefer to look at things that way, to manipulate and exploit them. Wherever you see natural language (English, French, Russian, etc.) being spoken under normal everyday conditions, you will see brands being talked up, deals offered, and haggling engaged in. Right from childhood, “smooth talkers” have a definite advantage: they can persuade others to do what they want, and often acquire groups of admirers and hangers-on. With adulthood, the horizons widen: a persuasive speaker can sell cars or insurance, get a good job or a promotion, attract friends and lovers, or rapidly climb the greasy pole of political ambition.

Those who get to the top – whether as our political masters, as captains of industry, or otherwise – instinctively trust their natural ability to make a persuasive case, convert others to their point of view, and (if the worst comes to the worst) to talk their way out of hot water.

One thing that they have difficulty coping with, or even understanding, is the unemotional, objective, matter-of-fact language of science and technology. Hearing an engineer present some plain facts and figures, the manager or politician finds himself continually asking, “Why did he say that? What’s his motive in making this claim? What’s in it for him?”

This fundamental contrast is the key running gag that makes Scott Adams’ Dilbert cartoon series so funny. The pointy-haired boss rarely opens his mouth without trying to making himself look good, do others down, or strive for dominance. So he is utterly baffled by the strange tribe of engineers, who make a religion of rigorous, objective precision and who habitually tell the truth without concern for their own personal benefit. They, in turn, are confused and disgusted by his obvious self-seeking and the degrading dishonesty it leads him into.

So, whenever we come across a term like “use case”, it is useful to consider not just what it ought to mean, but the personal agendas of people who seem to be abusing it or stretching its meaning.

No doubt when software engineers and designers talk about use cases, they are pretty clear about what they mean and what they are trying to accomplish.

But as soon as some “users” – anyone other than those who introduced the term because they found it helpful – pick it up and start to bandy it about, the motivation changes. Instead of trying to communicate as clearly as possible, eliminating all possible sources of confusion or ambiguity, we must realize that some people may be doing the exact opposite.

A Hunger for Meaning

by Ken Orr, Fellow and Senior Consultant

The other day, Ron Blitstein posted here about the term “SOA”:

The term “SOA” has become very confusing and possesses all the clarity of Web 2.0 (another term that drives me to distraction).

There are a number of words and phrases that I believe confuse those of us in enterprise architecture and/or systems development. The phrases that have most bothered me for the past few years are use cases, nonfunctional requirements, and lights on applications.

Let me start with use cases. My old friend James Robertson, one of the deans of requirements engineering, says that he has found nearly 40 different definitions of use case in modern systems literature. I can’t say that I have come up with that many, but I can say that the term is so frequently used and in so many ways that it has become “a distinction with a difference.” I think that the reason people use the term use case so often is that it means whatever they want it to mean. We have “business use cases,” “user use cases,” and “activity use cases.” From now on, whenever I hear someone use the term use case, I’m going to ask precisely what they mean. You might try that yourself if you’re confused.

Nonfunctional is another term that I think isn’t very useful. It makes you think that nonfunctional requirements are those that don’t do anything. Quite the contrary, nonfunctional are the systems functions that no system can do without: security, reliability, accessibility, and availability. Perhaps a better term would be prefunctional or superfunctional. I used to work for one of the large telephone companies; it used to describe itself as the folks that gave us the dial tone. We know today that nothing can function with nonfunctional requirements.

Then there is lights on. Lights on is often used to describe that boring set of functions that just has to be there but that are not “strategic” for competitive purposes. The last year has shown that lights on ought better to be called “lights off.” If the lights on business capabilities — like the nonfunctional technological capabilities — are not there, organizations cease to exist. Car companies have to make, market, and service cars; banks have to remain solvent and make loans; and media companies have to produce products that someone is willing to buy.

Like empty calories, empty terms and phrases create a hunger for meaning. Worse yet, terms that mean pretty much the opposite from what they sound like confuse both the listener and the speaker. In the spirit of the season, I resolve this year to more careful with my choice of words and with my responses to the bad communication habits of my friends and coworkers.

It’s About “Good Software Architecture” not “SOA”

by Ron Blitstein, Fellow

I was recently involved in a debate with my colleagues on the Cutter Business Technology Council about whether SOA has reached a tipping point. I do not believe that such a point has been reached. SOA isn’t a product, technology, or service. It is just a body of useful techniques for designing shareable, reusable, interoperable Web services. Perhaps the acronym should really be “GSA” or “good software architecture,” as the “debate” is really about the challenge and promise of good software architecture. The term “SOA” has become very confusing and possesses all the clarity of Web 2.0 (another term that drives me to distraction). Successful SOA is really about rearchitecting the application landscape and, as such, represents a massive shift in how most organizations work and think. It is much more than building service interfaces to existing applications; SOA requires a redesign of the application portfolio. It is not about adding layers of service-oriented integration, which mostly makes the landscape more complicated. Layering up services is not a replacement for good software architecture. At the end of the day, SOA is about the merits of GSA.

I travel quite a bit and work with many development organizations. My anecdotal assessment is that many are struggling under the weight of large legacy application portfolios, batch feeds, middleware, and spaghetti architectures. The presence of a useful solution to a problem may not guarantee its adoption. I recall a terrific cartoon from some years back that featured a medieval king preparing for battle as he rejects the efforts of a Gatling gun salesperson to help him achieve victory. (I was hoping to include the image here but couldn’t find it on the Web.) Though SOA has great promise and represents much progress over OO, much of the development community is battling with complicated portfolios, high maintenance cost, insufficient staffing, deficient SDLC frameworks, and other quotidian issues. Oddly, by exploiting SOA, an inspired and disciplined IT leader could more effectively tackle the challenges that these very factors create. However, for many organizations, the opportunity to harness SOA or even explore SOA may not exist at the moment. Business partners are uninterested in funding more technology panaceas during these challenging financial times, and IT shops haven’t the time or, in some cases, the skills to recognize/exploit the inherent power of SOA.

Though it saddens me to say it, I do not see the development discipline having reached the tipping point on GSA. If you are really doing architecture, then you have analyzed your existing applications architecture and determined why your portfolio of applications and data warehouses has so many redundant and overlapping elements. And then you build a business case to simplify the mess (hint: use SOA principles). Find the customer master, supplier master, and product master across the plethora of COTS applications and their bespoke cousins. One look at the application landscape within contemporary enterprises tells you that the tipping point remains beyond the next hill.

Good software architecture is a concept that has been and continues to be overdue. Like good design, GSA is difficult to achieve. How many of us have been frustrated by bad bottle openers and quirky corkscrews, let alone challenges associated with software interoperability? We know good design when we interact with it, but most efforts fall far short of the satisfaction you get when you pick up an Oxo Good Grips vegetable peeler, use a Swiss Army knife, pour water from an Alessi kettle, or place a Post-it Note on a colleague’s desk.

Self-discipline and Self-organization

by Jim Highsmith, Director and Fellow

The notion of a self-organizing team runs deeply in the agile community. However, there is a flip side to self-organization, one which agile teams often forget—self-discipline. Just as freedom and responsibility go hand-in-hand in a democracy, so do self-discipline and self-organization. Companies cannot empower teams that do not want to be empowered—those who are populated with individuals who refuse to accept any accountability for results, those who refuse to confront reality, those who gravitate to their cubicles and refuse to engage with other team members, those who are unwilling to accept team decisions, and those who disrespect colleagues.

Jim Collin (Good to Great: Why Some Companies Make the Leap and Others Don’t) presents three key ideas about what he calls a culture of discipline: “Build a culture around the idea of freedom and responsibility, within a framework. Fill that culture with self-disciplined people who are willing to go to extreme lengths to fulfill their responsibilities. Don’t confuse a culture of discipline with a tyrannical disciplinarian.”

Christopher Avery has also influenced my thinking on self-discipline. Christopher says, “I can control me (at least some of the time). Therefore, to improve teamwork, I need to improve me.” Hence the title of his book, (Teamwork is an Individual Skill: Getting Your Work Done When Sharing Responsibility).

I must admit, I’d often thought of teamwork as a, well, team effort. We’ve all been through team building sessions, which are valuable, but I really had to stop and think about “to improve teamwork, I need to improve me.” Christopher added to two additional ideas—another that was relatively traditional, and one with another new twist. First, “I am accountable for results and tasks that I have agreed to accept.” This one is fairly traditional, I’ve used it in my list of characteristics of self-discipline. But the second is different, it expands the boundaries of self-discipline—“I am responsible for ALL the relationships within my project community.” While many people have talked about the need for close communication and collaboration, Christopher’s statement is much more specific, and demanding—“I am responsible for ALL the relationships.”

Innovation and creativity come from interaction within teams of individuals. Interaction and synergy are driven by relationships. When every team member works on and takes responsibility for relationships it powers innovation, creativity, and performance. When teams contain members except this challenge as part of their self-discipline, performance increases significantly.

Predictions Gone Wild!

by Anne Mullaney, Vice President, Product Development and Marketing

Cutter Senior Consultants have made lots of predictions for 2010 (and the years that follow). I’m sure you’ve also seen many predictions from others. And you’ve probably had your fill of “a look back at 2009″ and “best of” articles. So we thought it would be fun to add a twist to all this soothsaying: A fill-in-the-blank prediction. Sort of like Mad-Libs, but without the parts of speech. Here’s our generic, reusable template for business technology predictions (v2010.0). Complete your prediction in the comments. Or make a video of it and post it on the Cutter Facebook page. Let’s see what happens!

• This past year we saw the maturation/saturation/stagnation of __________________1.0/2.0/3.0. We’re now squarely entering the __________________2.0/3.0/4.0 era. Last year we also saw the rapid emergence and adoption of __________________ service/product, with challenges reported by early adopters in the areas of __________________, __________________, and __________________.
• Rising to the top of CIOs’ list of concerns for the coming year are __________________, __________________, and __________________. This is prompting CIOs and management to adopt __________________.
• In this analyst’s opinion, the most disruptive industry development in the coming year will involve __________________’s buyout/merger/partnership/lawsuit of __________________, causing a ripple effect that will affect consumers of __________________ services/products.
• The company to watch will be __________________, as their expected release of __________________ will shake up the __________________ sector and will be a thorn in the side for __________________.
• Enterprise business and technology management roles of __________________, __________________, and __________________ will be high job-growth areas in the coming year. The new title of C__O is emerging to provide accountability for __________________ in both private- and public-sector enterprises; this role will report to the highest levels of leadership within the organization.
• Last but not least, the changing/continuing economic effects in the coming year will compel enterprises to __________________, and bring a renewed focus on __________________ technology and __________________ business practices.

Even more predictions

by Anne Mullaney, Vice President, Product Development and Marketing

Over the last week we’ve received predictions from more Cutter Senior Consultants. Here’s a preview of the latest additions:

• Rebecca Herold: Bigger privacy breaches than any that have occurred so far on social media sites will occur as a result of no information security or privacy pre-planning at many to most of these organizations.
• James Odell: systems will no longer primarily be top down. Instead, as individuals, small groups, and organizations interact around the world, technology must support approaches that are more side-by-side.
• Rob Austin: 2010 will be the year in which mobile devices become the client device of choice in many enterprises.
• Jim Highsmith: A small, but significant, number of organizations will “get it” when it comes to agility, and they will begin to appoint Chief Agility Officers (CAO).
• Karl Wiig: Increasingly, organizations and academia worldwide will increase their focus on intellectual capital and its role in making societies, organizations and people more competent for better performance.
• David Spann: The next financial crisis will be the growing amount of personal credit accruing in the U.S. and the hope that consumer spending will buy us out of the current crisis.
• David Coleman: We will see a steep retrenchment in the collaboration tools environment, with a few large vendors such as Microsoft and IBM/Lotus as the dominant enterprise players.
• Ken Orr: The netbook + 4G wireless network will create an explosive new marketplace.
• Mark Levison: There will be some big public agile adoption failures this year.
• Alexandre Rodrigues: 2010 will be marked by unique developments and changes in the way in which organizations make use of technology to support their business processes.
• Bart Perkins: IT’s stature as a business enabler will rise dramatically.

You can read more than just the headlines of these predictions (and the insight of other Cutter Senior Consultants) at the Cutter site. Let us know … do you agree? Disagree? Have any advice about how to prepare for what’s ahead?

Partnering in Outsourcing Deals: Is It a Myth or a Genuine Strategy?

by Sara Cullen, Senior Consultant

“Partnering” — besides being a mandatory buzzword — is a curious term. Nowadays, instead of taking over a company, we partner with it. We don’t sell anything anymore; we partner. And now, rather than outsourcing, we create strategic partnerships. While the goal of an amicable and mutually rewarding relationship is admirable, what each party truly expects from the other in an outsourcing arrangement formed under a “partnering vision” is quite different.

The client often wants a “well-behaving provider.” But what the client means by “well-behaving” is a provider that accepts nearly infinite scope creep without a commensurate increase in price, immediately reacts to the client’s ad hoc needs (at no charge), and performs what the client really meant in the specification instead of what was actually written and quoted (again, at no charge) — all the while acting under a fixed-price, punitive contract. This interpretation illustrates the client’s version of partnering as an environment where “the client is always right.” A “master/slave” relationship appears to be the goal.

As you might expect, the provider looks at partnering a bit differently. First of all, there must be blind, rather than earned, trust. The client should not ask any uncomfortable questions and should assume the provider is right (or risk undermining trust). Under no conditions is the provider’s margin to be adversely affected in any way, so anything that will cost the provider money must be charged at a profit. Moreover, partnering is about more than just the current contract; it is in everything the provider does; hence, if the client needs to procure more from the market than the scope of the current contract allows for, then this should also be procured from the provider wherever possible. The relationship is supposed to be monogamous; using another provider equates to your spouse cheating on you: it makes the client untrustworthy. After all, how many partners can one have in a marriage?

True partnering requires three times the investment in the relationship than a “nonpartnering” deal, with the people on both sides being the key. This investment is geared toward the following:

• Ensuring strong interpersonal relationships at multiple levels in both parties
• Implementing joint problem solving and opportunity discovery techniques
• Encouraging knowledge sharing and capturing solutions
• Developing a deep understanding of both organizations’ strengths and limitations as well as the political environments in which they operate

When is this investment worthwhile? When there is a high degree of uncertainty in the contract, typically due to the unpredictability of the subject matter (scope changes will be normal), unpredictability of resourcing requirements (uncertain supply sources/cost to supply), or long duration (unpredictable context, including business/markets, political/regulatory, and technological). Only a partnering-style relationship can handle significant change and not treat the contract as a zero-sum game where there is a winner and loser. The investment is, at a minimum, a hedge against being the loser and, ideally, in fostering an environment where both client and provider can win.

• del.icio.us
• Netscape
• Facebook
• Yahoo! My Web
• Twitter
• Google Bookmarks
• StumbleUpon
• BlinkList
• Digg
• Windows Live
• Technorati
• Newsvine
• Furl
• ma.gnolia

E-mail It

• To Address:
• Your Name:
• Your Address: