How to Build a Data Organization — Your Must-Have Building Blocks

The Chief Data Officer is still one of the newest C-suite titles. Many organizations are wondering how to hire and organize a data management program. I have had the privilege of developing leading data management programs for a number of organizations and have been asked to consult on the formation of others.

In this article, I will share what I have learned with the broader community —  What positions need to be filled? What to look for in the hunt for talent? And how to organize those hired?

What is a CDO?

A few years ago, I was in a meeting with a fairly new CDO and some other people. He explained how he got the position, “I was called into my boss’s office, and he said, ‘We need a CDO, and I’d like you to fill that role.’”

The newly appointed CDO replied, “What’s a CDO?”

Few CDOs have such a funny story to tell of their hiring, but many come into the position in a similarly random way. If you are one of those people or are thinking of hiring a CDO or a Chief Data Officer job description, you may find this section useful.

I have observed three types of CDO: the manager CDO, the technical CDO, and the all-purpose CDO.

A manager CDO has far more management experience than hands-on experience in managing data but is excellent at organizing things and keeping track of all that needs to be done. It is assumed that the manager CDO can leave the technical work to experts on his/her staff.

This is where things get interesting. Occasions will arise where the technical experts disagree with each other and the CDO will need to act as a tiebreaker. This can’t be done by the flip of the coin because making the wrong choice can often be disastrous for your program and the larger organization that depends so heavily on good data.

Enter the technical Deputy CDO — The technical Deputy CDO will be the one to make the tiebreaker calls. He/she should have greater knowledge and experience than anyone else on the data staff. If you are a manager CDO, make sure to team up with a good technical Deputy CDO.

The technical CDO has extensive hands-on experience and some management experience. Although not as natural a manager as the management CDO, any CDO must have some management experience.

A common mistake is to think that a person who has extensive experience managing technology is a technical expert, perhaps by osmosis. Experienced managers of technology, who have spent their entire careers managing, are management CDOs.

Just as in the case of the management CDO, the technical CDO may want to team up with a deputy with complementary skills. Some technical CDOs are just not excited about managing things. They would prefer spending their time devising the organization’s data strategy, mentoring, and coaching the technical staff.

Finally, the all-purpose CDO is one with the interests and skills to manage, govern, and make critical technical decisions.

Data architects, data scientists, and data librarians

These positions group together because they have something in common. None of them are easily found, ready-made, on the street. You have to hire them based on analytic aptitude and then train them.

The nature of the training is important.  Data science and data management are still emerging fields and misconceptions abound.  I’ll explain in some detail in a subsequent article.

How do you know if someone has analytic aptitude? The assessment is based on their education and hands-on experience. Suitable education and experience include computer science, mathematics, engineering, and the physical sciences.

Experience as an analyst is a big plus. Analysts get close contact time with the good and the bad of data systems as well as the customers of their analytic products. A good portion of my own ideas came from working as an analyst.

Terminology varies, but here I define the data architect’s role as being similar to that of the CDO, except at the division level. The CDO will be more focused on setting policy whereas the architect will be more focused on implementation. An alternative title for the Data Architect is Division CDO.

Data librarians have two roles, curation of the data and assisting users in finding and understanding. This is not much different from the librarian in a physical library.

The data scientist term has generated a lot of confusion. It is often used to describe a talented analyst who also knows how to program in Python. But of course, that person is still an analyst. A true data scientist is an expert not only in analytics but also in database design, data system design, and metadata management.

The problem with renaming our analysts as data scientists is that it causes confusion and can lead to the neglect of important work. It causes confusion because people wonder how the data scientist differs from an analyst. Are data scientists new and improved analysts? In what way are they improved?

The data scientist as an analyst can also be part of a larger dysfunction. I have known organizations where the data management program was entirely about analytics, ignoring all that comes before the analysis. We all know the familiar phrase, “Garbage in, garbage out.”

Enlightened database design, data system design, and metadata management are what make your data the substrate for powerful and accurate analytics. The data scientist must be the creator of great data, not just the consumer.

Analysts and database administrators

Unlike data architects, data scientists, and data librarians, good analysts and database administrators can be found ready-made. Analytics is a well-established field with a long history and database administrators have been around since there have been databases, going back to the 1960’s.

