Agile Careers

 

Jim ("Cope") Coplien is an old C++ shark who now integrates the technological and human sides of the software business as an author, coach, trainer, and executive consultant. He is one of the founders of the software pattern discipline, and his organizational patterns work is one of the foundations of both Scrum and XP. He currently works for Gertrud & Cope, is based in Denmark, and is a partner in the Scrum Foundation. He has authored or co-authored many books, including the recently released Wiley title, Lean Architecture for Agile Software Development. When he grows up, he wants to be an anthropologist. 

Log in to register a comment.

Subscribe here.

Blogs Blogs
Becoming

Andrea Tomasini’s mail byline has long been, “Agile isn’t something you do; it’s something you are.” It’s a tidily profound statement. Agile is about what you do in the moment; lean is about what you are. Andrea’s saw points more in a lean direction than an agile direction.

Where are you on your corporate merit ladder? Stack ranking is the darling of American culture and one of its most poisonous exports. It has taught engineers to establish a turf of some niveau, often heralded by a suitable title.

Such scales tend to have no definitive top. Barry Boehm notes that individual software skills vary by two orders of magnitude. The scale is logarithmic, and the top is difficult to delineate. For years the four-minute mile stood as an absolute, as did the 30 Kelvin limit for superconductivity. The limits humanity set for itself seem always to fall, and that is perhaps a deep aspect of what makes us human. What we do in any moment is for that moment, and is passing. What we are carries with it the potential to excel in the moment — and maybe more. But that’s a matter of effectively employing our faculties.

It’s less about what what you do than what you are and, beyond that, more about becoming than being. The difference between what you are and what you can become is a difference of statics and dynamics. “Doing your best” on a job is about what you are. My friend Jens Østergaard is a good and prolific Scrum trainer who understands that the future holds uncertainty. Both of us teach people to live each day of our projects expecting occasional failure (see: There is no Failure, only Feedback). If you fail, you can take comfort in knowing that you did your best.

Did your best is always in the context of what knowledge and resources were available to you at the time. Experience is sometimes the best teacher. It gives you the option to grow, and if you’re growing, what you will be tomorrow won’t be what you are today. The delta is about becoming.

Kaizen mind focuses more on this process of becoming than on what one is at any given time or even on the succession of hopefully ever-improving accomplishment or performance levels. The differences are subtle. The first focuses on results, and that phrase “focus on results” probably rings loud in the ears of those whose corporate cultures take it as a rallying cry. In a complex world, results are always transient in the moment.

Rather than focusing on results, it’s about focusing on the improvement process itself. Consider one engineer who focuses on improving her design, ever reducing the power needs of some system component. Meanwhile, another engineer focuses on making sure the feedback loops are in place and finds wisdom in many counselors instead of hanging her hopes on the insights that the current product generation yields up or that one can glean from a history of such data. The former is Pavlovian: a facility we can ascribe to dogs and even to earthworms. The latter is perhaps uniquely human, and may lie at the foundation of happiness in life.

“Becoming” is a word that Nonaka-sensei uses often. The grandfather of Scrum, he is steeped in the Japanese process frameworks that have inspired much of the modern world of complex development. He knows that focusing on the process will yield value; staring results too directly in the face leads to performance myopia.

Do-be-become. Do well, just be yourself, and continuously challenge yourself.

Methodical Doubt

All professionals recognize arbitrary truths that direct their day-to-day work. Such norms of respect for knowledge are keystones of culture. They become the unspoken and assumed backdrop against which professional discourse takes place. We first pick up these bits of authority through our education and find them reinforced in our interactions with those colleagues who came through the same upbringing.

Engineers are luckier than most because, at least for the simple stuff, we cling to the edge of the sciences. We put our faith in indisputable truth. E = IR, F=MA. The fist problem is that, within the span of a career, even the truths are disputable. Until 1986 we knew that superconductivity couldn’t exist above 30 degrees Kelvin; the 1987 Nobel Prize in Physics went to those who established superconductivity at 35 degrees Kelvin. The amount of knowledge doubles in science about every 10 years. But the larger problem is that many claims we hold as truths aren’t truths at all.

Engineering is often a hammer used to reinforce a timeless “truth.” The engineering label gives any claim a sheen of credibility, but it is in fact the self-reinforcing culture of like thinkers that gives these “truths" power.

