Year: 2010

Alan Kay on innovation and risk

Here’s a pointer to an excellent interview with Alan Kay. As always, Alan shares some deep insights about technology innovation and the willingness to take on risk (he’s not confident in the ability of most organizations to tolerate risk no matter how small the level of funding involved).

Anyone with an interest in the continuing role and development of Smalltalk has had lots to chew on over the past few days.

As part of a series of investigations into the most widely-used programming languages, Computerworld Australia has published a conversation with Alan Kay about his role in the development of the foundation of much of modern programming today: Smalltalk-80 , Object-Oriented Programming, and modern software development.

The Weekly Squeak: Smalltalk: the past, the present, and the future?
Michael Davies
Thu, 15 Jul 2010 10:00:45 GMT

Here’s a sample of Alan’s thinking :

What are the hurdles to those leaps in personal computing technology and concepts? Are companies attempting to redefine existing concepts or are they simply innovating too slowly?

It s largely about the enormous difference between News and New to human minds. Marketing people really want News (= a little difference to perk up attention, but on something completely understandable and incremental). This allows News to be told in a minute or two, yet is interesting to humans. New means invisible not immediately comprehensible , etc.

So New is often rejected outright, or is accepted only by denaturing it into News . For example, the big deal about computers is their programmability, and the big deal about that is meta .

For the public, the News made out of the first is to simply simulate old media they are already familiar with and make it a little more convenient on some dimensions and often making it less convenient in ones they don t care about (such as the poorer readability of text on a screen, especially for good readers).

For most computer people, the News that has been made out of New eliminates most meta from the way they go about designing and programming.

One way to look at this is that we are genetically much better set up to cope than to learn. So familiar-plus-pain is acceptable to most people.

[ComputerWorld Australia]

Alan can occasionally be a bit cryptic, but that’s because he assumes that you will do your share of the thinking when you listen to what he has to say.

Related articles by Zemanta
Enhanced by Zemanta

Review: Susan Cramm’s "8 Things We Hate About IT"

8 Things We Hate About IT: How to Move Beyond the Frustrations to Form a New Partnership with IT, Cramm, Susan

The tensions between business leaders and their IT counterparts remains an evergreen topic. Susan Cramm, a former CIO herself, weighs in on the topic in a way that’s revealing and productive in two ways. First, she looks from the outside in, asking what the business can and ought to do in order to get more value from the IT organization. Second, she focuses on the operational levels of the business instead of on the C-suite.

Cramm organizes her book around 8 tensions between line business leaders and It leaders that constitute the things "we hate about IT:"

  Line leaders hate when IT… IT leaders hate when the business…
Service or control is overly bureaucratic and control oriented makes half-baked requests and is clueless about impact
Results or respect consists of condescending techies who don’t listen treats IT professionals like untrustworthy servant-genies
Tactics or strategy is reactive rather than proactive develops plans without including IT
Expense or investment proposes "deluxe" when "good enough" will do focuses on costs not value
Quickness or quality doesn’t deliver on time changes its mind all the time
Customization or standardization doesn’t understand the true needs of the business want it all – right now – regardless of ROI
Innovation or bureaucracy doesn’t support innovation isn’t IT smart and doesn’t use or understand IT systems
Greatness or goodness inhibits business change is never satisfied with IT

(reproduced from Table I-1)

Straightforward and consistent with the kind of tension that invariably forms between the line and any centralized support function. Successful organizations don’t settle for picking one side or the other in these tensions, nor do they simply oscillate between the two poles. Instead, they make use of the tensions to create a more productive synthesis between the poles.

Cramm makes it very clear that her focus is on the business side of the equation:

business leaders may feel that IT leaders are being let off the hook, making the whole IT-business relationship the business leaders’ problem to solve. If you are to serve as a catalyst for positive change, this is the only productive point of view. The only person you can change is yourself, and, in the process of changing yourself, your counterparts in IT will be forced to change.

Starting from this core premise, Cramm examines each of these tensions with an eye toward providing line business leaders with a better perspective on what goes on in IT, why the tensions are the way they are, and recommendations on how to reconcile the tensions productively.

Although full of useful advice and perspective, I don’t think that it ultimately succeeds. There’s an unexamined assumption that IT functions the way that it does for good reasons and, therefore, line business leaders need to accept that reality and move on. That might indeed be accurate in the short run, but it will seriously hamper organizations that want to forge significantly better alliances between IT and the business. This book does a good job with one side of the story. What we need next is a companion effort to understand the other side.

