A Business Technology Place

Team chemistry – learning the mix

Can you describe team chemistry with words?

20 years removed from undergraduate college work and I’m still learning about team chemistry. It’s one of the simplest and yet most complex concepts. You know good chemistry when you have it because you can feel it. But yet, you may not quite be able to describe it with words. Good team chemistry keeps you motivated and involved. Bad team chemistry leaves you frustrated and looking for a way to leave.

I’ve been on teams with a good and bad mix. When it’s good, team members respect each other. They accept the faults in others and help find ways to look past weaknesses. Where there is good chemistry there is trust. You don’t have to ask for something twice. You don’t worry about how a task is completed because you know it will be completed. When there is good chemistry you recognize that each team member has a role that contributes to the whole. With good chemistry the individuals value the output of the team more than their individual output.

Teams with bad chemistry show the opposite characteristics. They disrespect each other and focus on one another’s faults. They don’t trust others to complete a task and would rather do it themselves. When the chemistry is off, the team members value their own output more than that of the team. With bad team chemistry the team members selectively hear their teammates with a filter that immediately gets defensive or says ‘no’.

Good chemistry happens when the results are more important than the credits.

Star athletes competing in a team sport often say their individual performance isn’t as important to them as the team winning. Charles Edward Montague wrote “There is no limit to what a man can do so long as he does not care a straw who gets the credit for it.” Many variations of this principle exist in quote, but the concept is the same. Teams accomplish more when individuals work together.

In one of my first software project management experiences, team was developing a B2B website for bankers to use. There was tight cohesion on the team from analysis, to requirements gathering, to design, and programming.We succeeded together and failed together and everyone knew it. The team focus was all about the goal of software releases. I felt good chemistry.

Bad chemistry happens when individuals are more interested in being “right” than in finding a solution.

I once made the mistake of always wanting to be “right”. I had a filter applied towards a manager based on past disagreements. No matter what they said, I found fault. When we disagreed about the direction to solve a problem or how complete a task, I argued to be “right” or to win the argument. It cost me a position and a relationship.

I’ve seen groups of people take sides in an office environment when disagreements and differences of opinions happened. They stopped listening to each other. They stopped working together. Solving problems for customers became less about the customer and more about their specific solution. The “right”solution. That’s bad business. That’s bad team chemistry.

There is a time to disagree and start over.

Sometimes as imperfect people we let ourselves devolve into bad chemistry. Sometimes the chemistry is there from the very beginning of a team due to personalities, individual goals, competitiveness, egos, or strong wills. There reaches a point where it’s not beneficial to go forward. It’s like trying to put the square peg in the round hole.

In the book of Ecclesiastes in the third chapter it says “For everything there is a season….a time to keep, and a time to cast away;”

Good chemistry isn’t something you can force on people. In some ways it just happens. Yet it’s also something that people have to intentionally work to keep in good balance. But there reaches a point when a team has bad chemistry that it’s time to agree to disagree and part ways. For the betterment of all involved it’s time to start afresh. I’ve been a part of a team that was disbanded because it wasn’t producing solutions. I’ve also been the new entrant to a situation where team members were not getting along and new players were needed to reset and refocus on business goals. When the chemistry isn’t good, the solution may be to re-rack the people.

Where operations, projects, and innovation collide and divide

To build it or to maintain it. That is the question.
It’s a classic question in organizational design. The answer of course is you have to do both. I’m not talking about the decision of a product nearing the end of its life cycle where you decide between adding additional features or putting it in maintenance mode. Rather, this is about allocation of people and teams within an eCommerce organization to maintenance or operational activities versus allocation to projects.

I’ve seen terms like “run the business”, “keep the lights on”, and “operations”.   Those terms refer to activities that an organization does to maintain service to existing customers or to maintain production of existing products. In an eCommerce team this might be activities like maintaining server equipment, network connectivity, data backups, content management.

But we also need people assigned to “build the business”, “new projects”, and “innovation”. These are tasks like building new features in the system and creating entirely new products and services that have new demand in the market place.

It’s not just an IT problem.
Other functional areas of an organization design responsibilities around this need. A typical Sales team will have inside account managers (run the business) and new partnership development (build the business). Marketing product managers are challenged with how to split time between servicing existing products (run the business) and building new features (build the business) for their product. IT is challenged with it because they have systems to maintain while also trying to help the business build features and solutions on new technology.

Eric Brown makes a good case for splitting the responsibilities and focus of an IT organization into operational and innovation areas. His point is that people are trained and have skills in certain areas. If that is “running the business”, then keep their focus on that so they do it really well. But don’t expect them to be good at bringing new innovation to the business.

