 Hello everyone and welcome. My name is Eric Fransen, stepping in today for Shannon Kemp, who is on vacation this week. We would like to thank you for joining this month's installment of the Monthly Dataversity Webinar Series, CDO Vision. This month, Tony Shaw is joined by guest speaker Anthony Algmin, who will discuss getting started as a CDO. A couple of points to get us started due to the large number of people that attend these sessions. You will be muted during the webinar. For questions, we will be collecting them via the Q and A box in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag CDO vision. All one word. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the webinar. Now, let me introduce our speakers for today. Anthony Algmin is the Chief Data Officer at the Chicago Transit Authority and was previously a data governance managing consultant RGP with deep experience in technology and business disciplines. Prior to joining RGP in 2014, Anthony served as the data governance practice lead for another strategy and management consulting firm in Chicago. He also spent over 12 years in the financial industry performing technology development and leadership roles for data warehousing, business intelligence, trading, accounting, and back office operations. Anthony frequently speaks at national and local events contributing thought leadership to the data governance and information management communities. Anthony has a BA from Illinois Wesleyan University and an MBA from Northwestern University. And moderating today's discussion is Dataversity's own CEO, Tony Shaw. Tony is, of course, responsible for the business strategy of the company and its subsidiaries, including Dataversity.net, all of which conduct educational conferences, training, and publishing activities focused in the area of enterprise data management. And with that, I will turn things over to Tony to get us started. Hello and welcome. Thanks a lot, Eric. With both of you who've done this for a long time, you'll know that Eric and I have been colleagues for many years. And so it's a pleasure to work with him again today on the webinar program. I'm particularly delighted to be welcoming Anthony Alderman today. I'm going to be referring to a presentation that Anthony did a couple of weeks ago at the data governance quality conference in San Diego, and we're going to borrow some of the slides from that presentation to provoke our conversation today. But we're mostly going to be conducting this session in kind of an interview format. But the slides will give us a useful prop for some of that conversation. I think you're all in for a treat over the next hour because Anthony's a lively and amusing personality and which is one of the reasons I invited him to participate with us today. So Anthony, good to have you with us. Why don't we start just with a little context, talk about the CTA, and let's start there. Sure. Tony, thanks for having me. I'm excited to be here today. And I think from the Chicago Transit Authority, I mean, we do the buses and the trains in the city of Chicago and some surrounding communities. We can trace our routes back about 150 years. There's around 11,000 total people in the organization with over a billion-dollar budget, not including capital expenditures. And I think that just to kind of level-set in the kind of organization that we have here, we have an organization that is doing a lot of things with heavy assets, with moving stuff around and have a lot of different systems with a lot of different kinds of data and has generally been operated in those silos. So we have separate operations departments and planning departments. And a lot of the information is kind of self-contained within those units and those different units, those different systems do their job and do their job as well. But there is a relatively early in the maturity cycle of enterprise data. And so they knew back, you know, a year ago, I guess it was now, that they needed to do something with data in more of an enterprise capacity. And we're looking to kind of bring on this capability from the outside and bringing in a person to lead that and growing up a group that can do more of those kinds of things, but didn't necessarily have a real deep vision of exactly how that needed to manifest. And I think as I came in, I came in after they had been struggling with that problem for about six months, and I came in as a consultant in my previous firm at RGP. And over time, after spending about four months as a consultant, we ended up deciding to kind of convert that position to a full-time role because they found that the kind of ideas that we were able to develop while I was here and the kind of insight that I brought to the problems that they had were exactly what they were looking for. And so I think that, you know, I had the opportunity, and it's a unique story in the way I came into the organization, but I think that hopefully the lessons that this organization has learned throughout this process will hopefully be things that people listening in today can apply to their own organizations and careers as well. Terrific. Well, we'll get into a lot of those questions shortly. You mentioned it's a heavy industry, heavy machinery organization. I just love this slide from the presentation with that racket of drill bits there. Those are some scary-sized pieces of equipment. Yeah, so I love this slide. So all these slides, and we're only going to show a few of them today, but I tried to bring in some pictures of some things that the CTA that people may not always have had access to see before. So this picture was one I took on a tour of the shop that fixes trains, and some of those drill bits, the big ones at the top, are literally the size of an arm. And I didn't see the drill that those go into, but I'm sure that would be even more scary. So this was one of the first slides you showed during your presentation in San Diego, and I thought it would be useful for you just to review these points because they do provide a context for your perspective on some of the other questions we'll be looking at. So why don't you just run through these three points here? Definitely. So keep in mind that the context of this presentation was really around being a chief data officer, becoming a chief data officer, and I thought that for the people that might be in that room, they may be thinking, how do I become a chief data officer? And that's really what my first point is, is that that's not necessarily the question you want to be asking yourself. It's not a solution looking for how do I do that. It's really the best place for a chief data officer is when that's exactly the answer to the problems at hand. And in our organization at CTA, it was the answer to the problems at hand because they really needed something to kind of string together the different data capabilities that they had in these small silos and have a group focused solely on amplifying those business capabilities that data can help drive in a very kind of universal way throughout the enterprise. And so that's really what I'm getting at, is don't think about, like, how do we get a CDO into this organization? Think about, does my organization need a chief data officer? And I'll kind of talk about some situations in a little bit where they may not, where a chief data officer may not be necessary. So the second point is really around, the chief data officer is not an IT job. First and foremost, like I just mentioned, we amplify business capabilities through data. So data and, you know, information technology, too. I mean, it's all about helping folks in a business do that business better. I go so far as to say the only value of data and data analytics is in the difference of what your business can do with it versus what it can do without it. It's in that differential is the only place that us as a data analytics group can really gauge our success, because otherwise we could produce a whole bunch of stuff, but even if it's interesting, and even if it's heavily used by people in the business, it may not be meaningful, may not be worth investing in because it's not actually driving business value. So it's really important to focus on that business side first, even though, in my third point, I come back to say, hey, the CDO is an IT job, because ultimately you're leveraging technology, you're leveraging that technology-amplifying power to do those things. And in another presentation I gave not too long ago where I kind of posited that instead of thinking of data as an asset, as something that just has math and sits somewhere with inertia and all that, think of data more as energy. Data is a thing that you can apply to a situation to make something happen. It's a change agent. And that is really what our data analytics group and what my role is all about in our organization is to be a change agent for the organization as a whole to figure out how can we be better at doing the buses, doing the trains, serving the people of Chicago and the outlying communities, and the best way possible, leveraging the data and insights we can get from the data throughout our organization. Well, I found myself quoting you later in the day during one of the panel sessions on three or four occasions, both from that opening slide as well as from this one. So again, it's from a contextual standpoint. I think some of these questions are really interesting to get your answers on. So why don't I also invite you just to run through this slide here and give us your perspective on some of these questions. Why are CDOs a thing right now? Right. So I think that in the role of the chief data officer, so the way I originally structured this slide was me asking the people in the room to comment on that. We don't have a forum right now where we can do that, so I'll give you my answers to it. So the role of the chief data officer in my mind is to be the kind of business advocate side of the IT coin. So it's more saying I don't think in a lot of cases our information technology organizations are as in tune with the business as they would like to be or have resource availability to be. And I think as if I'm focused solely or not necessarily solely, but very heavily on what are the business implications of everything that we're doing, I can be a proxy to the business in an effective way as it comes to data and IT strategy and tactics within an organization, how it influences projects, how it influences a queue of different things. So I think that the chief data officer is really about being a partner and we'll talk about some organizational structure things in a little bit, but I think it's about being a partner to the IT organization and representing the business and the business interests in that and being able to do so and converse in a language that is familiar to everyone within the IT realm and then can be disseminated back out on the business side as well. And I think it's really being that kind of translation agent to IT, but also having that kind of vision of what's really important to the business and representing that as well. And obviously I think this role has always been important. I think it's something that we are now seeing and I think if we look at that box on the bottom, it's really about the prominence of the importance is becoming greater and greater because of the capabilities of technology, because of the capabilities of data. If we're thinking about what we can do with these tools and the amplification or the energy that we can direct now is bigger and bigger and bigger with these kinds of massively powerful tools, if we don't get our calibration correct, then we're going to shoot it in the wrong spot. We're going to mishit what we're aiming for and we're doing it with ever bigger guns. And so I think that's really what it's about is to kind of take all of this potential and make sure we're aligning it properly to the business at hand. And so that's really what the organizations can do with a Chief Data Officer and a functioning data analytics group is to apply to learn all of these new capabilities and link them effectively to the business and really interact and take collaboration between information technology or between technology-enabled groups and business-focused ones and make that as powerful as possible and really bring to those collaboration sessions and understanding that we may have certain capabilities as a data analytics group where we can do kinds of analysis or we can build an enterprise warehouse or we can do these kinds of visualizations and things like that, but they're not going to get us too far even if we're trying to do our best on behalf of the business to do the things that are going to impact the business most. You know who knows who is going to impact or what's going to impact the business most? It's the business. And that's really where you're having a conversation where you're really listening and really collaborating as opposed to talking at one another through requirements documents or things like that, which in the large-scale IT types of programs, it's really difficult to get the kind of collaboration that we would like because the projects are so massive and the number of players and the kind of small slices of the overall insight available are spread among so many people. In a data world, in a data analytics world, if we can understand the real business needs and we have some really business-focused people in our data analytics group, if we can do that and then appreciate what's going on for the business, we can do a lot more than we could if we were just saying, hey, business, tell us what kind of data analytics you want and we'll build it for you. That's going to break down. And I think that having these kinds of separate entities give us another shot at getting that kind of collaboration right. And so a Chief Data Officer position, really going to solve our problems, this is when I start really getting on my soapbox if you didn't think I was there already. It may be. It may solve our problems if you get the right people and the right vision and the right type of thing in place. But if you just say, hey, I'm going to give somebody a Chief Data Officer title and hope they can figure it all out, that's not going to be really effective. The position, the title, none of that stuff is as important as the function that they perform. And I think one of the challenges that we have with Chief Data Officers is that we've created this new kind of role and in so many different businesses, it takes on such a different flavor that when you hear somebody's a Chief Data Officer, you don't even know what that means. And even us as the experts in what Chief Data Officers should be, we don't even have general agreement yet. And it's going to take time. It's the same thing that happened with Chief Information Officers or other C-level positions or any position. What does data scientists mean? We're going through a similar kind of evolution with that position as well. So ultimately, I'll just read my bottom point here, that data analytics capabilities are becoming more important, but our current organizations are poorly suited to building and connecting the business to these capabilities. So hopefully I've provided a little bit of context to what I mean in that box, but I think hopefully that comes through. So I guess that means that the answer to the question about how do you get started as a Chief Data Officer is going to be different in every case. But why don't we tell us a little bit about your role. So you started as the CDO of the Chicago Transit Authority in March of this year, which in CDO terms is maybe longer than many of the ones that are currently in that role, because I don't think there are many who've had the position for more than a couple of years at this point. Can you describe how the CTA decided that they wanted to have the CDO role and why they ultimately appointed you to the job? Yeah, I will try to do justice to this. I can't fully speak on the decision-makers because I was outside of some of that as a consultant. But I think I was brought in as a consultant to help them figure out how to solve these data challenges, where they knew there were things that they wanted to do with data or things that they were struggling with in terms of gaining insight into their own business that they knew there had to be a better way. And so as a consultant, I came in and started learning what were the challenges. And one of the big ones was around our FAIR system. There was kind of an infamous project that was done and a new FAIR system called Ventra that was released a couple of years ago. And there have been problems with it. There was a lot of issues with the rollout and then there's been lingering problems that have been somewhat public-facing and others that have been more internal in terms of our operations and the way we can work with it. And one of the challenges with that was around data. And the CTA didn't have full database-level access to that data. And so one of the things that we did while I was here as a consultant is we started getting that data in and doing something with it. And I think that as we started to gain some wins there, because I am coming back to your original question, as we started gaining some wins there and starting to show, hey, here's how we can derive some value from this data and here's a platform that we can put it in and here's how people can connect to it. And we started solving problems that had been lingering for a couple years. They said, hey, Anthony, why don't you come in and direct this group and do this stuff? And I said, okay, I'm interested in this and in these challenges, there are certainly ones we're solving and that I would be proud to help in any way I could. But the way they were originally approaching the position was at a director level, which would probably have not rolled up through IT directly, but I felt that would put them in a difficult position and in terms of the way the organization here is pretty hierarchical, that a director level is going to report up through other departments. And what I felt was in something where you're trying to do so many things in a new way, that group would be very challenged to be successful when they're beholden to some other group. Plus, it's kind of difficult to remain independent if you are reporting up through, say, a financial organization or IT or whatever. So there's always limited resources, there's a lot of politics and all of that. And so I said, we can have two conversations because they kept asking if I would be interested and I said we can have a couple conversations. The first is around what to see. In my opinion, as a consultant and doing the best I can for you is what I think this group really needs to be successful. And it was really around trying to make sure the CTA who saw there was some great leadership knew there was a problem with having trouble either hiring the right person for it or putting their finger on exactly how to structure that group and the way to make them successful. I wanted to help them with that first and I said, hey, let's talk about that. And then subsequently, or if you agree or if we decide that this is the way you want to help structure that, if you think I might still be a candidate for that, we can talk about that separately. But I wanted to make sure that the decision to do the right thing wasn't done in a conflict of interest scenario where I was saying, oh, I wanted to be a Chief Data Officer so that's the only thing I'm interested in. I wanted to make sure that first and foremost, my client did the right thing in creating a group that could be successful and then if they felt I could be successful helping to lead that group, then so much the better. And that's kind of the way it all panned out. We had some conversations around it. We said, this is how it should be structured, the way the position ended up falling out was, my position sits at the same level of the organization in terms of hierarchy as the CIO. So she's up here and a great partner of mine. And we really see eye to eye on a lot of the strategy going forward, but it allows my group to have the independence to do the things that we feel is best versus having to go up through and compete with specific resources that are allocated to IT as a whole, for example, or in some other area. And I think that as we've seen over the last few months and I think my team would concur with that, that independence has really helped us move things along in many ways, whereas otherwise things could have gotten bogged down and old ways of doing certain things. So I think that that's been very useful. And right now I report up through the Chief Internal Auditor who has both audit. I think of it kind of as a professional services type of consulting type organization where he's kind of the lead partner that has both the accounting and auditing wing under him as well as the consulting wing, even though we don't have the actual accounting group here that's often finance, but he has that kind of dual role. And I think that fits for now, but we've had talks where we're kind of in this incubation period where we're still growing up the team, we're still getting kind of our sea legs. Eventually we're going to move this out of audit and hopefully have it reporting directly into the president's office somewhere because then the audit group would maintain full independence and would be able to audit our activities as well. Right now there would be a conflict of interest and we'd have to go externally for full audits of our group. So that's kind of where we are right now, but it was because of the specifics of the situation that eventually led us to that path. We didn't have the endpoint fully in mind as we worked through it. That's how we got to it, yeah. Sure. So I'm going to ask you to just explore in a minute how the CDR role is defined vis-a-vis the CIR role, but before we do that, I just want to invite folks for a session today. If you have questions, type them in the Q&A box on the bottom right of your WebEx screen. We will take questions as they arise. If you have something, we'll also leave you some time at the end of the session to go through a little bit. You mentioned that your position is on the same level in the organization as the CIO. How is two-year-olds demarcated, please? Yeah, so the way I consider it is, you know, the CIO has a pretty enormous organization and is really doing a lot for the individual source systems, the systems that eventually provide data to our kind of analytics world, but also are doing much of the work of the CTA. I mean, she has the Oracle ERP platform, as well as countless other systems that are doing things for the buses and trains and facilities management and operations. All of these things are, you know, relatively discrete systems, but there are so many of them, they share various resources across the IT organization to keep maintained, to ensure that there's, you know, maintenance schedules, to make sure that they're supported properly and all of those things. So she's got her work really cut out for, and I think that it kind of is a good example of why it can be very difficult to create the kind of group that we have within the context of an IT organization because by comparison, our role as change agents in the organization is, you know, when it comes to data analytics, the thing that I think about is anything, as soon as we're looking at doing analysis around things that have already happened, or we need to bring data together between multiple different systems, or that we have a kind of specific request for information that can be fed to a business unit, or we need to be able to provide, you know, an interactive tool to get to a bunch of different kinds of information. It's about taking certain things that have patterns of consistency among those different individual systems, but mostly when you bring them together, the kinds of analysis, the kinds of capabilities you may need to look at across different data sets, that's where my team really gets involved. It's really around saying, okay, how can we, from an enterprise perspective, leverage information and make our business better, which is a really fundamentally different kind of role than the much more operations-focused role that most IT organizations are consumed by. And I say in a speech recently, you know, is how many IT organizations have the resources that they need to do what they need to do. I haven't found one yet, you know, and so they're always just trying to keep things secure. I mean, I work very closely with our Chief Information Security Officer, who sits in IT, and, you know, there's a million great ideas that he has that, you know, we have to pick and choose our spots very carefully in what we can actually fund. And that kind of operations mentality is crucial to be successful in an IT organization. And in our organization and data analytics, it's really around saying, what can we build new that can amplify the things that already are existing in those systems where we can get the most value of them however possible. And that's, I think, really where that kind of good partnership between myself and the CIO allows us to do some great things that neither one of us could do on our own. You know, I'm able to kind of build some new stuff without being encumbered by some of the keeping the lights on work that has to be done, and she's able to allow us to kind of go out there and test new things and bring new capabilities into the organization that she just doesn't have the resource headroom to be able to take on while there's so many other things that need to be addressed just from a keeping everything going perspective as well. Okay, so we have a small flurry of questions here related to structure. I'll dwell on those just for a minute. So one question is, given a company with data functions that are fragmented across the organization and not meeting business needs, how do you think an organization can gain awareness that it needs to bring those functions together with a chief data officer role to improve those capabilities of managing and leveraging data? That's an interesting question, and I can talk about it from the perspective of I don't like building a huge process before getting something done. And I also think about there are enormous amounts of data analytics capabilities throughout the CTA that have no formal tie-in with the data analytics group. And so I think from my perspective, there's an opportunity if you're creating a centralized group that's focused on data analytics, you have a big challenge in getting people to understand what it is you intend to do with that group. And I think you want to start showing what capabilities you can drive, but recognize that those data folks throughout your organization exist for a reason. And if you can create a data analytics group that has an ability to amplify their own capabilities throughout the organization, or if you pulled some of them into that group, it's finding a way that you can create things that add even more business value than they were able to do on their own and can be applied throughout the rest of the organization. I think it's an efficiency play where you say, hey, if you have a group where an individual is doing all this data analytics stuff and you have another group where another individual is doing very similar but with a different data set, there's synergies there. There's an ability to do things more efficiently. So that could be part of your business case to senior leadership. And one of the things, and we would get to it no matter what, but it's really around the effectiveness, the efficiency of these different groups and of the people that you have. And if you don't have the executive sponsorship or the executives that say, hey, we see the inefficiencies in this business or you can't convince them of that, then you're going to have a really tough time filling a chief data officer role. The chief data officer role is a culmination of a bunch of understanding, not a put it in place and hope they figure it out later. Thanks. So you've been referring a lot to analytics as you're describing your role, but in some organizations, the primary responsibility and the governance and quality and just sort of getting data into a... Can you define your role a little bit from the emphasis analytics versus other functions like governance? Okay. So my job as a consultant before I came to the CTA was in large part to build data governance practices to execute data governance and related projects, you know, metadata management, data quality and things like that. So I am no stranger to data governance. And I joke now because now that I'm in a position where it's largely my mandate to make sure we're doing data governance, I don't want to buy the thing that I used to sell. And that puts me in a precarious position because I don't want to be hypocritical about things, but at the same rate, I want to be very pragmatic about the resources that I'm applying. And so the way I look at governance and some of the kind of that DAMA framework thing, which I think is incredibly valuable, is that I'm trying to apply those layers in a kind of just-in-time manner. So because we're setting new precedents, we're building new capabilities, I'm trying to establish some good practices aligned with those first so that we can then use that as a seed to the rest of the organization. So this is not going to be applicable in a lot of organizations because you'll already have some sort of data governance or some sort of formalized quality or metadata or master data types of programs. We didn't have any of that at the CTA, so I'm growing all of that stuff as well. And the last thing I'm going to do is put a lot of my limited resources into a large umbrella of data governance to govern everything I might encounter down the road. I'm first going to make sure that I'm building something of value and then I'm governing it appropriately as that maturity continues to increase, the number of people it involves continues to increase. One of the areas of governance that we're really actively working on right now is how we're managing the security and the access permissions to various parts of our ever-growing cloud environment. So we're doing a lot of analytics in the AWS platform, specifically Redshift. And so this has never been done in the organization before everything's encrypted and compressed and we're getting enormous performance out of it. But because we have this sandbox, which is ultimately infinitely scalable, we need to make sure that as it infinitely scales, we haven't set a bad precedent in terms of how we assign access rights or how we secure different things or how we make sure things are always encrypted or any of that stuff. So those are the areas that I'm making sure that I and my team have the right policies around. So we self-govern. And then as more and more folks are impacted by what we're building, we're going to make sure that those governance policies apply to them as well. But right now we're in such a kind of start-up, build-it mentality that the governance aspects are kind of secondary. But I mean, I had a meeting specifically around metadata management with one of the people on my team this morning because now that we've got something, we need to make sure we're really documenting it appropriately and governing it, especially as it continues to grow very quickly. So I think it's taking that just in time, making sure that at every step, it's an agile mentality where at every step, deliver value. Make sure that the next thing that your team does is going to have an immediate impact to whatever your equivalent is to putting buses and trains out in service. That ultimately is how you got to govern where you apply any resources from a strategic perspective. Okay. So there's a couple of questions submitted around roles, which we'll get to in just a minute. And before we do, you mentioned that DAMA framework thing. You're probably referring to the DAMA DM box, the Body and Knowledge document. Yes. Which is available at dama.org for anybody who's interested in following up on that. Somebody had also asked about educational resources earlier. I assumed that you would include the DM box as part of the educational resources you'd recommend. And we might also return to that question a little bit later. So I've brought forward another of the slides that you presented in San Diego in your data analytics framework. And I'm going to suggest that you address this at the moment, and then we can come back to a couple of these questions about roles. So just take it through the framework that's on the screen right now. Absolutely. So I think it's a good lead-in to talk about, because I assume that some of the folks on this call are going to have that familiarity with the DM box. And that is definitely what I was referring to. I think it's a wonderful reference architecture for data types of use. I use it heavily as a consultant. I use it heavily now. But what I wanted to do was to make something like if you need something that's a good reference architecture, that's great. If you need a sleep aid, that's also great if you try to read that cover to cover. And so what I wanted to do was come up with a way that's a little bit more accessible for less data-focused individuals to understand what in the world we're trying to do. And that's where we came up with this data analytics framework. And so the first step, and so if you look at the full screen, the ultimate goal here, like we've talked about already, is business impact. It's what can you do with it versus what can you do without it. And knowing that is really ultimately the end. But if I'm trying to drive business impact, there's a few things that have to happen before I have a hope of making the impact that I desire. So the first thing, and this has been much of our focus, is around availability, data availability. It's I can't do much with data if I can't get to it. So like our fair system where much of the data was resident with the vendor, we had to get it so that we could access it, so we could make it available, so we could start to see where is valid, where might it not be right, where might there be information that we didn't even know we were getting. Starting to look at that from just get people access to it so they can start doing what they do best and bringing their business knowledge to bear on what that data is. If we lock data so down with a bunch of database administrators or data developers that aren't really bringing it forward to the business, we're missing a great opportunity. So once we have available data, the next focus is on understanding from a quality perspective what do we need to do with that data or how good does that data need to be to drive the things we want to do from a business impact perspective. And I wrote a whole white paper at my old consulting firm around strategic data quality and the bottom line of that is to say, hey we have, a lot of organizations have this mentality that if the data is not perfect then it's wrong and we've always got to be going for perfection. And I said that's crazy because A, you're never going to get there. It's never gotten there. You could always go to another layer of precision. You could always do something more to make it better. And frankly, nobody has enough resources to do that and so if we do that when some data we're just going to end up not looking at anything with some other data that's really important too. So what I've said is hey, understand the quality threshold. So how good of a data quality do you need to make the decision or to drive the activity that you need to do? And if you need 80% quality, however you want to measure it or however you want to assign a score to it, I don't care, but come up with what that is and know, hey, do I have enough? Do I not have enough? How important is the decision that we're trying to make? And be strategic about how you apply those resources and the limited resources to improving quality in the right places. If you make something 90% quality that only needs to be 80% to drive a decision, then you've wasted energy. You've wasted resources that could have been applied to something else. So really think about that. Push back on a business and say hey, if you're a marketing department, you really need to know 90% whether or not these people are writing the train to work or whether they're writing a train to a social gathering. Could you make a good marketing decision with 60% knowledge or 70% knowledge? What is that threshold? So then if you've gone through that exercise on any given amount of data, then adoption may occur. So the whole point is if you're going to build it, build something that people want to use. So it's necessary but not sufficient that people find it useful and interesting. It's absolutely critical to business impact that they find it useful and interesting. They could still get no business impact out of it if they find it useful and interesting. But you've got to at least get that. So the adoption is all around that useful and interesting thing. Are people going to use what we're building for them? Do they think it's going to impact the business in the end? So making sure that you're calibrating at every step and using this as kind of a building box approach to realize the next one doesn't happen without the one in front of it, and ultimately nothing's of value unless we make all the way to business impact. And so that's where I much rather take a smaller data set, drive it all the way to business impact, and then add to it versus spending the next 12 months building the best enterprise data warehouse, driving no actual adoption or quality over those 12 months, trying to do everything at once, and then hoping I'll flip a switch and miraculously transform the business. I just don't believe in that. And this analytics framework kind of comes from my core beliefs and how you should go about adding value to an organization through data. Okay. So we're going to come back to this question about roles and organizational structure. And I want to preface your remarks just by saying that when John Lively and I did some research seven or eight months ago around the role of the CDO, we found a vast difference in the size of CDO organizations, partly because they were so young. A lot of CDO quote-unquote organizations start out as one person as a pilot project, and then second year in, they start to get some budget and some personnel. Others start out with numerous people right away, but everyone is different. So I think, to Anthony's earlier point about along some more lines, it's a little dangerous to sort of use one size fits all for every organization. But, Anthony, why don't you talk about the organization that you have at the CTA? In particular, what are the key roles and functions that report to you? What sort of job functions do you have on your team? Give us some perspective. Sure. So I definitely agree with everything you said. And in our organization, like I mentioned before, we have a very much a start-up mentality where we know we're kind of growing this organically, and it's so core to strategy of the organization that it's something, too, that you've got to be very careful in where you outsource it, especially in terms of the leadership positions. So in my organization in particular, and keep in mind, we've doubled in size in the three months that I've been there. We're currently leveraging some contracted resources, but are hopefully going to transition more of those to full-time positions. They're operating in a full-time capacity right now. So we'll just talk about them as roles on the team, because I think that's the most useful. So right now, I have a total of six people reporting up to me. And the first is a senior manager who is incredibly connected with the business. He's been around the CTA for a year and a half, and has really been a key player in understanding some of the very deep needs of the fair system side, as well as being very much engaged on the various business-facing aspects of data throughout the organization. He's an incredible resource and kind of leads, on a day-to-day basis, the activities of the team as a whole. He brings more of that business side than the technology side. I also have one person who's a contractor who is a kind of very senior business analyst. He does a lot of our special projects and is currently helping to lead from a data perspective a large effort, almost the same size as a fair system rollout, but it's all internal around a lot of our operations capabilities with a new platform that's going in to replace many systems that we've relied on in the past. Then we have a data scientist who's leading a lot of our efforts around reporting and some business intelligence, creating some models for our supply chain group, as well as assisting in a variety of other capacities. And then two data analysts who are kind of more, are traditional like BI analysts, reporting analysts who are creating a lot of reports, doing a lot of the kind of regular reporting, as we're building up more sophisticated capabilities. They're kind of the glue that holds a lot of the things together. Once we build them, they make sure that we're getting them out to people in a consistent manner. Then we're starting to have a consistent service delivery of data services and offerings to the organization. They make a lot of that go on. And then the final person is a person who is really our one technical lead other than myself. He is a senior AWS architect developer, and he really has done an incredible job helping us operationalize a lot of the stuff that I originally built as a consultant in our Amazon AWS and Redshift platform. So he's really focused on automation. We're doing a lot of the data loads from our FAIR system. They're completely automated now. He's adding a bunch of capabilities and helping to lead us as we bring in a visualization tool. From the technical perspective. So that's kind of where we are right now. I think we're looking at bringing in a project manager and agile coach position. That's one that we have on our short list of things that we're trying to bring into the team immediately. We'd also be looking at bringing on some additional data developer and AWS developer type of roles. And I would say just if others out there find themselves going the AWS route, it's very difficult in the marketplace to find people with specified AWS talent. I find that a lot of BI focused individuals that have background in the Microsoft stack, I find that that skill set translates pretty well to what they're doing in the Redshift environment and some of their RDS stuff, especially if they have a little bit of like Python programming and things like that. You may not find an AWS developer out there, but you may be able to find some people whose skills are really transferable and that may be able to be available at a lower price point than somebody who has a lot of dedicated AWS experience because the platforms just haven't been out there that long to get enough experience out in the marketplace. Okay. And just for anybody who's not familiar, AWS of course is Amazon Web Services and Redshift is their data warehouse product. It's a reasonable summary of that. Okay. So we have some other questions about tools and structure. I'm going to skip over the tool ones for now because they're not quite as relevant to the topic we're dealing with today, but maybe we can deal with those in some of our follow-up. And as we only have 15 minutes left, I want to invite anybody who does have questions to try to get those in now because we have a short backlog here. I had a question which might provide some context to some of these other queries that people have. How is your workload or the projects that you work on determined? Do you come up with them as CEOs and down a wish list? How do you decide what you're going to work on? And I think you've touched on part of the issue why we want to bring in some more agile practices to the team. Is that right now, because we're kind of the start-up mentality, we're moving in a million directions at once and it's difficult for me to be fully transparent and even know to some extent exactly what everybody's working on at any given time and be able to kind of report up the chain of command what it is that our team is focused on. I articulate priorities. I share them both to my superiors as well as to my team and make sure that they understand what it is that are the most important things that we're focusing on right now. But I want to get to a point where we can measure productivity better and performance against those priorities because there's not, without some process, it's difficult to calibrate. So that is a constant challenge for us and I think part of it that's helped is that we have a daily stand-up where we talk about everything that's been going on yesterday, things that we're going to do today and any blockers that we have, which is kind of a very basic agile practice, but I think we need a little bit more maturity there before that really takes on. But I think that the point is that as a data analytics group and in the kind of level of maturity that we are, we're constantly being derailed, sorry, no pun intended, from what we had planned on doing to take on some more immediate project of the day or changing priorities. And so having that flexibility while still being responsive to our set priorities, that's a constant challenge and it's getting more and more difficult as our team continues to grow. So I don't know that I have a great answer for that. I'd kind of like to ask others in the group if they have some advice in terms of how to do that. Okay. There is a question also about the relationship between your office and either data governance councils or steering committees or data stewards within the business. Do those exist within the CTA and do you have a relationship with them? Yeah. So we don't have a formal data governance council or body with that name to it, but we do have some senior leadership groups that we are engaging with to make sure that what we're doing, our priorities and kind of the vision and strategy going forward align with the organizational interests and making sure that we're responsive. And so we have a loose group of a kind of a data advisory group is really what it is, but we have pretty good autonomy otherwise to make sure that as long as we're aligning and communicating effectively what we're doing and what our priorities as we see them are, we've found that that's been pretty effective, but it's something that we're looking to formalize more and more as we continue to mature. And as what we're producing, we've been so focused on this development side. We've now kind of turned a corner in that we're now bringing forward a lot of the capabilities to others in the organization, and I think it's going to be more and more important to help make sure the other senior leaders know, hey, these are the kinds of things that your group may benefit from. Let's make sure we're engaging everywhere appropriate to leverage these capabilities wherever we can in the organization. Again, it's something where we're in that relatively early maturity point where we haven't had that level of interaction and the organization just hasn't had those groups existing before, and in some cases we're creating those groups as part of that maturing process. Yeah, that was another of the things that John and I found in talking to people is that oftentimes the CDO role or organization evolves quite rapidly over the first year or so of its existence, and the structure can change, the priorities can change as everybody who is inside and outside that organization kind of figures out what works and what doesn't. There are a couple of other questions here about the tools, including DMBock and the CMMI data maturity model. I'm going to ask those questioners to be patient. We'll try to get to them at the end, but another slide I really want Anthony to address as we get close to our time, which is what sort of lessons has he learned so far? Anthony, why don't you take us through this final slide here? Right. In some of these we've touched on. The first nobody really knows what a chief data officer does until you tell them. It's a new position, right? It's different in every organization, and when you have this role in an organization like the CTA where a lot of things are pretty regimented and very traditional, people are just confused, and I think that it's up to you to determine what that position means in your organization, and then a key piece of that, and a key piece of being successful in that role, is to make sure you communicate effectively and market the value that you're adding to those in the organization, because it's true of any role, really, even if people think they know what that person does, we tend to oversimplify the things we don't fully understand, unless we've been there and had that role and done that in that organization, there's probably a lot of things we don't really understand about it. So it's on us as CDOs to make sure that people understand what it is that we're focused on, what it is that we're doing, and how we can help them, really. Until you do that, people are going to think you're coming in and, hey, now all data analytics must go through the data analytics organization, and that's not the case. Until you realize, hey, I'm an advocate for what you're doing. I'm here to help amplify what you're doing, and if we work together, I might be able to save you four hours of data manipulation and let you do twice as much analysis than the kinds of things that you're doing, and that only comes from being able to connect with people and start to understand and have empathy for what it is and the challenges that they have. I mean, I think if there was a number one skill that you would need as a chief data officer, it's empathy. It's really care about making the business better, making people's lives easier, making it easier for them to do the things they need to do, because I know I can go help our planning group or our performance management group in enormous ways, but there is no chance that I could do as good of a job as they could do at planning or at performance management, and so it's knowing that and recognizing that my role here is as an assistant, not as a dominator of anything. That's really the important thing. Now that said, the point around not being afraid to rock the boat is, hey, I'm in a very old organization that has a lot of things that are pretty set in their way, and I've been told and been very much given the mandate that I have to be a change agent in this organization, and the only way to do that is to push people and get them a little bit outside of their comfort zone, and recognize that sometimes in being that business amplifier, I may be amplifying things that shouldn't, you know, people would rather not have amplified, and that's where you've got to be judicious and knowing where to pick your spots, because, you know, if you try to change everything all at once and, you know, even though you work with people, you have to recognize that sometimes there are removable objects in some organizations or things that have enough inertia that it may be better to just work around them than to try to push them through, and that's really what picture battles accordingly is about. But they'll always collaborate, sometimes compromise, but never betray your values. It's really important to me, like, there are certain things that I think are the right way, and there are certain things that I think I know are the right way, and there are things that I can't ethically bring myself to do otherwise. And it's making sure that though I want to compromise, though I want to work with folks and make sure that there's good ways ahead, as a leader sometimes I have to know, is this something that I want to do, or is this something that is essential to do, either because of its need that's coming from the business or because it's ethically the only answer to a certain circumstance. And as you get into these leadership roles where there's not someone telling you what's right and wrong, necessarily, you have to have that conviction and you have to be able to say, hey, I know this is the right way. I can't betray my values and go against that, especially as you're trying to build some new capabilities. But then two, like once you get to position, don't change too much, and that can be read two ways intentionally. One is whatever got you there, keep doing. You know, don't become a different person because you have a Chief Data Officer title and people might look at you a little bit differently than they used to. You'll recognize that if you've been successful enough, if you've been able to make enough impact in an organization where they bestow this kind of responsibility on you, don't think that doing something entirely different is going to change that. I think the best way to become a Chief Data Officer is to be a Chief Data Officer. Come in and make it your personal mission to fix those things. Make it your personal mission to solve those data problems in one way or another, grassroots effort, whatever it takes, find a way to make people's lives better using data. You'll find your way to this Chief Data Officer role someday. And then ultimately, your role as a leader of people trumps everything else. The data side of what I do, I occasionally am able to get into some deep data stuff, but most of what I do is making sure that I'm managing well and making sure that I'm providing the right resources or the right vision and encouraging my team in the right way, making sure they stay motivated, making sure they understand that there's a point to all of this, making sure that if they don't realize that there's somebody else they need to talk to, that I make sure they talk to them and making sure that I'm protecting my people when they're out there trying to be change agents and they're not going to get everything right either, and that if they make a misstep that I can shoulder the burden of whatever happened and that I can protect them so that they can do what they do best. Because I think ultimately, when you're a Chief Data Officer or when you're any kind of manager, it's about helping people do what they do best and making them as powerful and successful and doing what they do best as possible, and that goes throughout the entire organization. Wherever data gets involved, which is in most places, if you can amplify your business capabilities and business success doing that, then so much the better and then you're on the right track. Okay, so that actually is a great answer to the question that was submitted here. To what extent should your core expertise be in building aspects to create business value versus program management experience? The question is asking, you know, is that an 80-20 split, 50-50? Do you have any... some response to that from the HIP about the relative importance of that experience? I think exposure to all of it is important. I think you have a huge blind spot if you haven't had some exposure to all of it. I think that being an expert in something is important as well and getting deep into something is important as well, but I think it's less important the specifics on that. I feel like I really rely a lot on a lot of the deep technical work that I've done. I mean, I've built data warehouses from scratch. I was able to code our first alpha version of AWS Spreadshift environment. It was able to leapfrog some things, but could a person who's never written a SQL query be a good Chief Data Officer? I'm sure they could. You know, I don't know that I'm qualified to determine that. That's kind of a meta level of understanding of Chief Data Officers that I won't pretend to have, but I do feel like, you know, I'm good at what you do. Don't deny what your aptitudes and what your specialties are. I hope you have some, but then find great people that do other things. I mean, I wouldn't be... and my team wouldn't be successful if we didn't have some of the people that we have on this team now because they bring stuff to this equation that I certainly don't, and that's where I feel like I'm very fortunate to have good people around me to do so many things that I can't do myself. I'm constantly learning from them, too. So I think if you have the opportunity to do this or you're building up to that opportunity to do it, be great at what it is that you're great at and find great people that can complement it well, form a team and, you know, change the world. I'm going to use the moderator's prerogative here and just ask you one final question. Have you made any mistakes so far? What would you do differently? And that only needs to be a very short answer. Yeah, I think it's, you know, despite my attempts to do so, there have been a couple of times where I pushed too hard or I had a blind spot where I didn't realize that a thing that I or somebody on my team was going to do was going to cause a lot of grief for others in the organization where it wasn't my intent, but that was the outcome and so I've had to, you know, respond to that a couple of times. And I think it's just making sure that I've done every bit of diligence that I can to avoid inadvertent challenges, especially on the people side, because the last thing I want to do is make people, you know, feel like we're taking something of theirs when we're really here to help amplify whoever we can find in this organization. And there's been a couple of circumstances where I wish I had that opportunity back. I imagine that, despite my best efforts, there'll be more of those, but I think that if I could do over a couple of those things where I accidentally stepped on toes that I didn't mean to step on, that would be my best answer to that. Okay. We're going to have to wrap things up here. Anthony, thank you so much for joining us today. I greatly appreciate it. And Eric's going to tell everybody in a minute what we'll be receiving in a couple of days. I just want to reiterate an offer I made right before the broadcast, is that if you're at all interested in either of our semiconferences in San Jose, August 18th through 20th, that's the DataVersity NoSQL Now or Smart Data Conferences. Just send me an email to tonywithdataversity.net and I'll send you that guest pass. Anthony, thank you again. And Eric, over to you. Yes, thank you, Tony, and thank you, Anthony. Really great presentation. Just to remind everyone, we will be posting the recording of today's webinar and slides through DataVersity.net within two business days, and we will send out a follow-up email to all of you who registered to let you know the links and other requested information. Thank you again for attending today's webinar. We hope to see you next time. And please have a great day and a very safe Fourth of July weekend. Thanks, Eric. Thanks, Anthony. I'll thank you guys.