Thinking Faster

Virtually There

I've been working lately with a few Fortune 500 firms that have a highly distributed workforce.  I guess in most cases that's not surprising, but what is interesting is the extent to which people in these firms are working virtually.  In many cases, individuals don't have an office and work primarily from home, or their "home" office is 50 or 100 miles away and they visit that location infrequently if at all.

This makes for some interesting visits.  I have occasionally been in the position of knowing more about an office building - where the restrooms are, where the coffee machine is - than the full time employees who are rarely, if ever, in the building.  But even more interesting is what is happening to how people work when they become virtual.

Working virtually is a blessing and a curse, it seems to me.  There are all the same pressures of the standard 8 to 5 job included in working virtually.  The same amount of work to get done, the same number of meetings, the same distractions.  However, as people work in a more distributed fashion, it becomes an expectation that you are available at almost anytime.  For instance, I'll participate in a call in a few days with a person in the UK and a person on the west coast.  The individual on the west coast will be dialing in at 5:30 am his time, and never gave that consequence a second thought. 

Working virtually also means working with technology - from teleconferencing and Skype to shared workspaces and video conferencing.  All of these technologies provide the means to bring people together, but they also require each of us to take on more support tasks.  There's no one here in my office who is responsible for Skype support, for example.  Additionally, we have at least as much overhead and planning for virtual meetings, if not more so, since it's inevitable that someone shows up late to a virtual meeting and someone must track them down.

This increased emphasis on virtual work means that line between work and "regular life" is not blurred, it's obliterated.  I can now participate in any discussion, meeting or email exchange from any location at any time, thanks to portable handheld BlackBerrys and teleconferencing.  What this means is that more and more people will be called on to participate in work related events in hours or locations that would have been unacceptable a few years ago, and we can expect to see some time shifting - virtual workers doing other things during the day since their time is expected in what were the "off hours".

There's also a question of etiquette in this brave new world.  What is the reasonable expectation for a virtual worker?  When is it appropriate to say "no" to an activity or task?  When is there too much of an expectation for you to support new technologies that enable your virtual work?

I was speaking with a friend in a large multinational who has individuals that report to him in six different countries.  He has never met, face to face, two of those individuals.  Perhaps I am old fashioned, but I cannot imagine managing someone I haven't met.  Or perhaps this is the wave of the future, and all our interaction with our colleagues will be virtual.  God help us if that's the case.

Teamwork Barriers

This post - or one soon to come - will mark the one year anniversary of writing this blog.  When I started I thought I'd write about teamwork and productivity.  To me it seems there are lots of tools and processes which optimize individual productivity but don't do much for team productivity, so I wanted to create a dialog about teamwork and productivity and innovation.

I'm concerned that we're becoming even more productive individually and less and less productive in teams.  One reason is the computing power we have at our fingertips.  Most of us can create a financial plan, develop the powerpoint presentation and write up a proposal without speaking to anyone else or leaving our desks.  With access to the internet, you too can be an instant expert on almost any subject without speaking to anyone in your company.

When I first got started writing this blog I thought a big problem was a lack of tools for teams.  I guess I still feel that way, but the lack of "teamware" is not what is holding back the productivity of teams to any great extent.  I wrote a post a while back called "There's no IT in team" which was one of my favorite titles.  In it I argued that the problem in many team work environments was a lack of tools to support team work.  In just over a year there have been a number of good team space and collaborative software applications to appear in the market.  They're not perfect but getting better all the time.

No, I think the real problem in improving teamwork in any organization comes down to cultural and motivational issues, and fear of the unknown.  Let's face it - if software tools were the most important aspect of team work, the Empire State building or the Suez Canal would never have been built.  What's changed is the concept of the individual as a free agent - able to gather information and process it individually to draw his or her own conclusions.  Another thing that has changed is the drumbeat of quarterly reporting - no one can miss a quarter anymore without some damn good reasoning, so everyone lives in fear of the financial numbers.  And with modern data processing we can discover right down to the person who was at fault.

