Designing Data Governance from the Ground Up

Data governance manages the people, processes, and strategy needed for deploying data projects to production. But doing it well is far from easy: Less than one-fourth of business leaders say their organizations are data-driven. In Designing Data Governance from the Ground Up, you’ll build a cross-functional strategy to create roadmaps and stewardship for data-focused projects, embed data governance into your engineering practice, and put processes in place to monitor data after deployment.

In the last decade, the amount of data people produced grew 3,000 percent. Most organizations lack the strategy to clean, collect, organize, and automate data for production-ready projects. Without effective data governance, most businesses will keep failing to gain value from the mountain of data that’s available to them.

There’s a plethora of content intended to help DataOps and DevOps teams reach production, but 90 percent of projects trained with big data fail to reach production because they lack governance.

This book shares six steps you can take to build a data governance strategy from scratch. You’ll find a data framework, pull together a team of data stewards, build a data governance team, define your roadmap, weave data governance into your development process, and monitor your data in production.

Whether you’re a chief data officer or individual contributor, this book will show you how to manage up, get the buy-in you need to build data governance, find the right colleagues to co-create data governance, and keep them engaged for the long haul.

@ Pragmatic Programmer

Samia Rahman, the director of enterprise data strategy, architecture, and governance at Seagen, explores, together with, Lauren Maffeo, a senior service designer at Steampunk,   the core principles of creating a data governance structure in small or large companies from the bottom up. The conversation picks on the most compelling parts of the book "Designing Data Governance from the Ground Up, written by Lauren.

Intro

Samia Rahman: Hi, everyone. Welcome to GOTO Book Club. I'm Samia Rahman, and I work as the director of enterprise data strategy, architecture, and governance at Seagen, a biotechnology company with a mission to better the lives of cancer patients through innovative, targeted therapies. I like to solve complex problems, leveraging data. And our book today is "Designing Data Governance from the Ground Up." And I'm super excited to talk to the author. Welcome, Lauren Maffeo. Would you like to introduce yourself?

Lauren Maffeo: Sure. First of all, thank you so much for having me. My name's Lauren Maffeo. I am, in my day job, a senior service designer at an organization called Steampunk. We are a human-centered design firm based in the northern Virginia, Washington D.C. area, serving U.S. federal government clients. So, we use a human-centered design approach to design and build technological systems that help the U.S. government run more efficiently, especially on digital platforms. I'm also an adjunct lecturer of design at George Washington University in Washington D.C., where I teach classes on interaction design and design futures. And I also, as you mentioned, wrote a book called "Designing Data Governance from the Ground Up," for Pragmatic Programmers. And true to the publisher name, it's meant to be a 100-page six-step guide to help people establish their first data governance programs from scratch and to help them manage their big data at scale more effectively.

Getting Started with Data Governance

Samia Rahman: That's awesome. Thanks, Lauren. I guess I'll start it off with a warmup question. How do you define data governance in your book?

Lauren Maffeo: I think it's really important to define data governance when you start the conversation, just like I think it's really important to define what you're talking about when you say AI, because everyone assumes that we all know what we're talking about when in truth, we're talking about wildly different things in many cases. So, I define data governance as your strategy for managing the people, processes, and tools that help you assess and govern your big data at scale. And big data is another loaded term that I almost dislike using, because it is so ubiquitous that it's everywhere, and seems to be nothing.

But truly, when I talk about big data, I mean an amount of data that is both produced and ingested by the average organization, which is beyond one person or one team to manage. That's a huge reason why I wanted to not only write this book on designing data governance but really use the book to emphasize why you need to engage your entire organization in this effort. There is too much data produced and ingested by the average organization today for one team or one person to manage it. Our systems for managing this data are outdated, and just not suited to the velocity of data that exists today.

And the reality is that data is going to play a larger and larger role in all of our jobs. I think in 5 to 10 years, marketing directors and anybody in a VP of sales role are no longer going to be able to say, "Data's not my job." The reality is that even in those modern roles, data plays a very big part in those folks' success in their roles, and that is only going to continue to grow. So it's crucial that we not only invest in data governance from the people, processes, and tools side but that we also engage everyone in both business and technical functions so that they have a hand in this effort.

