Book Image

Building Analytics Teams

By : John K. Thompson
5 (1)
Book Image

Building Analytics Teams

5 (1)
By: John K. Thompson

Overview of this book

In Building Analytics Teams, John K. Thompson, with his 30+ years of experience and expertise, illustrates the fundamental concepts of building and managing a high-performance analytics team, including what to do, who to hire, projects to undertake, and what to avoid in the journey of building an analytically sound team. The core processes in creating an effective analytics team and the importance of the business decision-making life cycle are explored to help achieve initial and sustainable success. The book demonstrates the various traits of a successful and high-performing analytics team and then delineates the path to achieve this with insights on the mindset, advanced analytics models, and predictions based on data analytics. It also emphasizes the significance of the macro and micro processes required to evolve in response to rapidly changing business needs. The book dives into the methods and practices of managing, developing, and leading an analytics team. Once you've brought the team up to speed, the book explains how to govern executive expectations and select winning projects. By the end of this book, you will have acquired the knowledge to create an effective business analytics team and develop a production environment that delivers ongoing operational improvements for your organization.
Table of Contents (14 chapters)
12
Other Books You May Enjoy
13
Index

We are different

Over the past 37 years, as an observer of human behavior, I have learned a great deal about the people who are drawn to, and are good at, developing advanced analytics systems and environments.

Different in a good way

In the past five years, I have had firsthand experience of the failures I have discussed up close in companies as diverse as biopharmaceuticals, computer hardware/software, and research and consulting services. This is a widespread and ubiquitous problem.

I refer to myself, and the teams that I build and manage, as being "special snowflakes." I say this because it is evocative of the truth. In addition to being truthful, I say it because the differences we exhibit and embody are a very positive aspect of our personalities and the value that we deliver. The rest of the organization needs to know that these teams and individuals are different, and that difference can be, and is a source of power, change, and competitive advantage. These differences are not to be managed out or reduced; they are to be understood, nurtured, and employed for the greater good.

Each individual that I have hired over the years who has turned out to be a brilliant developer, programmer, data scientist, business analyst, system engineer, data engineer, or data architect has been an unusual or unique person.

The ugly duckling

I first encountered this dynamic over a decade ago. I was running the operations of a UK-based company. We had a staff member that did not get along well with the team, and not just one or two other people, but the entire staff in the location that he worked in. He was multiple levels down in the organization from my position, but it had been raised to my attention that the organization as a whole would prefer to, in British parlance, make this position and person redundant. To put it in the American vernacular, the team wanted him fired.

I met with him. We talked a few times and I realized that we had an emerging need in an area where this person had been taking night classes. He possessed early stage skills, a strong desire, and it appeared that he had an aptitude for the work that we needed to have done.

Working from home was not very common at the time, but his commute was inordinately long, and it was not productive to have him in the office. I proposed that he start to work from home, and that he begin, as a side project, to build what the company would need in the coming weeks and months, but not to tell anyone.

By this time, he had been transferred to me as a direct report. He and I agreed that he would continue with his existing duties, to see if he could and would be productive working from home, and we would collaborate on the side project.

He did not need to collaborate closely with anyone on his regular duties. He had to receive work, execute his work, and return the completed work to the team that delivered the input materials to him. He executed this work efficiently, effectively, and flawlessly. Also, he worked in the same mode with me on the side project.

When removed from the office and having his communication reduced to email and a few phone calls, his productivity soared. The idiosyncrasies that were the cause of the interpersonal difficulties were not an issue any longer.

One of the problems was that he would fall asleep at his desk in the office. People were put off by this and attributed it to him being lazy. As it turns out, he did his best work at night. I told him that I did not care if he worked all night and slept some of the day; as long as his work throughput, quality, and responsiveness were good, I had no issues with his schedule.

When the side project was complete, I presented it to the management team and included the staff members who were the most vocal proponents of this person being dismissed. The reviews were uniformly positive and unanimous that the work was good and that the group would be very happy to have this application, and platform, represent the brand and company in the market. The belief in the room was that this work was accomplished by an outsourced third party. When I announced that it was built by the staff member from his new side project while he worked at home, the reaction was a muted agreement that keeping him on staff and engaged was the right course of action.

After a couple years of this arrangement, he resigned. He had developed a small, one-man consultancy, offering his services to companies in the US, UK, and Europe. He worked from his house and was making significantly more money and seemed the happiest I had ever seen him. He went from being despised and derided to being a successful employee and eventually an entrepreneur.

He sent me an email a few years ago thanking me for seeing what others had not: his passion, skill, dedication, and drive to be a contributing member of the team. He was an outcast. He did not know how to ask for an environment that would allow him to flourish. And rather than looking for a way for him to be successful, the rest of the organization went about shunning him and making him feel incapable and unprofessional for how he looked and behaved.

This wasn't the only brilliant individual I've encountered during my time working in the world of business and analytics.

A diamond in the rough

I inherited a brilliant analyst when I took over a business unit of a large technology company. This person came to me after my first all-company meeting. In that meeting, I told the entire global operation that anyone could come to my office at any time to discuss any topic. I also explained that I came into the office early and usually caught up on email, communications, and projects before other team members arrived, but that I was open to having impromptu conversations at that time.

This person came in and explained that he had started out as a social worker, helping people through challenging situations in their lives. A few years before this conversation, he decided that he wanted to pursue a master's degree in social work. As part of his studies, he was required to take a class in introductory statistics. It turned out that he was a natural at math and statistics. He was unaware of this gift and talent. He explained that he had lived in the town where the company maintained its headquarters and that he had never travelled very far, but that he wanted to travel as much as possible.

I smiled and said, "Be careful what you ask for, we may able to give it to you."