Asking the question is easy. Answering it is not.
So how do you solve allocating people across operational and new project work? In my mind, there’s no single answer. It involves creating a balance and is effected by a number of criteria:

  • People: How many people do you have? Smaller organizations may not have the luxury of dedicated people per function. I think this puts them in a tough spot because to Eric Brown’s point, not everyone has the mindset (or skillset) to contribute to both.
  • Time: How do you split time between operations and project? Do you set a goal for 50/50, 70/30, etc? That’s likely tough to follow week-by-week because emergencies like hard drive failures don’t run according to a schedule.
  • Priority: What’s more important the operations or getting new business? This is such a tough question. Leaders that have incentives based on new revenue growth certainly lean towards new business. But we know that companies that neglect their existing customers and operations may not see tomorrow to have a chance to build out new business.

eCommerce teams need to find a balance.
To play the eCommerce game, teams need the ability to experiment as well as implement change. That’s how you drive new business. But maintaining the existing store is just as important. So when you create an eCommerce organizational design make sure to account for run the business as well as build the business activities.

I’d like to know how you’ve solved this within your organization. What say you?

Rethink competitive analysis

Solution owners have the responsibility of performing a competitive analysis for an eCommerce team. It’s the process of knowing exactly how your site compares to the competition. We define if we are ahead, behind, or on par with key features that the industry and customers require. I’ve seen projects justified in the name of competitive alignment and at a larger scale entire strategies formulated in order to copy the competition.

But who says the competition is right?
Are they right because they are your competitor? If a competitor has an eCommerce site with a certain feature does that mean that my site must have it also? The answer is maybe. But it’s not your competitor that defines what is right, it’s your customers.

A better way to perform competitive analysis
First look at your customer input from tools such as surveys, web analytics research, and suggestion boxes. These tools will tell you what features customers value, those they don’t, and those they wish they had. This gives you the success factors or features to use in a competitive analysis grid. In other words, rather than using your competition as the baseline for success, use input from your customers.

It’s a multifaceted solution
When we start with what our customers are asking for first, we get a good view at the important features for the entire industry. This will provide some insight into competive analysis activities for new competitors or competitors with complementary products. Additionally, the will of the customer should be and is a much stronger position for project justification than merely copying a competitor.

Competitive analysis does have merit
With a thorough analysis you can see how you stack up to your competitor in meeting what customers value. You may have advantages in some areas and be behind in other areas. Plus, defining how you differ from the competition is one step towards creating your value proposition for prospective customers and investors.

Solutions ownership and competitive analysis are part of a complete eCommerce organization. See my mind map for an eCommerce organization for further thoughts on this topic.

eCommerce solutions ownership – customer focused results

An important role in an eCommerce operation is responsibility for solutions ownership and the results delivered to senior management and other stakeholders. It’s a senior role that focuses on the macro level results that  define the success and viability of the eCommerce team. In addition to the traditional financial and market metrics, the solutions owner must deliver customer focused results. It’s the customer focus that provides the building blocks for the traditional results and helps to set an eCommerce team apart from it’s competitors.

Traditional financial results

A solutions owner is responsible for profitable results with positive contribution margins. The contribution margin of a product is defined as the revenue minus the variable costs. eCommerce sites should consider both product variable costs as well as an allocation cost assigned to the channel for the variable costs associated with keeping the site running.

What about cost reduction? Typically, eCommerce operations help to reduce costs because they scale well and require less labor to maintain for the level of output. Cost reduction can be tied into the profitability calculations if the variable costs for the eCommerce channel are less than those for other channels. In this case, the channel would be more profitable per sale.

Customer focused financial results

An often overlooked part of financial results are those of the client, in a B2B relationship, or a customer, in a B2C relationship. In a B2B framework, the solutions owner is responsible not only for delivering results to his own company, but to his client as well.  The eCommerce operation is as successful as it is in keeping the client in business with it’s customers. The mission is to make the client profitable. This concept applies whether your site a straight B2B or a B2B2C site. Either way, the costs of the products from your eCommerce will be part of the final price that the end-customer pays and part of the profitability of the middle business.

The solution owner should also be concerned about the financial results of the customer because the customer’s financial results determine if they’ll be repeat customers. In this sense, the financial results must be in alignment with the strategic positioning of the product in the market place. If your product competes on lowest cost (i.e. Wal-Mart)  then obviously customers will repeat as long as they feel they get a better price. But if you compete on something other than price (i.e. Chic-Fil-A with community and customer service), then you will help customers to find ways to off-set the price premium. My drawer is full of Chic-Fil-A coupons for free food.  That makes me feel financially successful with those purchases. But it also makes me spend more money at their stores because when I go, I usually buy for other members in my family. I could list many other examples of this, but the point is the solutions manager must consider the financial results to the end-customer.

Traditional market results

