I don’t much care having my picture taken, having a face for radio and all that. Finding a photographer who is both highly skilled and easy to work with just adds to the challenge of getting a decent professional photograph. Well, I’ve found a photographer that I can recommend highly: Kiki Lavine (Kelly Photography). The entire process “just worked” and I had an excellent spread of choices for any number of contexts. Thank you, Kiki!

Teamed with her photographer husband, Joe (Lavine Photography), they are quite a gifted pair and I’m delighted to know them both.

I’ve a new article published on Mike Cohn’s Front Row Agile web site: Managing Client Behavior for Optimal Sprint Performance.

Old joke: A young couple visiting New York City for the first time has lost their way. They spot a street musician, just the person to help them get reoriented. “Excuse us, but can you tell us how to get to Carnegie Hall?” The musician stopped playing and thought for a moment before replying: “Practice.”

The prevailing wisdom is that it takes 10,000 hours of practice to achieve the level of mastery in any particular field of endeavor. Turns out, this is true for fields with well-defined measures for excellence like chess and music. In each of these areas, the rules are relatively simple, but mastering them isn’t easy. It’s pretty easy to tell when someone is playing an instrument out of tune or off-beat. And yet, a pawn shop guitar in the hands of Joe Satriani or Liona Boyd will likely result in that instrument expressing a voice no one knew it had. As for chess masters, they’re the ones who win against all challengers regardless the time or place of the match.

For areas of human endeavor where the edges are less well defined, like business or coaching, there may be no marker for how much practice it takes to reach a stable mastery. Having successfully started and built one business does not guarantee the next venture will be equally successful. A coach with a winning system for one team may end up at the bottom of the ranks when the same system is used with a different team.

Developing expertise with scrum is a blend of both of these. The rules are simple, but they are not easy to master. At the same time the territory isn’t well defined and frequently changes. A new client, a new team, or a new project and the edges for what is possible change. Misunderstanding this has been at the root of much of the frustration I’ve observed among people new to agile. They come from a world with well-defined edges – traditional project management practices filled with Gantt charts, milestones, functional specifications, use cases, deployment requirements, and a plethora of other artifacts that “must” be in place before work can begin. As many unknowns as possible must be made known, risks pounded down to trivial annoyances, and all traces of ambiguity squeezed out of the project plan. Learning how to let go of deeply rooted practices like this is no small thing. We like the comfort of well-defined rules. And when there’s work to be done with scarce resources to make it happen, we reach for the rules most familiar to us.

So how can we update the tried-and-true, super comfy confines of past practices and rule sets?

Practice.

Research following on the “10,000 hours of practice” generalization has shown that it isn’t just that someone has completed 10,000 hours of practice. The critical factor was how they practiced. Was each hour spent completing the same motions and behaviors from the previous hour or were they spent building on successive experiences, seeking greater challenges, and developing a deeper understanding of their craft? Following the latter path leads to the incremental improvements required to build mastery. And once obtained, the same attitude toward practice helps sustain a level of mastery. There will always be something more to learn, a fresh perspective to experience, or a more satisfying way to experience success.

There is a great deal of neuroscience at the foundation of practice and few would dispute the value of learning how to learn. And yet as our experience grows and we master a particular field, it’s deceptively easy to fall into a complacency of thought whereby we convince ourselves there isn’t anything else to learn. That is until some seismic paradigm shift makes it clear the rules have changed and we’d let our mastery go stale. The consequences of this are captured by Greene (2012) in his book, Mastery:

“We prefer to live with familiar ideas and habits of thinking, but we pay a steep price for this: our minds go dead from the lack of challenge and novelty; we reach a limit in our field and lose control over our fate because we become replaceable.” (pg. 176)

If this happens, learning how to learn may not be enough. Learning how to unlearn may be equally valuable for regaining mastery.

