What happens when you believe in unicorns? Part 1

Let me tell you a story about this guy down in Iowa. He is one of the best Business Intelligence developers (and friends) I know!

He has worked building Business Intelligence solutions for more than a decade. He can sit down with business partners, listen, challenge them, quickly build a mockup to solve their needs and see the future, and then execute on building that solution. Business partners at all levels love working with him. He is a true go to person. He is the true definition of a Business Intelligence unicorn and builds some of the best solutions I have ever seen (thanks for being an inspiration Dean)!

In BI and Data Science literature, Venn diagrams such as the one below are en vogue. All you really have to do is make people experts at every aspect and that is how you build a unicorn team member. They are very rare (or do not exist). Surely if they do, it takes decades of experience like my friend above to become such a rare creature. Lots of literature, and how we practice in reality, is we divvy up the responsibilities. We need a Business Analyst to do requirements, we need a Project Manager to run the project, we need Data and UI developer(s) to build the solutions, and on and on it goes.

Even though every leader I have ever worked with supports team member development, the idea of building people up to unicorn status seems like the holy grail. Often I hear:

Well that is just unrealistic! We can't expect people to do that. They just won't be able to (insert new skills here).

What if I told you that in six months time you could build unicorns within your team? Yes - you. Will they be Dean level unicorns from the story above - not yet! However, they will be well on their way and I guarantee they will be running laps around some people that have been working in the BI industry for decades.

A concept burned into my brain was introduced by Rob Collie of powerpivotpro.com. He describes communication, mostly on requirements, as the dark matter adding cost/time/frustration in your business intelligence projects. His lens is through how a consulting firm works, however the concept applies to internal teams as well (which I often compare to a small consulting firm). He describes almost in a joking manner how efficient it is to communicate with yourself! The less people that need to be involved in a solution build out, the shorter the game of telephone. This is where the magic lies - minimizing the number of humans needed by rounding out peoples skill sets.

In order to do this - you need to expand your beliefs in a few areas, and lose some of your legacy mindset.

What if BA's/Designers could build solutions?

This type of unicorn is often easier to build. Let me introduce you to another friend on mine -Dubay. He started his career translating technical manuals from English to Italian. He has a degree in Anthropology. When I met him, he was interested in the data space and was in a more traditional business analyst role. His tools of choice were - you guessed it - Excel and Access. Surely all he can build is crazy Rube Goldberg solutions right?! Matt was nudged to use some newer tools, in new ways, and yes within about 3 to 4 months was part of building one of the best BI solutions I have ever seen.

I hate to be the guy that says tools will fix a problem, however by definition - tools, used in very deliberate ways, fix problems! This whole concept is still driven by people changing who they are, and what they do. The nice thing is, the data & business intelligence tool industry is certainly making our job easier.

Many of the tools in the upper right of the Gartner Magic Quadrant are REALLY easy to learn and become proficient in - even if you do not have a technical background.

I would challenge you to find a willing business analyst, or simply a business person, give them a specific challenge to solve, and put a tool in their hands (Tableau, PowerBI, Qlikview, etc) - and I bet you will see a unicorn start to expose itself!

Can you lock them in a closet to do it on their own - no. However with some minor coaching, direction, and encouragement, or a little time with one of your more technical unicorns, they will be well down the path.

The beautiful thing about this creature is - they already have that elusive skill of “understanding the business”. Outside of tools making this unicorn more accessible, the habit side is also easier as they often come to the table with less experience in building solutions. Therefore, they do not have years of muscle memory within themselves that they need to move past. Thanks to Dan, Nate, Andrew, Laura, and countless others that uncovered this type of unicorn for me!

What if developers could do requirements?

I know - this is crazy talk. However, I wanted to introduce you to another friend of mine. Super technical guy, understood things WAY over my head, and often rubbed our business partners the wrong way. But then, on a new project he incorporated a new UI framework/template that was used to put lanes on the road, and frame the conversation with the business. Those mockups quickly turned into real solutions, that iterated and matured very quickly. The end state - a happy business partner with 4 or 5 highly interactive solutions that really propelled them forward from a data driven perspective. All of the solutions looked, and functioned very similarly. They were not super sexy from a visualization perspective, but paid attention to the fundamentals and encouraged the business to "swim" in the data.

You know you have found this unicorn in training when they say “the business never knows what they want”. I am a firm believer that people do not know what they want until they see what they want - so you just need to make this part easier.

What makes this group a bit trickier is their muscle memory is quite strong. They have probably worked in a position where a BA was there to do requirements, or maybe that was even required per the process. They are often used to a more classical method of development:

1. Gather requirements (this is one person or a set of people)

2. Acquire / simplify data via ETL (this is another person or a set of people)

3. Build a UI to spec

Furthermore, they are likely VERY good at the above process & building solutions in this way if they have done it for years - however they are being held back from their awesome.

What is crazy to watch is when someone in this area starts working just a bit differently - often via a design first approach - and pure magic starts to happen. They can often build REALLY fast, and if they get started doing their own templated designs as requirements - then you simply get out out of the way. These are often the best folks at coming up with new architectural patterns that can be followed by the first group to really accelerate the team en masse.

Dean - who I mentioned in the intro fits into this type of person - highly technical and also leans heavily on mockups early in the process.

All I can say is if you get a crazy technical / architectural brain good at the business & requirements side - watch out!!! Thanks to Dean, Big Dan, and Pankaj to name a few, that taught me about this special kind of creature.

In the end, what makes a good coach?

Thinking about this article, the people I have been priveleged to work with now and in the past - it makes me cherish the great teachers, mentors, leaders (independent of hierarchy), and people that have inspired me. It makes me think about my two little girls - and my dreams for them. And all in all, it got me asking people I know and myself:

What makes a good coach?

Here is what it boiled down to for me, and many others based on my informal survey:

1. You must always see the potential in people

2. You have to have a short term memory and always look forward. "There is always next" as Dean tells me

3. As a leader it is about their journey - the people you are blessed to coach - not yours

4. The magic is in coaching not just the individual, but also the team. The compound effects of this taking hold at the team level are insane.

5. Not improving is not an option. Each person and the team at large should get better every day, every week, every month - even if just a little. Those small improvements make a huge difference in the long run

6. Details matter

Will you get everyone - nope! However what if you get 20% of the team. How about 50% or 60%? What if the whole team is suited up in their unicorn costumes! Also, even if you get JUST ONE person, believe me it is worth it.

Stay tuned for part 2, where we will dig into tactical steps you can take to build your very own unicorn development program!