So, individual technology that was supposed to make us more productive has made us more likely to process the data to shed the best possible light (using PowerPoint as a demonstration medium) that our group, our team was doing what it should have.  As we build these walls around our business functions, geographies and product lines, we make it harder and harder to work across the organization at a time when customers are demanding faster and better business processes across the organization.

No, team work tools are not the issue.  Go get one or several if you need them - see Michael Sampson's blog for a list and good overview of many collaborative software packages.  But before you implement a cross-functional system, ask yourself and your teams if they are ready, willing and able to work in a cross-functional environment.  Do they have the motivation, compensation, management backing and culture to work across business functions, geographies and product lines successfully?

What gets in the way of successful teamwork?  Culture, compensation, motivation, loyalty to a business function over loyalty to the business as a whole, turf defense, and many more.  Software may be powerful, but no software can overcome these issues.

Organizational Chameleons

Yesterday I wrote a post concerning the fact that what had been - and still are - important business functions have become stovepipes.  That is, groups like Finance, Marketing, Sales have more sway in most business than necessary and hinder the work of adding value.  Add to that our adherence to the traditional top-down command and control hierarchical structures and you've got a firm that is rigid, bureaucratic and very slow to move.

When did finance become so important anyway?  It seems like in most businesses financial engineering, reporting and financial management have become more important than making a product or delivering a service.  I think this has moved the emphasis away from creating great products or providing excellent customer service.  It's easier for the finance guys to engineer a synthetic lease - whatever that means.  Here's my question - if finance is so important - do your customers know who your CFO is?  Do they care?

This isn't just to beat up on finance (although secretly I think we'd all like to do it occasionally).  Most customers and business partners don't know who runs manufacturing, or customer service, or marketing either.  They'd better know who runs sales or your firm is really in trouble.

My point is that our businesses are finally reaching the juncture in technology, information and cultural evolution where we can begin to morph our business models to fit the needs of the business as it exists today. The top-down model is creaky, and the fascination or power held by specific business functions is unnecessary and unwieldy.  I think there are several business models we can pursue which will make businesses more efficient, serve the customer more effectively and provide greater opportunities for employees.

Organize around a business process.

I'm no expert, but I think that Dell has done this fairly well.  Their whole goal is to get the order, make the product and ship the product as quickly and efficiently as possible.  Who's the leading technologist at Dell?  I don't have a clue.  They haven't attempted to differentiate around their technology, so that's not really important.  They chose to optimize their organization around a business process - taking the order, making the product, filling the order.  So in a "high tech" company, there's no clear R&D head or chief technologist.  Contrast this to Sun, for example, where the focus seems to be on the technology (still).  There are five or six significant, high profile technologists at Sun, yet for the most part they are very removed from their customer.  Sun until recently designed their own semiconductor. Did that really add tremendous value?  Does the customer care about that?  Did it make Sun more efficient?

In some businesses, especially as the products become commoditized, it makes sense to provide timely fulfillment, good service and great pricing.  That's what Dell has done in its niche.  Can this model be applied elsewhere?  Absolutely.

Organize around a customer or an industry

This makes sense for firms selling to a large, monolithic customer (USPS or a Federal agency, for example) or in cases where there is a large, homogeneous market (selling to the Big Three auto manufacturers, for instance).  In this case you'll structure your organization to the requirements and needs of the customer, and put the systems and hooks in place to satisfy that customer.  In the automotive world, for example, that lead to tight systems integration with downstream customers.
The nice thing about this model is the ability to FOCUS.  Everyone should have a clear line of sight to the customer or something that's important to the customer.  In a firm dedicated to a customer or to excellent customer service, can you imagine someone saying "Well, finance won't let me do that" or "IT said no to that request". 

Organize on the fly