In classic hacker culture, you aren’t a hacker until other recognized hackers call you a hacker. It’s a title to be earned, not claimed. The unfortunate title of “scrum master” aside, it is useful to take this credentialing tradition to heart with scrum as well. Consider yourself an apprentice scrum practitioner until other recognized scrum masters recognize your mastery. Holding such a frame keeps us humble, curious, and open to constant and never ending improvement.

I’ve been practicing, leading, or coaching scrum in one capacity or another for over 10 years and based on my billable hours over the past several years, I’m quite confident I’ve passed the 10,000 hour mark for practicing scrum. Even so, I’m not a master scrum master…yet. The reason is simple and is expressed by the great cellist Pablo Casals’ response to filmmaker Robert Snyder’s query as to why Casals continues to practice five hours a day at 80 years of age, “Because I think I am making progress.” I keep building upon my practice because each day I discover new ways to enhance team performance and improve my skills. Perhaps more telling, any time I think I’ve heard every excuse for not following the scrum framework, someone on one of my teams surprises me.

If you’re interested in staying on the path toward scrum mastery, you need to get out of the books and into the world. There are a variety of ready opportunities to mark and gauge your progress.

• Frequently review the framework for scrum and compare what’s there with your current projects. If there are mismatches, find out why. Is there really a good reason for straying from the framework? If so, open a dialog about these differences during your retrospectives.
• If possible, ask your fellow agile practitioners when they are holding their next review, backlog refinement, or sprint planning session and get yourself invited as an observer.
• There are probably a number of excellent agile related meet-ups in your area. Speaking from personal experience, these are incredibly valuable communities of support and new ideas.

References

Greene, R. (2012). Mastery. New York, NY: Viking Penguin

This article was originally published by the Scrum Alliance under Member Articles.

Recently I had the opportunity to attend the Mile High Agile 2015 conference in Denver where Mike Cohn delivered the morning keynote address: “Let Go of Knowing: How Holding onto Views May Be Holding You Back.” As you might expect from a seasoned professional, it was an excellent presentation and very well received. A collection of 250+ scrum masters, product owners, and agile coaches is no stranger to mistakes, failures, and terrifying moments of doubt.

As valuable as the ideas in Cohn’s presentation are, I want to take them further. Not further into the value of keeping our sense of sureness somewhat relaxed, rather onto some thoughts about what’s next. After we’ve reached a place of acknowledging we don’t know something and are less sure then we were just a moment before, where do we go from there? It’s an important question, because if you don’t have an answer, you’re open to trouble.

The “I Don’t Know” Vacuum

Humans are wired to find meaning in almost every pattern they experience. The cognitive vacuum created by doubt and uncertainty is so strong it will cause seemingly rational people to grasp at the most untenable of straws. It’s a difficult path, but developing the skill for being comfortable with moments of doubt and uncertainty can lead to new insights and deeper understanding if we give our brains a little time to search and explore. Hanging out in a space of doubt and uncertainty may be fine for a little while, but it isn’t a wise place to build a home.

After acknowledging we don’t know something or that we’ve  been wrong in our thinking, it’s important to make sure the question “What’s next?” doesn’t go begging. I’d wager we’ve all had the dubious pleasure of discovering what we don’t know in full view of others and in those situations the answer to this question becomes critical. It may not need an immediate answer, but it does need an answer. If you don’t work to fill the vacuum left by “I don’t know” or “I was wrong,” someone else surely will and it may not move the conversation in the direction you intended.

The phenomenon works like this. Bob, a capable scrum master, ends up in a situation that reveals a lack of experience or understanding with the scrum framework and doesn’t know what to do. Alice, maybe immediately or maybe later, moves into the ambiguity, assumes control, and tells the team what should be done. If Alice is wise in the ways of agile, this could end well. If command-and-control is her modus operandi in the defence of silos and waterfall, it probably won’t.

So how can an agile practitioner prepare themselves to respond effectively in situations of doubt and uncertainty? Here are a few things that have worked for me.