Review: Clay Shirky and Cognitive Surplus

Cognitive Surplus: Creativity and Generosity in a Connected Age, Shirky, Clay

Anyone who can use lolcats to make a relevant and provocative intellectual point is worth paying attention to. Clay Shirky pulls it off in his latest book. Here’s his point:

Let’s nominate the process of making a lolcat as the stupidest possible creative act…. The stupidest possible creative act is still a creative act. [p.18]

Cognitive Surplus is a follow on to Shirky’s previous book, Here Comes Everybody: The Power of Organizing Without Organizations. In it, he explores the following thesis:

Imagine treating the free time of the world’s educated citizenry as an aggregate, a kind of cognitive surplus. How big would the surplus be? To figure it out, we need a unit of measurement, so let’s start with Wikipedia. Suppose we consider the total amount of time people have spent on it as a kind of unit – every edit made to every article, and every argument about those edits, for every language that Wikipedia exists it. That would represent something like one hundred million hours of human thought….One hundred million hours of cumulative thought is obviously a lot. How much is it, though compared to the amount of time we spend watching television?

Americans watch roughly two hundred billion hours of TV every year. That represents about two thousand Wikipedias’ projects’ worth of free time annually….One thing that makes the current age remarkable is that we can now treat free time as a general social asset that can be harnessed for large, communally created projects, rather than as a set of of individual minutes to be whiled away one person at a time. [pp.9-10]

Shirky takes this notion and uses it as a lever to pry beneath the surface of lolcats, the Apache project, PatientsLikeMe.com, and other examples to look for something beyond the obvious. What makes it work is Shirky’s willingness to stay in the questions long enough to see and articulate deeper linkages and possible root causes.

One of the things that makes this work is that Shirky understands technology well enough to distinguish between accidental and essential features of the technology (to borrow a notion from Fred Brooks). Where this ultimately leads him is away from technology to look deeper into human behavior and motivation.

Like everyone else who’s been paying attention, Shirky turns to the wealth of insights coming out of the broad area of behavioral economics to understand why so much of the what is apparently surprising about today’s technology environment rests in our crappy assumptions about human behavior. As he argues in a chapter titled "Opportunity" when we find new technology leading to uses that are "surprising," the surprise is located in an assumption about behavior and motivation rooted in an accident of history not a fundamental attribute of the human animal. For example, he neatly skewers both the RIAA’s and the techno-utopians analyses of Napster and concludes:

The rise of music sharing isn’t a social calamity involving general lawlessness; nor is it the dawn of a new age of human kindness. It’s just new opportunities linked to old motives via the right incentives. When you get that right, you can change the way people interact with one another in fairly fundamental ways, and you can shape people’s behavior around things as simple as sharing music and as complex as civic engagement. [p.126]

For those of you who prefer your arguments condensed for more rapid consumption, Shirky provides one in the following TED talk

Shirky has his detractors. There are those who dismiss him as just another techno-utopian who imagines a world at odds with the practical realities of the day. At the level of a 20 minute keynote speech, that’s not an unwarranted takeaway. When you give his arguments a deeper reading, I think you’ll more likely to conclude they are worth your investment in wrapping your head around them.

Related articles by Zemanta

Enhanced by Zemanta

Culture, Process, and Practice – Effective leverage for Enterprise 2.0

The discussion about organizational culture in knowledge management and Enterprise 2.0 efforts is evolving in useful and pragmatic ways. The earliest discussions ignored culture entirely and implicitly assumed that technology would magically shape the organization as needed. The next round of discussion identified sharing as a desirable global cultural characteristic. If you were in a sharing culture, all was good. Time would ultimately reward your virtue. Those with equal need but less virtue whispered of incentives and WIIFM (what’s in it for me?). Crass and vulgar, but perhaps sufficient for most organizations.

In general these open ended discussions of culture are unsatisfying. They make gross assumptions on the basis of little data. Dave Snowden’s principles of knowledge management (see Rendering Knowledge) provide important pointers to a better answer with his emphasis on the behavior of individual knowledge workers.

Enterprise 2.0 as the extension of ERP

Michael Idinopulos of SocialText noted a shift in the debate at the recent Enterprise 2.0 conference in Boston. In a post titled The End of the Culture 2.0 Crusade?, he observed that:

Last week, the Enterprise 2.0 world turned a corner. Nobody pounded the table for cultural change. Nobody talked about incentives or change management. Nobody talked about transparency or modeling collaborative behavior.

Instead, people talked about process.

…

This is the most pragmatic shift in focus since the inception of Enterprise 2.0. It will have huge effects on the pervasiveness of social software in the enterprise, because it shows a clear path to the business value companies can realize from their implementations.

I ve been arguing for some time that social software achieves widespread adoption only when workers use it in the flow of work. Asking your colleagues to step outside their daily processes and tools to share what they know or network with others won t get you very far. (Trust me, I ve tried.) Bringing your colleagues collaborative tools and practices that make their daily processes better, faster, cheaper, and more interesting does work. It s all about process. Improve the process, you win. Don t improve the process, you lose.

This point of view squares with Ross Mayfield’s that broken business processes contribute to email overload and that

(Employees) spend most of their time handling exceptions to business processes. That s what they are doing in their inbox for four hours a day. E-mail has become the great exception handler.

While this is a very attractive position, it is incomplete in an important, and potentially dangerous, way. If you focus Enterprise 2.0 efforts solely on business process you may get scale, you will likely avoid the issue of culture, BUT you risk missing an opportunity for great leverage.

Leaving Process for Practice: Leveraging Knowledge Work as Craft

Focusing solely on Enterprise 2.0 efforts as an extension of existing business processes treats Enterprise 2.0 as a residual, clean-up, effort. It presumes that the goal worth pursuing is the efficient execution of well-defined processes. It reduces Enterprise 2.0 to an afterthought to ERP.

There is an assumption in this process-centric view that all relevant behavior can be reduced to business rules in the automated system. Exceptions are viewed as system failures or design failures. Moreover, failures in the system are attributed to resistance on the part of system users and operators. Instead of interpreting failures as resistance, what if we start by treating them simply as data?

If you start with process, your goal is uniformity at scale. Ideally, every situation should be treated in exactly the same way. This is eminently logical if you are calculating payroll withholding taxes. It is clever when you extend that logic to treating airline seats as a perishable commodity whose price might vary depending on the day of the week. Can you push in this direction forever?

Are there situations where uniformity and scale are not the appropriate criteria? Of course. The realm of art and craft is all about uniqueness and the value of limited scale. What happens if we opt to start from the art and craft end of the spectrum?

One choice is to accept the dichotomy. There is a class of problems suited to process thinking and a class of problems suited to art and craft. Another choice is to continue to force fit problems into a process view of the world. This has been a successful approach. Consider the number of problems that have been transformed into algorithmic problems well-suited to automation — inventory control and demand forecasting to name two.

A third choice is to ask how to improve art and craft without presupposing that uniform process is the goal. This was the approach started by Vannevar Bush, Doug Engelbart, and their intellectual heirs. This approach spawned much of the technology environment that we operate within today. Oddly, we’ve largely ignored their motives in creating this technology; to support more effective ways of wrestling with intellectual problems.

Engelbart, and those working on his agenda, started building new technology tools because our previous tools and methods were inadequate for the problems we had to solve. They built tools to support new kinds of problem-framing and problem-solving practices. We’ve adopted the tools without considering the practices and behaviors they were designed to enable.

Culture as the sum of shared behaviors

Those who lay the blame for failed efforts to introduce knowledge management or Enterprise 2.0 tools on organizational culture are picking up on this behavioral issue. They are doing so, however, at the wrong level of detail. Organizational culture is a convenient shorthand for the practices and behaviors that constitute "they way we work around here." Changing culture is hard because it’s an abstraction; there’s nothing to push against to get it to move.

While changing behaviors can also be hard, as anyone who’s tried to adopt a new habit can attest, it is possible. Change the right behaviors and eventually you have a new culture. The opportunity in Enterprise 2.0 technologies lies in the new behaviors that become possible. The challenge is that these technologies do not dictate a single set of obvious behaviors. In fact, it is possible to adopt the technologies and make no behavioral changes at all. 

Focusing on behavior is still a challenge. Technology opens up possibilities while setting few constraints. The activities we are interested in here are equally unconstrained by business process; we’ve defined them as the behaviors that don’t fit within the mantle of process. We need to go back to observing how work is currently being done, ask what flows smoothly, see where things get stuck, and design alternate ways to make use of the new range of available tools. We’ll visit those questions tomorrow.

