A journey of a thousand miles begins with a single step
千里之行，始於足下— Laozi, Tao Te Ching
This series of posts has analyzed a very real issue in software development – the fact that many companies have lost control of their Engineering function. In my experience, the solution is not a quick one, but in this post, I want to talk about the first step toward creating an effective team. Notice that I didn’t say only “Engineering team” because the crux of my solution is that the Engineers and Product Management work together as one.
The one lesson that I have learned each time I helped a team turn around was that when the Product Management team and the Engineers work as one, almost all problems disappear. Having said that, it’s not as easy as commanding it to be done – the cooperation needs to be cultured into both teams. How do we do that? In my experience, it’s a three-stage process:
- Mutual Objective
- Mutual Respect and Understanding
- Mutual Effort
They work in an inside-out manner as shown in the following:
Mutual Objective
For any two groups to work together, the first step to achieve cooperation is to find a common purpose between them. As long as the objective of Engineering is to do the best technical work and the objective of the business people is the get the most valuable features, there will always be a chasm between them. The preceding posts outline why the only objective for everyone is to provide value to the Customer. Educating both sides on that (especially the Engineering side, since I would hope that the business people already believe that) can help toward achieving the first stage.
As mentioned, this is not a rapid change – like any paradigm shift [1], one session will not do it. I’ll talk later about how this slow-ish evolution happens, but as long as you are aware of the need for patience [2], you can accomplish the shift. The most effective catalyst is to have your Engineers increase their direct and indirect contact with real Customers. There is nothing like a conference call (or even a site visit) with an angry Customer to help an Engineer understand why the Customer Membrane matters.
Mutual Respect and Understanding
It is difficult for two groups to cooperate when one or both sides don’t respect the other. To me, this is one of the biggest impediments to creating a high functioning product team. I mentioned in a previous post that Engineers often disrespect their business colleagues because they lack technical chops. On the other side, the business-types often disrespect the technical-types because they lack the business knowledge and the soft skills that business-types pride themselves on (such as making presentations, creating requirements and talking to Customers).
Communication and understanding is an equal challenge between these two groups. The Engineers use odd words such as “lambda”, “polymorphism” and “deprecated”. The Product Managers use vague non-technical words like “stakeholders”, “leverage” and “synergy”. It’s like they’re speaking completely different languages [3].
Both respect and understanding are major impediments to progress and success between these two teams. I propose that the root of both issues is a single (and perhaps surprising) factor: fear.
The business people are generally afraid when the Engineers get deep into their technical discussions. They don’t understand most (or any) of it and it’s embarrassing for most humans to admit that they don’t understand [4]. The end result is the Emporer’s New Clothes effect [5] – those afraid to look unenlightened just pretend to see what it is they’re told to see.
Some Engineers are afraid of the Product Managers because they often want to talk and many Engineers are not big on the “talking thing”. But, the more relevant aspect of their fear is something that they probably aren’t even aware of: they are afraid of the business side because they don’t understand it. Ironically, it’s the mirror of the issue that their business colleagues have. Keep in mind that any specific Engineer has probably been the smartest kid in their class (at least in topics like Math and Science) all the way through their childhood. They might even have been the smartest kid in university or college. Most have developed a singular focus on technology and coding that garners them daily respect with their Engineering peers. They are experts at a lot of technical “things”. But Customers, business concepts, presentations and the like are things well outside of their areas of expertise and that is frightening for anyone, not just Engineers. If you want to see true fear, ask an Engineer to make a presentation in front of a large group.
How do we ratchet down the fear factor? First, by sharing the mutual objective in Stage 1 and exposing the Engineers to the business. This will help them learn about Customer needs and that should decrease the fear of not knowing. Also, in empowering the Product Managers in driving for business value, they shouldn’t feel sheepish about asking for explanations – in business terms – of any technical topics. And lastly, through encouraging acceptance by both groups that the other is vital to success and different in their (equally important) specialties. All of this should slowly help build the mutual respect that is vital to mutual progress.
Mutual Effort
The last stage often happens automatically once the previous two (challenging) stages start to take hold. Once you have a shared purpose, shared respect and improved communication, teams should naturally work together in a more harmonious fashion. But this still needs to be accompanied by the actual act of working together. Scrum enforces this by having the Product Owner and the technical team function as one unit. But if you’re not into Agile or Scrum, at least make sure that you don’t have a siloed organization where specifications get built in isolation, thrown over a virtual wall and worked on by the Engineers. There needs to be constant contact and I strongly suggest co-location (i.e., the Engineers and Product Managers for a specific product are all in one area). [6]
I promise that when you can advance the teams through these three stages, success will follow. I have hacked this a few times in my career by going back and forth between Engineering and Product Management roles for the same product. In my current role, I came to the company along with a colleague from a previous company – one of us on the Engineering side and one on the Product Management side. Since we had a pre-existing relationship and mutual respect, it created instant cooperation and we modeled that collaboration for all team members.
So, with that said, we are at the end of this introductory series of posts. I hope the posts have been helpful, regardless of what part you play in the software development process. I’ll build on these concepts in the subsequent series and, as always, I look forward to your comments.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] or exercise program
[2] As my long-time mentor said so gracefully – you can view at the following link
[3] In fact, they are
[4] Or “grok” as the Engineers might say in their language.
[6] There are many studies about the impact of distance on cooperation and the results (depending on which study you trust) are that somewhere between 8 and 50 meters is the magic distance where cooperation drops off badly.
Credits:
Raj Eiamworakul Spiderman on the Great Wall of China
Leave a Reply