The Psychology of Analytics - When Working Is Not Working

(Read Part 1, Part 2, Part 3, Part 4 and Part 5 of this Psychology of Analytics series.)

I led a data science team that stretched from Singapore to Sao Paulo, and I always told my team members that it didn’t matter how many hours a week they worked. I only wanted them to always deliver something creative to solve a problem on time.

They could go to the park, to the movies, whatever they wanted, but they must still come up with a new idea and without delaying the project. It might seem crazy, but no one on the team ever dropped the ball.

I am not saying that we didn’t procrastinate – even I did that. But the deadline looming made them more creative. The closer and closer the time came to demo, it allowed the team to – as writers often say – “kill their babies,” meaning, to cut out the things that really don’t matter to get to the core of what does.

British naval historian and author Cyril Northcote Parkison explained in 1955: “A lack of real activity does not, of necessity, result in leisure… The thing to be done swells in importance and complexity in a direct ration with the time to be spent.”

So in essence, the more time you push back and delay, the more complex and lost from purpose something becomes.

And why should we be working longer and longer hours in 2015? In 1930, the economist John Maynard Keynes forecasted that by the end of the 20th century, advances in technology would allow employees to work just 15 hours a week. However, employees seem to work more hours now than any generation previously. Maybe working is not working.

While it’s a stretch for project managers, directors or executives to pack more in a work day or learn to code, in today’s age, it’s easy to be blinded with science by your team. Allowing team members to build without understanding technically – not just conceptually – what your team is innovating towards quickly becomes a black hole.

Every innovation should be pitched, beta tested and put in front of either an executive panel or sample consumer panel to be judged in less than a week. Yes, one week, especially when it comes to analytics. Innovation should be revenue generating in less than 90 days in some form or another, if not – move on.

If you want a data science team to reach for the stars but not take years and millions of dollars to get there, try the following five tips:

1. Ban Powerpoints. Do not use them, view them or create them. If your team cannot convey their idea or problem statement in a Tweet – you haven’t cut to the core of the problem. Have everyone create a Tweet around the problem you are trying to solve. That’s right, 140 characters only. (Perhaps you do not prohibit the use of infographics or media files to accentuate the Tweet.)
2. Build a prototype in three days. Have your team (either individually or in a group) build something. Tell your team they can use anything they want – open source, freemium, your IT department’s technology that’s already – they just need to build something. It can be as easy as a website with HTML5 components, but it must be a consumer-friendly analytical application that tells a story and offers a way to solve it.
3. Create data in one day. Oftentimes, people build analytical applications based on the data that is accessible to them internally. However, try to build the application first and then the data that would feed the analytical app you created. This means creating the data that sometimes doesn’t exist. It won’t be available in huge quantities, but creating the data you need – or “faking it before you make it” – allows you to look within your organization and ask – “Do we have the data in the first place to solve this problem?” Because today, data subscriptions are just as lucrative as the applications they feed, and both can be subscription based.
4. Host Friday Pitch Days. I call this the Mad Men Carousel speech. Give everyone who has built a prototype five minutes to tell a panel – either executive or consumer-facing – about the problem, the analytical application to solve the problem and how it will pay for itself. The most important point is it must carry an emotional punch.
5. Monitor if it goes viral internally for three weeks. After you choose the best betas, give the team a week to refine and clean up, and release them internally to the wild. Do a write-up for your internal intranet and see if employees use them, share them or email feedback. If your own internal employees do not want to use the analytical applications you build, why would your customers and partners? When you hit a certain KPI for sharing, virality, then allow them to share outside the organization to partners, etc. Then monitor. This will tell you quickly if you have a winner or a loser. If you do not achieve the shares or uses that you wanted, mothball it and go after solving another problem.

Data science can be more art than science. And the greatest data scientists I ever worked with all seemed a bit mad in their own ways, but all were driven with the notion that one analytical application – just one – could change the world.

‘“Sanity is not statistical.”'― George Orwell, 1984