Feynman-ize the Conversation

In his book “Surely You’re Joking , Mr. Feynman!,” Nobel physicist Richard Feynman tells a story from his early career where several building engineers started reviewing blueprints with him, thinking he knew how to read them. He didn’t. Having been surprised by being placed in a position of assumed expertise, Feynman improvised by pointing at a mysterious but ubiquitous symbol on the blueprint and asking, “What if that sticks?” The engineers studied the blueprint in light of Feynman’s question and realized the plans had a critical flaw in a system of safety valves.

That’s how to Feynman-ize a conversation. Start asking questions about things you don’t understand in a manner that challenges those around you to seek the answer you need. In essence, it expands the sphere of doubt and uncertainty to include others in the situation. This tactic is particularly effective in situations where corporate politics are strong. Bringing the whole team into the uncertainty space helps neutralize unhelpful behaviors and increase the probability the best answer for the moment will be found. It is no longer just you who doesn’t know. It’s us that that don’t know. That’s a bigger vacuum in search of an answer. In short order, it’s likely one will be pulled in.

The Solution Menu

Thinking of the agile practitioners in my professional circle, they are all adept at generating possibilities and searching their experience reservoir for answers based on similar circumstances. When the creative juices or flow of answers from the past are somewhat parched by the current challenge, it is natural to project the appearance of not knowing. Unless you’ve drawn a complete blank, you can still use the less-than-ideal options that came to mind.

“I can think of several possible solutions,” you might say. “But I’m not yet sure how they can be adapted to this challenge.” Then offer your short list of items for consideration. One of those menu choices might be the spark that inspires a team members to think of a better idea. Someone else may find an innovative combination of menu choices that gets to the heart of the issue. I’ve even had someone mishear one of my menu choices such that what they thought they heard turned out to be the more viable solution. This is just another way to leverage the power of everyone’s innate drive for finding meaning.

Design an Experiment

If there is a glove that fits the “I don’t know” hand, it’s experimentation. I suppose you could work to stretch the guessing glove over “I don’t know.” But if your team is aware that you don’t know something, it’s worse if they know you’re pretending that you do. Challenges and problems are the situation’s way of asking you questions. If the answers aren’t apparent, form a solution hypothesis, set up a simple test, and evaluate the results. And as the shampoo bottle says: lather, rinse, repeat until the problem is washed away. It’s another way to expand the sphere of uncertainty to include the whole team and increase the creative power brought to bear on the problem. If your shampoo bottle is this agile, I’ve every confidence you can be, too.

Now I’m curious. What has helped you move past “I don’t know?”

This article was originally published by the Scrum Alliance under Member Articles.

Adverse surprises during a team driven project are about as welcome as whooping cough at a glassblowers convention. Minimizing the opportunity for surprises comes down to how well expectations are defined at the very beginning and how well they are managed during the course of the project. Unidentified expectations are like landmines in the project path. When they explode, it’s bad and the course of the project WILL change. Product owners can’t elucidate all the expectations a stakeholder may have, but with experience they can define the major ones. With practice and attention, experienced product owners can tease out all but the minor expectations that are often dependant on discovery within the project’s sprints.

Key to this skill is knowing the questions to ask at the beginning. In my experience, stakeholders rarely deliberately hold back their expectations. They just don’t know what they don’t know and it is the product owner’s responsibility to establish clarity around expectations. Intuitively obvious expectations rarely play out as such.

A few questions for stakeholders that I’ve found helpful:

• What business problems do you intend to solve with this project?
• What do you need to see to know the project is progressing?
• What will you see when the project is done?
• What is your availability commitment for the duration of the project?
• How often to you expect to meet to review progress?
• How long do YOU think it will take to complete the project?
• To what extent are your functional groups integrated?
• Describe your process from design to development to implementation?
• Are there other stakeholders we need to know about and include?
• What factors have helped and hurt success with past projects?