Typically a solutions owner oversees market results that focus on market share, units sold, and the percentage of products sold through the eCommerce channel (channel penetration). These are good and necessary result categories that show how the eCommerce operation is performing in a broader context. It’s important to note that growth may not be the expected result in all cases. If the product is in the declining stage of its product life-cycle then year-over-year comparisons may be expected to show decline.

Customer focused market results

A solutions owner with a customer focused view of market results recognizes that the eCommerce channel does not compete with other channels but is offered as a complementary channel to the customer. In the early days of eCommerce, many companies setup the eCommerce channel as a stand-alone profit center with separate P&L metrics from other channels. There was fear among retailers that the eCommerce site would cut into the storefront sales. That kind of thinking leads to internal competition and moves the focus away from the customer. Over the years, companies have realized that customers like to shop using multiple channels.  So it’s the job of the eCommerce site to deliver an experience on par with a brick and mortar storefront and that has cross channel linking for the customer.

Organizational results

A third area for solution owners to deliver results is with organizational engagement.  As with any good manager the solutions owner must engage employees in the overall mission and success of the team. This means communicating openly about the objectives of the team and explaining how the objectives align to the greater organization. People respond when they believe and understand how they belong to the bigger picture.

Defining an eCommerce Operation – Experience and Usability

UPDATE 10/27/10 – I posted a mind map of my eCommerce Operation on mindmeister that replaces the original map contained in this post. This includes the latest updates to my organizational thoughts on an eCommerce team.

This is my seventh and final post in the series on the topic of defining an eCommerce operation. Certainly I’ve not covered every detail or function of an eCommerce grouped tasked with operations,

eCommerce Operation

An eCommerce Operation Team Structure

maintenance, and new growth. However, this and the previous posts provide a baseline of the most important functions needed in an eCommerce model and provide guidance on the eCommerce team structure.

The area tasked with defining the customer experience and usability of the site is of utmost importance. This part of your team defines the flow of the site, the visual appearance,  and how customers interact with it. The important thing to remember is that to the customer, they are not interacting with your site. They are interacting with your brand. Your eCommerce site is an extension of your brand. It can find, make, keep, and lose customers based on the experience they have with your site.

The experience and usability of the site can be molded in four key areas of release management.  They are prototypes, mockups, use cases, and process maps. They fit logically together and in sequence to guide the designer and implementors in the final output.


The prototype is used to show the concept of a software program or release. The eCommerce team could use a basic functional piece of software, a sequenced set of pictures, a storyboard of hand drawings, or any other type of visual output to display their prototype. The idea is to gain acceptance of the software concept and to create discussion about it to help mold and shape the final output. I know many traditionalists will argue that a true prototype must be a functional piece of software. I do believe this is valuable, and one form of a prototype, but today with today’s tools we have the ability to link static pages together without necessarily making them functional. Remember, the key purpose of this step is to communicate an idea or concept to stakeholders.

In some cases, the prototype is used as a proof of concept. Can the design team make something work on a smaller scale so that it increases confidence it can be done on a larger scale. In this case, the prototype is important in order to secure funding for the software release.

Use Cases

The use case describes how a system responds to actions on it. In an abstract sense we can think of objects performing actions on the system and then specifying how the system will react.  The objects could be people, other programs, or events.  The objects are often called actors and the use case creates a series of steps that describe the action and the resulting response from the system.

The use cases have value because they help the designers and testers to craft the expected flows of the system.  A use case document is also typically easy to read and less formal and verbose than many traditional requirements documents.

It should be noted here, that my good friend Mike Cottmeyer tells me the proper name in agile development methods is “user story“.  Looks like in the case of a user story, the documentation of the requirement is simplified but requires and additional step of documenting an acceptance test.

Regardless of the methodology used, remember the key task with this work is to define the expected use of your system. Define who will use it, how they will use it, and what they expect to see as the results.

Process Maps

Once you have established use cases for a release, you can combine all of them with a process map, or flow chart.  This document defines how all the pieces of the software will fit together and flow to make a complete system. It shows how various use cases may be linked, describes decision points, and shows the possible paths through a system.


The mockup is a way of designing the user interface of system through images or drawings. The mockups are not functional. The purpose of the mockups are to allow your designers to create the page layouts that comprise the system. They’ll be considering things like object locations, form layouts, colors, fonts, etc.  Don’t discredit the importance of this step. Many a A/B test has proven that things like the color of button or location of an object on the screen can have impact on your site conversion rates. You don’t necessarily need a designer for this task, but you do need someone who is visual that can bring your process flows to life.

I added the experience and usability functions to the concept map for an eCommerce model that I’ve discussed.  I welcome your feedback and input.  No model is ever complete and in the spirit of continuous improvement I’ll always be looking for ways to tweak to so that it creates more value.