5 Lessons From a Three-Time DevOps Leader | DevOps Onramp 2023

here and welcome to my talk. I'm devops onramp lessons from a three-time devops leader. In late 2014.

I received a phone call that would actually make some pretty substantial changes in My Career Direct trajectory call was from a friend of mine colleague someone I didn't a couple of businesses with startup companies and a long time partner Alan shimo today is of course CEO of Textron group. And we have these calls fairly often who called me up and say are icons. Hey, have you heard of this?

What do you know about that? What's happening here? Give me a call and ask me this kind of fateful questions.

Have you heard a devops? I said devops. Mmm don't think so.

This is 2014 devops have been around but it was still you know early in its adoption cycle. com. So what you go read up on it and tell me what you think.

If you can figure it out kind of tell me give me your perspective on it. So it's gonna be big if you know, if you've been an entrepreneur in a startup world, you kind of hear that phrase a lot. It's gonna be big.

This is the big thing. Revolutionary it's whatever and sometimes it is. Most the times it's a little bit lesser a lot less than that.

So who knew I didn't know so I kind of started on this path of Trying to figure out what is devops the back. Then there wasn't a ton of information around there's some there were some good information, but you had to kind of find find it and then really digest it to understand at least I did. So later that year that same year.

I began my first devops implementation and since I've done that at two other organizations Hi, my name is Mitch Ashley. I'm principal analyst with techstrung research. com.

In this talk, I'm going to share five important lessons released by what I feel were lessons important lessons for me. About implementing devops at three different organizations over the past nine plus years now understand that those organizations weren't just kind of pristine development teams. They're all had sort of the different flavors of it.

The first was where I was a VP of it CIO leader of a Global Research Consortium, which ran a lot of projects that involved a lot of external parties, but projects started up and down some lasted a month or two a few weeks sometimes and others were ongoing year after year. The second was a spinout organization which took a monolithic SAS service that have been built more than 10 years prior. That that handled a lot of transactions for that industry over 92 million transactions a year.

So it's a successful application. But built in a very traditional way running on a private data center or colocate colocation hosted facilities. And the third isn't all Cloud online tech media analyst research company AKA Textron or I currently work very different companies a very different places.

And I come to this as you know, as a devops person as a product leader product developer as a CTO as a repeat at a co-founder and entrepreneur. You know just with that idea of I really enjoy software and internet services and security and have this affinity for experimentation and taking ideas and productizing new technologies not everything that I get my hands on. But certainly I've done that multiple times across my career and it's what I really enjoy doing and that's why devops and treat me.

So let's jump right into. Now I'm not gonna give you a prescriptive devops 101. Here's what it is.

Here's what a CDC ICD looks like here's what a tool chain looks like here's a workflow pipeline all of those things. There's a lot of good course material and books and things about that. I want to try to pull from my experience Implement those things what some of the lessons that I learned about.

And of course with those lessons probably behind every one of them are some mistakes that I made that led me to so that conclusion. Lesson one devops is about how whenever someone asked me about. What is devops the first thing I say.

Well, that's a devops is not a thing. It's not a technology. It's not a methodology.

It's not a product. It's about how we create software. It's really changing the approach that we take in some significant ways though.

It's not turning it upside down. It's not guess that making it something unrecognizable but it brings some some different ideas to the table that can be pretty revolutionary when you really get to that point where the flywheel is turning in your ear and you're doing this. at a highly productive level there was a lot of devops product on the market so not to say that there aren't devops products the fantastic fantastic products, but those products and tools and open source things like that are implementing some of the ideas behind devops which are one of the reasons why it's such a Vibrant Community is the ideas behind devops are really what those tools are implementing and there's various flavors about how they do that.

So devops is about how we create software. Let me step back about why that's important to me early in my career. And you could tell I've been doing this a little while.

I experienced several generations of what I call the methodology Wars and AKA pulling the term from the Clone Wars from Star Wars which were largely waterfall specifications based project management driven software life cycles things that Big accounting and consulting firms put together assistance integrators put together largely to demonstrate their competence in delivering software and also to use competitively to win business. but the problem with those those approaches first of all, they're all waterfall and built on kind of the thinking at the time from you know, the 90s and before and 90s after But they all can have suffered from some common things one. They were very linear in their linear in their approach.

Meaning. Here's the steps. Here's phase one.