Samia Rahman: Yeah. Plus one to that last part everyone needs to make data their business, to drive the business forward or accomplish that value prop they're looking to get done. So, you mentioned that this is a Pragmatic book, 106 pages. Who would you say is the target audience for your book?

Lauren Maffeo: Yeah, I do, like any author, hope that it has as wide appeal as possible. That said, I did write it for people who are decision-makers about data strategy in their organizations, and they know they need a strategy and a blueprint to help manage their data more effectively, but they need help getting started. And so, very often, that person is a Chief Data Officer. They typically report to the CIO, or the CTO in some cases, but ultimately, their job is to figure out how to help their organization make the most effective use of data possible. This book was really written for them, in order to give them a blueprint and a path forward on how to do it. I say, in the preface of the book, that it is not a book about techniques like linear regression. We don't debate what data science is, we don't talk about different data science methods or trends. And that's because that information, I think, is pretty ubiquitous online. It's very easy to throw a rock on Medium and find posts of that nature.

What I struggled with as a systems designer with my clients was when I was looking for help with a holistic strategy for how to make decisions about that data, how to assess data sets for quality, how to determine which data sets should be kept more secure versus which ones should be made open, I found nothing. Now, I will say, this was about two to three years ago, and the online landscape has changed. I see, for instance, a lot more people now writing about data governance on LinkedIn in a way that they did not before. But this is still a relatively new concept, I would argue, in the data space. And certainly, even if the concept of governance is not new, that velocity of data, that volume of data, is new. And so, we've always needed data governance. I think before it was easier to brush it off and say, "No one's gonna notice if we don't do this. It's gonna have minimal effect if we do this." And now, it's a runaway train, and I'm hoping that the book can help leaders in charge of solving it do that.

Recommended talk: Data Mesh: Data-Driven Value at Scale • Zhamak Dehghani & Samia Rahman • GOTO 2022

Samia Rahman: I think what I've observed in my career is, that either there are data governance bodies that have been there for over 20 years, and no one really codified it into a book. It's also, there's some, I think, shifts in thinking, right? Big data, or large volumes of data, has disrupted how we are thinking about managing that data effectively. And then the second part is a lot of people either let it accumulate as debt, is how I see it. And now they're up, like, you know, putting in a lot of energy to get out of that debt so that they can effectively use AI and other technology that's emerging to innovate, so that makes sense. So, I'll go into, your book is outlined in six chapters. I guess, if the audience were to read your book, what would they take away in terms of getting started in their journey of data governance? What would you suggest that they start doing?

Lauren Maffeo: If I could distill that down, and the six chapters down into one takeaway, I hope it would be that everything you do regarding your data strategy has to align back to the fundamental reason why your business exists. If you don't know what that reason is, you have to get really clear on that really fast, because I think the entire reason we're in this mess with data, that we have the technical debt with data that we do, is because, for so long, the data part of the organization has been siloed from the business side, and neither group has taken a lot of time to try collaborating and understanding each other. And so now we're in this moment where it's not too much of an exaggeration to say that everything we do in the modern organization is powered by data in some form or fashion. The velocity of it is so huge now that there are no mechanisms in place to not only define what quality looks like but also to have the business and data sides talking to each other in a cohesive way.

That's why the first chapter of the book really stresses how crucial it is to not only know what your business's mission statement is but to write a singular statement in one to two sentences for how your organization is going to manage and governance data, that ties back to the mission statement. So, I use Warby Parker as an example in the book, of a company that's a pretty beloved brand. We all know Warby Parker well, even if we don't buy their products. Then, it asks the audience to think about its succinct mission statement, why it exists, which data they need, and how their data management practices could enhance that mission statement. I think without that very clear, direct path back to the business mission statement, everything else you do, everything else that is discussed in the book, really builds upon that. Because if you don't have that fundamental tie-in back to the organization and what they're trying to do, really, all of your other efforts are going to be superfluous, and they might even fail. I think that fundamental disconnect between the business and the technical side is why we've encountered so many challenges for so long.

Samia Rahman: A hundred percent agree. I think every organization I've been into, they've had three or four attempts at setting up a data governance body, and they did not focus on the business outcome. So, that, I think, is shifting now. People are realizing, that if I don't understand the business, I'm not gonna succeed here as an individual, or the business is also not gonna succeed here. That's so crucial.

Data Stewards & Governance Driven-Development

