Much of what passes for career growth is about individual aspirations and assessing one's place in the pecking order. But those with the greatest careers focus on seeing the fruits of their efforts blossom in others.

In the end, career has two consequences: to create value for the world around us, and to support and influence our colleagues. The bottom line is usually people, whether through the indirect contributions of our products and services or the more direct gift of our own time and presence (see Two People at a Time).

Many of us feel we do a great deed by giving our colleagues what our job requires or by being helpful. It’s one thing to be the light or water for a plant, and quite another to be the earth where the plant takes root or the trellis on which it leans for support and climbs skyward. Gardeners come and go, but the soil and trellis persist for at least a season of its development.

Bad colleagues (and consultants) position themselves as the primary sources of light or water for a plant to create a dependency of I-have-water-and-you-don’t. Creative people can always find alternative sources of water and light. Being the soil or the trellis creates an even stronger dependency, of course, but with the adventure of commitment for at least a season — a period together in a department or project. That kind of commitment takes trust and, if an increase in value ensues, it builds trust.

From a pragmatic perspective, growing others is about amplification. Giving someone your product or supporting them with your service is like selling fish; giving of yourself is more like selling fishing poles. Of course, don’t neglect your responsibility to generate value, but keep the bigger picture in mind.

Larry Constantine once relayed a challenge he received from a friend years earlier: Given the choice, would he rather have contributed something of long term significance but remain unknown and unappreciated or would he have preferred to become widely recognized but have done little of consequence?  Years later, Larry denies the premise that this is an either/or choice — but those who seek fame first diminish their chances to have both. The trellis hides behind the rose.

This attitude points to a deeper love either for other people, or for ideas themselves, than for one’s own career. It’s an attitude with roots in feeling secure and is a posture more easily attained from a position of accomplishment. As such, the opportunities to broadly grow others increase as one’s own contributions increase.

The usual view of career is that one rises through the Maslow hierarchy of needs. Gainful employment lets you meet basic physiological needs; a higher-paying job affords one a residence in a more secure neighborhood. This security affords one the opportunities to “belong” to some community, either within or outside of work. Accomplishment and a secure identity increase self-esteem, and ultimately one attains the pinnacle of self-actualization.

Choose to regard your vocation from a collective rather than individualistic perspective. Agile focuses more on the result (“working software”) in community (“individuals and interactions”) than on what sets one apart. “Belonging” is a birthright of agile rather than something earned. Group potential outshines the social ideal of achieving individual potential. Self-worth and actualization precipitate naturally from supporting  your team — but not vice-versa.

It’s about the Thou rather than the I. It is you, directly, rather than your product or service, that creates the greatest value in others. Invest in another individual’s career.

I'd like to share some thoughts about paradigms of workplace engagement based on our relationship to risk. These four paradigms of engagement are: conservatism, courage, trust, and existensialism.

A conservative avoids risk by avoiding conflict or even transparency. A colleague of mine used to avoid saying “the team failed the Scrum Sprint” to distance himself from any implied negativism. He revived his use of the word only after discovering that his boss had been using it while encouraging employees to take more risks.

In the courage paradigm, one strives for some greater good while acknowledging possible negative personal consequences. Courage is personal: consequences for colleagues or for the enterprise are a separate issue. While courage is often cited as an agile value it smacks of a hero culture and of short-term solutions in a climate of fear. That’s not sustainable. Courage may open the door to change, but great agile organizations take the extra steps to engage the culture instead of  just assaulting it.