This is by no means an exhaustive list of questions. And they may even seem obvious. The answers, however, are almost never obvious.

I also find it effective to challenge stakeholders with scenarios.

• What happens if we discover this project will take two months longer than expected?
• What happens if we discover a desired solution is technically unfeasible?
• How will you support us if we encounter significant delays from client deliverables?

Product owners need to keep pursuing clarity around expectations until they are satisfied they have a good understanding of how the people side of the project will unfold. This will go a long way to helping the development team handle the technical side of the project.

While stakeholders answer these questions, product owners need to pay attention not just the words stakeholders use to answer, but how they answer as well. They need to be scanning for underlying assumptions that drive the answers. These often reflect relevant cultural drivers which can signal significant expectations seemingly unrelated to the project at hand. For example, perhaps the product owner has established the expectation of a three business day turnaround for feedback from the stakeholder when asked to review periodic project deliverables. “We can complete our reviews within three business days and work to get them to you as fast as possible,” says the stakeholder somewhat hesitantly as he looks off into the distance. Where the pain begins is when the inattentive product owner discovers that, while the feedback may be ready, the client organization has a thick layer of compliance and the feedback is hung up in legal for an additional one to two weeks…every time. If the stakeholder’s responses reflect something less than 100% commitment, keep asking questions designed to surface underlying assumptions.

As each sprint concludes, and eventually the project as well, the savvy product owner knows their work with expectations isn’t complete. Retrospectives for each sprint, each release, and the project conclusion should make note of the expectations that were missed and consider questions that could have been asked that would have helped surface the surprise expectations sooner.

This is also an excellent time to consider if any of the existing expectations have changed or if it appears there may be new expectations emerging. Internal forces, such as changes in team composition, and external forces, such as shifting market demands, can significantly impact the set of expectations a product owner is tasked with managing.

If  you expected to read these kinds of things about surfacing stakeholder expectations, then you’re probably an experienced product owner.

More than 10 years ago I switched from using Quicken for managing personal finances to using an accounting application I developed for the task. I posted my rationale for doing so at the time and see not much has changed in the commercial landscape since then to change my thinking. Intuit is still diligently upsetting customers. Although my needs, demands, and interests have changed. I no longer have time to maintain the code I wrote and a year or two back my accounting needs changed. So I switched from the custom coded solution to GnuCash.

For the most part, I’m quite pleased with the capabilities of GnuCash. Best of all, it’s open source. So I have full access to the code and, more importantly, the data. Where it is weak is in reporting capabilities. I find it rather frustrating to get to the view I want. True to the spirit of open source, users can create their own custom reports. Accomplishing this requires the user to be familiar with the Scheme programming language. When I was younger, this would have been a minor inconvenience. However, graybeard that I am amongst software developers, I’ve learned and forgotten more programming languages than I care to recall. Adding another bone to that yard is less than attractive.

So I turned to my go-to language since version 1.5.2: Python. Even after crafting all manner of solutions in Python over the past 15+ years, it still amazes me what I can do with it. My problems with GnuCash were no exception. Since my data isn’t locked up in some proprietary format, it was a simple enough task to craft a couple of SQL commands that would extract the data I need and wrap them inside an efficient Python script. Simply by setting a date range in a configuration file, I get the (so far) three reports I need in 2-3 seconds.

For those interested, I’m including the current incarnation of the code below. The data captured in the three csv files are:

• A raw dump of the data, suitable for working within a spreadsheet
• A subtotal report that includes line item details
• A subtotal report without line item details

Configuration File

Python Script

Improvements and enhancements are left as an exercise for the reader.

In a previous post, I described several of the shortcomings with planning poker, particularly when the tool is used in a context that includes more than just the developer’s shop. Estimating levels of effort for a set of tasks by a close knit group of individuals well qualified to complete those tasks can efficiently and reliable be cast with a tool like planning poker. Once the set of tasks starts to include items that fall outside the expertise of the group, or the group begins to include cross functional team mates, or both, the method becomes increasingly less reliable.