Samia Rahman: In terms of getting started, I think you also talk a little bit about data stewardship. What are some of the things that folks should be accounting for when identifying data stewards and getting them involved in the process?

Lauren Maffeo: That's a great question. Because even though this book is written for data decision-makers, you can't do this work alone. A big part of it is, what product managers are familiar with, and even data scientists are familiar with, which is leading without direct authority. You have to figure out how to motivate your colleagues across functions to work in a cohesive way, without actually maybe having the direct autonomy to manage them. And that's a very difficult position to be in, but there's precedent for it with the product manager role.

When you, as a data leader, are thinking about data stewards in your organization, you wanna start by asking, what are my key data domains? What are the domains that my organization produces and ingests data on? And then you wanna define sub-domains from there. So, a process map exercise, where you map out your core organizational data domains, and then identify the sub-domains underneath, is going to be a really important exercise, for many reasons. It's crucial if you're setting up a data governance tool like Collibra because you're going to have to define that internally within the tool, but you also need to think about who owns that data.

The concept of ownership is fraught at best, especially when it comes to data. Maybe a better way to frame data stewardship is to say, "Who in my organization is the most senior subject matter expert who is closest to this data, and understands it the most effectively?" And the answers in those cases could be someone in a technical role, somebody on your data team who's an architect, an engineer, a scientist. But it could very well be someone who is in a marketing role, a sales role, or customer success because they're the people who are dealing with the data in this particular domain/ subdomain most often. They're probably the people who know what is meant by certain data definitions and domains. They're probably the most equipped to write those definitions themselves and to assess which metadata should be attached to particular pieces of data so that it's found more easily. Do you really wanna be thinking about who is the most senior subject matter expert on the data in this domain? That is the person who is most well-positioned to serve as your steward.

Samia Rahman: That resonates a lot. In my experience, I've seen usually the SMEs are the folks, it's not the data scientists or the data engineers. They could be, but if it is compliance-related or if you're in biotech, the SME lives in the business, and they are always invested because they have to stay compliant with the FDA and other regulatory bodies. So, that resonates a lot. I wanna shift to the last two chapters of your book. Governance-driven development really piqued my interest. My understanding, and the thing that I've been always trying to ask others to take the mindset of, is the shift left on governance. Do it at the point of creation of any application, any process, etc. What is your take on governance-driven development? How do you define it, and how do you encourage people to use it?

Lauren Maffeo: That's a great question, and I love that you're asking about these chapters. When I give interviews and do podcasts about this book, I'm most often asked about the people side of it. This makes complete sense because I think that is the aspect of this work that is most often ignored. The concept of writing, excuse me, the mission statement for data is something that is very familiar to me as a systems and service designer, but it is very foreign to a lot of folks. Having said all of that, the reason I emphasize governance-driven development is to say, that something I see in organizations a lot to date is that there's this 100-page, I've literally read 100-page memos on data governance before. I had a client once send me an internal data governance document defining what they had done in the past, that was about 60 pages and 20 years old.

I see this huge, incredibly obvious disconnect between the data governance, if it's done at all, that is written down almost in an unreadable document that sits in, like, a digital ether somewhere. And then there's the technical environment, and there's just a fundamental mismatch, where the governance does not go into the technical environment. The argument I make in that chapter is that you are doing all of this mission-driven work around your data so that it is embedded into your tools. Because data governance is about the strategy to manage the people, processes, and tools. And so, if the processes and strategy are not reflected in your tools, that is...you're not really doing data governance. And so, then it becomes a question of, okay, it's all well and good to define your data stewards, to come up with a data governance council, to write a charter. What happens after that? And the reality is that those principles, all of the work you've done to foster that cross-functional collaboration, should be evident in your technical environment.

That chapter, you mentioned uses Netflix as an example of an organization that I think did an exemplary job embedding governance into the technical environment. They were trying to implement a new streaming service architecture at a time when that technology was very new, largely unproven, and very supported by open source before it became commercialized. And the big thing that stuck out with me, when I was reading this blog post from the engineering lead at Netflix who led this effort, was that he literally created an environment where he gave his team and his data stewards room to fail. In this example, they were using Kafka clusters, which were unfamiliar to the team at the time, because it was such a new technology. And he knew that if they deployed, that was going to be an enormous risk to Netflix. They could take a server down. At a bare minimum, service would be disrupted, which was unacceptable. And so, he created a sandbox environment where people could get comfortable using this technology before they were using it and deploying it in a larger way.