LATE BREAKING LINK: As I was about to publish this post, John Tropea of Library Clips posted a lengthy piece on Have we been doing Enterprise 2.0 in reverse : Socialising processes and Adaptive Case Management. I’ve only just skimmed it, but it’s squarely part of this evolving conversation.

Fred Brooks on the Design of Design

The Design of Design: Essays from a Computer Scientist, Brooks, Frederick P.

Currently a professor of computer science at the University of North Carolina, Fred Brooks led the development of IBM’s System/360 and its operating system. He’s the author of The Mythical Man-Month : Essays on Software Engineering, which remains one of the best books on project management in the real world. In The Design of Design,  Brooks reflects on what he has learned about the problems of design over the course of his long and distinguished career. He combines his reflections with case studies drawn from multiple design efforts. Here is his justification for adding one more volume to the growing literature about design:

the design process has evolved very rapidly since World War II, and the set of changes has rarely been discussed. Team design is increasingly the norm for complex artifacts. Teams are often geographically dispersed. Designers are increasingly divorced from both use and implementation — typically they no longer can build with their own hands the things they design. All kinds of designs are now captured in computer models instead of drawings. Formal design processes are increasingly taught, and they are often mandated by employers.

…

I believe a "science of design" to be an impossible and indeed misleading goal. This liberating skepticism gives license to speak from intuition and experience — including the experience of other designers who have graciously shared their insights with me.  [The Design of Design, pp.xi-xii]

Brooks begins with a look at various rational, engineering-centric, models of the design process including Herbert Simon’s view of design as a search process and various waterfall models of software development. His take, and mine, is that these models bear only a passing resemblance to how real designers actually do design. Whatever value they might have as reminders to experienced designers is outweighed by the risks they pose in the hands of those without the necessary experience base to appreciate their limitations.

Brooks frames the design process problem this way:

  • If the Rational model is really wrong,
  • If having a wrong model really matters, and
  • If there are deep reasons for the long persistence of the wrong model,

then what are better models that

  • Emphasize the progressive discovery and evolution of design requirements,
  • Are memorably visualized so that they can be readily taught and readily understood by team and stakeholders, and
  • Still facilitate contracting among fallen humans?  {p.52]

Brooks thinks that something along the lines of Barry Boehm’s Spiral Model of software development will best meet these criteria.

In the middle section of his book, Brooks explores a variety of topics and issues relating to design including

  • when collaboration is useful vs. when it is not
  • conceptual integrity
  • identifying the core budgeted constraint (rarely money)
  • finding and developing great designers

In the final section, Brooks examines several cases in depth.

As a series of essays and reflections, this book is most valuable to those who have wrestled with design problems of their own. Given the frequency with which all of us are presented with design problems, Brooks’ reflections on real design problems offers many useful insights. Among the insights that I will be mulling over:

  • the boldest design decisions, whoever made them, have accounted for a high fraction of the goodness of the outcome
  • great designs have conceptual integrity–unity, economy, clarity. They not only work, they delight.
  • An articulated guess beats an unspoken assumption
  • wrong explicit assumptions are much better than vague ones
  • If a design, particularly a team design, is to have conceptual integrity, one should name the scarce resource explicitly, track it publicly, control it firmly 