The third is trust: to rely on expected standards of behavior. Svendsen delineates three kinds of trust in Tillid: Tænkepauser 4 (http://www.tænkepauser.dk). Individual trust draws on past experience between individuals. Individual trust alone may not serve the greater good (even criminal gang members trust each other), so we must add the dimension of community. We exhibit social trust towards strangers with whom we may share common culture and its implied moral framework. For example, between Danes, one’s word is one’s word. Last is trust for institutions. Low corruption leads to trust in the government, which is a boon for business. Smart Trust by Covey (Simon & Schuster, 2012) relates a direct correlation between per capita GDP and trust at a national level (p. 15).  

The last paradigm, existentialism, is about responsible action without regard to any pre-formulated consequences.  Existensialistic efforts revolve around individual initiative or small, closed systems; agile approaches embrace open systems.

The same colleague who dodged the word “fail” once asked me to enter into a responsibility contract with him whereby we would encode all commitments in writing and never expose any missed commitments. Human behavior is so broad, varied, and dynamic as to defy any attempt at comprehensive codification in writing: “Agile covenants” and “agile team charters” are oxymorons. They represent closed systems. Maybe we could express the right level of human empathy in the language of music or poetry, but certainly not that of a team charter or other contract.  Svendson relates: “Social trust is thus the ability to work in groups on common goals. As the American political scientist Elinor Ostrom, who received the Nobel Prize in 2009, writes, voluntary cooperation builds on self-policing, thereby establishing an informal institution without written rules. This stands in opposition to forced cooperation enforced by an authority in accordance with formal written rules.” Forced. Enforced. Authority. Formal. Read: Not agile.

Agile is about responsible action beyond the individual towards customers and colleagues. This means going beyond conservatism, personal courage, and individual trust to the contextualized dialog of social trust. A static written covenant soon fades out of date while “living documents” come to be viewed as instruments of fashion.

Great trust unfolds at the level of enterprise and culture, and great change agents link individual influence to change at that scope. Untrusting societies waste resources on burglar alarms, lawyers, contracts, and security. Those, like social contracts, are forms of control. Svendsen adds, “If confidence in the community disappears, things become less flexible and more cumbersome.” Reach beyond individual trust and social trust to create open communities of trust in your institutions.

Imagine a career with zero risk. It smacks of an ad in a cheap magazine, targeting the unsophisticated to lure them into some kind of scheme. There are careers with little risk, such as being a hotel receptionist. Then there are careers where risk avoidance is essential to the nature of the job or the state of the technology, such as bomb defusing or piloting commercial airliners. Then there are careers like race car driving where the risk itself draws us to the profession. I think that a great engineering career is much like race car driving in this respect — though I have also seen engineers in the hotel receptionist category. Of course, you never can make risk go to zero.

I used to work in the then-prestigious Bell Labs Research, where our job was to explore new frontiers. The unexplored always has risk of low payoff and the application of research results has sometimes made things worse. The nature of research is to take risk.  The question arises: how do you reward a researcher? What is good research? A developer playing it safe and masquerading as a researcher wouldn’t fare well in the organization: they rarely fuel the innovation engine. So a balanced degree of failure is not only allowed, but expected. This is the risk paradox: for someone in a research career, there is no personal risk in taking risk. The enterprise manages the risk at a higher level by managing the number of people allowed to fail as frequently as researchers do.

We tend to associate research with novelty and risk with adventure. Risk and adventure are related but neither one is about novelty alone. I can have adventure without risking value, life or limb, such as we challenge ourselves to on roller-coaster rides. Maybe there is always a potential sense of adventure behind risk-taking, but too much of it can lead to compulsive dysfunctions as with habitual gamblers.

Engineers tend to be conservative (see The Grass is Greener) and, as such, try to push risk into the distant columns beyond the decimal point. Our profession is so linked to risk aversion as to color English vocabulary: you rarely hear the term “under-engineered” in vernacular English, but its complement is common.

An agile project or career is one with higher-than-normal risk. Great organizations not only tolerate risk, but encourage it. Don’t tempt fate with irresponsible action. On the other hand, don’t avoid failing: strive for excellence instead.  In Bell Labs Research, even in the days when we were expected to be “relevant,” playing it safe was not an option. I teach Scrum students to push themselves to the raw edge of complexity staring in the face of chaos. It’s important not only that you learn your organization’s current risk appetite, but also that you help the organization push the limits to the edge of increased value. And remember that in well-managed risk, there is no failure: only feedback.

All risk has a time factor. I have taken career risks by making a stand for what was right when I could have stayed quiet. That sometimes cost me in the short term, but I have no regrets. Maturity helps one cope with the delay in the gratification of knowing one has done the right thing. That knowledge itself is a treasured outcome above and beyond the value accrued over the years from such decisions, and that helps put the short term losses in perspective. Maybe there is less career risk in taking career risks than you might imagine.

It’s hard to grow in an organization where everyone shares all your views.

You hope to learn when you sign up to a online discussion group; you hope to be challenged when you read a book. You take up a job not because you can do it perfectly, but because it will bring you to a point of creating value unachievable from your current state. Value comes in what the French call différance (different from the French word for difference, which is différence) — on ongoing interplay of conflicting ideas that play out in dialectic.

Conflict is an essential ingredient of growth. I’ll claim that the more intense the conflict, the more rapid the growth, within a certain field of play. That field of play is sometimes difficult to delineate, and this installment is about those boundaries.

I often join organizations for the sake of the challenge. “Joining” ranges from having beers with fans of the opposing football team during a championship match to devoting my career efforts to an organization that I believe I can better change from the inside than from the outside. Neither of these postures says anything inherently bad about any football team or any organization. However, no organization (or football team) is ever perfect, and the dialectic process changes both object and subject in the process.

There are always rules for “joining.” It means playing fairly by the rules of their game. If I join an online discussion group I should not represent myself as an unqualified opponent of the foundations that draw the group together, even if I think they are all misguided. I should instead play within the group’s own rules to deconstruct our respective posture and lead all of us into learning. This is respect for the individuals that I join and courtesy in my engagement with them. Play clean, by the rules.

The group may expect something of me for the prize of joining up. If it’s a job, I need to produce. If it’s a club, I’m expected to attend and engage. Joining only to affect your agenda is subterfuge. Be trustworthy and loyal.

One rule of the game is to tackle one issue at a time. If I jump all over the place, dodging when cornered, and ever charging up new hills, I’ll at best be viewed as a flake and will certainly not achieve my objective. Paradigm shifts rarely happen from within but rather through changes in the environment or in how we view it; it’s difficult to project those views from inside a system. One step at a time.

It is always important to be open for change myself. If I make myself part of the system and if I am changing it, then I must also be willing to change. This means being able to take a dispassionate stance, at least occasionally, and of course it implies great listening skills. Keep an open mind.

Be yourself. It’s important to be genuine. People have learned over many centuries to be able to smell politics. Let the chips fall where they may. Be friendly and helpful.

You may trigger emotion — emotion which in turn can cause fear or insecurity to rise in you. Follow your heart, and do what is right. Be brave.

Most important, be aware of the prize. By joining and fighting, am I giving or taking? It’s O.K. to benefit both from association with a group of people and from the debates that go along with that association. But you will lose trust if the prize is the pride of being right or personal gain from lining them up to your position. Be generous.

Someone recently posted the question on an IEEE Computer Society forum: “What is the best Information Technology certification?” As I elaborated in my earlier comments on Certification, I don’t find certification level as a meaningful qualifier for any job above technician. Certification may help you land a job, but it’s no way to launch or even advance a career. I went so far in my advice as to say that I’d probably refuse any employment offer where the question of certification arose during the interview process. And I further recommended that job experience deserves the spot as the determining factor in employment qualification.

Research evidences this. Paul Oehrlein’s “Determining Future Success of College Students” (Undergraduate Economic Review, Vol. 5 [2009], Iss. 1, Art. 7, The Berkeley Electronic Press, 2009) indicates that experience overshadows factors such as SAT scores and grades by about an order of magnitude. If you view grades and experience to be independent measures — and this seems to be so according to research in most fields — then don’t sweat the grades, but do be attentive to experience.

Can I say anything useful about experience in a finite ‘blog entry? Many of my other musings here are in some way quantifiable and lead to concrete action that might even be planned: investing in others; giving, time management, acting in terms of the big picture instead of the immediate. It’s a bit harder to accelerate one’s acquisition of experience beyond a certain level. While experience is more than just accumulating grey hairs, it’s difficult to claim a seasoned perspective on one’s profession without the gift of years. The gifts of perseverance and reflection, or at least of endurance, are also important.

Experience is more than a collection of experiences. Experience is practical and requires the kind of reflection that leads to learning. It grows gradually through life’s way stations. Learning happens in the hands and heart more than in the head. It unfolds over the intervals necessary for assimilation and integration; however, the passage of time alone is no guarantee of learning and we shouldn’t confuse grey hairs with experience. Research in project management shows little correlation between proficiency and  years in the field (Attributes of a High Performance PM - 2007, The Executive Board, http://www.executiveboard.com). Experience can’t derive from being a bystander in the classroom or on the assembly line: You have to be in the game. It means diving in, doing work, building stuff, and taking risks.

Not all experience is positive in the short term. Reinforcing experience seldom changes behavior; we tend to learn from failure. Remembering your successes and failures helps you to use life and career as a scientific laboratory. Look for the patterns in what succeeds and what fails; some of you may find a diary or journal to be a useful tool.

Experience starts now. Even if you are just in school, take the opportunity to apply your nascent skills in an internship, part-time job, or other avocation that grows you. Applying your skills is much more important in the long term than achieving some academic grade. It’s rare that you can perfectly plan experience in advance: it’s not so much about setting aside a two-year stint at some position that affords a check mark on your CV as it is about capitalizing on the opportunities in your environment. Experience is much about keeping your eyes open for such opportunities.

The sweetest experience is hard-won and the best experience is broad, generalizing across life disciplines and situations. Take risks, be introspective, and always be seeking the next higher niveau.

Certification aspires to be a societal recognition of some level of professional competence. It’s a measure neither of performance nor ability: a shortcut that claims to predict long-term professional competence. While most certification requires training, it is usually granted on the basis of a few minutes of testing that purport to predict a career of behavior.

While we hold the stereotype that certification indicates an elite level of performance, conveyed by those holding the highest standards in a given field, it’s difficult to find anything that indicates why this should be so. That is, there is little culture of meta-certification: of certifying those who establish certification norms. Its goal is always to separate the included from the excluded, but there is often little evidence that it separates the capable from the desirous.

It isn’t the individuals involved who are the issue, but rather the institution of certification itself. Certification is a trust substitute. I can trust that a proxy certifying agency has established trust on my behalf rather than requiring that I take that bothersome time to do so.

Too often, these norms are set by people who have more of an interest than any imbued right or moral imperative to establish them. They need only to avoid the extremes that would attract controversy, and rarely invoke any empirical grounding. That this is largely so should raise our suspicions. Standardization efforts rarely tap into broad practice or the representation of broad mores, because the people who develop standards almost always take the mantle on themselves instead of being thrust into the position by a supportive constituency. That in itself doesn’t imply that standards-makers are inherently evil or opportunistic. I have known many of these people and they are doing their best to do a good thing.

At best, certification sets the bar at a level sufficiently above blind stumbling to gain the label of competence. But success in today’s engineering and software worlds depends on being able to handle complex situations that defy teachable technique. Any “skill” that can be evaluated with a test is suspect: as highlighted in Is there a doctor in the house, we know that test scores are poor indicators of future performance. Most certification tests knowledge — not practice.

Certification makes sense at the level of agreed, objective standards with a foundation in absolute axioms. Lawyers are certified by the bar on the basis of understanding arbitrary rules of conduct called ethics. Lawyers must be ethical: they need not be moral. Certification comes from being able to mechanically adhere to codified workflows of court procedure and client engagement — not for the aptitude to follow them. The same is true for most technology certifications, whose exams largely test knowledge at the very lowest layers of the Bloom taxonomy. So though Scrum practice has moral and business implications, ScrumMaster certification is largely about level-1 Bloom knowledge (regurgitation) of elements of the Scrum framework and of technique.

Few certifying entities enforce the practices covered in the evaluation instrument. Maybe we presume that the certified should police themselves. If that’s the case, it’s difficult to argue the value of certification. Agile principles are rooted in continuous feedback — not a one-time assessment of one’s direction as in waterfall, but through ongoing introspection. Certification should be a process rather than an event or even a series of events. Even better is a life process of learning and of Kaizen mind. Certification pretends to establish the trust that can launch one’s career in some well-defined profession, but at best it only prepares one for a job.

Disclosure: IEEE Computer Society is a provider of two certifications for software developers--the CSDA and CSDP.

The voluntary, uncompensated gifts of time, talent, and treasures that professionals offer to their colleagues are among the more wonderful social norms among engineers. Or course, it’s not only engineers who do this, and maybe other professions are much better at it than we are. However, I feel in my heart that we do our share.

And, in fact, I would guess that the present audience here, that reflects a high IEEE affiliation, is better than most. Gifting has become a tradition at some of the pattern conferences around the world. There’s something about the sense of identity and purpose conveyed by a professional group, be it a club or a swarm, that switches on the giving gene.

On a practical level it’s hard to find the time to turn the great ideas that society has given you into the gift of a journal article or of a short talk at your local professional chapter of the Klystron Generator Society. Fear plays a role here, as we know our professional time has value—value that our jobs traditionally convert into money that puts food on the table for those we love. And that’s a real practicality. But to cling to that perspective alone is unbalanced and short-sighted. Going beyond the job perspective to the career perspective looks beyond this month’s budget to the long-term good of not only your family, but the profession, and humanity as a whole.

A potential paradox lurks here. One can argue that, in the end, there is no altruism. One can clearly benefit from public appearances, and when I give my time to the local Ruby programming group or to the opening of a nerd café in my greater neighborhood, I am aware that I also gain publicity. This sometimes gives me pause to reflect. It’s both important, and difficult, to keep one’s motivations clear. Codes of professional ethics and dialog with your colleagues can shed light on this issue and perhaps modulate your feelings. Understand why you do what you do.

That said, it is crucial to realize that giving does not have to be a zero-sum game. In fact, it is this balance between giving and receiving that can offset the survival fear rooted in the relationships between one’s talents and one’s survival. If everyone wins in the long term by the giving of your time or talent, that’s better than a gift of sacrifice. Sacrifice and grief are sometimes useful tools in righting an untoward situation, as one finds with hansei in Japanese culture. But the notion that gift has value without someone having to suffer is a trap of Western culture that we can trace back to Aristotle, and which has been amplified in the predominate belief system mores of the Western hemisphere. A gift should be cause for celebration, both for the giver and the receiver.

On the other side, be a gracious recipient if you receive a gift. It’s more blessed to give than to receive, but it’s also blessed to receive graciously. Jerry Weinberg says that gratitude is the most powerful of human emotions. It can be difficult for you to receive a gift if its offering makes you feel beholding to the giver. That causes you to put the giver in a negative light: to view them as manipulative. Get over it. It’s likely that feeling isn’t as much about your benefactor as about you, and about how you feel the world works. That’s food for thought.

It’s about priorities. Put some gifting on your backlog, and tap into the joy of giving.

One only has to look at how we dress  to see that engineers are not a very faddish lot. But engineering has roots in the sciences. That science may often be driven more by fashion than by need is one of our disturbing realizations of the past two centuries. Science is sexy, and sexiness begs fashion. Many such fashions revolve around societal myths about the scientific nature of things, fed by the science fiction fantasies of our youth — ideas like the speed of light. If you can sniff that neutrinos might travel faster than light, it’s important to start the presses rolling.

We in our horn-rimmed glasses and plaid shirts see ourselves as having one foot firmly planted in the concrete, the girders, or the silicon mazes of production. We respect the laws of physics for how they temper sensationalism. But our few sensational successes owe more to project management than to science, such as the supply chain management that enabled the Empire State Building to be built in a year. Maybe that’s because the bulk of engineering is about management, contract administration, and project management (It’s Not Engineering, Jim).

We are also accountable to real markets that expect concrete deliverables. We derive credibility by bridging science to practice. Those around the edge of engineering, like so-called software engineers, so envy this credibility that to co-opt the name and to carry on cargo cult imitations of engineering practices become elements of fashion in their own right.

Nonetheless, engineering has close ties to the scientific community through the research that we sponsor. And our accountability to the market hones our sense of fashion; unconstrained by deliveries or economics, our research partners redouble their pursuit of fads. Research funding depends on it.

Doug McIlroy mused (ca. 1991):

Many illustrious computer scientists have given summaries of results in [STOC, FOCS, and SIGGRAPH] proceedings papers and then never fleshed them out; more than once it has happened that the result is wrong, at least in detail. Thus a surprising theorem announced in proceedings should be regarded with skepticism.  If you regard your work as of more than transient value, and hope that others will too, you will go the extra mile for archival publication. Conference proceedings keep the pot boiling on the stove; the archival literature provides the floor for the stove to stand on.

Also check out http://online.wsj.com/article/SB118972683557627104.html

This leads us to the golden concept of innovation, so embraced by the science-meets-application world today. Oh, that would be us. Innovation is killing us: the good of innovation drives out the perfect of invention. Optimizing those innovations that the market yearns can cause entire companies, or perhaps entire nations, to lose their vision. Consider their government’s urgent call for action to Finnish industry back in 2009  (http://www.aka.fi/Tiedostot/Tiedostot/Arviointitoiminta/SIGHT_Summary.pdf): 

A disproportionate amount of research at universities today focuses on application and product development at the expense of basic research. Key policy documents over the past few years have placed scientific research primarily in a technological and economic context. Other relevant factors probably include the large proportion of doctoral students within the research community, the standard of the science infrastructure, the research system’s low level of internationalisation as well as defects in the principles of research funding and scientific management.

You know the rest. The right approach requires balance and courage. Innovate, but nurture invention as well. That means focusing on the long term, and on a world ecosystem, instead of just the market you are being paid to research and develop.

What should an engineer be thankful for?

The usual seasonal platitudes might include being born into a situation that afforded a shot at an engineering education. One might be grateful for the education itself — but most American folks feel that their education was something they bought, rather than a gift. We might be grateful for the particular care or dedication of a particular professor or manager — gifts in the realm of the undeserved or unearned. Among the most powerful of these gifts is to have a true mentor.

We learn from many along the way: managers, colleagues, teachers and parents. They all deserve a special place in making us wha we are. Some of us have coaches, and we of course have learned at their table. But coaches live near the slippery slope of professionals just doing their job, and the ulterior motive of supporting their families can give us pause (sometimes undeserved) about their idealism. Mentors are a bit different because in spite of having the same kind of long term commitment to us as a coach, their role as mentor is usually incidental to some other role in our life constellation. That other role can of course be that of manager or teacher or advisor. We don’t remember all managers, or all teachers, as mentors. We remember our mentors as mentors, much as we think of our parents as parents — the parallels between the two run strong.

There is something spiritual about the relationship between mentor and mentee. A mentor is a teacher, and we explicitly lift up that a caring kind of teaching is going on in that relationship. The dictionary suggests that experience and trust are key to mentoring.

I was assigned a mentor during my early days at Bell Labs. He had all the wisdom of two more years of service than I did. He maybe invested 20 or 30 hours in mentoring me over the first year (2000 hours) of my job — if one can call such a level of investment mentoring. I’m sure he cared about my success, but I can’t say that he was invested in it. Which is mentoring?

One of my most profound mentors was Jerry Weinberg, who epitomizes many of the best qualities of good mentors. He was able to develop empathy with my situation and yet maintain a degree of objectivity.  He could tell me I was full of crap when he thought so. And, most of all, we connected with each other because we wanted to — not because of any obvious “professional” motive such as was at play with my Bell Labs mentor. Sure, we both benefited from the good feelings about the relationship and for the prospects of how it would help one (or both) or us improve our judgment and the other (or both) have increased influence. What made it powerful is that it was Two, focused on One. The One was me. For Jerry to invest the time in that relationship without expectation of return was a great gift.

Larry Constantine was another — sharing painful lessons and powerful metaphors from his career. The sharing was deep, and personal. My old technical manage Neil Haller got me interested in running, and we had many mentorly chats while pounding the pavement during the lunch hour.

I in turn have tried to give back — through spiritual, long-term investments in people. Similar to the Danish concept of friend which is usually limited to two or three in number, and which tend to last decades, my concept of mentoring is concentrated and focused. How about yours?

A ghost from my childhood still haunts me: the memory of luddites fearfully pitted against factory assembly lines. What’s odd is that in spite of the familiarity of the rant from my childhood, I can’t recall the last time I heard it on the street or read it in the news. Automation is an accepted part of modern society. Perhaps it stands on the shoulders of the 1960s Utopian hopes that technology would relieve us of mundane tasks and give us lives of leisure, or perhaps society is satiated that demand has just caught up with supply.

We usually associate automation with industrialism, but the arts aren’t immune from technology. This is an important side discussion because engineering lies in an uncomfortable space between science and art. Modern art history has been a struggle between the forces of mass production and human individuality: the beaux arts, the Arts and Crafts movement and Art Nouveau celebrate the human in art; the London Great Exhibition of 1851 and Art Deco highlighted the contributions of machines. Most modernistic schools have this same industrial streak.

In late-19th century Japan Sakichi Toyoda noticed that his looms wasted cloth when continuing to run after their yarn ran out or when weft threads broke. His inventions put “human intelligence into the machine.” The looms could now automatically detect these conditions and shut down so that a person could repair the problem, restart the loom, and avoid the waste. 

Taiichi Ohno would later incorporate this concept as a pillar of the Toyota Production System, and called it autonomation. It would appear in Toyota plants as, among other practices, “stop the line.”

Ohno distinguishes autonomation from automation as having a human touch or a limited form of human intelligence. Autonomation doesn’t fix problems: it merely stops the machines so a human can fix them. Full automation requires that a machine find and fix its own problems, but that’s rarely cost-effective. Let humans intervene for the quirky job of problem-solving rather than doing the dehumanizing job of standing guard over the assembly line. While full automation is not cost-effective, autonomation is.

Computers are heralded for automating our tasks. Why does it not give great joy to employees that use electronic time-card systems instead of paper? Because the paper never worked in the first place. Autonomation not only goes above blind automation to accommodate errors, but focuses on techniques that have been proven to work without machines. Too much software today promises only to do things differently than we have done in the past. This is the same misplaced assumption that fueled modernism in design: that to be new or different was automatically to be better, if it employed the latest technology. Give a graduate class the assignment to create a tool to help a team track progress on its tasks and they’ll computerize the task: No CS student will consider solving the problem with stickies on the wall, let alone consider evaluating whether that might be a better solution than the automated one.

Too much software today pushes users into a position of meeting the machine on its level and its terms, forcing people to do things that machines do well. The programs aren’t intentionally masochistic: they’re striving towards full automation, but they fail with a high cost to the end user experience. Consider that the next time you submit an ACM paper online or use another online web service.

Prove in the human processes first, leaving out automation, and then automate that new process if it helps. Avoid technology for its own sake.