The old days of software development were grounded in a belief that discipline could generate perfect up-front requirements — a belief that perhaps emerged from the hope that such reasoning could eventually be fully automated, but that good human effort was an adequate substitute in the mean time. Methodology — another one of the truths that was a product of that culture — was held to be enough to achieve success. If we ever failed to deliver, we blamed ourselves and created a notion called a “post-morten” to discover where we had failed to follow the methodology. No one dared question the methodology itself.

As engineers, we are prone to follow method. Have you ever been working on a project and, faced with a design decision, found yourself falling back on one of the rules you were taught, in spite of the fact that you had more than an inkling that the current wisdom might be unwise?

Few truths are absolute; it is in fact unlikely that there is any single static truth in any endeavor. Truth is a process. Strongly typed programming languages are not always good, and weak typing sometimes has its advantages. Context is everything, and experimentation and good dialog are its handmaidens. The biggest problem with the dogmatic engineering mindset, rooted in the supposed truth of the sciences, is that they are context free. Most interesting complex problems of the modern world are highly contextualized. There is a two-edged sword here, as the common wisdom is diluted as much by fads as by myths. Again: experimentation and dialog must prevail.

Progress in day-to-day practice should enjoy more immediacy than Nobel recognition allows. And while peer review is important, common sense and collegiality in your workplace and professional societies can go a long way, particularly when coupled with methodical doubt. The next time your intuition runs up against the standards of truth of your discipline, talk up your idea a bit. Experiment and work against the grain a bit. You don’t have to be a genius to realize these breakthroughs. Hundreds of engineers recognize them every day but, repressed by the industry myths and the leverage they exert through peer pressure, retreat from learning to the misguided rote of alchemy. Great invention happens humbly every day. Don’t let the disproportionate recognition of a select few inventions discourage progress.

Work and Vacation

I love my work. I like to think of myself as not delineating the work part of myself from the non-work part of myself (see The Whole Person). So I started thinking the other day: what makes vacation special?

We shouldn’t have to contrast the happiness of vacation with less happy times at work. We celebrate many positive emotions in the workplace: feelings of accomplishment, of having excelled, of great teamwork, and of seeing satisfied customers. Vacation is supposed to make us happy, but few of us associate it with accomplishment, excellence or teamwork. However, the contrast may not be as stark as we imagine. Many use vacation to pursue excellence or accomplishment in pastimes like extreme cycling, mountain climbing, or participating in a tennis tournament.

I have an ongoing argument with the vice president who hired me for my current engagement. I feel strongly that an agile team should account vacation as it accounts work — e.g., to make vacation a Product Backlog Item. Why? Partly because it makes it easier to adjust production schedules for time off. Partly because a great enterprise sends a signal that it values personal well-being on a par with the bottom line. And it’s partly because it’s difficult to separate these two. Maybe I program at work to help the company serve its clients. But maybe I also program on vacation to create a video game for amusement or just for the satisfaction of having done it.

I think the distinction between time off and work time isn’t so much the activities themselves as what vacation portends for routines, focus, and goals.  Maybe we need to be refreshed with new life rhythms that afford us the time to sleep in or to act on whims rather than scheduled ritual or duty (see The Tyranny of the Urgent). Though we come to relax at home at the end of a work day, and there’s no place like home, there’s something about the routines and focus of home life that takes us far from home for our vacation plans. While on vacation I should be free from any goals of my boss or workplace, so I can be selfish for a while and focus my daylight hours on my own aspirations and the other people in my life.

A wise person, however, probably uses such opportunities to broaden the self beyond what workplace activities allow, and to feed a part of ourselves that otherwise is nourished only on evenings and weekends. It’s hard to separate work from any notion of a future objective, but vacation begs that rare human state of living in the now. Reading fiction and poetry, engaging nature, and experiencing new lands and cultures are the common diversions. But wander more deeply into emotional and spiritual explorations as well. Take time to pause in life and just soak it all in. The more goal-driven will build on those reflections to chart new life directions. But on vacation, perhaps as more broadly in life, the goal isn’t necessarily to have a goal.

Be generous to yourself with your time, and don’t hesitate to plan (but not over-plan) free time (see To Everything There is a Season). Europeans seem better to understand this, or are at least better to realize it, than Americans. Our traditions in Europe come close to closing down the entire nation for about a month — July in the north and August in the south. And don’t feel guilty about enjoying your work. Whether at work or on vacation, you deserve the best for yourself.

Growing Others

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.

Trust

 

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.

The Risk Paradox

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.

Sign Up and Fight!

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.

Experience

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

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.

 

Charity

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.

Showing 11 - 20 of 57 results.
Items per Page 10
of 6