That's what consulting firms seem to do best.  Many consulting firms are organizational chameleons, able to morph into the required structure and components based on the problem presented.  Of course, consulting firms have to do this to survive, and there are secondary organizational structures within most consulting firms, but these firms are a great example of plucking people from different roles and regions to present a team to solve a problem.  That team will be disbanded once the project is complete and may or may not work together again.  In this model, the focus is on solving the problem presented.  Everyone on the team should have a very clear focus and goal.

In any of these organizational models, we are trying to use the firm's resources, especially the people, as effectively as possible.  In these models we've moved from a top down command and control model to a model which provides much more decision making at the interaction with the customer or the challenge.  Business functions, which were once stovepipes, now return to their rightful role as SERVICE organizations to the groups that are building product, solving a customer problem or generating great customer service.  The organizational structure, rather than getting in the way of getting things done, becomes an enabler to getting more stuff done more effectively and more efficiently.

The Smaller the Better

In a continuing vein of scholastic research, let's plumb again the employer-employee relationship, only this time let's evaluate the number of people in any hierarchy.

I have a general rule of thumb about staffing a team or a project.  I usually estimate the amount of work to do and how long it will take to accomplish given a certain number of people involved.  Then, with years of experience behind me to guide me, I add 10% more time and subtract 10% of the resources.  Why?  Even if I kept all the people I originally estimated on the team, we'd still end up taking longer than anticipated.  I dealt with some of the reasons in my post Sunny Day Scenarios.

Note though, that I am advocating making your team, your hierarchy, your organization as small as possible.  That's counter-intuitive in a time when we are evaluated on how large a team we manage.  Frankly, I'd rather manage a smaller team that has greater focus and higher commitment.  I guess it's a question of guerilla tactics versus the armed frontal assault.

Why are smaller teams better than larger teams, most things being equal?

1.  Focus - a manager can spend more time with each person on a smaller team as necessary.
2.  Clarity - in a smaller team, everyone has a line of sight to everyone else.  Everyone is aware of the circumstances, the successes, the failures and the expectations.
3.  Cohesion - smaller teams have a greater chance to be more cohesive.  (The corollary here is they also have a better chance of tearing each other apart)
4.  Administration - I need to recruit, train and bring fewer people up the learning curve, so we spend more time on real work and less on the administration of the team
5.  Interaction - I can interact more easily with each individual and gain a sense of their commitment level
6.  Visibility - Since it is harder to "hide" on a small team, I can quickly weed out those who aren't up to snuff or just aren't bought in to the program.

There's one other one as well - esprit de corps.  Belonging to a small, elite group who share common goals and work together effectively reinforces a group bonding and culture.

Many of you reading this will scoff - with a larger team I can always throw more bodies at a problem.  Well, no, not really.  As I add people to a problem there becomes an issue of dimishing marginal returns.  Eventually I add enough people where most of them simply get in each other's way.  As the team gets larger I have to lower my standards for the people in the group to continue to add people to the team.  I have a greater chance to bring aboard folks with less commitment and less loyalty.  As I bring more people aboard I have no line of sight to each team member and have to begin to place individuals who job is just to manage others in between me and the rest of the team.  At that point, I'd better be a project management expert, and so had all the other folks in the chain of command, because culture, communication and team loyalty aren't going to be the big drivers to bring a project in on time.

I understand in some circumstances it's simply not feasible to have a small team on a project, but I will encourage you to keep the teams in anything you do as small, as focused and as cohesive as possible.

When is a team not a team?

Here's a quick joke for context - When is a door not a door?  When it's ajar.

When is a team not a team?  When the goals, objectives and expectations of the members of the team aren't the same.  Then, the "team" is merely a collection of people who have different agendas.

We are working with one such "team" right now.  The dynamics are very interesting.

This team was nominally brought together to investigate some shortcomings in their current systems and to recommend new applications and systems to improve productivity.  However, rather than adopt a common goal and set of expectations, each person has brought their own ideas and biases to the table. 