The issue is a mismatch between relative scales when the team includes an increasingly diverse set of project specialties. A content editor is likely to have very little insight into the effort required to modify a production database schema and therefore offer an effort estimation that is little more than a guess based on what they think it “should” be. Similarly for a coder faced with estimating the effort needed to translate 5,000 words of text from English to Latvian. The answer is to add a second dimension to the estimation: a weight factor to the estimator’s level of expertise relative to the nature of the card being considered.

A similar effect is in play when organizing teams according to Agile principles. When implementing Agile methodologies at the organizational level it is important to consider the impact of forming teams of generalists versus specialists. According to Scrum, for example, it is preferable to have a good measure of skill overlap – that is, generalized skills that allow for any one team mate to work on a variety of tasks during a sprint. This is very efficient for highly technical and coherent domains. Differences in preferred coding language among team mates is less an issue when all team mates understand advanced coding practices and the underlying architecture for the solution. In this case, it is easier to measure sprint velocity when a set of complimentary technical skills allow for cross functional participation and re-balancing when needed (vacations, illness, uncommon feature requests, etc.) As with planning poker,however, efficiency degrades as domain expertise on the team becomes more incoherent.

In cases where the knowledge and solution domains have a great deal of overlap, generalization allows for a lot of high quality collaboration. However, when an Agile team is formed to address larger organizational problems, specialization rather than generalization has a greater influence on team velocity. The risk is that with very little overlap specialized team expertise can result in either shallow solutions or wasteful speculation – waste that isn’t discovered until much later. Moreover, re-balancing the team becomes problematic and most often results in delays and missed commitments due to the limited ability for cross functional participation among team mates.

The challenge, then, for cases where knowledge and solution domains have minimal overlap is to find a way to manage the specialized expertise domains in a way that is useful (reliable, predictable, actionable). Success becomes increasingly dependent on how good an organization is at estimating levels of effort when the team is composed of specialists. The answer is to add a second dimension to the estimation: a weight factor to the estimator’s level of expertise relative to the nature of the card being considered.

With a weighted expertise factor calibrated to the problem and solution contexts a more reliable velocity emerges over time. With this enhanced velocity reliability comes an increased reliability in level of effort estimates, greater accuracy in resource planning, and less waste.

[In the fall of 2013, I completed a course on Coursera titled “Creativity, Innovation, and Change” presented by Drs. Jack V. Matson, Kathryn W. Jablokow, and Darrell Velegol at Pennsylvania State University. It was an excellent class. At the end, they invited the class (How many tens of thousands of us?) to submit short essays about our experence. The plan was to select the best of these essays and roll them into a free Kindle book. Today, they sent out this update:

We are sorry to inform you that we have decided not to proceed with the publication of a CIC eBook. The submissions were read and commented on by four reviewers.  The consensus was that the manuscripts for the most part would take efforts far beyond our capabilities and means to edit and upgrade to meet the standards for publishing.  We are very sorry that the plan did not work out.

What follows is slightly edited version of the essay I submitted for consideration.]

Creativity Under Pressure – When necessity drives innovation.

Background

When you hear someone speak of an individual they know as being creative, what images come to mind? Often, they spring from stereotypes and assumptions about such an individual being an artist of some sort. Someone unconstrained by time or attachment to career, family, or a mortgage. My personal favorite is the image of a haggard individual wearing a beret, a thin cigarette balanced on their lower lip, and busy being inspired by things us mortals cannot see. A foreign accent adds the final touch to firmly set the speaker’s creative individual in the “That’s not me.” category. Our preconceived notions and assumptions assure us we are not creative.