The role of the analyst needs little explanation, but it is important to note that analytics is the final stage of a longer process of collecting, processing, documenting, and structuring the data. A good analysis is not possible without all the data management that comes before it.

This is not always understood, and I have seen data management programs fail because the entire effort consisted of analytics, which the organization already had.

Database administrators will oversee the operation of your database management systems, their updates, and permissions, while the data librarians curate the contents.

The most common hiring mistake

Everyone wants to feel special and so do organizations. So, when hiring data experts most organizations’ data officer job descriptions or announcements are full of requirements pertaining to the subject matter of their organization.

Banks want finance experience, healthcare companies want medical experience, defense contractors want defense experience, etc.

In my experience, most of the best data experts come into an organization with absolutely no subject matter experience whatsoever. How can this be?  There are three reasons:

First of all, your data is not as unique as you think. In fact, everyone’s data issues are very similar, and whatever is specific can be learned very quickly by the best data people. What very rarely happens is a subject matter expert in some other area becoming an expert in data.

Second, by opening up the pool of candidates beyond those rare people who are data geniuses and who also have years of experience in your subject matter, your odds of finding the right talent are greatly increased.

Finally, I often see members of an organization stare at a problem for decades, without resolution. Then someone with a fresh set of eyes solves that problem in a matter of months.  You need new blood.

So, the uniqueness of your data is not what is going to make your organization great,  but hiring the right data team just might.

Organizing your team

Once you have a great team, how do you organize them?  There is more than one way of course. Here I will share a particular organization chart (org chart) that works well and explain why.  You can adapt it to your organization’s unique needs.

The most common org chart question is, “Where do we put the CDO?” Perhaps my data professional bias is showing, but you don’t want the CDO buried too low in the chart. The reason for this is that your greatest challenges will be in the area of cultural change rather than technical.

Leading cultural change requires considerable authority. Place your CDO directly under your CEO, along with your CIO. The Deputy CDO reports to the CDO and stands in for him/her as needed, as well as complementing the CDO’s skill set.

The CDO has a staff of direct reporting data professionals who create any required enterprise data systems. They also write policy.

As for the Data Architects, they report to the CDO. They can even be called Division CDOs. Don’t be stingy with titles, because you don’t want to make people or the data program seem unimportant. The remaining staff report to the Data Architects / Division CDOs.

The Data Architects may also report to their division heads, but this sometimes leads to a fragmentation of the data program and a lack of policy compliance. The  Data Architect structure can be repeated in multiple layers for very large organizations.

Last but not least is the Data Governance Council. These are the data stakeholders. The purpose of the Council is to act as a bottom-up and top-down communication channel. It is bottom-up in the sense that the stakeholders have a place to report their requirements. It is top-down in the sense that the CDO has a place to disseminate enterprise strategy and policy. The CDO chairs the Council.

The Council is not a voting body because the design-by-committee does not produce coherent results. As the name suggests, the Council provides wise counsel to the CDO in terms of policy contents and requirements.

Conclusion

Talent is a primary driver for the success of any organization, and this is especially true for data management where high levels of analytic aptitude and training are required. If your organization is like most, you will need an org chart that enables cultural change, leadership, and the contributions of all your stakeholders. I hope these key factors will help you on your journey to data greatness.

About the author:

Dr. Mark Brady is currently Deputy Chief Data Officer of the Office of the Undersecretary of Defense Research & Engineering / TRMC and Senior Manager at KBR.

A world-class expert in data management, he has served as Chief Data Officer for the Space Force, Chief Data Officer for the Air Force Space Command, Data Architect for The DOJ, and Information Architect for the National Marine Fisheries Service.

He also helped establishe electronic trade standards as U.S. delegate to the United Nations, served on the White House Data Cabinet, and the National Oceanic and Atmospheric Administration’s Big Data Council.

Prior to his federal service he conducted basic scientific research in neuroscience;taught neuroscience and statistics;conducted industrial R&D in artificial intelligence, software, medical electronics, traffic management, electrophoresis, and mathematical modeling for automotive geometry. He is an inventor and author, with a number of patents from this work in industry.