I think that's an example of where you really wanna be very clear about what your principles, are and who your people are before you go into the tooling. But you also cannot fundamentally separate your data mission statement from your tools. It really has to be a co-creative process between people across the org. And as the data leader in your organization, you know, I would argue that is your core responsibility. That's something I think is missed by a lot of people, is that the chief data officer role is fundamentally not a technical role. It does require technical expertise, but it is a strategic business function. And it is your job to figure out not only what your values for data are, and what your data governance strategy should be, but then how is that going to be reflected in the tools you choose, and how you set them up.

Recommended talk: Why Most Data Projects Fail & How to Avoid It • Jesse Anderson • GOTO 2023

Samia Rahman: Yeah. Yeah. Definitely agree. I've seen that disconnect a lot. People end up spending a lot of time on the charter and the, you know, getting people together, but then the tooling is not reflecting it. Yeah. And I've seen similar documents that are, I call them as undigestible policies or documents, as the developer or as the technical person, it's like, there's so much jargon. Simplify it for me so I can just code it out, right? So, there's lots of opportunities, I think, in the industry for everyone to take that mindset, and leverage technology for what it's meant for, right? To automate as much as possible while balancing the people and the process together.

Samia Rahman: So, shifting, from governance-driven development to monitoring data in production, I think, there, again, very much piqued my interest. You talk about data mesh principles. You also talk about planning to monitor the entire lifecycle. This, I think, ties into, again, governance-driven development, because you can't just say, "I'm doing it at this point, and then it's free for all," but you have to do it as data keeps evolving, as the business keeps evolving. So, can you tell us a little more about that chapter, what we should take away from that, and your key messages there perhaps?

Lauren Maffeo: I think this really goes back to the concept of managing data as a product. Because we think of a successful deployment as the endpoint. The endpoint is somewhat of a misnomer, because even once you deploy, of course, you're gonna make feature updates, you're going to update the code, if we're talking about traditional code. But with data, it's much more complicated than that. And so, it's not enough to say you've deployed your algorithm to production and now you're done. That's especially not the case if you are truly using AI techniques and technologies, and I say that because a lot of people say that certain things are AI when they're not. If you're truly using something like machine learning, you deploy, and that is only the beginning. Your model is going to constantly be ingesting new data. It's constantly going to be learning from this new information. It's going to be updating itself for better or worse, and refining its results. If you do not have data monitoring in place, that's the perfect recipe for data drift, which is a term for the quality of your model decreasing over time, which is very common.

You really do need to take this approach that you have these standards for what quality data looks like per domain and subdomain. You have your data categorized as effectively as possible, and then you need those standards in place prior to deployment, because then, once you do deploy to production, you're going to have to constantly be ingesting that new data, and assessing any new data that's taken in against those predefined standards, because this work never stops. And that's what makes it so difficult because there are a lot more complications with data than there are with software code. And one of those complications is that the types of data that exist today are much messier. It used to be, for instance, that we had a, you know, most data was structured, it could easily live in an on-premise data warehouse, it could easily be manipulated in Excel, people could create custom Excel models to work with the data that they had. There is way too much data that exists today. Excel cannot hold the average amount of data that exists today, because there's too much of it.

And so, we need to be thinking more holistically about, not only what are our data standards, but how are we applying them, not just to the data we currently have, but to the data that we will continue to ingest.

Anti-Patterns and Failure Modes

Samia Rahman: The machine learning space gets complicated. I guess, you mentioned that there is an emergence or proliferation of unstructured data, but I think there are still many industries that have a lot of structured data, but they're still struggling with some of those basics. So, I'd like to kind of explore, what are some of the anti-patterns or failure modes that you're seeing, that people should avoid, and they should be taking your guidance from the book to address them. I think I mentioned earlier, that I've been in organizations where they started, it crashed, started, it crashed, and then on the fourth attempt, they meet some traction on governance. So, curious about your experiences and reflections.

