I have been following Clarke Ching's efforts to write Rolling Rocks Downhill over the years, including reading one or two early versions. But somehow the final published version felt very different from the earlier versions. One thing that hasn't changed - I could hear him in the voice of the main character I read the book to myself. I've noticed the same thing when I've read other books by people I know in real life.
In some sense, the book is a classic business novel in the Theory of Constraints vein: the main character (Steve) has a major problem: the software project that he thought had nine months gets pushed to finish in six and then even faster due to market pressures. The situation seems hopeless, but then he begrudgingly asks for help from a "guru" (on an ultimatum from his boss). In this case, though, the guru isn't positive that he can solve the immediate problem - though he does think he can help Steve in general. The guru leaves Steve alone for long stretches with various things to ponder - come to think of it, this isn't too far from "Jonah" in The Goal. One thing that was interesting about this guru is that he often didn't have the answer - not that he didn't want to say, it seemed he truly didn't know (and was willing to admit it!).
The story develops, and Steve learns a lot. The guru introduces some TOC and Lean concepts, and some of Steve's business partners introduce some new ways of thinking as well. He learns about the constraint and why it is important to identify it. He learns that forecasts are always wrong and spending too much time refining them is often time wasted. He learns ideas about smaller and smaller batches to create speed.
In the end, the team pulls off amazing feats and pulls the company from the brink of irrelevance. One of the biggest things they do is break a huge conflict that sat at the bottom of their reality: take actions for the short term or take actions for the long term. Do it fast or do it right, and they couldn't see a way to do both.
While the story is about the struggles of the development team and the larger business, one of the biggest take-aways for me is the way Clarke describes the Evaporating Cloud (or Conflict Diagram), which is a classic of the Theory of Constraints thinking processes. He also combined it with some thinking from Kelvyn Youngman that brings in the 4 views of change. Clarke has this available on his website as well.
Classically, the Evaporating Cloud is a diagram to help articulate the logic behind conflicts that occur. One describes an overall goal (A) and two needs of the system (B and C). Each of the needs generates and action (D and D'). The two actions are where the conflict resides. One reads it: In order to meet the goal, we must meet needs B and C. In order to satisfy B, we believe we must do D. In order to satisfy C, we believe we must do D'. And D and D' cannot exist at the same time. Just as important, taking action D puts need C in danger, and doing D' puts B in danger. We are in a conflict. Often organizations will find themselves swinging between actions as one need or the other becomes predominant. But both needs are important - but we compromise to get less that full amount of each need. A central tenet behind TOC is that all conflicts (of this type) can be removed - "evaporated." The key behind these diagrams is what connects the lines - the process of building the diagram helps to expose the assumptions underlying the "we believe". Why must we do D? or D'? What makes them conflict? As you (and the team) think through this - talking it out often helps - the reasoning behind why one action or the other comes into play. Could there be different actions we could take that allow us to meet both needs?
Conflicts are sometimes articulated with statements like, "On the one hand ..., but on the other hand ...." What Clarke has done in the book (through the guru) is to take this kind of statement and make the conflict cloud more physical. Turning the cloud, so that "A" is on the top, he draws a stick figure with D and D' in each hand. B and C on the shoulders - representing the "weight" of each need. And then the common goal is the head. He even take the idea of actions jeopardizing the opposite need: poke yourself in the opposite shoulder with your index finger. I really liked how this description of the conflict diagram has a physical feel to it - much more visceral than the dry cloud on a white board or a piece of paper.
The other thing he brings to the cloud is from Kelvyn Youngman. The cloud can be mapped to the four views of change: the benefits and hazards of a change, and the benefits and hazards of not changing. (This is best illustrated in the entertaining video on "resistance to change".) In Clarke's setup, below each hand you add the pro's and con's of the action. Understanding these pro's and con's helps to articulate the needs. And it helps to draw out the assumptions underneath the arrows in the conflict diagram. This is all described much better in chapters 13 and 14 - go read it there.
In the story, Steve and the guru develop the conflict diagram for Steve's software project. But then later on, there are a couple other conflicts that don't get their own diagram. What Clarke does though is describe Steve weighing the conflict in his hands and wriggling his shoulders as he thinks through the needs. There was even the line, "My shoulders ached from the weights I carried with me that day." This language, for me, makes the conflict feel much more visceral. (I've heard that TOC for Education encourages children to draw the conflict on the playground and stand in the boxes to discuss interpersonal conflicts.)
Another classic "problem" in software or any knowledge-work environment is Parkinson's Law: usually formulated as "the work expands to fill the time allotted." Clarke took another direction with this one in the software development world, "The scope of the project always expands until it's too big to fit in the time available to deliver it." When development happens in big batches, people throw more and more into the project until it bursts. He gives some great examples of this as he discusses the problem with a colleague (in Chapter 11). They also suggest the opposite: if you cut the scope to make the delivery date more reasonable, people might relax or slow down. This is the Student Syndrome: I don't need to worry because I have plenty of time. (Note: People aren't bad, this is a natural reaction to the environment we are in. And the extent of either of these varies by person / company / group.)
One final item: I've known for a while that Clarke has a sense of humor. It's in the writing - the little things like the coffee jokes or the expensive-looking pen that the guru carries. Or the fact that the book website is Clarke Ching www.Rolls.Rocks. And his humor shows up in the sub-titles of the book. On the Amazon page for the book, the subtitle comes up as "How to Ship YOUR Software Projects On Time, Every Time." But on the cover of the paperback it says "The Agile Business Novel." And the Kindle on Amazon, the cover says "The Agile Business Novel (which never mentions Agile)". But then on my Kindle device, it says "Accelerate AGILE using Goldratt's TOC." And in the book itself, the subtitle shows up as, "Read this when your AGILE implementation sucks."
Here is a quote for the day:
A schedule defends from chaos and whim. It is a net for catching days. It is a scaffolding on which a worker can stand and labor with both hands at sections of time. - Annie Dillard in The Writing Life from 2009
Heard on a the Manager Tools podcast* recently
One-time events create change like dieting only on your birthday and expecting to lose weight.
I love this statement, whether it has to do with the performance review process, or just about anything else.
When we think of a change, the outward sign is that behavior or some other measurable signal has changed. Attending a training course - or dieting for one day - will not create a lasting change. The event must be followed by a regular course of action, coaching, check-ins, ... whatever is appropriate for the type of change desired.
* I am fairly certain I heard it on Manager Tools. The quote appears in a section of a book that discusses performance reviews. And this suggests that I probably heard this on the Manager Tools podcast on performance reviews from the beginning of the year.
I have known Kevin Fox for over fifteen years. I first learned Theory of Constraints through him in a couple Critical Chain implementations and later worked on a manufacturing (drum-buffer-rope) project with his company. He has a new book out this past fall, Aligned & Engaged: Hidden Keys for Turning Teamwork into Profit.*
Overall the book is split into two sections that cover the dimensions of Alignment and Engagement. And the bulk of the book is set up as a set of 29 "practices" around teamwork, each of which are linked to four key topics: Creating Time, Doing the Right Things, Doing Things Right, and Magnifying Impact. The practices are written for leaders, not the teams - leaders have responsibility to create the right environment that enables the company to achieve more and more of its goal.
Many of the practices Kevin describes are ideas and elements I am familiar with in my own consulting practice, but I haven't always thought of them in the ways he describes. And many of the concepts come right out of Theory of Constraints, though it is nice to see that he talks about the ideas in ways that do not require deep TOC knowledge.
The introduction sets the stage. Companies are made of people, and those people have to work together well for the company to work well. Just like an athletic team. But it is not teamwork itself that a company should strive for - it is results. Ineffective teamwork is strongly connected to poor performance, but the classic "teamwork" solutions to the problem like retreats or team-building activities don't address the core problems. Ineffective teamwork is a symptom of deeper problems in the organization - it won't be solved by going on a retreat.
How do you recognize a problem with Alignment or Engagement? Chapter three provides a nice discussion of the likely effects. Alignment issues will appear in things like strong (internal) silos; problems that show up late; internal measures look good even though company performance is poor; local improvement efforts don't impact the bottom line; end-of-the-month syndrome is strong; and mismatches between supply and demand. And issues with engagement appear as things like low employee participation; few new ideas generated; a lot of time spent explaining problems, rather than solving them; blaming; and people keep regular hours. This last one struck me as odd, but Kevin's explanation strikes a chord: it's not that we should demand long hours of people, but we should expect people will do what it takes to get things done, which might mean starting early or staying late from time to time.
The 29 practices that make up the bulk of the book are those practices that link to the bottom line. Some practices help create more time for the leader or the team to focus on the right things - they might even help the teams discover the right things to do. That gives you better effectiveness. There are also that help up in doing these things well - once you know what to do, how do you do that better (efficiency). Interesting that "not doing the wrong things" isn't mentioned explicitly, but it goes without saying that clear goals and clear ways to achieve those goals will have people doing much less of the wrong thing too.
While the book doesn't explicitly claim to be a Theory of Constraints book, many of the practices have elements borrowed from TOC ideas and practices. So, for me many of the deeper explanations behind the practices weren't necessary for me. The language is intentionally removed from the details of TOC, so that anyone could pick up the book and make use of one, two or all 29 of the practices.
The list of practices with my quick comments in italics
- Communicate the goal - If people don't know the goal, how can there be alignment?
- Share company results with everyone
- Replace local measures with global ones - This one is obvious and not-so-obvious. What does it mean from day to day for people? Most people shouldn't be busy all the time in order to have protective capacity to deal with variability, uncertainty, surprises. Local measures drive busy-ness, rather than effectiveness. "Accountability is overrated if what you are holding people accountable for doesn't help your company reach its goal."
- Find the constraint of your business
- Blue light your business - I've used versions of the blue light story many times. "Putting people in charge of somethings is not the same as having them care."
- Use T, I and OE to align decisions to the goal - This comes from TOC and is a much better way to use financial information to help make decisions.
- Routinely review and re-align your measures
- Map what good alignment looks like - Another idea i've used many times: What does good look like for you, for your business, for the team?
- Spend most of your time and energy on today
- Use Pareto to stop wasting efforts
- Stop the multi-tasking - Nothing more to say here!
- Relate everything back to the big picture
- Focus on throughput - Very specifically, focus on those activities that will generate more money through sales. Not more production. More sales (and profits from them - big discounts to ship more product doesn't get you more profits).
- Use measures to provide fast feedback on ideas
- Picture what engagement looks like - More what good looks like thinking.
- Innovate on process - If you ask people for suggestions, ask them to focus on the areas that are creating the largest problems in your business.
- Use images to show 'what good looks like' - The third entry on this topic. What good looks like is a strong way to help people think about how things could/should work.
- Reward the good more than you punish the bad
- Share your ideas last - Leaders influence people by everything they say and do. Let people have their say first, before injecting your own ideas.
- Provide opportunities for growth
- Don't kill ideas, use questions - Ask questions about any suggestion: What problem are you trying to solve? Is the problem worth solving? Will the solution (idea) solve the problem? Will the idea create unintended consequences?
* Review based on a complimentary galley copy when the title was Teamwork for Profit. Some of the specific practice names and titles may have changed in the final book, but the overall concept remains.
I read a pair of Gary Klein books that look at decision making and intuition, which seems to be the core of his work. I started with The Power of Intuition: How to Use Your Gut Feelings to Make Better Decisions at Work (from 2004). And then I backed up to his Sources of Power: How People Make Decisions (from 1999), which describes more of the background research.
The basic idea is that human decision making is governed by a lot of processes from the snap decisions people make in emergencies to longer, considered decisions. Klein's argument is that people rely on "intuition" a lot more than we might acknowledge. These intuitions are based primarily on past experiences as well as some amount of knowledge. His concern, at least in The Power of Intuition, is that many decision-making frameworks rely almost exclusively on using logic and analysis to define the process. And in certain situations, the decisions are not governed by the analysis. One might be able to review the situation and devise a logical explanation as to why and how a decision was made. The conversation in the books is that in the moment of decision, people don't rely on analysis but on their intuition.
He developed a term for this: recognition primed decision making (RPD). Source of Power describes how this model of decision making arises in situations where there is no time to do analysis, such as firefighting or medical emergencies. Power of Intuition then takes this and develops a model around helping people develop their own intuitions better.
And how to develop this expertise? Not by sitting people in a classroom and teaching to them. It's always a challenge because there is some aspect of "knowledge development" that people (me!) believe is best done through a stand-and-deliver style. But getting quickly beyond the basic knowledge and embedding that into people's psyche must allow for real-work application and practice in situations where it matters.
Klein makes an important clarification here. It's not sufficient to throw people into an experience with their new knowledge and expect intuitions to develop. The whole point of intuition is that it has to be fast and primed by recognizing the right queues. When a concept is new, we don't know what queues to look for, even if we have been "told" what to do. The experience has to be reviewed - debriefed - with a specific eye to the key points where a queue was helpful in successes (or missed in failures). There has to be a deliberate intent behind the practice. Maybe this isn't such a surprise with our current understanding of multiple modes of learning and the Agyris concept of double-loop learning. Of course, I still hear plenty of assumptions that training gives people enough knowledge, experience, insight, and drive to change the way they operate.
Klein presents a number of methods for developing intuition, whether through the above practice or by the every day life of business. Take action, review it. Plan an action, do pre-mortems. Clarify the goals. Every day, there are "opportunities" to develop better and better intuitions.
As an example of this in the TOC community, Eli Schragenheim introduced the idea of a mystery analysis at the TOC ICO conference in 2013. When reality differs from expectations, there must have been some underlying assumption or belief that wasn't what we expected. What was the logic behind the actions we took and the expectations? What happened instead? What else must have been happening that we didn't expect? This is a reasonable way to do an after-action when something bad happens, but it should be used equally well when something "good" happens - when an effort works out much better than expected.
Of course, as I read, I highlight quotes and other interesting ideas. These books seem to be loaded with more than usual. Or I was particularly heavy with the highlighter. Here are some of those.
From The Power of Intuition (no page numbers, as I was reading an ebook...)
- "The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honors the servant and has forgotten the gift." - Nice way to say that intuition has been given a bad rap. Klein also references Herbert Simon's concept of "bounded rationality" that suggests for more complex decisions, the level of complication is such that "rational" approaches to decision making are less and less useful.
- There is a nice discussion about how intuition becomes so innate that we forget how we thought before we had the intuition. We forget how hard it was to get a concept, once we know it. (Unless you have children who are trying to learn similar things.)
- Ways to tap into intuition: "you aren't restricted to asking people what decision they would make. You can ask them what information they would gather, or what questions they would have, or how they would assess the situation. You can ask them what problems they might anticipate, or what they would expect to happen in the future. You can ask them what guidance they would offer. These are all ways people use their intuitions. "
- I love the idea of a pre-mortem: asking questions about what might cause an activity to fail or go awry. Basically an after-action-review in reverse. Imagine the effort has failed, what might have caused that to happen? Again, this taps into intuition, and it can make your plans even better.
- "The five sources of uncertainty are missing information, unreliable information, conflicting information, noisy information, and confusing information. Just because they are all called by the same term, 'uncertainty,' we should not treat them as equivalent." And there is some discussion for tolerance of ambiguity that is important in decision making as well. We can't allow ourselves to be paralyzed by lack of information, but we need to develop the intuitions to know when we have sufficient information to move.
- Maybe we should be careful about being too specific in our instructions to people. We need to allow them to develop their intuitions as well. "If you just tell subordinates what you want them to do, without telling them why you need it done, you have kept things simple, but you have also made your plan more vulnerable."
And some from Sources of Power:
- Another version of the fog of war from the first page: We try to understand how people handle all of the typical confusions and pressures of their environments, such as missing information, time constraints, vague goals, and changing conditions.
- Falling in love with our ideas? "We can ask what evidence you would need to give up your explanation. Sadly, the answer is that if you are determined enough, you might never give it up." I think of Occam's Razor in reading this section - at some point the justifications just become too much, and we have to break our love for our ideas.
- There was an interesting discussion of problem solving that made me think of the value of Agile development ideas. "[Researcher Karl] Duncker found that as his subjects worked on these problems, they simultaneously changed their understanding of the goal and assessed solutions. A subject might think of a solution, try it out, realize it would not work, realize what was missing, and then add to the definition of the goal. This new definition would suggest new approaches, and when these approaches failed, they helped to clarify the goal even further." This seems almost a perfect example of Agile - and the research was reported in 1935 and 1945.
- Klein formalized the idea of commanders intent in terms of the information one might provide" "There are seven types of information that a person could present to help the people receiving the request to understand what to do:
- The purpose of the task (the higher-level goals).
- The objective of the task (an image of the desired outcome).
- The sequence of steps in the plan.
- The rationale for the plan.
- The key decisions that may have to be made.
- Antigoals (unwanted outcomes). [I particularly like the discussion around this one for some reason.]
- Constraints and other considerations."
The (Australian) Financial Review has a list of 12 things that kill innovation in your organization. For people that pay attention to this space, the entries should sound familiar. (Discovered via retweet on Twitter.)
- A culture of fear
- Lack of meaningful mission and vision
- Too much hierarchy
- Old-School HR practices
- The blame game
- Overly prescriptive job design
- Lone wolf thinking
- Low autonomy
Reading through this list and the brief description of each, one can see some familiar conflicts, in particular the effects that happen when organizations swing between strong vs loose structure. And Blame and Fear are two big killers of just about any kind of organizational initiatives. They have very little place in organizations which are trying to understand how they tick and how to respond to the pressures they are under.
Two that made me wonder there the "old-school HR practices" and "filtering". For HR the list suggests that "new school" is more flexible and diverse in hiring and promotion decisions than in the past. I suspect there is more under the surface of that one. The "filtering" entry is about filtering and limiting the flow of information. Strongly connected to Silos - and to fear and blame and micromanagement for that matter.
A quick article with opinions from six people on project killers: 6 Experts Share the #1 Thing That Derails a Project | Smartsheet. Of course, there are six different things listed as "the #1 thing." And there are a few more listed in the comments.
I mention this article because my friend, Johanna Rothman is quoted as suggesting multitasking is the killer, "The silent project killer, and in my experience the thing that kills more projects, is multitasking." Of course, I had to smile, seeing this. I often talk about this in my discussions of project management and Critical Chain Projects - specifically I talk about multitasking killing flow. Too much switching from task to task to task without getting anything done. This means we can't hand something to the next step in the line (without it getting stuck as well).
Please note: Having a queue of work is not multitasking. It's when I am forced to pull things into active mode before I finish what is in front of me.
A couple of the other suggestions in this article in my mind have to do with understanding what the project is. When there isn't alignment or agreement on what we are doing in a project, it almost guarantees that the project will get stuck in swirl and scope creep. Which often leads to even more multitasking as we try to figure out what it is that we are really supposed to be doing.
Lean Learning Center has a nice article on a familiar topic, creating more time for what is important. Click "Like" If You Have Enough Time
Time is the only resource we have that we cannot get more of. Yet time is squandered at an unbelievable rate. Organizations manage money with obvious structure and measures of return on investment. When it comes to time, individuals are left to Darwinian survival mode. Hundreds of emails daily, multiple meetings with unclear return on time spent, and administrative tasks consume high percentages of time. Studies have shown that management spends 10-20% of work time on current priorities, coaching, and identifying improvement opportunities. The remaining time is spent on other stuff.
I find that it isn't only management where this happens. It could be the salespeople meeting with decision makers 5-10% of their time. Or project team members spread across many activities and several projects. If these people could increase the focus - have dedicated time for their most important activities - what would be the benefit to them? What would be the benefit to the organization?
The post goes on to recommend some specific actions around observing how one's time is spent today. Essentially: are people doing that which is most important, or are they doing whatever happens to be in front of them at the moment.
Reflect back to Covey's 4 Quadrants (Urgent + Important; Not Urgent + Important; Urgent + Unimportant; Not Urgent + Unimportant): Clearly, dropping those activities which fall in the "unimportant" quadrants can make a big difference. Most people who talk about this topic also suggest that doing better with focus means that the level of "urgency" also drops - when people have time to focus on the important aspects of their work, many of the urgent activities get handled correctly and with much less fanfare. Time gets created by not wasting it.
One big area I always check: how much multitasking are people doing? How much of the unimportant or the last-minute urgencies get in the way of being able to focus on very few things at one time. How often do people get started (hurry, hurry, this is really important) only to discover that there are incomplete preparations that stall the effort? How much benefit would be gained by giving people mechanisms - and the organization trusting those mechanisms - to enable focus and finish, rather than start-stop-start-stop of multitasking.
The folks at Realization, makers of the CCPM software Concerto, post newsletters and articles on topics related to Critical Chain from time to time. There’s No Such Thing as Good Multitasking one talks about the classic problem of multitasking and somehow people think there is "good" or "bad" multitasking. (I even talk about "bad multitasking", as this comes from older CCPM discussions.)
I love this anecdote:
The chief engineer from one of our clients kept track of every time he interrupted his first-line managers during one day. It got so bad, that by about 2 p.m., when he had already interrupted his managers more than 20 times, he felt too guilty to interrupt them again, and instead collected a list to be discussed in the next morning's meeting.
It is often not enough for individuals to say "no multitasking". They may not control the incoming requests - but their managers? How much control do they exert over this process? In these kinds of implementations, we often find the sources of interruptions and requests coming from exactly the people who want their people to "work smarter, not harder."
So, what to do? Seeing the problem is a big portion of this. The anecdote above had the manager listing all his interruptions. Other teams use CCPM tools to list out their tasks to provide focus - focus on the task with the most buffer consumption for which they have responsibility. Other groups go simple: use white board and sticky-notes to show the work and decide where to focus.
"You can only find things by not looking for them." - Kenneth Stanley
Another interesting link from my friend Luis Suarez. This time the video of Kenneth Stanley talking about his new book, Why Greatness Cannot Be Planned: The Myth of the Objective.
Obviously, the statement at the outset seems counter to much of the thinking in business and in life. The talk and the book suggest that you cannot often get to the goal. And he uses his Artificial Intelligence research project called pic breeder that has inspired the thinking in his book.
He picks out an idea of deception. When the goal is far away from where you are today, there is no obvious way to get there. And there are some paths which seem to be right but lead you astray either through local optima or some other effect. It's the classic line of "You can't get there from here." You have to go somewhere else first - somewhere that doesn't appear to be related.
He talks about the idea that objectives can lead to convergence on something that is not really what we want - that they don't take us to where we really want to go. He pulls into the idea of group dynamics and collaboration. Objectives might lead to compromise, rather than new bright findings.
Rather than heading for big objectives, people / teams who create new things operate at a level of "stepping stones". They find interesting or useful way points - maybe those way points are their creative output. Then they move from those stepping stones to new ones. Or different people take these stepping stones and move in completely different directions. This is staring to sound like the history of discovery - scientific or otherwise. "Fortune favors the prepared mind" (Louis Pasteur). The prepared mind may be familiar with many of those stepping stones and can try something new from there.
"Those with expertise have the ability to identify when things are interesting." - Kenneth Stanley
I have to think, as I listen to the video, that there is a specific type of objective that is being described. Much of the other thinking and reading on the topic of "goal attainment" talks about similar struggles to meet the real goals of a project, business, enterprise. Often the issue has to do with truly understanding what is the goal - what is the intent behind what someone has stated as an objective. "Implement X" might be fine as a statement for a project, but if you don't understand why X is needed, what underlying problem you are trying to solve, maybe X isn't actually going to help you with that. People need to know the intent behind the goals. They also need to know things like why the current proposal is the right path or direction. Where are the restrictions/constraints we must follow? What can we break?
This puts me in mind of the Cynefin concept of complexity: the environment in which you are sitting is such that you cannot control it. Rather than trying to add control (or goals in this case), take small steps and look at the results. Reinforce those things you like to see, and dampen the things you don't like to see.
Cameron Conaway has a familiar-sounding piece on Work Email is Dying. What's Next?. He opens with the familiar / fun story of the creation of email in 1971 - in the early days of the ARPANET. Yes, 1971. Over 40 years ago. [Hat tip to Luis Suarez of Living in a World Without Email for the link.]
And there it is. Good ol’ 1971. The year email began its journey to becoming the world’s premier workplace communication tool.
As it still is. Even as it approaches its 44th birthday this October.
And even as new tools have risen up and made many parts of it obsolete.
Conaway's article has a fun way about it. I love the quotes from various business leaders on what they are doing / trying to get work done.
Sadly, though, the essence is very familiar: We spend too much time in email, and it isn't a terribly effective means of collaboration. And yet, for many people and organizations, it doesn't seem there is any impetus to operate differently.
The recommendation? Give it a whirl - try something more focused on the task at hand. And if it doesn't work, email will always be there, like an old habit that you can't break.
Mike Gilronan, a Boston local knowledge management friend, has a nice piece on collaboration in the Boston Business Journal, Five ways to improve collaboration among remote teams. Mike has worked in the collaboration world for a long time, so these topics are familiar. Mike is currently doing enterprise content management at McGladrey.
As we learned in Boston this past winter, the ability to be productive and collaborate with team members, even if nature or other circumstances prevent us from being in the same place at the same time, is critical to success in modern business. More and more, our workplaces and teams are virtual, with remote workers and teams being asked to connect and collaborate. Teams that do so effectively can build a real competitive advantage by providing access to the best resources, delivering products and services more efficiently, and accelerating the pace of innovation.
His five items are sometimes obvious, and yet do we use them all?
- Hire for it.
- Foster a culture of collaboration.
- Connect securely, from any device, anywhere.
- Invest in tools that work the way your teams do.
- Know when to escalate.
And of course, other people write about this stuff as well, such as my friend Johanna Rothman's thinking on remote Agile teams, where she focuses on trust, flexibility and internal cohesion.