This article is the next installment of the “10 weeks to Lean Integration” series.  If you are joining the discussion now, you may want to read previous postings starting with this one which includes links to related articles.

Empowering teams is primarily the responsibility of senior management, but front-line staff can also take power through their actions. The book X-Teams(1) lays out the dilemma quite succinctly:“Top managers have a vision, but how can they get the rest of the organization to implement the programs needed to realize it?”

This would not be a dilemma if personal and organizational goals were aligned, if teams have the support and tools they need, if all the information needed to get the work done were available and didn’t change constantly, and if the work were not highly dependent on other activities inside and outside the organization.

These conditions are quite rare, hence the advice from X-Teams that teams need to be externally focused and not internally isolated and that their power and effectiveness comes from a combination of top-management empowerment, treating people with respect, and team member initiative. In the world of integration, there are a number of specific techniques which can help.

First, clearly define responsibilities of the integration team. Much of the problem with integration in organizations is that while the responsibilities of each functional area are well defined, there is a tremendous amount of ambiguity around who is accountable for the information exchanges between groups. This same problem about who is responsible for the “white space” is evident in the technology arena. More specifically, who is responsible for the integration systems?

An integration system is a collection of components that are managed as a unit for purposes of data integration. It is separate from, and provides services to, other application systems within the enterprise. The services may include data migration, data consolidation, data synchronization, data quality, or process orchestration, to name just a few. This contrasts with the traditional view, in which integration components are managed as part of a business application. In a worst case scenario, they are not managed at all (i.e., they are “orphan” integration components).

An integration system views the integration components from a holistic perspective. It defines clear boundaries around each business application and explicitly defines all the components that collectively represent the integration system and its functions, regardless of how distributed those components might be. This provides the ability to sustain data integration across applications after initial projects are completed.  In short, integration teams are empowered when they have clear responsibilities for well-defined integration systems.

Second, automate routine activities to give people jobs where they have to think. Many integration tasks are very repetitive which has two downsides; 1) using manual labor to perform repetitive tasks is a waste of labor, and 2) staff are lulled into complacency when the work is too routine and they are not being challenged intellectually.

It is important to note that automating manual activities is NEVER about replacing people with machines. Instead, it is about raising the level of integration that may be achieved. For example, if you take a team of 10 people that do nothing but data mapping, and you reduce the need for staff down to 5 people through improved automation, you can then use the other 5 people to focus on more value added capabilities such as end-to-end process flows, master data management or improved data quality all of which create much more value for the enterprise than low-level mapping work.

Third, treat the extended team, including offshore partners, as first-order team members. This relates to both formal measures such as metrics and incentives and informal techniques such as team celebrations and recognition. Most company human resource policies put limits around this since it is important for tax and legal reasons to not treat contract staff the same as employees, but that doesn’t mean that contractors can’t be treated as team members.

For example, if you have an incentive bonus for employees, then make it a point to negotiate the terms of the contract with your partner such that staff assigned to your project are eligible for similar project bonuses from their employer. Informal techniques for team can be even more powerful. For example, ordering a celebration cake and having it delivered to the offices of your offshore partner in Mumbai when a project milestone is achieved is tremendously motivating for the remote staff.

Fourth, teach staff how to learn and solve problems, and teach managers how to teach staff. Note that we didn’t say teach technical skills. Of course if someone is expected to develop Java programs they need to learn Java – but that is not where team empowerment comes from. Empowerment arises when staff are able to think “outside the box” (i.e. to not put artificial barriers around their job responsibilities) and are not afraid to tackle problems that are outside of their comfort zone.

While some people have a natural tendency for this capability, there are a number of techniques and skills that can help everyone improve. In any event, the first step should be to ensure that first line managers and supervisors have the skills necessary to coach their staff.

Tune in next week for Part 7 in the series on the topic of quality and how to “error proof” the integration development process.

Note (1) Deborah Ancona, Henrik Bresman, X-Teams: How to Build Teams that Lead, Innovate, and Succeed, 2007, Harvard Business School Publishing Corporation

If you’d like to get Informatica blogs on the fly, just click the ‘Subscribe’ button on the right side of the screen.