Lauren Maffeo: I think when it comes to what people should be monitoring for, you really need to be automating that. You need to have set up a tool, and there are several out there, and I'm personally tool-agnostic. But, for instance, when we're talking about data governance, typically, I work with clients who are trying to implement with Collibra or Informatica. I think the thing that I wanna stress about using those tools is you need to be setting up your entire technical environment so that it can automate assessments of where data falls short so that you get a real-time view of how your data is flowing through various algorithms and pipelines, where you've set up data lineage tracking so that you know how one data point is being used across various algorithms and lines of business. You want to be setting up automated scans so that you can quickly get a snapshot of which data needs attention, and that you can also assign that quality check to the right data owner. All of that, it really stresses why you need all of those things set up and decided on before you settle on a tool, and that is the exact opposite of what I see most people do, even at a very senior level.

I will frequently talk to chief data officers who say, "We have Qlik, we have Collibra, we're getting Databricks next year. They name off all of these tools. And they also get very excited about new and upcoming tools, whether it's SageMaker in AWS, whether it's all of these different things. I mean, there's no shortage of tooling out there marketed at technologists to help solve these problems with data. But if you have not done that fundamental groundwork to decide who owns which data sets, who is responsible for making key decisions about it, what those decisions are, if you have not given them the right levels of access within your environment, all of that is going to fall short, and then your tools aren't going to meet your goals, and you're going to get frustrated and complain that the tool didn't do its job, when it actually did what you set it up to do, which is not a whole lot. And that does not mean that you need every single aspect of this work figured out before you buy a product, but what I'm saying is that I very often see this hyper fixation on tools and techniques, with literally no strategy for how to use them, and that is where the disconnect comes in.

Samia Rahman: Oh, my god. That makes me smile, or laugh a lot inside because I've seen...I was at a company where one of the technologies that they bought sat empty, unused for two years. They obviously could afford it, but the governance was just, no one was doing anything about it. "Yay, we bought the fancy tool. That's a checkmark in my goals for the year." And yeah, that one, I think, is the biggest anti-pattern that I've seen, that people need to avoid. And keep it lean is, I think, the main mantra, right? Do just enough, and then keep evolving and maturing. Technology's easy to buy, but if you don't have the design, and the processes, and the mindsets, like governance-driven development, then you're not gonna succeed with that technology. So, with the...

Lauren Maffeo: On that note, I sat on a panel at Barnard College a few years ago, and a woman in the audience, who worked for IBM at the time, came up afterward and told me a story about how because she was in charge of client services for IBM Watson, which had been marketed to people as this magic bullet that could implement AI across your organization. And she said that she had had several clients say to her, "What do you mean I have to train it?" They had bought IBM Watson, and didn't understand that, yes, they bought the tool, but they had to set it up and had to, again, establish the data domains and sub-domains. They had to figure out pipelines, and how that was going to work. And part of the challenge is, you could make the case that Watson was marketed as an out-of-the-box, all-purpose solution, to help you embed AI in your organization. And that's pretty misleading, I would argue.

I think, for me, that goes back to this broad problem I see regarding literacy about data, which you could also just say is data literacy. But I think that the more AI and data services get embedded throughout our culture, the knowledge, the more that happens, the worse data literacy seems to get. I think that's also a fundamental challenge, is that these products and services, market themselves as being autonomous and independent. Which, yes, they automate tasks. So, for instance, data scanning for quality, yes, that should be automated within the tooling. You still have to decide what data quality looks like. Because if you do not put your standards in the tool, it isn't going to know how to make the right assessment. And that was five years ago I had that conversation with that woman at IBM, and I don't see that problem getting better.

Evolving Role of Data Product Managers

Samia Rahman: Yes. I agree. This is a wake-up call, or a reinforcement for everyone out there, to take Lauren Maffeo's advice, and I'll plus-one it. I wanna ask one other question before we wrap up, which is, I see this trend of emergence of data product managers, right, who are looking at the roadmap, the value of the data. You can also think of them as application product managers. There's a lot of overlap. They're all building data-driven applications, whether it's in predictive analytics, using AI or ML techniques, or just operational. At the end of the day, there's always data. How do you see those roles, their roadmaps, and their responsibilities, overlapping with the data steward? Curious about your thoughts, because I've been observing a lot of things there, and I'm curious to hear from the community what the reflections are.