The truth is all of us are creative. The artist’s Muses are not the only source of inspiration. Chance can inspire creative ideas by the convergence of seemingly unrelated circumstances and events. An activity as passive as sleep can lead to creative ideas. Moving away from beauty toward the other end of the inspiration spectrum, the source may not necessarily be pleasant. Frustration and irritation may inspire us to find a creative solution as we spend an inordinate amount of time searching for a way to scratch a just-out-of-reach itch. Crisis, too, can be a source of inspiration, often of the very intense variety. Chance surrounds all of us. We all sleep. And alas, we are all subject to frustrating or crisis situations from time to time in our lives. We are immersed in opportunities for creative inspiration.

Perhaps the least obvious or explored opportunities for applying creativity and experimenting with innovative ideas happen when we are under pressure to perform. At first glance, the tendency is to think that such situations require extensive knowledge, abundant prior practice, and scenario rehearsals in order to navigate them successfully. It’s fair to say that the chances for successfully responding to a crisis situation are greatly enhanced by deep knowledge and experience related to the situation.

The Apollo 13 mission to the Moon is a familiar example of crisis driven creativity by a team of experts. Survival of the astronauts following the explosion of an oxygen canister depended on NASA engineers finding a way to literally fit a square object into a round hole. The toxic build-up of CO2 could only be prevented by finding a way to fit a cube shaped CO2 filter into a cylinder shaped socket using nothing but the materials the astronauts had with them. Of course we know from history the team of engineers succeeded in this exercise of creative improvisation.

Individual experts have also succeeded in devising creative solutions in crisis situations, and in doing so introduced critical changes in protocols and procedures that have saved lives. For example, smokejumber Wagner Dodge’s actions in the Mann Gulch forest fire on August 5, 1949, introduced the practice of setting escape fires as a way to protect firefighters caught in “blow-ups.”

What I’ve always found interesting about these and similar examples is that, although the creative and innovative solutions were found while “on the job” and using established expertise, the solutions were counter to what the individuals and teams were expected to do. The NASA engineers were paid to design and build an extremely high tech solution for sending three men to the moon and bringing them safely back to Earth. Their job descriptions likely didn’t call for the ability to “build a fully functional CO2 scrubber from a pile of junk.” Wagner Dodge was expected put out fires, not start them.

The Course

What else is important in preparing us to respond creatively in high pressure situations? It’s a question that’s dogged me for years. The “Creativity, Innovation, and Change” (CIC) course offered by Pennsylvania State University and taught by Professors Jack Matson, Kathryn Jablokow, and Darrell Velegol offered an opportunity to explore this question.

The first insight from the course was the importance of the “adjacent possible” to creative and innovative problem solving, even in crisis situations. The phrase was originally suggested by the theoretical biologist Stuart Kauffman to describe evolutionary complexity. The idea is that innovative or creative ideas occur incrementally. While they may appear as substantial leaps forward, they are in fact derived from a collection of adjacent ideas that coalesced to make a single idea possible. As an individual explores deeper and farther into an idea space, they extend the boundaries around which adjacent ideas collect, increasing the potential for new idea combinations. In other words, increasing the likelihood of creative or innovative ideas.

In the case of Apollo 13, the deep experience and knowledge of the engineers allowed them to consider a wide spectrum of possibilities for combining an extremely limited number of objects in a way that could remove CO2 from a spacecraft. In the case of Wagner Dodge, his extensive experience with fighting forest fires allowed him to spontaneously combine a variety of “adjacent possibilities” in a way that lead to the idea of lighting an escape fire.

That’s the theory, anyway. There’s a difference, though, between theory and practice. Albert Einstein explains, “In theory they are the same. In practice, they are not.” The CIC course offered an abundance of techniques and methods that facilitated the transfer of learning and strengthened the connection between theory and practice. In particular, there were two important reframes that opened the door to deliberately improving how I approach creativity and innovation in stressful situations:
“Successful” failures are those that are strategic. That is, not random guesses about what will work, but deliberate experiments designed to succeed. Yet if they fail, the design of the experiments also reveal weaknesses that are preventing the eventual success. Unconsciously, I had already become reasonably good a doing this. But there was significant room for improvement. Using many of the methods and techniques offered during the CIC course, I deliberately unpacked my unconscious competence in this area, consciously explored how I could practice becoming even more competent with this skill, and am now exploring ways to integrate the new capabilities back into unconscious competence.

