Have you ever custom-ordered a product or service and waited eagerly in anticipation for its arrival, only to be shocked and disappointed that the vendor could miss the mark so badly? It’s not a position you want to be in as the receiver — and definitely not a great place to be as the giver. I was in an Italian restaurant once and ordered Pasta Aglio Et Olio (not on the menu). Fifteen minutes later, the waitress brought me uncooked spaghetti and water. I realize that what I ordered was not on the menu, but this is a very easy dish to make, and I would have expected an Italian restaurant to make it well.
In most circumstances, what your data science team is building has complexities that many will not appreciate. That said, if they’re critical in supporting your product strategy (i.e., data science is built within your next product offering), then they’re chartered to produce a working product — not fancy data science. To do this, everyone on your data science team has the responsibility to step outside the math and own your next big product in total. When pride of product ownership is missing from your data science team, your whole strategy suffers.
It takes a community
It’s critical that everyone on your data science team takes pride in what they’re developing. The mindset, beliefs, and attitudes of your entire data science team should resemble those of you, your general manager, and your sales team. When you introduce a new product into the market, you and your general manager are very sensitive to how your market will receive it. Your sales team and most likely your marketing team are in the same boat, because they deal with your market on a daily basis. And even though your data science team is not in direct contact with your market, they should act as if they are. In fact, they should behave as if they themselves are consumers of the product they’re building. This is what pride of ownership means.
Pride of ownership keeps everyone in the data science team oriented on the real goal — delivering a product. I’ve witnessed many technical organizations disintegrate into competitive factions, desperate to protect their own function. I was recently involved in a User Acceptance Test (UAT) for a small technology effort in a large oil and gas company. When I browsed through the past records of functional testing, I knew we were in trouble. The volume and character of defects that came out of their first functional test were alarming; the product was failing on a very basic level. After three cycles of back and forth, I guess they felt it was ready for the users to take a spin — or more likely, they just ran out of time. I personally crashed the system in the first five minutes by simply pushing a few buttons. This is what happens when everyone is just worried about their function and nobody is concerned about the product as a whole.
The pride of the pride
To ensure pride of ownership is embraced, there are preventive and corrective actions you can take. On the preventive side, make sure everyone on your team is shooting for the same goal:
- Architects are not designing a system — they’re building a product.
- Business analyst are not translating requirements — they’re building a product.
- Mathematicians are not solving difficult math problems — they’re building a product.
- Developers are not writing code — they’re building a product.
- Testers are not executing test cases — they’re building a product.
This concept extends beyond what you might consider your core team. There should be analytic managers, coaches, and change managers on your data science team as well. So:
- Managers are not trying to hit a date — they’re building a product.
- Coaches are not keeping your team happy and motivated — they’re building a product.
- Change managers are not engaging resisters — they’re building a product.
Making this very clear upfront is very important; however, building in positive and negative consequences is the best preventive measure you can take. For instance, develop objective measures on the quality of a build and hold developers accountable through performance reviews. Many leadership speeches go in one ear and out the other, but people will pay attention to anything that directly affects their career.
On the corrective side, abruptly interrupt the execution for a root cause analysis if you have evidence of the wrong behaviors. You may not be wild about obstructing forward motion to understand why people aren’t taking ownership in their product; however, it’s time well spent. This is a group intervention that’s best lead by your coach or whoever is responsible for the human dynamics in your data science team. It’s important that you focus on the cause of the problem and not try to adapt to its effects. For instance, more rigorous testing is not a solution for bad code — you must understand why the developers think that it’s okay to throw bad code over the wall to the testing team. And remember, 95% of the time, it’s not about the people — it’s about the process and what’s motivating their behavior.
Isolating your data science team from your target market presents a great challenge for your product strategy. To build your next great product, your data science team must take great pride in what they’re developing and how your market will receive it. Without this sense of pride, expect long delays in product development and disappointed customers. To prevent this from happening, send a clear message that the entire team is responsible for either making a great product or sinking the corporate strategy. Furthermore, make sure everyone clearly understands the consequences for not taking ownership of the product. And, if you notice that certain team members are more worried about doing their job than building a product, halt everything and run an intervention — yes, it’s that important. Believe me, nobody finds uncooked spaghetti and water very appealing.