Cloud Repatriation Part 2 - CTO Advisor Virtual Conference
Transcript
>> Just to recap, from our last conversation, all roads lead to CIO's needing architects with skill to meet the drivers of workload placement. Those drivers could be based on new types of workloads such as AI, ML, IOT, or business opportunities powered by the cloud. Tim talked about, in the last session, about the importance of knowing the value of the workload. First off, what are these workloads and how do we skill up to properly identify and place the workloads in our hybrid infrastructure?
So question one goes to Jo. The SolarWinds IT report, I just did a podcast with them going over the results of this survey, mentioned that IT pros, mainly us infrastructure-focused types are not really paying a lot of attention to AI, ML and IOT. Jo, what are we missing? What are you seeing out in the field when it comes to AI, ML and IOT that us IT infrastructure pros kind of don't see? >> Well, I found the word focus pretty interesting and I found it interesting because I thought about something silly first.
You know how when you have a little kid and you're trying to get that little kid to eat veggies, maybe having the veggies on the plate is not the best way to get that kid to eat the veggies. Maybe mixing them into the stew is a better way to get that child to partake in the veggies, right? So, what I'm driving at is that all these technologies that you just mentioned, AI, ML, IOT, they are being consumed, but maybe they're not just the star of the plate, right?
And I think we need to separate them out in buckets for a minute, because, IOT is happening, and it's happening in a number of verticals, and IT is the one implementing it. So if we look at industrial IOT, that's booming, and we look at technologies like manufacturing, transportation, utilities, healthcare, smart cities, they're implementing in a big way. And so if we focus on a smart city application for a minute, we know of a client that integrated their water meter technology with Azure cloud, and this made them capable of tracking real-time water consumption.
It was the IT folks that did this, right? And this project involved 50,000 smart meters. And what they were after was they were after looking at the consumption and trying to really optimize that water flow and save gallons of water and they were able to do that. And again, it was the IT team that did this. The second thing that I want to talk about is how some of the technologies that you mentioned, while they're not the star of the plate, they are being baked into tools.
For example, you look at AI and you look at how many security vendors are baking AI into their as a service tools. And the IT guys are utilizing AI with maybe not even realizing how much they're utilizing AI. So if we look at a SEM, for example, and a SEM as a service tool, you've got AI looking at the log files to determine what is a real threat and what isn't, instead of having somebody spend the time to go through the log files.
You're looking at AI in action and IT teams are using that. So I think that focus is a really interesting word. I think we're getting what we need in doses and we're going to learn to expand upon that. That's my answer. >> You know I liked that answer and the fact that you focused on focus. , to the larger team panel, do you guys think that this is a opportunity for IT infrastructure, IT in general, to take the horns of it, and to start to create, basically, infrastructure as a service for AI.
AI and ML being like disciplines of IT proper instead of kind of sitting at that application layer where I think it sits today. >> Yeah, I'll jump in there, Keith. I think that's absolutely something that needs to happen. It needs almost to just kind of blend in there and be, like we don't talk about electricity, we talk about what we do with it. I think artificial intelligence and machine learning are going to be the same way. And so one of the things that we see, our cloud research team tracks something like 400,000 different ways that you can do cloud services today.
You can't do that in a spreadsheet anymore, but if you use automation and intelligence, you can find things, for example, like, had a conversation the other day. Everybody wants to embrace paths and database as a service and stuff like that. There is a tipping point in almost every cloud provider, Keith, where when you're over certain amount of memory, right around 64 gigs or so, it's actually cheaper to run that on-prem. And so what you need to understand is help me automate the tipping point where the juice isn't worth the squeeze anymore.
So we should absolutely be doing that. That's just baked into how we make good decisions. >> Hmm, I think one of the challenges with that approach is when we look at something like AWS, they announced a couple of years at re:Invent, these solutions that are generic and consumable, you know, hot dog, not a hot dog, these forget-the-LANs solution that they deployed, do we have the skill, and this conversation will be focused on the skill, do we have the skill within the enterprise IT scope to even consumerize the solution so that we're providing it as a service of IT?
>> Do you actually have to do that, though, I think is one of the questions that I'd ask. I mean, one of the interesting things is IT as a broker for cloud services, right? That's the governance layer that kind of connects their internal consumers with the right services and helps them understand how that fits into considerations like where data lives and how the networks connect and things of that nature. Even if you decide to go cloud-native with some sort of AI and ML solution to solve your specific application problem, it doesn't mean that that's an island, that your data scientist necessarily goes to the cloud, writes his code and has no effect on the rest of your IT infrastructure.
I mean, hopefully, if you're leveraging a SAS service like that that handles something like image recognition, it is doing a lot of the upload for you. It is meant to get, I think, the IT folks out of the way of having to worry about that from an infrastructure perspective. But I think that application doesn't live in a vacuum, and so how it connects to all the other things that you're doing is still the domain of IT and super relevant. >> I think you have to kind of break it down into different layers.
To answer your question, Keith, the first thing that I would look at, in terms of does IT have the skills, depends on what aspect you're talking about. Are they building an internal public or private cloud type of environment or are they moving to public cloud? And those are two very different aspects because you're essentially building a whole service off of an architecture that is somewhat foreign to you, somewhat different from what you're traditionally doing. Whereas consuming that service is a much lower hurdle, relatively speaking.
So I think it's important to understand the differences there because that then leads to some of the issues why people are repatriating workloads. But I do think, to Bobby's point, you do get to a point where you realize that the public cloud vendors are really just providing a general purpose service. I mean, yes, they have different versions of that service, but all of them, all of the major providers, they're all geared to address the broader community of potential customers. When you get to a certain scale, a certain size, or you have very specific requirements to be able to tune your infrastructure for a given application or workload, that's when things start to get problematic for the general public cloud providers, and you start to look at alternative solutions.
But that doesn't necessarily mean you're bringing it back into your corporate data center or running it the way you used to run it. >> So, Tim, I think this segues into the second question. " And he categorized the business as these people that were using this CI/CD process, which, I think both me and you will agree, would be IT. CI/CD is a process that the business doesn't care about. That is a IT process. I'm tempted to ask whose fault that is that that perception persists, but we are here for direction.
How do we enable, and more importantly, empower our teams to learn more about business drivers so that we can get back to that talent question that we asked before, which was do we have the talent to deploy AI? Well, what do you mean by AI, and how is that relevant to the business? We need to get to the core of that answer. So how do we empower our teams to engage the business? >> Yeah, so first and foremost, stop calling it the business.
IT is part of the business, right? And when you start to talk about there's IT and the business, you start to create this us and them culture where IT is different, or people outside of IT start to think that IT thinks they're better than everyone else. It doesn't end well is the point. And so it's important to understand that we're all part of the business. And when you create that construct for your vernacular and your conversations, you also start to build relationships with those outside of IT.
And that's really important because you need to understand the nature of your business. And that becomes the context in which you build the right skills to determine, okay, here are the business objectives that we're trying to achieve, all of us, those inside of IT as well as outside, as well as trying to understand what technical skills are going to be needed as we start to mold which technologies fit in to address which business objectives. But I always confer back to you have to look at your business, the nature of your business, understand how you spend money, how you make money, how you engage with customers, understand what the board objectives are, the C-suite objectives are, understand each of those tiers.
When you do, it starts to become clear where you should be putting your energy and where you should stop putting your energy. From there, the other pieces can start to fall out in terms of, okay, where do we have gaps? Where do we need to maybe shift resources or shift skills or fill some of those gaps in skillset. But that's where I'd start. >> So, question to the larger panel, where have you guys seen this work and not work, what are you seeing in the field?
Oh, that's a stopper because, I'll tell you why. I worked for VMware, when I spent a lot of time working for VMware, I saw acceleration of the number of customers that I met. Me and my small firm, I can only meet so many customers, I have so much reach. , and it was really all very similar that no one really focused on the end product of their organization. It was all about, how do I reduce costs? How do I reduce my storage costs?
How do I optimize for de-dupe? How do I lower my VMware bill? It was nothing about accelerating the business. So I think it's rare to have this conversation, especially within our, and when I say our, cause Tim is an exception, Tim and Jo are exceptions, within our infrastructure-focused view that we just don't always align to the business. >> Jo: Let me say something, if I can. >> Go ahead, Jo. >> Okay, so I have a friend that's a CIO that is super forward-thinking and he went into a new organization and he aligned with the CMO.
And, yeah, by aligning with the CMO he was able to come up with some really great ideas that was going to not only drive further customer satisfaction, but some of the stuff that they were doing was actually going to decrease time to revenue. And I thought, man, I love this synergy. I wish I saw this more, it was so refreshing. >> I'll piggyback on what Jo was saying. Keith, I think you and I have talked about this before. We say all the time in corporations, people, process, technology, and I think that's actually not a great terminology.
People, process, product or people, process, problem. What is it that we're trying to do for end users or customers or what is the problem that we're trying to actually solve? We lose sight of that, fall in love with the tech, and then we're down in the bowels of the data center of the cloud and we're like, "What are we doing again? "Who are we doing this for? " That should be at the forefront, as Tim and Jo were talking about. >> You know, I'm building the CTO Advisor data center, and I had to go to the data center today, and one of the things I, literally, I was going to the data center to do two things.
One, to plug in a USB drive, super low level techy stuff. That's the only thing that they let allowed me to do. One, plug in the USB drive and two, plug in a cable, and (distortion drowns out speaker) ask myself, and I tried to ask myself, what value is this bringing my target customer when this is complete? Why am I taking time out of my day, because I'm not a tech, I'm not a engineer, why am I taking time out of my day to go plug in a USB port, and a console cable?
And I think if you constantly ask yourself that question and go through that exercise, you start to connect the value of what you do to the business, and more importantly, 'cause Tim talked about this before, if you want to know how much something costs, outsource it, you start to recognize the value of the thing that you do and whether or not you should do it or if you should just simply pay someone else to do it, it's not worth your time. So Bobby, you spoke up last, therefore you get the next question.
We've talked about the soft skill needed to make these complex things. However, we have both you and another CTO on the line, Matt, and you deal directly with analytics. So I'm going to ask you what sounds like a simple question. Who's the customer for workload costs in transformation analytics and what are or should be their use of that data? >> Okay. I would say it's probably typically most often the CIO, or the VP of Ops Transformation or sometimes the CTO.
That's usually the individual or the team that's the biggest recipient of this. But Keith, if you let me expand the question a little bit, part of what end up happening is, again, and I've said this before, the technology's the easy part. Thinking about who we're serving, thinking about what we're ultimately trying to do. And I'll tell you something that I came up with in the past week or so. We are falling in love so much with the technology and the tooling.
We're not failing for lack of tooling, we're failing for lack of planning. And the issue that I think we're having is when you think about tools in technology, those help you with better answers and faster results, not better questions. And the problem that most of us are having is that people are not asking the right questions. And so, ultimately, when we go back to the CIO, again, kind of juxtaposing a lot into the stuff we've talked about, what is the problem that you're trying to solve for your other peers at the leadership table?
It's not just about a data center, it's not just about storage, it's about how we're trying to enable our customers, it's around how we're trying to do things better, to transform, to be more nimble. We're not connecting it to the why. So, in theory, the CIO should be asking why and how they enable the other peers. The CMO, the business units, the line of business executives and stuff like that. That's not happening as much. >> Part of my job, lately, has been engaged certainly with people who are wrestling with data challenges.
The platform that we're running which both helps people connect data from on-prem into cloud environments as well as take the same pool of data and attach it to multiple clouds at the same time has given me a chance to engage around some really interesting use cases. I will say that maybe just because of bias towards what we do, we tend to be solving things, maybe, that public clouds are inherently not good at, especially if you want to use multiple clouds, which is these very large data footprints where data gravity becomes a huge problem because it's so difficult to move from one cloud to another.
So I've been exposed to a lot of use cases that are much more big-data oriented. And in that, it's interesting because I've seen this trend with this particular aspect, even though, at the end of the day, it's still technology, it's gotten completely away from the traditional IT consumer. Just to have some examples, I've got Chief Architect at a healthcare company and he's completely oriented around solving problems for healthcare patients. It's not really even an IT discussion, right? A data scientist at a enormous firm doing genomic analysis, where his whole company is oriented around how do we process genetic data, how do we do it more quickly, and very specifically about different use cases.
" How do we deal with that hyper-performant version and how do we get those two things to coexist? If there's a need for a very rapid scale up of genomic analysis, I think the COVID situation's probably made us all sensitive to even a use case like that, how do we deal with those? Even the people dealing with self driving cars. How do we process hundreds of petabytes of data so that we can retrain a model about how a car can drive itself?
These questions are both fascinating and they also get completely away from traditional IT both in the way that they approach it, because it's so completely business-driven, as well as the way that they approach the technology because the requirements look so different that I think that sort of, air quotes, "traditional IT workload" that you see in the enterprise. And I think the other side of the coin there, when you think about traditional enterprise where I see a lot of interest and a lot of engagement on these, really is about, I think IT folks need to have just a little bit more of a mindset around developers.
A lot of this stuff that we're doing today is so oriented around software productivity. Tim, on the last time we got together made such a incredibly cogent point, it still sticks out in my head, really, about how these giant grown-in-the-cloud companies typically manage one or two apps, at enormous cloud scale, but the typical enterprise actually ends up managing hundreds or thousands of apps, often at very small scale to do very specific tasks. And that whole sprawling-line-of-business thing is a huge concern. And I think at the end of the day, the value you get out of those applications as a business is totally derived from what your developers can do with them.
How fast can they iterate on it? How fast can they deliver new value to the business with those apps? And so I think having that super developer-oriented mindset in IT about how you empower them to make quick progress is absolutely critical to how you deliver value to the enterprise. >> That was a mouthful. So let's spend a little bit of time breaking that last part of the question up. I think it's obvious that I love the genomics example, because I have a farmer background and that was one of the most challenging parts of providing infrastructure to them is getting the data where they needed the data and where they need data is not always where the data was produced.
So, if you get it in the clinic and then you need to move it from a clinic to a HPC cluster, how does that functionally happen, and how do you design a system that that allows it? And then, secondly, how do you get to the right person to have those conversations? We talked a lot about the Enterprise Architect, in the last session. Let's talk about the role of Enterprise Architect in all of this that we just talked about. Is the Enterprise Architect the right function to be able to stitch all of these conversations across workload types, business outcomes, and the point at which we're actually talking to Tim, forgive me, "the business", about the value of these systems.
Is it the EAs? That just seems like a lot of responsibility. >> I'll jump in on that, Keith. I think that's a lot to expect any one person to be able to do, but the Enterprise Architects probably have unfair expectations on their plate. Now what a lot of VAs are doing is they're fighting the wrong battle. They're fighting about IAAS and PAAS and SAAS and CAAS. We had a discussion on social media about that the other day. In my opinion, I'm going to introduce a new term here to remix, I think all the public providers to a certain extent are pushing CAAS, but not containers, confusion as a service.
There's too much stuff to figure out what in the world I'm supposed to be doing. And the reality is I need to come back to what is the problem I'm trying to solve, so I'll simplify it. I want to piggyback on something that Matt said. If I'm an Enterprise Architect, I should be able to solve this question. What are the three D's of data? Talk about data storage, data transport and data organization. Databases, data lakes and data warehouses because we know data is the lifeblood of the enterprise.
That's really where the rubber meets the road. If an EA can at least start to think about data, then I think it expands their mind beyond tooling and technology to think about how this is going to be used throughout the entire enterprise. But most can't do it. >> There's also a simple question, though, Bobby, that they have to be asking first and that's how and why. And so this is the part that I think gets lost in translation and where we kind of get wrapped around the axle is we get so caught up, and we've seen this, gosh, I can't tell you how many times I've been in conversations about data warehouses that went on for months, trying to architect the right schema and the right architecture for that data warehouse.
And guess what happens a month after it goes into production? It needs a change. And so my point to this is that I think we put too much structure in I'll just say the broader IT organization, and we really don't encourage nor give people license to think. And so I think this is where we've kind of lost creativity in IT as well, to step back and say, "Okay, I'm an Enterprise Architect. " Well, probably not. So who do I need to bring into that circle to be able to have that fruitful conversation so that we are working cohesively as a team rather than this just coming down to one person or one given team.
Usually, at least in the organizations that I've led and been part of, it's not typically one person. It's usually, the EA is a function that's a team of people. So larger organizations. But I do think, to your point, you have to step back and ask yourself, so what data, where's it coming from, how's it going to be used, how could this be changing down the road, how do we ensure that we're creating the right degree of flexibility because we know that, and the last 120 days are a perfect example of this, the world has changed on a dime.
And guess what? Six months ago, you could have said the same thing, that the world is changing. We're working very differently, our customers are looking for something very differently. The technology that we have access to is very different. And so we have all of these opportunities, but we really need to encourage our staff to that license to think and be creative and help them be more involved in the process than they have been in the past. >> So, I want to wrap this up in the next five minutes and if anyone in the chat wants to chime in, let me know.
This is a lot. I mean, we've covered a lot over the past two panels and obviously not every organization is going to have all the skill they need to even start. So they're going to need to go out and get help from folks like Tim, from folks like Jo, even from our vendor friends. Bobby and Matt have added greatly to the overall conversation. What types of questions should we be using or asking to filter out if the advisor or the vendor has done their homework and they really know how to do the hard work?
Because we see the marketing material, but once we pull back that layer, we're like, ah, you know what, my team could have provided much better commentary than what I've gotten from these advisors. >> Boy, I haven't really thought about that. (Jo laughs) There's been this consistent advice from this group, which is understand the thing that you were trying to do at the business level before you go and embark on these projects. The fantastic litmus test for your vendor is get engaged, articulate that business problem.
What are you trying to solve for? What are the parameters? And then get to a position where you can ask them to kind of give that back to you. What do you think you're solving with whatever it is that you're proposing and don't listen to the speeds and feeds part of that conversation. Don't pay attention to, it's the flash hotness this or it's the cloud agile that, listen to, if they can articulate the business challenge back to you and they understand what you're solving for, that's a great first step, at the very least.
>> I'm going to answer different. That was good, but, 'cause the driver's important. We always say to them, okay, what's the driver for this project? And we get like this various set of answers sometimes. They're not able to clearly, customers aren't able to clearly articulate what the driver is. Well, because we think we should go to the cloud, or we think we should do this. Well, no, why are you doing this thing here? The other thing that I want to share with you guys, it's super fun and super interesting, is we put together a scorecard for the IT team.
We're agnostic, we don't really care who they pick, and we put together a scorecard for them and we send it out to the decision makers in the group and we ask them to just answer the scorecard and send it back to us. And how they pick a vendor and what they think is important is so telling to us. Because, think about, for a minute, how vendors get picked. How do they get picked from an IT team? Is it a consensus, did somebody just raise their hand and say, I like this guy, I like that guy, I like this other guy?
Bobby's shaking his head. Bobby, what would you say? >> Honestly, who went to golf or who went to dinner with somebody? >> Yeah, and I want to also add to what Jo was saying. You know, a lot of times, folks, and also what Bobby was just commenting on, a lot of times it's who you know, right? Or who do you know that someone else, it's that one degree of separation or two degrees of separation. But I think that the piece you have to be careful about is you need someone that understands your business.
Because at the end of the day, and I'll harp on this again and I'll sound like a broken record, but you've got to understand your business (distortion interrupts the speaker) and foremost. Otherwise it's just tech for tech's sake. But the same thing should be true for your vendors. They should understand at a fundamental level. And I don't mean the motherhood and apple pie version of healthcare or financial service. Great, you do a bank. So people go into the bank and they get money from the ATM.
They need to know a deeper level than that, if you're talking about working with the bank. But the other piece you have to be cautious against is don't create a requirement that they have worked with your industry before. I've run across a number of cases and I'll just use myself as an example of this. The very first time that I worked with a healthcare client and the very first time that I worked with a financial services client, these are both highly regulated industries.
I personally didn't have experience in either of those industries at the time, other than just being a consumer of each of those different functions. But the reason why they brought me in was because they didn't want someone that was jaded to that industry. " They really wanted to bring advice and expertise from other industries to bear. So, for example, I could bring a major airline into healthcare, or healthcare into financial services. So, it's important to understand what they've done but don't create a requirement around it.
How flexible are they in terms of really doing their homework and understanding? For example, if you want to ask them, and this is a great test, ask them what they think, ask the vendor what they think, your top five objectives are, your top five core issues are, and see if you get two to three of those that match up with what your business objectives are. If the answer is yes, great. If the answer is no, move along. >> Yeah, and some advice to vendors, because I've been there as a vendor for a very short period of time and even in my role now advising folks, I don't wait until I have that meeting with the person who cares about that.
Everyone should care about that question, but the person who's going to make the decision based on that answer, I should already know the answer to that question. Great question, but the part of doing the homework, and not just vendors, if you're looking for a job, and you want to work in one of these forward-thinking organizations, do your homework. Homework isn't iSCSI versus NFS versus file that really doesn't matter in the long run. That stuff will work itself out. What works itself out is if you can describe why iSCSI, if at all makes a difference to reducing the wait time for someone sitting on a bus stop, then that absolutely matters.
If it doesn't, you know what, let the vendors figure that part out. This is where IT is moving in my opinion. Any last comments, questions from the audience? Bobby, I see you kind of have something percolating, burning, that you want to get out. Anybody have anything they want to get out before we wrap up? >> You talked about vendors, Keith, and I think when it comes to the enterprise, if I was sitting in the seat of an executive making a decision, I don't want to know your success, I want to know where you fail.
I want to know where there was a dumpster fire when you were done. Now, you pulled it out of the trash can and you're a savior, but something crashed and burned and it was hideous because the challenge that we have, Keith, in any sort of cloud projects is that our time horizon is too short, and I'll tell you what I mean by that. The definition of success is too short-sighted. Does success mean you got to the cloud or does success mean that you can get out if you need to?
Does success mean that you didn't have to retrain or fire all your staff? How many dead bodies were there when this thing was all done? Too many of us are in the first generation, maybe second generation of this, and we're redefining and figuring out what success looks like, so, from a vendor, I want to know where stuff has not gone well before, so that I can learn from that and not hit all of those landmines. If you're not willing to be honest with me about that, I've been married 20 years, Keith, I'm not going to buy a book from someone who just got married yesterday.
Love your thoughts, but it's on paper, it hasn't been proven yet. >> But the reality is, Bobby, I mean, let me counterbalance that. The reality is, from a customer standpoint, I'm not going to tell you where my problems are, or where I've had issues. And the reason why is because most vendors have burned that torch profusely. So that's just open shooting field, right? It's like, just open up the wallet and it's just shooting fish in a barrel. I was so surprised, went from my role at PWC versus my role at VMware.
At PWC, it was open the kimono, I know that's overused, but it was like, here's our problem, help us fix our problem versus, from a vendor perspective, yeah, I'm not going to tell you what our problem is because you're trying to sell me. >> Yes. But Keith, this comes back to the reasons why that does work in certain situations and not others. And it goes back to relationships and trust. If I have trust with you, if I trust Bobby, yes, absolutely, Bobby, come on in, close the door.
I'll tell you exactly what's going on. Here's my list of issues. Any of those you can help me with? Great, pick and choose. But if I'm going in and I just met Keith off the street and Keith comes in, I'm not going to share it with you, until we build that trust, we have that relationship, and then, it's just like Bobby. I'm going to share what's going on. >> Again, Tim, and I agree with everything you were saying. The challenge that most of us have is that people are asking the wrong questions.
It's like, you're right, trust comes in because there are a lot of consultants that said, "Okay, you asked me how much compute "is going to cost me on Amazon. " What I didn't tell you is all the other stuff like egress and chattiness and- So, I need to be able to tell you, this is what you didn't ask me, Tim, that you should have. And if I can't earn that right, then, again, it's not the tech, it's can I steer you or lead the witness so that you don't come up short just because you didn't know to ask the right question.
A lot of us have soldiers pointed in the wrong direction. We brought firepower to the fight but they're fighting the wrong people. >> That's right. >> I come for the conversation but stay for the Bobby's analogies. Jo, did you want one last comment? >> Yeah, I was going to say, guys, let's talk about a metric-driven approach to a decision. Let's have some quantifiable reasons, both hard and soft, meaning cost-based, features, functionality, that we utilize to make that decision and take that up to the CIO, instead of just picking somebody.
How about that? >> So we'll close out there. We have had two really great conversations. We've all sent this to our network of folks. You'll be able to see the replay of this on YouTube. It'll come out as another CTO Advisor podcast next week. Share it with your fans. If you guys have any questions, hit the folks up here on either Twitter, 'cause we're all very active on Twitter, or at our respective portals. We'll end out with everyone saying where people can reach them, if you're listening to this in podcast format.
Let's start out with Bobby. com. Thanks for having me, Keith. >> Thank you, Bobby, Tim? com. >> Matt? >> Yeah, Twitter, it's just @MattWallace, so that's pretty easy to remember. com if you want to email me. >> And finally, but not least, Jo. >> I'm @digitalcloudgal on Twitter. >> And you can find me on Twitter @CTOAdvisor. And obviously you found me somehow because you're listening to this. Talk to you next CTO Advisor CTO dose.