One person is convinced that there is no problem with the current way of doing things.  One person is convinced that all the team needs is to do what he suggests and that all other discussion is useless.  One person has locked on to a large and expensive software application because the vendor told him it would meet his needs, which aren't the needs of the group.  Another person in the team wants to implement several applications or custom solutions to solve several point problems and is not worried about integration.  None of these folks has the vision to define the goals beyond their own special interests or needs.

Now, this may be a team in name, but it's not a team in spirit or outcome.  Everyone is out to defend turf, to take on as few new responsibilities as possible and to get only what they want out of any new system with as few compromises as possible.  No, this is not a kindergarten class but an actual example of a set of professionals who were supposed to be a team, but have not decided to work together yet for the common good.

Before you laugh or point fingers, ask yourself - are teams in our organization really that different?  What common visions and goals do teams in our organization share?  Are teams united for success across all members and functions of the team? 

Successful teamwork is about getting everyone on the team, as much as possible, to work for the common good of the team and the organization, leaving aside as much as possible their personal or functional biases and "wins" to get what's best for the team and organization as a whole.  Teams function very well when they have common goals and ideals, and not at all when they don't.

What we have in the team we are working with right now is simply a collection of individuals who are seeking to optimize their own personal agendas and goals rather than improve the working environment for the organization as a whole.  The leadership of this organization is going to have to step in soon to force some goodwill and corporate goals on this group, or this will become a circular firing squad.

When is a team not a team?  When it has no common objectives or goals.

Successful Teamwork - The tools

Yesterday, I wrote about successful teamwork and the fundamentals that should exist to support successful teamwork.  Today I want to examine the tools that should be available for teams to work successfully.  Yesterday I used a sports analogy (I know, overused) so today we'll use a construction analogy.

Every day skyscrapers are built by construction crews all over the country.  These buildings require a wide array of skills and talents to complete, and many of the subcontractors and laborers will work together on just one building.  In many cases, the workers bring their own tools to the site.  Imagine the chaos if there weren't blueprints and architects to manage the process.

This description is similar to how we work in teams in business.  A number of people come together to evaluate an idea or make a recommedation.  They come from different parts of the business (marketing, finance, sales, manufacturing) and bring their own biases and tools.  However, as we discussed yesterday, there generally is not an experienced architect (coach) to help guide the group, and there are rarely any agreed processes or tools to get the work done. 

In most team environments, there is little or no thought given to how the new team should manage information, how that team should collaborate and communicate, or how the team should document its findings and results.  The blueprint for successful teamwork does not exist.  Tools, such as they are, usually consist of Word, Excel and Outlook.  That is not to say these tools are wrong, just that there's little thought given to the way we capture, store and exchange information as transient teams.

I wrote in an earlier post about a large consumer goods company that was reduced to using Excel rather than a BI tool since the BI tool could not be deployed before the life of the project was completed.  This is a common problem and indicates that tools to support teams and their work are not a priority to IT.  IT organizations in most businesses have become fixated on "enterprise" systems which support business transactions and have denigrated personal and workgroup productivity tools.

What do teams need to be successful? 

• An agreed approach on how they should work - the blueprint
• A coach who can keep them on track and keep them honest - the architect
• A set of tools to support knowledge management, data analysis and collaboration
  - These tools can be packaged tools like some I've recommended
  - These tools can be as simple as Wikis and web logs the team builds for
      itself
• Clear goals and objectives from its sponsor

Once we have these items in place, the tools and the fundamentals, our teams can become more productive.

Successful Teamwork - The Foundation

I wrote a few posts ago about working successfully in teams, and identified a few significant challenges to getting something done effectively in teams.  I want to return to that theme over the next few posts and explore some of the issues in more depth.