Here's phase two. Here's the steps in each. They were prescriptive.

Here's the document that you fill out. Here's the steps that you take within that here's the signatures you gain. Here's here's what the hell you build a test plan all kinds of things that makes sense.

But again a lot of work to put a lot that together and takes a lot of time which led also it kind of promoted very large releases and I learned pretty early in my career anything that takes longer than three months was always going to be late that was kind of the sort of Axiom that I developed as if you're planning anything more than three months. You're I can pretty much guarantee really good chance. We're not going to deliver on time, which always led me to do to find other ways to do things.

Also scope creep was a huge problem anything that's that long the requirements the needs the business especially today has changed. We've already moved on from what those requirements were from when that document might have been written two three six twelve months ago. And probably the biggest downside is they became dogmatic, you know, what's the right way to do this?

This is the methodology. There's a way you have to follow to follow the methodology kind of and it led to why I call it the methodology Wars. and there were several generations of this and one of the things that sort of broke that Log Jam for me at least was agile and when agile came along and I bring up agile because there are many things we carry forward from agile and still use today.

We carry forward into devops. And an agile was important because it really thought about well, how do we think about doing things in shorter interval shorter Cycles? How do we do that?

How do we create software using cross-functional teens collaborative teams multi-disciplinary teams? And mostly disciplined teams, excuse me, and also doing work in smaller units. We're not doing releases in three months or six or 12.

We're doing releases in four weeks, maybe two weeks and it brought together some visual planning and working tools like kanban boards, which I thought was quite fascinating and really really spoke to me is a good way helpful way to do things. It was also adaptable. No, Agile had certifications and things that you could take and there were certain books that were sort of foundational to it.

There's course was the manifesto that there was written in 2001. But also could be adapted you could go become a black belt that black belt scrum master. And here's the way you do things and you know, whether you followed it or not might lead to people judging you whether you were a you know, following the methodology or not.

I think less so agile, so it wasn't as dot as dogmatic or maybe dogmatic at all like the prayers but it's still fairly prescriptive, but I think it certainly took the kind of the bad experiences of the the Clone Wars the methodologies Wars away from it. So what makes devops about how we create software that leads me to lesson 2? You won't find a book that says here's devops.

Here's the definitive devops. Here's how you do it. Here's what it is.

Here's the steps. You take follow the 12-phase program and you'll be doing devops there really isn't. And that's what part of that initial Journey for me was about is like understanding.

So if there's not one thing if there isn't a book and there's some there's great books one blog post or one paper or whatever it is. There are a series of those but there is the one thing the one paper the one book to rule them all. Yet kind of go back and say well, how did it form?

Why did they form it? What did they do? What were they trying to do?

What did they use as sources? Of ideas of what we're applying in devops and I've been fortunate to go along the way get to know people like some of the early contributors and so contributors today folks like John Willis and Damon Edwards and and many others as humble and a number of folks around. How this happened and what they're trying to accomplish is interesting.

I recorded an interview at AWS re:invent in 2022 with John John Willis and Damon Edwards. And one of the things they said to me was they said we were very intentional not to make a prescriptive not to write a Manifesto. We wanted devops to become what people needed it to be not what we as the thought leaders behind it prescribed it to be and also sense of we would be limiting the potential of what it is because there's some kind of fundamental ideas that changing about how we're working but it has to be done in a way that people can use it and adopt it.

So I think that was a pretty brilliant thing to do even though it may frustrate us as an engineer an engineering manager as a CIO saying where's the book? How do we do this? How do we know if we're doing it, right?

So the kind of things that I heard in 2014 and Beyond or a bit confusing some made sense, but you know, that was the time of andresen's software's eating the world which I very much agreed with. I've been kind of doing work in that area already during a lot of things in the networking and security world that the software but they're also things like well, we don't need Ops anymore. Everything's been gonna be done by developers.

They're gonna automate everything. We don't they'll answer the pager at nights. You know two Pizza meetings and you know, you run what you create or whatever the phrases.

and there's I'm sure there's truth to those in many scenarios with that didn't seem to me like that was gonna be like successful across the board not everyone. I rarely feel like jobs like that get a limited. We don't need Ops or security or whatever.

Maybe you don't need tape hangers anymore from from those days, but that's usually don't go away the evolvement change. So there's also the thought behind the constraint theory of theory of constraint that gold Rat creative wrote about is book the goal and subsequent papers, which I had also read pretty fundamental to it. But this idea of the constraint is the thing you should work about.

