In a recent episode of Data Chats, a podcast by Pragmatic Institute and The Data Incubator, host Chris Richardson interviews Ahmad Namini, a business analytics professor at Brandeis University, data analytics instructor at The Data Incubator and data instructor at Pragmatic Institute.
Chris and Ahmad discuss the structure and secrets of strong data teams and thriving data cultures. Ahmed outlines a strategic approach to taking a data team from good to great and what to look for when trying to hire data professionals, including the three types of data roles.
Editor’s Note: This conversation has been lightly edited and condensed for clarity.
Give us a big picture view of the data landscape.
Data is produced everywhere at all times under so many different conditions.
For example, if you are in the advertising field, you might wonder, “How are people interacting? What are they buying? What are they returning? What are they browsing?”
All of this is being captured.
My background is mainly in finance, and the field is geared toward things like what’s being traded and analyst reports. It could be textual, it could be a number, it could be a spike in prices that are telling a story. In finance, we call this a “signal.”
That signal means some kind of action, whether you buy or sell or hold or hedge against some uncertainty.
What I like to always say is, “Tell the story of your data and then figure out the action items.”
To make these signals actionable, business leaders have to truly understand the data and understand what it is not.
How you massage that data to make it operational is important too. For instance, in finance, if the data is stale and old, it has no meaning whatsoever, even though you captured it correctly.
I remember on Wall Street, we would get something like two terabytes of data per day. By the time we’d analyzed it and were able to make a decision on what to do, the opportunity was already lost. So what’s the point?
In business, you have to be able to understand your audience, your operations, whatever that you do. The data is a proxy for giving you something to measure and understand what you can manage.
There’s an old adage in business schools: “You could only manage what you can measure.” I think that’s an important concept.
If you were to make an ideal data team for a general business, what kind of roles and what kind of responsibilities would be most important?
There are three forms: data engineer, data analyst and data scientist. Unfortunately, they all are generic terms, but here’s the gist of what I am looking for in each role.
Data Engineer
A data engineer is a person trying to make sure that the information flow is happening. They’re typically software development types. They build what’s called data pipelines where they capture data from a specific source.
It comes into their corporation, then they have to clean it and find what’s missing. Data is archived and sent downstream.
Data Analyst
The data analysts can now take that data and discern some kind of business or actionable intelligence from all of that data.
Data Scientist
The data scientists are more theoretical. If you have a data project that’s rather involved, they may take existing models and modules that everybody has and fine-tune it to something more specific.
The goal is to have that teamwork in a group environment where everybody understands each other’s roles. This strategy means there is a workflow and the end product should generate some kind of edge in the marketplace.
That edge in business could be profits, it could be better compliance recognition and so forth.
To be a good data scientist, you have to know what data analysts do. And both of them have to understand what a data engineer does.
I would strongly urge all three of them to interact with each other.
Most data projects fail or don’t deliver what they say they will. Why or where do we see problems in that data pipeline?
I would honestly say it comes down to two words: “managing expectations.” Everybody nowadays believes that data science and machine learning, in general, can solve everybody’s problems. It’s just not true.
The first reaction to capturing data is, “We got something. Where is the outcome, the money or profit?”
But, the right approach is deciding if the data that exists answers the questions being asked at the business leadership level. Then, if you get an answer, does it make sense, and what are the logistics of putting the information to work?
Managing expectations is the key. It’s doing a deep dive into what the data is. What story is it telling me?
Based upon the expectation of a business leader, will you be able to create an edge or some kind of profit from this insight. If the answer is yes, then it’s perfect because you’re getting the right kind of metrics.
The other big problem is that it’s not easy to formulate and communicate between business leaders that are thinking about the business and the data science pipeline because sometimes they don’t talk the same language.
One thing that I would strongly urge is that the data professionals work with business professionals and vice versa because they have to understand each other.
Data people should understand the business domain knowledge. If you’re in finance, you have to understand finance. If you’re in insurance, you have to understand insurance. If you’re in marketing, you have to understand the market. You just have to find a way to understand each other’s goals, constraints, problems and skills.
Ideally, you have a broad range of interdisciplinary knowledge, but what’s a practical way to get that type of training without investing in multiple degrees?
The bottom line is that you’ve got to have a culture that wants that kind of interaction. I found that any form of networking, gatherings or just getting people in the same room from different disciplines is a great thing. You want that kind of cross-fertilization. That culture breeds interactions and new thoughts.
I’m a hands-on coder, which meant I could talk to coders, but then I also understood the theoretical aspects of quantitative analysis on finance. People like to work with me, but that’s mainly because I like to work with them. So I don’t know if I have the answer, but I would say that developing the culture that breeds that kind of interaction is the key.
If you are part of a hiring committee, and you want to create a data culture, what kind of characteristics would you recommend?
I personally think that skill set is by far the most important, but so is natural curiosity.
The people in the data science pipeline have to be able to code, understand statistics and utilize algorithms. In this field, skill sets are constantly changing, and you also need someone who isn’t satisfied with what they know now. There’s always going to be something new in technology, especially in machine learning.
Business domain knowledge is also key. Just because I’m a data scientist or a data engineer or a data analyst. It doesn’t mean I can divorce myself from the concept of what the corporation is trying to do.
There are two models when we discuss the concept of culture. One is distributed across the firm. You have a few data engineers and data scientists sprinkled throughout the business. The second is data professionals are autonomous and you have to schedule time with them.
I really liked the first one better where they’re part of the business. I think every company is different, but I just want to say you have to have that kind of interaction and you want them to learn the business domain knowledge.
What steps or processes would you put in place to help a team go from good to amazing?
Being from finance, the salary structures are that you get a base and then a bonus. That always works because, if you do well, then you’re going to make money.
You have to produce. People love to be incentivized and also congratulated for a job well done. If they’re not doing a good job, then do they need something to actually help them do a better job, more resources or more training. Every time that I had a review, I loved it because it made me see where I was good and where I was bad. To understand clearly how to make myself better.
We hear phrases like, “fail better,” and the idea that you learn from failure. How can you actually put that concept into practice?
I’ve found that working with technical people in general, they realize that doing everything right all the time is extraordinarily difficult. Things are just too complex with too many moving parts.
The beauty with data is you’re going to get answers, so that’s not failure. You’re just getting a point of view from the data you’ve collected, analyzed and presented, which can then be used by the decision-makers.
If you find out that the premise of the project made it impossible for data to give you answers. That is not a failure. That’s an understanding that you couldn’t have what you thought you wanted.
The best boss I ever had allowed us to fail on a small scale because we would learn from that. Once we understood what we did wrong or how we can become better, then we had a lot more capital, and that’s a financial way of thinking. By the time you get a big portfolio, in theory, you know what you’re doing.
If you’re taking on a small project and you can demonstrate success by producing something useful, then you’re given more of the responsibility and more of a say at the table.
I think that’s important and that’s really some kind of notoriety that you’ll gain within the firm, but failing is not a bad thing, it’s just gotta be on a scale that is manageable for the firm.
What two things would you give a data team to do tomorrow to make themselves better either on an individual or group level?
1. Learn the business
Understand what the CEO all the way down to your manager needs to accomplish. Learn what the layers are to achieve profitability.
2. Ask questions
Try to understand and propose new ways of using data that can help you.
* * *
Want to learn more? Check out our courses for individuals and teams at Pragmatic Data.