Over the next year, this young man proved to be an invaluable staff member, due to the fact that he listened carefully to clients in all industries and of all levels of seniority and expertise, from senior executives to data scientists and business analysts who were both prospects and clients. He could translate what they described and needed into not only system specifications, but working prototypes quickly, easily, and accurately. He was amazing at his job. We had him on a plane each week, and he loved it. He travelled to Japan, Western and Eastern Europe, Canada, Mexico, and more.

His unique combination of empathy, math acumen, verbal, written, and presentation communication skills, comfort with uncertainty, lack of ego, and pure joy in helping people made him exceptionally successful. Of course, all of this comes with a unique set of personal needs and personality traits, but those idiosyncrasies made him who he is. He continues to be a valued employee, a reliable person, and a contributing member of the team and his community.

Ideal traits

In both the preceding vignettes, the majority of managers would not have seen the synthesis of skills and traits as being diamonds in the rough. When they both came to me, they had been sidelined and pigeonholed as a "type" of person. That was wrong, and it was a disservice to both and the value that they could and did bring to the respective companies and clients.

For the most part, individuals who are adept at building analytical environments possess or exhibit the following characteristics:

  • Optimistic yet skeptical
  • Intensely curious
  • Mostly introverted
  • Logical
  • A combination of left and right brain orientation at the same time
  • Intelligent
  • Self-critical
  • Prone to perfection
  • Social, but reserved
  • In some cases, they appear to exhibit a lack of focus or possibly too much focus

Managing a high-performing analytics team is a unique endeavor. Such teams need solid guidance, but, in general, do not react well to micromanagement.

Management by a non-practitioner or novice typically ends in failure. Managing a team that is building advanced analytics environments is not the same as managing a typical information technology project. Many firms fail in the organizational design phase of building an analytics team. Organizations and managers often fail to realize that managing a group of analytics professionals is more similar to managing a group of creative professionals than it is to managing a group of programmers. We will talk more about this in Chapter 2, Building an Analytics Team.

A common mistake

The great majority of non-technical people, and I include corporate executives in this category, think and believe that a technical resource is the same regardless of whether they are developing transactional systems (for example, Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and so on), business intelligence, dashboards, or artificial intelligence applications.

Executives, across a wide range of industries, tend to think and act as if any technical resource is interchangeable with any other. And part of this problem stems from the fact that they see technical people as resources. They do not understand, and for the most part, do not try to understand, the nuances of the various differences between the skillsets, motivations, and intrinsic interests of individuals who possess technical talent. This mindset and view is patently false, and it is one that causes companies around the world to waste millions, if not billions, of dollars each year.

A partial cause of this situation is that the technology function is a relatively new addition to the corporate structure. Think of accounting, manufacturing, sales, and distribution.

These functions have been in organizational structures for millennia. No competent executive would say that we can take a top performing sales professional and put them in accounting. It sounds ludicrous to even say it.

But, given that the technology function has been part of the corporate environment for less than 80 years, we hear nonsensical statements like, "We can take the developers who created the CRM system and have them build the artificial intelligence system for predictive maintenance." This is a ridiculous idea that is bound to fail, but I have had senior executives, across several industries, say this exact thing to me and believe this is a reasonable statement or question. They truly believe that they know what they are talking about.

Part of this lack of understanding comes from the fact that senior executives know that the technology function is relatively new, and it is different, but they do not want to know how or why it is different. They are willing to delve into the intricacies of international tax policy or transfer pricing, but ask them to dive into the details of how an artificial intelligence system will revolutionize manufacturing or supply chain operations, and that topic is not worth the intellectual energy to understand at a deep and functional level. That is for the "technical people."

This problem is not limited to a lack of understanding of the composition of project teams, but also a lack of the skills, experience, and expertise needed to manage teams that are tasked with building advanced analytics systems. Again, senior management sees a person who has managed the implementation of an enterprise system like a business intelligence environment and/or application, and they assign them to build a self-healing supply chain management platform. A grave error.

Obscured vision

These mistaken beliefs and the decisions made about hiring, organizing, and undertaking advanced analytics projects dooms a substantial percentage of efforts to fail before those projects have even started. And the disappointing fact is that the executives who have made these mistakes have no idea that they have set the project on the road to failure, even before any funds have been spent or a single person hired. And at the end of the failed projects, those executives will lay the blame at the feet of the technology, or the technical team or the outsourcing partner or all of them, but little to no cause for failure will be attributed to their lack of leadership or understanding of what was to be undertaken or accomplished.

I see this today in companies that has decided to place advanced analytics teams in the individual functional and operational areas around the world. The idea sounds rational, and the approach appears to be justified, and it can be, but it takes a deep understanding of the business and the analytical applications and technologies that will be applied. There are precious few people in this organization that understand the triumvirate of business requirements, technical skills, and solution development/application. What has happened in this specific instance is that managers have hired people who professed to have, but in reality, do not possess the technical and business skills to competently approach the solution development process. The disconnect between the business operators, the newly hired data scientists and analysts, and the hiring managers have delivered almost no results in the set timeframe.

When leaders and managers allow this kind of rudderless environment to be built or to develop, data scientists resign and move on.

The hiring managers are confused as to why they couldn't manage these projects, just like they did other, seemingly similar, projects, and the executives grumble that the teams did not deliver the promised return. A powerful mix of failure, frustration, and resentment ensues.

It is difficult to see the problems clearly from the individual perspectives of the players involved, but when you take a view with a bit of distance, it is easy to see that the projects undertaken in this approach had a very small chance of succeeding.

Given that we have outlined where we can see pitfalls in the strategic direction set for analytics teams and groups, let's examine the optimal organizational structure and where the analytics function and team should fit into the overall company.