I'll talk a little bit more about it, but you should read his book automation is key that made sense to me faster release Cycles, okay. Um emulating or looking to Netflix and Google as the model. Mmm.

None of us are there are no other netflixes in Google's. I mean, there are a data adaptations of it the targets and the Facebooks or whoever linkedin's of the world. But you know, most of us are not in those environments we could be next impossible at least in my journey to become what Netflix is there there unique.

com. Called The devops Journey and you can find it there. I'll make sure we include a link here at the end of this talk.

But what I did learn the little that, I didn't know about the beginning of my journey as I started on this path of devops. Is I really did realize that. Okay, these some of these things are coming together and unique way about how we create software.

This is the why behind this is how we create software. So let's talk about what some of those formational things are. A lot of devops goes back to Deming quality and also to Toyota production management you ever heard I've ever read the book Toyota way.

About what Toyota did in the forties in early late forties and early 50s around really changing some fundamentals that led to just-in-time Manufacturing in a number of other things. But the biggest thing that also came from Deming and Toyota is this idea of continuous Improvement. Where you know we have a vision of where we're going, but we challenge ourselves to improve about how we work continuously.

And whenever we have an issue we go to the source we figure out where that issue is remove the problem or improve it incrementally and we continuously move through that process. There's a lot of good books written on kaizan and and the Toyota Way definitely things to read there's a lot more about it about respecting for people and teamwork and and how to have the right processes produce the right results Etc a lot of reference information, but that's a source for a lot of it. Actually we're convon came from is one of the methods if you will kanbons are literally on a on a stand-up on a stand with wires across it and and cards High hanging on it.

literally, but one of the things also that came from this work was The idea of small batches of work, so kind of back to my if if a project can take longer than three months, it's going to be late. Well kind of that idea. Well then how do you break it up into smaller pieces that you can deliver more quickly quickly.

So this idea of like breaking things into smaller and smaller components batches of work. Which now also is is supported and maybe influenced even by software architectures textures like Cloud native. It's one of the reasons why it's so kind of complement or compatible with with devops though not required.

You can do devops without doing Cloud native. The others lean manufacturing lean software Concepts like minimum viable products that are so a lot of things that kind of came from that work but gold rats theory of constraints was also a major contributor to this about identifying where the constraint is in the system. Where the bottleneck is if you want to think about a constraint that way deciding, you know, how can you exploit that constraint in other words?

You know, how do you take that? Is there a way to take that constraint and use it to your benefit or how do you subordinate everything else? So you you basically Elevate constraints and then you work those now.

Let me say it a different way my way of saying it is. Essentially gold Rat gross over simplification, but he said identify the biggest bottleneck because if you work on anything before the bottleneck are you doing is making work arrive faster more work arrives faster and the bottleneck just holds more work back if you work on things to the right after the bottleneck. Well, you're creating use capacity because now things will flow more efficiently, but they'll never Flow faster than what the bottleneck release.

So if you take that bottleneck and and work it improve it potentially resolve it now, you can flow more work through the process and probably the next bottleneck will move somewhere else, or maybe it's continuous 14 that same bottleneck. I think one of the best sources for looking at what's with the ideas behind devops are is going to the Phoenix project. Now when I started this journey with my team this was you know nude everybody some foreign sounded scary actually in some ways maybe many ways.

So we did a book club. We did we read the Phoenix project together. I was one of the first things that I got my hands on from Gene Kim and a number of folks the wrote that and it followed very much the same novel style that the gold did which Gene used as this is inspiration for that, but it focused on the three ways and you can read the details about it.

But essentially the three ways are The principles of flow that helps accelerate delivery of work through the development to operations to customers. So how do you create flow in other words taking resistance and and bottlenecks out of the system the principles of feedback creating more feedback sooner helps us understand what's happening and make changes and improvements and know when those changes that improvements are actually moving us forward. And then the principles of continuous learning and experimentation this idea of it's not one Silver Bullet, but it's many smaller steps that lead to improvements in quality improvements and flow improvements of velocity of how quickly we ship software or put our software into production.

So from agile, we have the eye that idea of smaller more frequent leases Sprint planning stuff selecting work the comb board. And all of this helps us focus on a couple of things one eliminating waste, how do we not do work? That isn't necessary.