“Failure” is a necessary, even desired process for finding success. This ran counter to my get-it-right perfectionist approach to success. Likely the result of having to work in too many crisis situations where failure was not an option, it was nonetheless a poor strategy for finding success in day-to-day business. In concert with point number one, these failures should be strategic.
Each of these insights are encapsulated in the “Intelligent Fast Failure” (IFF) principle presented in the CIC course and further described in Prof. Matson’s book, “Innovate or Die!”:

The “Intelligent” part refers to gaining as much knowledge as possible from each failure. The “Fast” part means speeding up the trials to quickly map the unknown thereby minimizing frustration and resources spent.

The “fast” part also increases the pool of “adjacent possibilities” and raises the potential for successful innovations to emerge from the process.

The Test

Has all this experimentation and thought practice made a difference in my ability to respond more creatively in stressful situations? A full-on test in crisis mode hasn’t happened as yet. And frankly, I’d count my self fortunate if I never had to face such a test again. But there are indications the changes are having a positive effect.

These days, work typically offers the most abundant opportunities for stressful situations. Most recently, I was tasked with coordinating a significant change in how an organization went about the process of completing projects. The prevailing process had deep roots in the company’s culture and was incapable of scaling to meet growth goals for the organization. With so much personal investment into the old way of doing things, implementing a more agile and scalable process was going to require as much mediation and negotiation as it was process definition and skill development.
Using the techniques and methods that support the IFF principle, I have been successfully implementing a wide range of new ideas and process improvements into the organization in a way that makes them appear less as a threat and more as a value to each of the stakeholders.

The staffing firm OfficeTeam has an interesting infographic showing how often people go into work when they’re ill. It’s not stated, but implied that “go into work” means “go into the office to work.” My subjective experience matches what the small OfficeTeam study revealed. Far too many people come into the office to work when, in the interests of the health of their co-workers, it would be better they stayed home.

I’ve heard many excuses for why people do this. “It’s just a head cold.”, “I’m past the contagious phase.”, “There’s too much important work to get done this week.”, “I don’t want to get behind any further than I already am.” The list is endless. When my career advanced to the point I needed to manage people, I learned more of what was motivating some of these excuses. They included things like home life was so miserable that the employee would rather come into the office sick than stay at home. There was also a perverse incentive in play at work environments that allotted employees a bulk quantity of paid time off for use as vacation and sick time. Want a longer vacation? Work sick rather than take a “vacation” day to recoup and prevent the spread illnesses to co-workers. As a manager, I frequently used my authority to send people home when they came in sick.

Viewed from another perspective, the OfficeTeam study reveals an often unstated value to telecommuting. When one at least has the option to work remotely and their productivity is not compromised by that option, they can organize their work around such things as seasonal illness much more effectively and prevent the spread of illness to co-workers. Personally, I took paid time off for sick days. I found it much easier to “catch up” when I felt better than try to remain productive when sick. In fact, the work that was done while ill was usually of poor quality and needed to be reworked later. However, when feeling ill while working remote, I would put in a day or two of light work and make up the slack later when I felt better, even if that make-up time was on the weekend.

In this type of scenario and given the long view, productivity is likely to be consistent and of high quality. Furthermore, containing the illness and preventing the spread to other members of the work team helps maintain organizational productivity. A topic for another day is: How do you measure productivity in a remote work force so that it can be evaluated for consistency, quality, and other such metrics?

Big Data Edition

Those on the Big Data Bandwagon say you can never have too much data. But if you do have too much to manage and are overloaded, you can always jump off the wagon and push.