Observable work – more on knowledge work visibility (#owork)

My post on the visibility of knowledge work last week generated some some excellent comments and excellent blog posts around the web. For my own benefit I wanted to gather up what I’ve come across so far and put it in one place.

Recap

Greg Lloyd, CEO at Traction Software, kicked things off. pulled together some key threads of the conversation and gave us a better label – “observable work.” His initial summary:

I believe that principles of open, observable work like open book financial reporting to employees – is a simple and powerful principle that people at every level of an organization can become comfortable using. In my opinion, wider adoption of observable work principles can succeed with support and encouragement from true leaders at every level of an organization – as Peter Drucker defines that role: “A manager’s task is to make the strengths of people effective and their weakness irrelevant–and that applies fully as much to the manager’s boss as it applies to the manager’s subordinates.” Enterprise 2.0 and Observable Work

Greg also pointed to an excellent post by John Tropea at Library Clips:

why do I have close to total awareness of people in my personal life that requires low effort, but yet in the workplace I don t have this ambient awareness!

In fact it may be more crucial to have micro-blogging/activity stream networks in the workplace as we share and work on the same/similar/related goals and tasks within our teams, across teams, workgroups, and enterprise wide so the more we are aware, the more we can be on the same page, and have better coordination, cooperation and collaboration surface opportunities (emergence), have the best people on the right tasks, and generally have the ability to be more responsive and adaptive.

Balancing Uniqueness and Uniformity in Knowledge Work

Self-portrait of Leonardo da Vinci. Red chalk....

Image via Wikipedia

The essence of good knowledge work is uniqueness not uniformity. The ideal knowledge work product is exactly what your client asked for and could only have been created by you. The challenge is that we have been conditioned by the industrial economy to value uniformity and see uniqueness as undesirable variation instead of the essential quality it has become.

To deliver better knowledge work products, we need to unlearn habits and develop new perspectives. Our inappropriate habits stem from assumptions about industrial work. With industrial thinking, once you ve created a new product the goal becomes how to replicate it predictably. You specify the characteristics of the output precisely, lock down the process, or, ideally, do both. That works if you need to manufacture cars or calculate every employee s pay stub correctly. It doesn t when the goal is to create the new product. The primary challenge here is to shift focus away from the issue of replication and toward creation. The question becomes how do we manage to create this? instead of how do we produce the same thing all over again?

Creating good knowledge work has a challenge beyond simple uniqueness. It is the same challenge faced by artists who once worked at the pleasure of their patrons. You want to create your art, but ultimately, you have to please your patron as well. You need to educate your patron about the nature and qualities of the output you have been commissioned to create and you need to learn from your patron what limits and constraints they face in putting that output to work. The unique insights where value resides may need to be packaged in a document or presentation package comfortable to the organization. Or you may need to place those insights in a more familiar context that lets them be seen by the organization.

Working out a feasible balance between the unique and the familiar is more complex and more subtle than either simply delivering what the customer asks for or creating an off-the-shelf product. It is not precisely a negotiation, nor is it generally a full-bore collaboration.

A basic strategy for discovering an appropriate knowledge work output has three parts.

1. Defining a deliverable.

If you ve grown up in a professional services environment, what s the deliverable? gets tattooed on the inside of your eyeballs. It s essential in professional services because it creates something tangible for which you can get paid. In any form of knowledge work the notion is valuable in that it makes something tangible out of what can otherwise be an amorphous process. A deliverable might be a spreadsheet or a presentation, an executive workshop, or a first release of a new information system; regardless, it needs to be something that both you and your client can point to and decide that it is done.

2. Understanding how the deliverable will be used.

The most important thing to understand about a deliverable is what your customer intends to do with it. Will it be used to identify a decision to be made? Justify that decision to someone higher in the food chain? Generate or eliminate alternatives?

Each of these possible uses influences what is important about the deliverable and what is secondary or irrelevant. For example, if your customer wants to understand whether a particular technology does or doesn t work in their current environment, a lengthy analysis of the current state of the software market isn t likely to be relevant.

That same analysis may be the essential requirement of someone evaluating whether to introduce their technology to the market. Whether you invest in preparing the analysis depends first and foremost on whether someone needs it.

3. Determining how the deliverable can be created.

Understanding how a deliverable will be used sets limits and focuses your attention on how it should be created. An executive who needs an answer about whether to invest in a new distribution channel may prefer that answer delivered on a one-page memo. However, if your customer is that executive s support staff, you may need to create substantial supporting analyses. Even in that case, whether you deliver that supporting analysis as a bound report, an electronic document, or organized as a series of frequently asked questions will affect both its value to the customer and its cost (to you) to create.

This three-step process should be followed for every piece of knowledge work we create. The urge to standardize outputs or processes is a holdover from industrial practices that is inappropriate in a knowledge work environment. Applied here, it risks short-circuiting the essential interaction. We must define and deliver the unique output that integrates client needs with your ability to create an appropriately unique solution.

More from Dan Pink on the Science of Motivation and Purpose

My long-time friend (old is such an ugly word) Vaughn Merlyn at IT Organization Circa 2017 points to the following fascinating animation to a speech by Dan Pink on his most recent book Drive, which I reviewed here earlier this year. It’s well worth 10 minutes of your time to watch.

 

We are in the midst of learning some immensely meaningful stuff about how our minds work in recent years. I’m willing to bet that those organizations that factor this knowledge into their designs first are going to make significant strides in the next few years.