How do we how do we remove wait time? Which of course is wasting our resources? And causing context shifts cognitive load is people switch between work and also managing the cost of unscheduled work.

You can read a lot about this in cold rats work and so in the Phoenix project But I think one of the also important things is understanding that handoffs in our flow always create delays. It can be as minimal as I'm done with this step next person take the work that may happen immediately that's going to go into their queue or whatever that person or that process is and so there's automatically delay. Maybe it's a few seconds.

Maybe it's a few weeks, but you have delay when they're hand-offs. So, how can you think make those things more repeatable and more efficient? So we've ended up with many definitions of devops a common one.

You kind of see is a variation of devops is a combination of cultural philosophies practices and tools increases an organizations ability to deliver applications and services the high velocity evolving improving products at faster Pace than organizations using traditional software development and infrastructure management processes. That doesn't tell me what devops is but I understand what it's trying to and to address and of course automation is a big part of devops because if we are going to do a lot more work in smaller chunks and want to increase flow automation of that work of our how that work flows into the system is extremely important. And that's what often way organizations start with continuous integration.

And we say they start with cicd. Usually it's start with continuous integration and some CD if you will into test environments and things like that, not typically into automated at least into production, but some organizations do take that. further so those are the some of the ideas and I think if you as a devops leader get your head around those ideas and in practice, that's what you're really putting in practice with devops and then applying it to this workflow work streams and also to the tool chains the set of tools that you're leveraging open source commercial products, maybe some of the things that you built into some automated processes that help this workflow more quickly and it's smaller chunks and get out the door sooner.

So that leads me to lesson 4. devops in practice the devops infinity loop and in parenthetical and why devops doesn't really work like the infinity Loops shows us. I'll talk about why that is and again a moment.

We've all likely seen the infinity loop that's labeled with plan or Discovery create build test release deploy operate monitor plant mechanical back to that cycle. Well, if you sort of unhook the plan from the monitor string that back out that's a linear process and While we may go through those we go through all of those processes. We don't as one big step or one big path to that whole thing.

Our develops actually works is we have many cycles of all of those things occurring it at in parallel. So for example We may have because we were breaking work into smaller chunks. Batches of work, you know, we'll plan them that way we'll have multiple of those things happening in the planning phase deciding and they may be released or moved to the next create phase create step.

If you will on their own path, it's ready. Maybe on a combo board somebody picks their own work holds that down maybe some other way. A planning about how those things go to the next step but in that development kind of creating build phase.

Or steps there are tens maybe hundreds maybe thousands of those Loops happening concurrently, so it's not one big bunch all happening together in the create and then build and then test it's hundreds or dozens flowing through that process that their own pace. As quickly as the developer creates it checks it in runs automated tests, you know CI happens in the build phase tests or run Etc. And then at some point or release process happens so that can be Delivery or deployment there are definitions of what those two terms mean essentially.

Do you get a to a point where so there's a then a manual step that has to happen before it goes into production or is it automatically put into production? So there are a lot of many many miniature steps that are happening along this process. And that's why I say the infinity loop and I wouldn't have want to have to create an iconic image of how devops work because it's a little bit down intuitive to having one image that can show all of that inner workings, but that's essentially what's happening inside that infinity loop is it's a bunch of small little Loops that all happening concurrently managed through flow and kind of what the planning are of what things are take priority.

You need to be released as they are ready and they do get bunched up and releases. Yeah benched up together or released independently, so we could just depend on what what you need whether they're single elements of work, you know releases of code or small batches of that. So don't get caught up in following the infinity loop it caught up in a lot of work is happening in parallel on each one of those steps things can be in its own path and you're managing the flow of how work comes out of all of that process and then gets delivered eventually to software that customers employees and partners and others.

Of course, they're using whether that's a mobile app web app the Mainframe application, whatever it may be So let's talk a little bit about lesson five. DNA eats culture for lunch. And of course, I'm referring to the 2013 book culture each strategy for lunch by Kurt Kaufman and Catherine Sorensen, which is based on a quote from Peter Drucker famous Management Consultant the idea that culture each strategy for lunch.

Meaning the culture of the organization is what really accomplishes things now. I've been through several culture change efforts. And while there have been changes made a couple things that I've learned along the way is is extremely difficult to change a culture.