I've been warned that sports analogies are overused, but let's throw caution to the wind.  A baseball team consists of people who have dramatically different skills and talents - from a home run hitting/weak throwing first baseman to a slick fielding yet singles hitting shortstop to a strikeout pitcher who can't hit his own weight.  Bring all these individuals together with a great coach and common objectives and you can build a winning team.

In business we pull people from sales, from marketing, from manufacturing and from finance and stick them in a team and ask them to be productive.  They generally have no coach and don't "practice" working as a team.  For the most part, most business teams come together once, do something and then disband.  These teams have no long term objectives except as individuals who hope to get something done and return to their "real" job.

Like a baseball team, each team member has incentives that may distract from the team's goals.  A home run hitter may have incentives in his contract that encourages him to swing for the fences when a simple single will suffice.  A financial manager on a team may have incentives or directions from his functional manager that make it difficult to help the team reach good decisions.  Additionally, most individuals recognize that certain business functions have more sway.  In technology firms, the people with the power are the design engineers.  In pharma firms, they are the brand managers.  Often, if the team includes a person from one of these areas, this person dictates the direction of the team.

What's the point?  To make teams more effective, we've got to establish a set of operating principles.

• We need to practice working as teams.  I know we can't just drop all of our "real" work, but if a baseball team can go to spring training for 3 months, certainly we can train people to work effectively in teams for a week or so a year
• We need to provide coaches for our teams.  If a baseball team needs a hitting coach, a bench coach, a pitching coach and a head coach, why doesn't a business team need a teaming coach.  Why not have a non-involved senior manager act as a coach to teams that are just getting started or who need an independent ear?
• We need to make sure teams have appropriate compensation.  Don't allow personal incentives to get in the way of the right decision.  Consider compensating the team based on the team's goals, rather than on their functional deparmentmental or individual goals.
• We need to balance the playing field.  If all of the team members are there because they can add value to the discussion and decisions, then they all should have equal weight.  If a team loads up on homerun hitters at the cost of good pitching (I'm talking about you, Texas Rangers), the team is unbalanced and will have a poor result.  In a pharmaceutical firm, a heavy dose of brand managers will certainly have an impact on a team.  Find the right balance and ensure no one person or function dominates the team.

If we put these foundational items in place, we can establish the baselines to help teams operate successfully.  Then we need to provide the tools to help the team perform at an even higher level.  But that's a post for another day.

Working successfully in teams

Working in a team is hard sometimes, not because it has to be, but because we make it that way.  Why re-invent the wheel every time?

Let's face it, on the whole, projects and tasks that teams work on require approximately five key tasks:

• Finding the data or information.  After the team receives its direction, it needs to find out what data or information exists about its responsibilities and deliverables.  This can be simplified through business intelligence or corporate dashboards.
• Finding out who knows what.  Has anyone in the organization or outside the organization done something like this before?  What can we learn from it.  This can be simplified through knowledge management.
• Meeting with the other team members to discuss direction, purpose, the information we have and the information we need.  This requires meeting management, leadership and organizational skills.
• Agreeing on a solution or set of alternatives.  The team meets once the data is collected, evaluated and reviewed and sets a recommnedation or defines a set of alternatives.
• Creating a recommendation, a rationale and a paper trail.  Once the team has completed its work, it makes a recommendation, creates a document or set of documents to establish its thinking and leaves behind a paper trail.  This can be managed with document management.

OK, if there are only five key factors, why is teamwork so hard?  Typically, competing agendas, culture, politics and unclear goals are some reasons.  Additionally, even though the five tasks of a team are relatively simple, generally speaking none of these tools exist and few teams establish a "workbench" of applications or tools to support themselves.  So, lack of clear objectives and political concerns cloud the ability of the team to interact well, while a lack of tools and processes interfere with the team's ability to gather, analyze and create new information.

No wonder teams struggle to create something of value.  What can be done to make teams more effective?  That will be the topic of the next few posts, but you can believe we'll return to two topics:

• Clear goals, culture, politics and communication
• Tools and applications to improve collaboration and effectiveness