The top 5 terms I have heard constantly in the last 12 months when it comes to the intersection of data, technology, and finance, are:
- Data governance
- Big data
- Data analytics
- Information management
I am going to pick on the first one, but the reality is that they are all intertwined. We have a lot of data in finance; it is an undisputed fact. For example, how many trades do you think happen on the NYSE in one day? On November 24, 2014 it was 2,622,543,626 purchases and sales. Let me emphasize that: over 2.6 billion transactions in a single trading day. 
How much data goes into support a single transaction? Take a glimpse here (and that is just a tiny subset). Multiply by 2.6 billion.
Now that we all agree there’s a lot of data in play here, just in one area of financial services, let’s go back to data governance and how to establish good data practices to support strong data governance.
The people you hire into your data governance practice can make or break you. They can do that in three ways: domain knowledge, technical knowledge, and people skills – we are going to talk about each of them.
Knowing about the right domain
The financial services industry cycles back and forth from one extreme to the other when it comes to the value of domain knowledge. Some months, we simply do not care about it, and we just want:
- The best technical talent (come one, come all data scientists!), or
- The smartest minds (what was your IQ derived from your SAT score, an exam you took potentially more than 10 years ago?), or
- The lowest cost (if we have 1,000 of a resource, we can make anything work, right? Widgets in, widgets out?)
After that seems to strike out, other months the pendulum swings to:
- x decades of experience in doing exactly the same thing at
- [fill in the blank] Big 4 consulting company at
- [fill in the blank] Bulge Bracket investment bank with
- [fill in the blank] name brand MBA (or MS or PhD or JD or…)
You get the picture. We are of split minds of what background will provide us strength and sanity to our burgeoning data governance needs.
Here’s the truth: domain knowledge matters. A lot, even, but it is not everything. You want someone who understands the micro (e.g. if in the legal document world, someone who understands the interlock of certain collateral provisions and default provisions) but also who understands the macro (why regulators care about the consistency of process and the availability/accessibility of data).
Well managed data can tell a story that weaves together a number of elements; the person you hire to help you tell that story should probably a) have one of their own and b) be able to do the same for your data and fit it together with how it impacts your clients and your business.
Getting back to that technical talent thing…
Yes, it matters, too. But you already know what I’m about to say, don’t you? It matters, but it definitely is not everything. You know why? If there is one take away you get here, remember this:
People use processes and tools to do work.
Technical talent is great, but just because someone programs in Java, Python, R, Perl, Node.js, et al. (they change, daily!), would you call that person a data scientist? No, not quite, being a scientist is not just doing. In fact, your best scientists are sometimes less about doing (they always find a grad assistant for that) and more about asking the right questions.
So, don’t make the assumption that someone having a bagful of technical tricks is synonymous with the skill and ability to lead a data governance function. Find some who understands data mining and analytics technologies; on occasion they may need to step up to the plate, but it is more important that they get the why (and when and where to use) versus the how.
Last but not least, we’ve always got people, people, people everywhere
I’m sorry, I said about if you took one thing away, it was the quote about people, processes, and tools, but I’m taking that back. If you really only talk one thing away from this article, let it be this quote:
More data governance programs, functions, goals, initiatives, and exercises fail because your “data masters” do not understand people.
I’m a data person and I can spend all day talking to other data people. We have a common language (see metadata, analytics, standardization, etc.). We understand the logical models; we have these analytics minds; we can parse bit from byte, data point from object.
But where many of my data colleagues fail is that we forget that 99.99% of the people who will hopefully benefit from our work may neither care nor understand what we do. We fail to put ourselves in the shoes of our consumers and so we design processes, we put forth recommendations, we communicate justifications, and sometimes we demand decisions, which ultimately fail because they ultimately do not resonate with the audience.
And then our feelings get hurt. We rail against our “audience”. We try to educate, but we rarely do it from the right place – we do it from a place of superiority.
So, you want the most important quality you should look for when building out a data governance team? Find people who get people. Find people who think about people. Find people who can translate the grandiose concepts, and even hubris, of data governance, into the common sense, day-to-day things that drive the day-to-day doings, front-to-back, of your financial services organization.
Goldilocks had it right
Do you remember the story of Goldilocks and the Three Beers? She ate all the porridge of the Wee Bear (because his was just the right temperature); she broke the chair of the Wee Bear (because his was just the right size); and then she took a nap in the Wee Bear’s bed (because it was just the right size).
Of course, she was caught, escaped and promised to be a good girl, but that is where our stories diverge right now; we can leave that part to the kids.
Data governance is almost like Goldilocks tramping through the cabin. Sometimes we try to do too much, too fast (too big a chair, too hot); sometimes we don’t fund the initiatives enough, giving it the right attention, support, and resources (the porridge is too cold; the bed too hard). It is not a one-size-fits-all endeavor.
When deciding when, where, and how to establish data governance in the modern financial institution, a couple of factors come into play:
- Do we have a history of change? How do we handle it? How accepting is the culture?
- Do we have people who can champion the value, folks who are doing the work, day-to-day, that will be come from the initiative? How do we get them onboard?
- Too fast, and we create chaos. Too slow, and it never gains traction. What is the right pace for this? What are the internal drivers or opportunities that exist to help this along? What are the external ones?
- Do I need data governance everywhere? (Probably, eventually!) Where do I start? What gets me the most benefit for the most reasonable costs? What is my real opportunity costs, beyond the numbers?
- Can we go the distance on this? Data governance is fundamental, radical change – are we willing to persevere as an organization through that fundamental, radical change?
Data governance is an evolving thing and we need to evolve with it
No company, big or small, will ever succeed from starting at chaos today to becoming The Circle tomorrow – nor should they want to! (Remember, that book was a cautionary tale)
Remember, two key things to help you along the way:
- Find the right people.
- Ask and answer the right questions before you start.
You tackle those and I’m sure you’ll give the goal of establishing data governance at your organization quite a good head start.
Article adapted from a shorter posting on LinkedIn.
 NYSE Market Data. http://www.nyxdata.com/Data-Products/Product-Summaries. Accessed Tue, Nov 25, 2014 at 1020 EDT.
Please share this with a friend or colleague who you know would benefit from it by using the buttons below.
Also, let’s start a conversation! Please comment below or send me an email at firstname.lastname@example.org.