It's one thing to say we operate this way and now we're going to turn the page in operate in a pretty substantial different way. There are conditions where that happens, but they're they tend to be fairly drastic. Change situations things drivers of why that happens saying that we're going to move to a devops culture.

Or we're going to move to a security culture Security First or whatever code oftentimes. It's multiple things. We want to move to in terms of cultural change.

I think it's really less about cultural change and it's more about understanding. How your organization works the DNA of your organization and the DNA kind of conceptually of the people in the organization work and how you can leverage that to your benefit. So let me give an example.

Saying that you know in a month, we're going to start doing you know, 10 deploys into production a week or a day when we don't do 10 deploys into production a year. That's that's gonna be a shock to the system and impossible probably to achieve in nearly any organization. Rather the approaches.

We want to start to implement a process of where we can increase more frequently and continuously improve of that and eventually get to a point where we don't know what the right number is. Maybe the number of deploys per day isn't actually the metric the real thing is about how do we get functionality capability into the market to achieve what our business and strategy rules are and are we able to meet the pace that the business would like us to meet? And delivering those capabilities using this technique called devops.

So when I say DNA of a culture, I mean things like Step back and examine. You know, we're what's our culture about. How do we measure things?

How do we reward and recognize people? Sometimes it's heroics. Sometimes it's where data driven we make decisions on data.

We measure everything. We're based on kind of more of a charismatic organization where we follow this leader and and they set the path out and that's how they go. So why do I say all of this?

That's probably your best path as understanding how that DNA in the organization. We work and then how do we adapt? devops in that situation For example if you're very data-driven.

Or very metrics driven great then focus on what are the key metrics we want to start to improve at an incrementally grow in it could be to place per day. It could be how much software we're able to deliver using this technique maybe versus past methods of working. It could be testing.

It could be many many metrics that we leverage. But if that's what you that's how you operate and that's how people behave and how people are rewarded. It's it's a great thing to do.

It's interesting. There's a lot of definitions of what company culture is and one of them is you know, it's a shared set of workplace beliefs values attitudes standards purposes and behaviors. I kind of boil it down to this.

You get culture whether you intentionally seek it or not. You every company has a culture oftentimes and unintended culture. That's primarily set by the CEO or leaders of the organization because when CEOs change culture tends to change or at least adapt to that person.

So especially true in the startup company. It's all about sort of the leader or Founders people like that. So when culture really changes meaningful change, it's when CEOs Senior Management or ownership like a PE firm buying a startup company or a public company.

That's when culture change because the fundamentals of the business or how it's being led or how it's being measured those things are changing so suddenly in a young company guess what cost efficiency profitability things like that suddenly rise to the top of the list. We thought there was on the list top the list, but now they're Paramount. There's also crisis like near cataclysmic events, you know business model that has been disrupted by maybe a game changer in the market.

Some economic conditions unforeseen or outside the control of the organization or thought leader change founder leaves and someone comes in oftentimes and startups that happens, you know professional management comes in and that sometimes that works. Sometimes it doesn't I think oftentimes you think is cultural changes. But I call creating many cultures like we tried to change from the bottom up and some of that will have an impact.

Sort of these anti-culture groups, you know, we're gonna raise the pirate flag and do things differently and kind of pull ourselves out of the mainstream of things go go determine new ways of doing things and then adoption falls off because they oftentimes are too counterculture to that. So I'm saying all this because I think if you look what I've tried to do is look at what's important to the organization. How does it make decisions and operate?

What are the what are the behaviors explicit and not explicit? Unintentional but still get recognized you kind of get the culture you're allowed to operate. You know, you may say you're you do this, but if people outside operate outside of those Norms, you're not really sticking to that idea.

So leverage the DNA principles behind our organization's work and then begin with where you are to to begin shifting or adding and adapting devops to that. Lastly I'd like to end with a bonus kind of lesson outside of the five that I mentioned one of the strengths of devops. I said early on that there is no Manifesto.

There's not one book and that was intentional by some of the leaders behind creating this idea in the movement. and it's a it's not about a set of principles solely, but it's about its ability to evolve and adapt one reason why I say this is oftentimes people will in a negative way say is what are all these asterisk op things. There's data Ops aiops.

Ml Ops Picking Ops finops you can put Ops at the end of anything. You know, is that confusing things or or what? Why are we doing that and I think one of the things devops has done is help rather than eliminating jobs or devaluing what people do and the roles that they play.

