In our last article, we discussed using other people’s resources to overcome the bottleneck that budgets and resources present. Today we’re going to talk about partnering with the enemy.
Enemy is a strong word for a team that you find yourself at odds with, though it may often feel that you are at war with them. There is an obvious conflict with competitors, as you fight for every customer. This type of conflict is excellent for the market; it should help create a competitive environment driving innovation and cheaper prices. You have to be very careful when approaching an external competitor with a proposal to work together in certain areas because there are numerous laws protecting consumers for collusion and price fixing. That doesn’t mean that competitors can’t partner together for specific initiatives. The term for merging competition with collaboration is coopetition. Instead of going head to head with competitors on everything, often it’s worthwhile for both sides to define the competitive areas, while at the same time defining where you can collaborate.
The most difficult conflicts to deal with are those among internal teams that are supposed to work together, not compete. If you look at the entire ecosystem of what goes into a product/service, there is plenty of opportunity to point fingers from one department to another, throwing blame in every direction.
- Marketing promises features that aren’t practical
- Sales promises deliveries that can’t be accomplished
- Purchasing isn’t bringing materials quickly enough
- Manufacturing is building too slowly
- Support is taking too long answering the phone and giving bad solutions when they do
Every group is siloed in their specific areas, expecting everyone around them to be marching to the same beat that they are.
In software development, the teams at odds were the development, quality, operations and support engineers. There was a proverbial wall that developers would throw their software over and expect that everyone else would make sure it worked. The operations team would yell back that there is a problem, but not give developers access to production environments to see what the problem was. There was never enough time to properly test the code, and it was very difficult to support. After years of suffering though this situation, full of accusations and blame, a number of new methodologies arose: DevOps, Agile and Continuous Integration. The ideas that came out were:
- cross-train people to be proficient in both development and operations
- incorporate the operations and testing requirements into the development process
- release features/fixes as soon as they’re ready instead of waiting for a huge, time-based release
- raise problems as soon as they come with a cross-functional team
These new methodologies drastically improved the relationships between the various teams. Instead of being constantly at war and blaming each other, they started working together and appreciating what each side brought to the table. One of the terms used was tearing down the wall. Developers, for example, have to learn about environments, scalability and testing. Just because something works on their computer, doesn’t mean it is a good fit for a production. Cross-functional meetings enable all the players to bring up things that they find to be important, and explain why it is relevant to the other people as well. As an example, software developers may not fully understand what is needed to handle thousands of hits per second. That is purely in the realm of operations. However, by having the discussion early, including what the expectations are, the software can be developed differently to make it easier to scale.
This methodology does not have to be used exclusively for software development. Think about forming a working group between key people in marketing, sales, manufacturing, purchasing and IT. This has to be professional representatives who understand the reality of the work, not managers. When the disparate teams realize what is going on in the other departments and what impact they are having on them, they can actually start to work together to remove bottlenecks and focus on the good of the organization instead of only their group’s narrow scope. Blame should not be assigned, but it should be replaced with responsibility and accountability.
If there is conflict among any groups that should have the same overall goal in mind, that is the time to stop and think. While every person, team and organization has their own goals, these should all be able to combine together for the greater good. This is true all the way up the line. From individuals & teams all the way up through regions, countries and society as a whole.
Comments
Post a Comment