Once upon a time in a prior century I taught classes called "Strategic Business Analysis" and a modeling class on a combination of ERD, Function Hierarchy Diagram and CRUD matrices using Oracle Designer. I taught these as "requirements and understanding the business gathering", not designing a database. This worked so well that Oracle Designer could generate 95+ of a finished application, i.e. all of the grunt work.
ERD in particular was taught as a "thought discipline", with heavy focus on meaningful working of entities, attributes and particularly relationships.
A part of the offerings, I would hold an afternoon or evening session with the business and stakeholders using a group reading of their ERDs with heavy emphasis on speaking aloud the MAY BE, MUST BE of the relationships (ala Barker et alia).
That was what we called as "Business Analyst"; they may or may not have been database experts.
I got in hot water when working for Oracle on a very early clinical study application. I trained the nurses to read the, who the provide feedback to the Oracle consultants, who were not happy to have their work questioned.
I don't think such a position is very common these days.
I've only heard of these sorts of positions in heavily regulated places, where reporting something wrong creates substantial legal liabilities. And even then, they were mostly monitoring adherence to the law, not making sure people stuck to some internal standard.
Oct 27, 2023·edited Oct 27, 2023Liked by Benn Stancil
I have been wondering about this post for awhile now, and I still don't know how I'd like to chew on it.
There are a few sub-components that are probably worth addressing:
1) "We were at our best when we weren't just building dashboards and mechanically tracking metrics; we were at our best when we were given vague problems, well-sourced data, and the time and tools to go exploring."
If you asked me at heart whether I believed this, I'd still lean "YES!!". Part of the challenge is that "analytics" is emergent out of multiple cultural streams, but one of the dominant starting points of "analytics" IS consulting. McKinsey was originally a managerial accounting firm promising unique insights from balance-sheets. Even Frederick Taylor, the inventor of Industrial Engineering, was originally a consultant hawking an idea.
The investment in data analytics should (ideally) be used to bridge the strategy gap. (Now, it might not actually do so, but that still seems odd if true. As in, data is a strategic investment)
2) "And the panelists' point—that data projects are prone to failure, and don’t often deliver meaningful insights—wasn’t some bold new take"
This is also fairly interesting. Having been through a number of scenarios, I find that data projects inherit a lot of the problems of business projects & technology projects. Everything from every domain has to coordinate relatively well together.
That being said, and this is where I do have some wonder -- is FP&A supposed to go into the "analytics" category, or "accounting" category? FP&A (in my understanding) is a function dependent upon accounting, but with the analytical drive for strategic insights. It is NOT technically innovative, but it's not boring accounting.
If you told me that the future of analytics was FP&A, and that the future of data was accounting, then I don't see a huge concern. However, data as accounting without an FP&A dimension feels... odd to me?
3) "First, there may not actually be gold in a lot of those thar hills. Most of us may just have “moderately valuable datasets that can inspire moderate business improvements.” Second, finding meaning in data is very hard, as suggested by our continued insistence that most job candidates who are trained to do it actually can’t. Third, even if we do find something interesting, it’s hard and expensive to make it useful"
I'm definitely still curious on this bit. If you told me that everything could be solved without an analyst, then I could definitely believe that. The analogy in my head is a process redesign project; arguably "this project doesn't work right" doesn't require a data ecosystem, nor does "we should fix this manufacturing line as it is causing all of the problems", etc.
However, it's still true that you need to have people who can solve the people problems, and reason effectively, even if you work without a database. The tools aren't actually central, and 6 Sigma professionals and/or Industrial Engineers are still paid well even though they aren't in the "Data analytics" revolution.
-----------------
And just to get my head on straight, is this a disillusionment that "data is a magical & transformative force" or actually a statement that data SMEs are less helpful than Industrial Engineers & FP&A professionals?
I think I'm in the same camp that analytics work, at its best, is mostly consulting. I don't think that's always true - for places like analytics departments on sports teams, the job really is to use data to optimize some process or decision in a way that only data can. But for most companies, that's not really how decisions get made, or how their business works. The decisions are more consulting shaped. And in that, data is just one type of input, along with intuition, and qualitative research, and whatever else. And in those places, the value people can ad is being able to bring that type of input into the conversation.
And I think I agree with your comparison with FP&A? That seems like a good analogy - where data is a kind of general accounting, and analytics is a kind of general FP&A that extends it. That said, I don't think that quite answers what we as data people should be doing, because it's so broad. FP&A probably works because the people who do it know a lot about the various details of accounting, and finance, and stuff like that. I could see us following that pattern over time though, where people start specializing in various domains, and become "consultants" of sorts for that sort of problem.
On the third point, I'm kind of mixed here I think. I don't think we've historically done a good job of the drive-by type type of thing where data people are supposed to be the people who "reason well about problems" or whatever. That's really hard; we aren't all that good at it; and other people are already capable. So even if we are better than average, the gap isn't so high to make up for our lack of domain expertise, and the cost of adding more people to the process.
But the solution to that may also be specialization? Then we can be inserted a lot more easily, and the marginal edge in "good problem solving skills" becomes more useful. That, or we really do operate like consultants, and tend to be a little more formulaic in the way provide advice. Which I think is my answer to your final question: Data can be a magical and transformative force, but it's really hard to make it so. If we want everyone to have that magic, we've got to make the job easier somehow. (And I'd say that design is similar, actually. Companies that have great designers can do magical things because of it, both in what they build and in how their customers feel about them. It's just really hard to be that good at it, and not many people are.)
I think an interesting component of this conversation is that companies want to be different even in areas there is no reason to be. Market differentiation = necessary it’s the reason your still in business. Data differentiation - it can definitely be a differentiator for your business - no question. But just doing things differently for the sake of it - not helpful. As has been said by several authors in posts this week - when in doubt be boring.
I think there’s quietly a very smart point in here: So, *so* many startups feel like the way they need to win is through differentiation. It’s having a smarter angle to some problem, and being able to explain why they, ackshually, aren’t the same as anyone else in the market.
I think that’s often a huge miss. One, for the reason you said - differentiation isn’t needed. And two, and maybe even more importantly, it keeps companies from just saying, we’re going to be the competition by beating them straight up. We’re going to make a better product. We’re going to win by walking in their front door, not by sneaking in some window they don’t see. Too many startups are afraid of that challenge, I think .
YES! If I asked a founder of hot new startup - "What is your business strategy?" - NO ONE says - Well we are going to do the same thing as X... but in a more discipline and focused way. However I think there is AMPLE room for startups to do just that! Maybe startups need to take advice from football coaches. Interviewer: "Coach how are you going to win this game?" Coach: "Well, we just need to execute on the fundamentals and make sure we don't beat ourselves and play disciplined football with good fundamentals." And the difference between football and a startup -- in football you can't hide when your team plays poorly and looses. In a business - you can hide poor performance AND change the rules at the last minute to show how your team is ACTUALLY winning. :-)
Exactly, like, in sports, you expect coaches to just say, we're going to line up toe to toe, and beat them. Sure, you've got strategies and all that, but more often than not, you win by being the better team. (For small startup taking on Google or something, that probably doesn't exactly work; a high school basketball team isn't going to beat the Jazz by "being the better team." But I think that mentality often carries over when it's startup v startup.)
Yup - BUT a startup CAN pickoff a small part of what Google does and beat them at that. i.e. I think Superhuman found a spot where the Google email client are weak Or arc.net and the chrome browser. I don’t know how big either of those will get - but atleast enough to have a small or midsized niche.
Ah, good point, that's very true. And in that case, it makes even more sense to me to run right at it, and not try to be clever about how you're better.
Accounting has been around for 7,000 years. Double entry book keeping is a relatively recent discovery in the last 500+ years. Hopefully data teams will not take as long to coalesce on commonly observed patterns that work across domains and institute them as gospel to make subsequent generations of data teams boring.
Accounting/finance folk are often surprised when I tell them that w/ a bit of programming, sql, and tech training they could do most of my job. If only they knew....
I'd love a GAAP for DS, but I've been/am on projects to "standardize metrics" across a bunch of RELEATED product lines within the same megacorp and the lowest common denominator metric list is still very sad... Revenue/accounting stuff, basic 'success of flow/funnel" stuff, and some variation of customer acquisition/retention ... maybe that's already enough to get by, but past that it gets very hard to ignore the nuance *for product dev work*. Nuance in financials, which are probably as messy as DS metrics, can get footnoted away pretty regularly, but line managers aren't using those same metrics to make decisions either
Maybe that's an ok split? I don't necessarily think that we should limit everything we do to some standard thing (there are obviously lots of questions that would require exploration and novelty and all that), but it'd seem useful to have more consistency around the metrics that are intended to evaluate performance and benchmarking.
I guess to put it another way, my own ignorance about finance is somewhat instructive. I know only very basic stuff about accounting, but my assumptions are that they're rule based and consistent - and therefore, very reliable. If an accountant tells me something, I'm like, yeah, I guess that's what it is, no reason to argue.
Data folks don't seem to have that inherent trust. To create it, we seem to think about how we would create it to *convince ourselves,* with robust technical systems and all that. But we don't need to convince ourselves; we just need to convince others. And demonstrating that we are rigorous rule followers in some way - even if it's just sticking to the handbook on a few metrics or something - could go a long way in making people trust us the same way I believe in accountants.
I'm no expert in accounting either, tho I had to study bits of it early in my college days. The advantage accounting has over DS is that they've had a couple centuries of shenanigans and counter-shenanigans to learn to prevent obvious abuses. But even those guidelines have lots of gray area open to interpretation (and thus why accounting firms can command a lot of pay). Heck, in 2015ish, they updated the GAAP rules for one of the most fundamental questions in accounting, "when do you recognize revenue" : https://www.fasb.org/revrec . They're undoubtedly better than us at it and we should learn from them. But it's a fundamentally hard problem =D
Fair, and I'm sure lots of real accountants would be quick to point out that they aren't just rule followers, and a lot is open to interpretation (same with the law). But there's something in that mindset that I think is useful, whereas data people seem to want to be more inventive. Which can serve us well, at times, but I suspect causes a lot of problems.
"Most of us may just have 'moderately valuable datasets that can inspire moderate business improvements.'"
<<nodding head>>
Once upon a time in a prior century I taught classes called "Strategic Business Analysis" and a modeling class on a combination of ERD, Function Hierarchy Diagram and CRUD matrices using Oracle Designer. I taught these as "requirements and understanding the business gathering", not designing a database. This worked so well that Oracle Designer could generate 95+ of a finished application, i.e. all of the grunt work.
ERD in particular was taught as a "thought discipline", with heavy focus on meaningful working of entities, attributes and particularly relationships.
A part of the offerings, I would hold an afternoon or evening session with the business and stakeholders using a group reading of their ERDs with heavy emphasis on speaking aloud the MAY BE, MUST BE of the relationships (ala Barker et alia).
That was what we called as "Business Analyst"; they may or may not have been database experts.
I got in hot water when working for Oracle on a very early clinical study application. I trained the nurses to read the, who the provide feedback to the Oracle consultants, who were not happy to have their work questioned.
I don't think such a position is very common these days.
I've only heard of these sorts of positions in heavily regulated places, where reporting something wrong creates substantial legal liabilities. And even then, they were mostly monitoring adherence to the law, not making sure people stuck to some internal standard.
I have been wondering about this post for awhile now, and I still don't know how I'd like to chew on it.
There are a few sub-components that are probably worth addressing:
1) "We were at our best when we weren't just building dashboards and mechanically tracking metrics; we were at our best when we were given vague problems, well-sourced data, and the time and tools to go exploring."
If you asked me at heart whether I believed this, I'd still lean "YES!!". Part of the challenge is that "analytics" is emergent out of multiple cultural streams, but one of the dominant starting points of "analytics" IS consulting. McKinsey was originally a managerial accounting firm promising unique insights from balance-sheets. Even Frederick Taylor, the inventor of Industrial Engineering, was originally a consultant hawking an idea.
The investment in data analytics should (ideally) be used to bridge the strategy gap. (Now, it might not actually do so, but that still seems odd if true. As in, data is a strategic investment)
2) "And the panelists' point—that data projects are prone to failure, and don’t often deliver meaningful insights—wasn’t some bold new take"
This is also fairly interesting. Having been through a number of scenarios, I find that data projects inherit a lot of the problems of business projects & technology projects. Everything from every domain has to coordinate relatively well together.
That being said, and this is where I do have some wonder -- is FP&A supposed to go into the "analytics" category, or "accounting" category? FP&A (in my understanding) is a function dependent upon accounting, but with the analytical drive for strategic insights. It is NOT technically innovative, but it's not boring accounting.
If you told me that the future of analytics was FP&A, and that the future of data was accounting, then I don't see a huge concern. However, data as accounting without an FP&A dimension feels... odd to me?
3) "First, there may not actually be gold in a lot of those thar hills. Most of us may just have “moderately valuable datasets that can inspire moderate business improvements.” Second, finding meaning in data is very hard, as suggested by our continued insistence that most job candidates who are trained to do it actually can’t. Third, even if we do find something interesting, it’s hard and expensive to make it useful"
I'm definitely still curious on this bit. If you told me that everything could be solved without an analyst, then I could definitely believe that. The analogy in my head is a process redesign project; arguably "this project doesn't work right" doesn't require a data ecosystem, nor does "we should fix this manufacturing line as it is causing all of the problems", etc.
However, it's still true that you need to have people who can solve the people problems, and reason effectively, even if you work without a database. The tools aren't actually central, and 6 Sigma professionals and/or Industrial Engineers are still paid well even though they aren't in the "Data analytics" revolution.
-----------------
And just to get my head on straight, is this a disillusionment that "data is a magical & transformative force" or actually a statement that data SMEs are less helpful than Industrial Engineers & FP&A professionals?
I think I'm in the same camp that analytics work, at its best, is mostly consulting. I don't think that's always true - for places like analytics departments on sports teams, the job really is to use data to optimize some process or decision in a way that only data can. But for most companies, that's not really how decisions get made, or how their business works. The decisions are more consulting shaped. And in that, data is just one type of input, along with intuition, and qualitative research, and whatever else. And in those places, the value people can ad is being able to bring that type of input into the conversation.
And I think I agree with your comparison with FP&A? That seems like a good analogy - where data is a kind of general accounting, and analytics is a kind of general FP&A that extends it. That said, I don't think that quite answers what we as data people should be doing, because it's so broad. FP&A probably works because the people who do it know a lot about the various details of accounting, and finance, and stuff like that. I could see us following that pattern over time though, where people start specializing in various domains, and become "consultants" of sorts for that sort of problem.
On the third point, I'm kind of mixed here I think. I don't think we've historically done a good job of the drive-by type type of thing where data people are supposed to be the people who "reason well about problems" or whatever. That's really hard; we aren't all that good at it; and other people are already capable. So even if we are better than average, the gap isn't so high to make up for our lack of domain expertise, and the cost of adding more people to the process.
But the solution to that may also be specialization? Then we can be inserted a lot more easily, and the marginal edge in "good problem solving skills" becomes more useful. That, or we really do operate like consultants, and tend to be a little more formulaic in the way provide advice. Which I think is my answer to your final question: Data can be a magical and transformative force, but it's really hard to make it so. If we want everyone to have that magic, we've got to make the job easier somehow. (And I'd say that design is similar, actually. Companies that have great designers can do magical things because of it, both in what they build and in how their customers feel about them. It's just really hard to be that good at it, and not many people are.)
(sorry for the massive edit, I typed this out then had to copy & paste)
Why didn't you link the Alcaraz-Zverev point referenced? :-)
Ah, it's the first link in the footnote. This one: https://www.youtube.com/watch?v=uSaCK8xKWtI&t=77s
And now I've watched it five more times.
Ah, sorry missed that. Now I've watched it 5 times myself!
I think an interesting component of this conversation is that companies want to be different even in areas there is no reason to be. Market differentiation = necessary it’s the reason your still in business. Data differentiation - it can definitely be a differentiator for your business - no question. But just doing things differently for the sake of it - not helpful. As has been said by several authors in posts this week - when in doubt be boring.
I think there’s quietly a very smart point in here: So, *so* many startups feel like the way they need to win is through differentiation. It’s having a smarter angle to some problem, and being able to explain why they, ackshually, aren’t the same as anyone else in the market.
I think that’s often a huge miss. One, for the reason you said - differentiation isn’t needed. And two, and maybe even more importantly, it keeps companies from just saying, we’re going to be the competition by beating them straight up. We’re going to make a better product. We’re going to win by walking in their front door, not by sneaking in some window they don’t see. Too many startups are afraid of that challenge, I think .
YES! If I asked a founder of hot new startup - "What is your business strategy?" - NO ONE says - Well we are going to do the same thing as X... but in a more discipline and focused way. However I think there is AMPLE room for startups to do just that! Maybe startups need to take advice from football coaches. Interviewer: "Coach how are you going to win this game?" Coach: "Well, we just need to execute on the fundamentals and make sure we don't beat ourselves and play disciplined football with good fundamentals." And the difference between football and a startup -- in football you can't hide when your team plays poorly and looses. In a business - you can hide poor performance AND change the rules at the last minute to show how your team is ACTUALLY winning. :-)
Exactly, like, in sports, you expect coaches to just say, we're going to line up toe to toe, and beat them. Sure, you've got strategies and all that, but more often than not, you win by being the better team. (For small startup taking on Google or something, that probably doesn't exactly work; a high school basketball team isn't going to beat the Jazz by "being the better team." But I think that mentality often carries over when it's startup v startup.)
Yup - BUT a startup CAN pickoff a small part of what Google does and beat them at that. i.e. I think Superhuman found a spot where the Google email client are weak Or arc.net and the chrome browser. I don’t know how big either of those will get - but atleast enough to have a small or midsized niche.
Ah, good point, that's very true. And in that case, it makes even more sense to me to run right at it, and not try to be clever about how you're better.
Or as Olivia would say - doing it differently without a reason - “bad idea right?”
Accounting has been around for 7,000 years. Double entry book keeping is a relatively recent discovery in the last 500+ years. Hopefully data teams will not take as long to coalesce on commonly observed patterns that work across domains and institute them as gospel to make subsequent generations of data teams boring.
We mostly seem to go in circles reinventing old stuff that was cool ten years ago and lame five years ago, so our trajectory is not good.
As I always say, somehow we always return to the command line.
Accounting/finance folk are often surprised when I tell them that w/ a bit of programming, sql, and tech training they could do most of my job. If only they knew....
I'd love a GAAP for DS, but I've been/am on projects to "standardize metrics" across a bunch of RELEATED product lines within the same megacorp and the lowest common denominator metric list is still very sad... Revenue/accounting stuff, basic 'success of flow/funnel" stuff, and some variation of customer acquisition/retention ... maybe that's already enough to get by, but past that it gets very hard to ignore the nuance *for product dev work*. Nuance in financials, which are probably as messy as DS metrics, can get footnoted away pretty regularly, but line managers aren't using those same metrics to make decisions either
Maybe that's an ok split? I don't necessarily think that we should limit everything we do to some standard thing (there are obviously lots of questions that would require exploration and novelty and all that), but it'd seem useful to have more consistency around the metrics that are intended to evaluate performance and benchmarking.
I guess to put it another way, my own ignorance about finance is somewhat instructive. I know only very basic stuff about accounting, but my assumptions are that they're rule based and consistent - and therefore, very reliable. If an accountant tells me something, I'm like, yeah, I guess that's what it is, no reason to argue.
Data folks don't seem to have that inherent trust. To create it, we seem to think about how we would create it to *convince ourselves,* with robust technical systems and all that. But we don't need to convince ourselves; we just need to convince others. And demonstrating that we are rigorous rule followers in some way - even if it's just sticking to the handbook on a few metrics or something - could go a long way in making people trust us the same way I believe in accountants.
I'm no expert in accounting either, tho I had to study bits of it early in my college days. The advantage accounting has over DS is that they've had a couple centuries of shenanigans and counter-shenanigans to learn to prevent obvious abuses. But even those guidelines have lots of gray area open to interpretation (and thus why accounting firms can command a lot of pay). Heck, in 2015ish, they updated the GAAP rules for one of the most fundamental questions in accounting, "when do you recognize revenue" : https://www.fasb.org/revrec . They're undoubtedly better than us at it and we should learn from them. But it's a fundamentally hard problem =D
Fair, and I'm sure lots of real accountants would be quick to point out that they aren't just rule followers, and a lot is open to interpretation (same with the law). But there's something in that mindset that I think is useful, whereas data people seem to want to be more inventive. Which can serve us well, at times, but I suspect causes a lot of problems.