There's actually help Elevate them. because of the cross-functional nature and and bring it to light how software is being created and what their role in that whether it's compliance people or security people anything on that Spectrum so devsecops things like that. So I think that that adaptability in the visibility and transparency that's created to devops is really it's superpower and that's why it's head staying power and I think it'll be with us for a long time.

Now other things may come along and you know create new ideas and there's a new generation something. I doubt it'll fully replace devops. I think like agile those things will continue to be carry carried forward and evolved and be adapted and if it gets sort of replaced or at least evolve to this next thing of what it's going to be all better for the future and I think even some of the a thought leaders behind devops would it concur they'd love to see it continue to grow and maybe out crow with something the original ideas or so, let me let me step back from one moment.

I said, I would talk a little bit about the three companies that I worked at and what those experiences were like and I want to highlight this because they were all very different at very different places. In their own development maturity. The first was a research Consortium for the global cable industry for Broadband services and also Media Services and more and it had over 60 members and I don't remember how many different projects concurrent projects that might be running any one time, but it was literally in the maybe hundreds certainly thousands.

And that was at a period time where a lot more kind of technology in the network is Shifting to software kind of projects software-defined radios. Just pick one example in many others, you know adding API first kind of designs into software security appliances and networking appliances turning into software Etc. So it was a time when the organization wanted to spin up a lot more software development projects.

Most of them not very big sometimes only for a month or two. Sometimes as I mentioned before could be ongoing for for several years many years. When I was running the organizations we were going through a modernization phase of a lot of the infrastructure and software and services that we were using and was a good time.

To actually bring in devops because they're a lot more projects starting up and the cloud was beginning to be adopted in the organization. That was this is in kind of early 2014-15 or so when we started leveraging devops and we did the Phoenix project book club. And essentially what we did was kind of set up software development devops as a service.

I mean I overstating it a bit because these are early in the in the life of understanding how to do devops but we created a self-serve platforms that internal teams that were starting up basically making it easier to get your project going and shortening the startup Time by using the here's the tool set. Here's the way we can do this as you can set it up. We have CC ICD tools we have Get based repository we happen to be using atlassian products and other parts of the company.

So it was a natural fit to start to use some of their emerging tools and Technology, you know, Jenkins open source and many other things. But it was great because the it organizations supporting projects could evolve right along with the rest of the company as we started to do more and more software projects. So scenario number two is actually a spin-out company.

Which was taking elements from a SAS product. net application is fairly old been around the people who had originally created were no longer there. There was a bit of trepidation maybe a lot of a modifying certain parts of that app.

Because people didn't understand it. It's too big too big too unwieldy. So we actually coupled bringing devops and along with taking part of that.

Well take a whole app and moving into the clouds or the lift and shift at first but also then taking some of the functionality from the monolith carving it out and doing microservices and containerization. Because those are the parts of the app that we wanted to iterate to create new services with and do some new competitive things in market. So that shift not just to the cloud but wanting to do more things with the monolith and figuring out a way to leverage Cloud native was a great big case.

We're actually combining that with devops was a perfect opportunity. Excuse me. Last but not least is where I am today.

Tech strung is in all Cloud company. We don't have any servers anywhere. I mean we're leveraging all services in the cloud SAS Services productivity tools.

We have some servers that we run. Codon a lot of website. a lot of integration code and things like that and range from HP and Python and JavaScript and languages like that that we use today.

So it's much more of an integration workflow. Tying systems together pulling data doing analysis. So from different systems that we can then leverage for making business decisions.

I'm monitoring the applications. It's not a peer devops flow but kind of many places. We're applying those devops principles and using some devops oriented tools to do that.

There's just adapting some of the ideas from devops into our situation the technology that we're using and then evolving how we create software along with that day by day. So I hope this talk has been helpful to you again. There are a lot of great things you can you can pull from I mentioned the Phoenix project.

There's the devops handbook also mmm. And I will provide some links that you can go get more information about this. So thank you for being with me today.

Hope this has been helpful. Feel free to reach out to me if you have questions or want to talk more. com.

I'm happy to respond. You'll see me on LinkedIn LinkedIn and many other places. So enjoy the rest of the conference.

I hope it's been a great day and look forward to seeing you again soon.