Ask the right questions. I also think it’s more important to ask the right questions than to get the right answers. It’s easy to get answers. We know how to do that, and we have a ton of technology to help in this area. What’s hard is asking the right questions which are going to drive business impact. A lot of this is about surfacing and testing assumptions about what people think drives behavior or business metrics. For example, game design is very creative but is based on a lot of assumptions, like “We can make the game more enjoyable and get people to play longer if we add this feature or change how hard it is to get to the next level in the game.” If you pose these assumptions as questions and test them, then you can prove them right or wrong. That’s key to gaining understanding.
Finally, it’s important to embed analysts inside the business teams they support. They need to sit side-by-side with business people, participate in all their meetings, and contribute their analytical knowledge and perspective. If they’re not embedded, they can’t possibly master the nuances of the business they’re trying to support. It will take them much longer to perform an analysis and they might miss important details. Also, if they’re not embedded, it’s harder for them to persuade business people to test their assumptions and act on the output to improve the business. You need to be perceived as a business person who uses technology to solve business problems.
So my keys to success are: 1) talk the language of business, 2) let the business do the talking, and 3) get quick wins and build on your success. Ultimately, it’s all about sales. It took me some time to check my technical content and language at the door to the executive suite. I discovered that the more I discussed architectures, schemas, and tools, the less business people seemed interested in what I had to say. But if I talked about business concerns, say increasing wafer counts per square foot of factory floor at a semiconductor company, then executives paid attention.
To deliver successful projects, it’s also critical to follow a clear methodology that involves plenty of dialogue between business and the BI team. Executives need to define objectives, communicate them to everyone involved, define measures of success, and hold someone accountable for the outcome. The development team needs to hire the right people, with appropriate technical and business skills, to develop the infrastructure and applications. The business needs to assign the right business people to work with the development team to define requirements and provide continual feedback to ensure applications meet their objectives and needs.
Also Read: Nobody knows what actually they are doing
The right culture also matters. A data-driven culture that values empiricism keeps politics and opinions in check. People frame their ideas as hypotheses and submit them to testing and experimentation. Although decisions are evaluated scientifically, there is still room for judgment and intuition. This kind of culture values data and analytics immensely, creating a supportive environment in which data developers and analysts thrive. The right culture also minimizes rules and processes to prevent stifling innovation and learning. It continually prunes processes that don’t add value and is willing to incur some risk to ensure a fluid, fast-moving environment.
To get the most value from your people and culture, you need the right organizational structure. I prefer a federated organization in which a central team supports the activities of embedded data developers and analysts while giving them ample opportunities to collaborate and share knowledge. Here, data developers sit side-by-side with the business people they support. As a result, they become immersed in the business and more effective at what they do. In a federated organization, you align first with the business, and then optimize technical functions.
In a dynamic business environment, data developers with a diversity of skills trump a collection of specialists. Specialization is a fine thing when you have well-defined requirements. But in a fast-moving company, developers need to discover requirements as they go. By developing an entire solution from requirements to testing, they can respond immediately, iterate rapidly, and deliver optimal solutions more quickly than a team of specialists that require endless meetings to coordinate their activities. The ideal data developer focuses on mastering a business domain rather than a technical specialty.