Lauren Maffeo: This is a great and really important question. I was thinking about it this morning, knowing we were talking, as I walked my dog because it's... I was thinking data product managers could, in theory at least, totally replace the concept of data stewards, if there is that one person who is both a subject matter expert on data in your domains, and they have enough knowledge about data to make decisions on it. Now, that does not mean that they are a trained data scientist. It doesn't mean that they are specialized in the different types of math and statistics needed to be a data scientist, but they know enough about a particular domain to lead decisions about it.

So, in theory, I do think the data product manager role has legs. I think it is here to stay. I fundamentally agree with the data-as-a-product approach to managing big data, because I think data as a service is not meeting the needs of today's data environment. And so, of course, if you're going to be managing data as a product, it's only natural that you would have data product managers as well. I think that the resistance internally that I have to it is that I just don't see most organizations today as being mature enough to set data product managers up for success. And I feel disappointed that I even am saying that, but that's the reality of it.

Before my current job at Steampunk, I was an analyst at Gartner for several years. And Gartner is really a leader in assessing where organizations are, where different markets are, and specifically doing data maturity assessments. And for years now, the volume of data has only continued to increase. Meanwhile, the number of leaders and organizations who say they're data-driven is actually decreasing in many surveys. And so, I really worry that we would only be doing to data product managers what we've done to data scientists for years, which is that we sell them this really cool job, where they're gonna build all these really interesting models, and instead, they clean spreadsheets 80% of their day. And I worry that we would do exactly the same thing to data product managers.

I think the role and the concept have a lot of potential, but personally, I need to see data governance writ large, across the industry, increase in maturity a substantial amount before I would even feel comfortable recommending people to data product manager roles because I don't want to send them into a lion's den.

Recommended talk: Modern Event-driven Architecture: Adopting Data in Motion • Alex Stuart • GOTO 2022

Samia Rahman: Yeah, yeah. I think, in my observation, data governance is evolving into an enabling organization, where, if there are existing product managers, your app product managers, etc., they become customers of your governance as a service, so that they can apply it and embed it, and do that governance-driven development. They're monitoring that data production through the lifecycle of whatever they're building. They also know their downstream customers. Now, when you don't have those people, and you're creating those new roles, whether it's a steward, or application, or sorry, data product managers, that's where the empowerment, I 100% agree, there's a resistance usually, because they will always lead with "Why?" And the business or whoever they're interacting with, "Who are you here to challenge me, or ask me why," right?

So, that collaboration, I think, is the key there, so that they are empowered to partner with those SMEs, lower the effort on the SMEs, and really take care of governing the data, and making sure it's usable, right?

At the end of the day, it's all about the usability and value of that data. I've seen it evolve. Hopefully, it scales out a lot more, and people, or leaders, are empowering those folks to ask those questions in a safe manner, right? There's a whole change management aspect to it. But it's a whole thing we can talk about, and maybe you can write about it in the future. With that, any last parting words for the audience?

Lauren Maffeo: The main thing I would say moving forward is that, what we're talking about is truly a marathon, not a sprint, to use a cliche. This is an enormous endeavor, and it's not lost on me how much is being asked of somebody in this position to set up data governance. It is an enormous endeavor. It requires you to lead many people across functions, without any real direct authority over them, which is incredibly hard work. But I do think that you need to view it as an investment in the long term. Sometimes when people are doing different advocacy work or projects, they specifically say that they are planting a tree for the future. They know that they might not even see the fruits of their labor, but they're still invested in planting the initial seeds, even if they won't see the final tree, and I do think that that's the best way to look at it, is that this is truly something bigger than you.

And even though it's meant to benefit your organization, it's even actually bigger than the team and the organization itself, because you, at some point, through your own doing or not, will leave your organization, and you really wanna have a solid foundation. We're seeing the consequences now of what has happened due to that lack of foundation. And so, you, as a data strategy leader, have a huge opportunity to lay that foundation that has not existed for people to build upon and improve. That also doesn't mean that it's going to stay stagnant. We all know how fast this industry changes. Sometimes too fast, in my opinion, because we like to move forward, to distract from the fact that we haven't solved the three problems before it. But fundamentally, if you lay that strong foundation, you can still build upon it to meet the moment, but you do have to invest in building it first.

Samia Rahman: Awesome. Thank you, Lauren Maffeo. So, thank you to the audience for listening in. And hope you all pick up the book, enjoy reading, and get to actually apply what Lauren Maffeo said, and lay the foundation for a better future for your organization.

Lauren Maffeo: So, thank you so much for having me.