Glamour in Business Analytics

Or how mindset and attitude are most critical hiring criteria

If you need access to data, you usually go through some central entity. The department of Global Business Analytics. Their main skill is to be a guard keeper on who is allowed to send data, what data should be sent, how it’s transformed, and who has the right to gain access to data. Additionally, technical complexities around building on-premise data cubes required hiring highly skilled database and server admins.

It’s an exclusive club of professionals. They are in the center of the world. They are looked at in awe. Lines are queuing up every day to get a slice of their data for the next presentation to the CEO.

Business Analytics needs personalities who need this glamour.

There is an alternative way. Supported by technological advancement that make it easier to democratize data. Technologies that are cloud-based, focusing on ease of moving data, and delaying complex data transformation towards the end of the chain. And supported by organizations that believe in democratizing and decentralizing access to data.

It’s a way that removes the glamour from the Central Business Analytics team. It merely becomes an engineering team. Just like any other software engineering team. With technical challenges, interesting client interactions and a publicly visible roadmap to execute on. No glamour, no fuss, just work. Interesting and challenging work.

Embrace technology and start hiring for the right mindset.

The organization that shouldn’t exist

Or how to rethink your next org-chart.

Refactoring code is straight forward. I don’t have hard feelings deleting code. Potentially even enjoy it. This is different with organizations. While organizations must evolve, change and adopt, the speed and flexibility is still limited with regards to people.

So it’s critical that organizations that shouldn’t exists don’t start to exist. And I continue seeing it happening. And then people are surprised of a re-org once someone notices the problem. They are everywhere:

The software engineers maintaining a legacy system that are tasked to also re-invent the future instead of radically under-staffing the legacy system and truly focus on the future.

The DevOps team not believing in the company’s principles by holding on to a central, gate-keeping mindset and related staffing while it could focus on engineering, trust and enabling autonomous teams.

The project management office with a heavyweight, central quarterly planning process involving 10.000s of hours and imposing non-suitable processes to teams instead of working along simple principles and objectives leading to autonomously operating teams.

The system admins that believe in the past and continue hosting servers and building racks for virtual machines instead of embracing the cloud.

The security teams that continue purchasing expensive firewall hardware and worry about USB sticks being put into computers instead of following the more secure and lightweight zero-trust concept.

Embrace change. Be radical. Trust in people. Think of the future.

The show man

Or why the worst managers succeed.

There’s this kind of team in each company that everyone knows. Not because it’s a successful team. But because that team is famous for big escalations, production problems and an architecture that evolved badly with no way out of the mess.

And then there’s the manager of this team. Highly successful.

Why? Simple. He is the one who gets recognized by the customers.

He’s constantly visiting. Fighting fire. His weeks are turbulent. Full of de-escalations, workarounds, meetings. Resulting in an action plan and a promise to do better. He leaves for the weekend with a big thank you from the customer. In the end, he was the only one who was visible to the customer that week. And he’s the only one who gets mentioned in customer’s reports seen by the leadership team.

Two kinds of batteries

There are two kinds of batteries. Those that come fully charged and can be used once. And those that come half-charged and are meant to be used many times.

I was surprised those very same approaches exist for trust.

My world view assumed that trust starts neutral (or half-charged). You do good things together, and trust builds up. And it goes down when things go bad. Once you have charged the trust battery close to 100%, projects succeed, no matter what. If it’s down to 30% or less, projects start to fail.

Recently I learned from a close co-worker, that his world view assumes full trust at the start. That is, 100% charged. Everytime the other person screws up, it goes down a bit. Never up.

It’s useful to me to understand that this other world view exists. It’s also useful for those to understand that most others think differently.