All Things Pivotal Podcast Episode #19: Welcome Cote

March 11, 2015 Simon Elisha

featured-pivotal-podcastWhen creating content on an ongoing basis for an international listening audience, variety is key. The All Things Pivotal podcast is a constant “work in progress” as we seek to provide our listeners content that is interesting, informative, useful and relevant.

The content will continue to be a range of technical detail, industry trends and interesting interviews. To that end, Michael Cote is joining the All Things Pivotal podcast as co-host to provide an additional voice and raft of interesting content for our listeners. You can learn more about Cote’s background and why he joined Pivotal in his recent Pivotal People profile blog.

So stand by for an even more varied range of topics, guests and insights. This week Cote & I had the rare opportunity to be in the same city (San Francisco) so recorded an episode discussing Cote and his background, as well as the kinds of conversations we are frequently having with customers.

PLAY EPISODE #19

 

Resources

Transcript

Announcer:
Welcome to the All Things Pivotal podcast. The podcast at the intersection of agile, cloud, and big data. Stay tuned for regular updates to technical deep dives, architecture discussions, and interviews. Please share your feedback with us by e-mailing podcast@pivotal.io.

Simon Elisha:
Hello everybody. Welcome back to the All Things Pivotal podcast. Fantastic to have you back. Coming to you live on tape, as they say, from beautiful San Francisco. In fact, I’m sitting here in an amazing room with an amazing view over the Bay Area. I can see the Golden Gate Bridge, but I’m not alone.

I’m joined by a new voice who is joining the All Things Pivotal podcast, Mr. Michael Coté, better known as Coté in the technical podcasting community. Welcome, Coté.

Coté:
Yeah, thanks. This is one of the best views of San Francisco I’ve ever seen, and not from a hotel.

Simon Elisha:
Yeah, clearly there was a booking anomaly.

Coté:
That’s right, and you got a couch in here.

Simon Elisha:
I know, it’s fancy.

Coté:
Very fancy accommodations.

Simon Elisha:
Kind of comfy.

Coté:
We can have a different show than the usual monologuing of knowledge that comes out of the show.

Simon Elisha:
You’re correct. It will not be the delivery of knowledge; it will be the discussion of knowledge.

Coté:
That’s right.

Simon Elisha:
Coté, tell us about what you’re going to be doing at Pivotal.

Coté:
I work in, for some reason we call it technical marketing instead of product marketing, which is fine, but I work in that team.

Simon Elisha:
Does that mean you code?

Coté:
That’s right. That would be scary for Pivotal Cloud Foundry. I’ve been here since, I guess a month now, and I made sure to sign up for my health insurance benefits. I cleared that 30-day window.

Yeah, I think basically, there’s just a lot of explaining what it is Pivotal Cloud Foundry is up to, and how people are using it, and why it’s a useful engine to use the old Thomas the Tank thing.

I was having dinner with some people last night. I came here to speak about continuous delivery at a little Heavybit event, and they had all their customers and start-up people afterwards.

There’s a re-occurring conversation that I end up having when I tell people I work at Pivotal, and people know about Hearts of Pivotal. Usually everyone knows about Tracker that I come across, which is interesting.

Then you kind of explain all of the rest of the portfolio that they have, and they’re usually interested to know more, which is a glass half-way full of what it’s saying, that there’s a lot of explaining ourselves.

Simon Elisha:
There’s a lot of work to be done, and I think it’s interesting, because kind of depending on the perspective you come to for the questions you have as a customer, be it you’re embarking on Agile, or you’re struggling with Continuous Delivery, or you’re wondering what this Market Services thing is or detecting the whole data thing.

Pivotal can look different to different people and has different benefits and opportunities for people, so that’s …

Coté:
Yeah. No, I think that’s exactly the case. I’ve been an analyst off and on for several years, and what I tend to fall back on doing in analyst work is trying to … I don’t know, these are a bunch of cheesy cliché phrases, but sort of explain big picture things.

To your point of, what’s if we zoom back from the various little projects and technologies? How does this sort of all fit together?

I think there was some good talks. We’re here at our sales kick-off. There was some good talks rallying the troops internally, doing I think some pretty good sort of complicated web of big pictury visions.

They were nice, and it’ll be fun to go through all of those various themes and things that people have been talking about, and customers and prospects have been asking us about over the last year.

Simon Elisha:
Exactly.

Coté:
Really just explaining those out. I mean, it’s almost as if … I think there are maybe ten or so different, we’ll keep calling them themes.

Simon Elisha:
Yeah.

Coté:
We’ll use insider-marketing talk, but themes that people are interested in. I feel like a function that I have, and other people on my team have, and to a certain extent yourself as well, is this is a table top that we’re looking at. Now we need to make sure there’s legs underneath it. There’s a whole bunch of conduit underneath all those round tables.

Simon Elisha:
It’s layers all the way down that we have to go through.

Coté:
Yeah, and this is … What episode is this?

Simon Elisha:
I think we’re on 19.

Coté:
Yeah. I mean, the sort of almost 20 episodes in, and I mean you’ve been carving out a whole bunch of legs. Each episode is part of the portfolio, and the suite, and everything going on there. I think that’s great.

I, myself, consume podcasts a lot, or I’ve almost shifted into the … I download a lot of podcasts that one day I will listen to.

Simon Elisha:
Well, this is what I call the matrix theory of knowledge gathering, whereby downloading it you already know it.

Coté:
That’s right.

Simon Elisha:
First you have to read it, or listen to it.

Coté:
Right. It’s sort of like if you’ve got a gigantic, to use the metaphor ‘podcast lake’ in front of you. Surely you’re not this thirsty, whether you’re drinking or not.

Simon Elisha:
Exactly, but it’s interesting what you said about that big picture piece. Often when I speak with listeners of the podcast, etcetera, they talk about the fact that one of the things they struggle with is explaining internally why they’re interested in a particular technology or design pattern, etcetera. Part of it is it challenges IT professionals to explain the big picture to internal stakeholders.

You look at something like Blue/Green deployment. Very cool, exciting. We know we can do it. It’s the way of the future. It helps with continuous delivery, etcetera, but how do you sell that to a line of business manager or a business stakeholder? They could care less about that technology.

Although we’d love to talk about it, they’re really bad if you could tell them how you can get your product in the hands of your customers without any disruption, any time, and be continuously improving it all the time.

Is that interesting to you? They’re, ‘Totally! I want that,’ but if you say, ‘Hey, let me tell you about Blue-Green deployment,’ they’re like, ‘Eh.’ Not so exciting.

Coté:
Right. It’s a little hammer before talking about the house you’re going to build. There’s all sorts of interesting hammers. Yeah, that’s part of what was interesting to me about Pivotal, just sort of defeating as an anti-boredom measure as an analyst.

When I was working on strategy at Dell, you spend a lot of time in that exact situation you’re talking about, where here’s all these technologies, and how do we get business … How do I explain the business side of it? I think that’s definitely in the past.

I was at 451 Research for about a year and a half, and that’s what I would encounter with enterprises, as everyone calls them all the time. It’s, ‘So I think I want a cloud, and I know that’s supposed to result in something awesome. Can you help me fill in the details?’

Simon Elisha:
‘What would that actually be?’

Coté:
Yeah, and I always think it’s easy as technologists to kind of make fun of that situation, but I always think of myself and the issue I have with financial planners.

I always go to a financial planner, and I want them to not ask me questions, but of course the first thing they do is ask me a bunch of questions. I feel like if I knew what my personal financial goals were, I would not be here talking to you. I think that’s a large part of all of us, whether we’re at Pivotal or other places, when we’re taking all these new technologies from the consumer cloud world.

In the consumer space, they don’t have this problem, because their job is just to make consumer’s happy. They don’t need to explain their technology. What we have to do more on the enterprise side is explain why these awesome technologies … What they are, and how they connect to actually doing something for you.

Simon Elisha:
What matters.

Coté:
Yeah, instead of being like those damn financial planners, who are always asking me what my life goals are. Terrible.

Simon Elisha:
It is always interesting when you shift contexts or domains out of your own domain of expertise into something you know nothing about. It’s, ‘Ah, that’s what it feels like.’

Coté:
Yeah, exactly.

Simon Elisha:
I’ve got to change my perspective and be a little understanding. I guess we should probably talk about what we’re going to be doing with the podcast going forward, because certainly one of the things we’re getting our arms around is doing both that big picture interview, but also diving deep on certain topics where it suits, and then interviewing the right people at the right time.

There’s a bunch of ideas coming. Shall we share some great planning thoughts, if you like?

Coté:
Yeah. Well, I’ll tell you what I’ve been thinking of doing, and people I’ve been trying to line up is … What are a few examples? I mentioned I was at this Heavybit event yesterday, and I ran into a couple of people there that I think our representative of the types of interviews or episodes, whatever you want call it, that I’ve been thinking of doing.

One of them was this guy Jacob, who’s the CEO of Apire, or A-P-I-R-E. I can never figure out how to pronounce things nowadays. Basically, they do … I’m sure they have a fancier way of pitching it, but they help you do your docs for APIs. Which, if you think about it, does become quite a bit of a problem if you’re doing all your ‘microservicey’ kind of stuff on a month or a weekly turn, and if you’re not documenting it, then that’s a mess.

It was funny, he was joking in his presentation, ‘I’m going to use the G word. Governance.’

Simon Elisha:
Everyone recoil in horror?

Coté:
Yeah. You know the room was pretty hip to things, but yeah, it was a good joke. It’s the equivalent of process seat belts. You would be kind of crazy not to just wear a seat belt when you’re driving around.

Anyways, he had one slide in particular that was great, and he was saying, ‘So this microservice and stuff, how is this different from SOA?’ He only spoke to the slide three minutes or something, but I thought, ‘That’s a whole presentation you could do.’

Someone who knows the sort of mindset and thinking of SOA really well, and then someone who knows microservices stuff really well; it would be great just to sit them down and have them explain how these things are related or connected. To be a Rosetta Stone, if you will.

Simon Elisha:
Exactly. Or we could do it Thunder Dome style where it’s two man enter, one man leave smack-down.

Coté:
We’ll get Anne Thomas Maines out of retirement and have her come battle the microservices kids and see what results from that. Along those lines, there was a guy who does a lot of API evangelism stuff. We ended up talking, and he had a more impressive beard than I did, so…

Simon Elisha:
That’s saying something, because yours is a pretty good beard.

Coté:
Yeah. He was walking dangerously close to the hobo line, which I get to every now and then.

Simon Elisha:
It’s a fine … It’s almost like the hipster.

Coté:
That’s right. There’s an artistry to it, so there’s much respect there. Similarly, he was going over lots of projects and work he’s done of just not even really using the word microservices, but just wrapping an API around something.

There was one story in particular he was telling that I really liked, which was I was helping some people figure out API management solutions … products and offerings. We heard pitches from a few people, and then finally they said, ‘What do we do to deploy these APIs that we’re developing?’

There’s sort of an epiphany that he had in his head which was sort of, ‘Oh, wow. These guys are way at the beginning of this,’ because API management is sort of once you already have APIs. It’s sort of, you’ve got a bunch of problems and you were sorting it out, but you haven’t even built the problem-generating machine yet.

Just having an extended conversation with him about what that is and what he’s seeing there. I think across the board of … If we divide the world into, I guess we can use the idea of bi-modal IT, which is sort of like your old IT that just is functioning and doing things, and you’re going to quarantine it off and maybe not worry about it.

Then you’ve got this brand new Greenfield IT, where you’re trying to do something interesting with software. I think in thinking about both of those schizophrenically-like types of managing IT, we have a lot to speak to to both of those scenarios. It would be nice to connect that stuff up more.

I really just want to figure out the stories, and experiences, and questions that people are asking out there and document them. For example, you talk with customers and people out in the field a lot. What are they worried about or are questioning about?

Simon Elisha:
Yeah, for sure. Well, there tend to be common things that come up. Every customer is slightly different, but there’s always that common thread that comes through.

One of them is speed of delivery. You can get into nuances of what software methodology you’re using or what your tool chain looks like, but before it, it’s just, ‘How do I move faster?’

These are heaps of organizations that are used to maybe a quarterly release, very often an annual release. It’s this whole, ‘We’re really scared of releasing. It’s high risk. We’ve got to go slow and be careful.’

It’s a complete inverse thought pattern to how the Internet giants do it, which is, ‘We’re going to release often. We’re going to encourage it, and you’ll get so used to doing it, it won’t even be special for you.’

You look at companies like Amazon when they’re releasing every few seconds. You have companies like Facebook where, certainly in the past … I think they’ve changed a little now, but in the past, your first days as a developer at Facebook, you push code to production. Welcome aboard. We’re just going to rip that bandage off, and that’s what you’re going to do.

A lot of organizations want to get to that end point, but again, as you mentioned earlier, what are all the steps to get to that outcome? What are all the concepts you have to go through? What’s the tooling you need? What are some of the things that may exist in your environment at the moment that might stop you from getting there?

There’s a massive cultural change piece that has to get on; that’s huge as well. That sort of conversation really comes up a lot.

Coté:
Yeah. It’s interesting you mention that, because this event I was at yesterday, that was a major theme throughout all of the talks. It was almost, now that you have this continuous delivery engine, now you have five problems. Just merely having the tool.

It’s hard enough to get the tool in place and do this, but it’s important to focus on not only keeping up with the speed that this almost forces you to operate at, but also to realize the potential of what you have.

That’s one of the things that I speak about often, is sort of in the devops world, we’ve been developing this idea of a service delivery platform for a long time, sort of this pipeline.

One of the things that’s often spoken about but kind of left out of the kind of cold and dry analysis of it, is this idea that you’re establishing a feedback loop. That you can start feeding into your decision making and your product management.

I think for a programmer or a technologist, it’s pretty obvious what you do with a feedback loop, because that’s kind of what development is. I’m going to type some code, compile it, run it, and see what happens, so you know the efficiency of a feedback loop.

One of the things, especially with the customer base that we have at Pivotal that I’m excited to figure out is, so if I take that to a business person, do they know what to do with a feedback loop.

It feels like some businesses know what to do with a feedback loop, because they’re the ones who are always updating apps on my phone and adding new features, whereas other new businesses I feel like, I don’t know, maybe they’re sorting their backends out, and so there’s a bunch of things they’re doing, but they’re not really … I would love it if they analyzed how I and other people were using their software, and started changing it and moving it around.

Simon Elisha:
It’s interesting. This comes up again as a cultural challenge as well the folks who manage and have custody of a lot of that information. I talk to a lot of customers around operationalizing their data, and there’s really exposing it and letting it out.

Coté:
Yeah. No, that’s a good example.

Simon Elisha:
I was speaking at a conference in Australia that was specifically around chief data officers, and it was almost 50/50 in the audience of those who were very open to people accessing data and wanted to make it a valuable asset for the organization to actually use it.

The other half of everyone totally what I would call the Department of No. Seriously, I’m talking about, ‘We need to reduce the number of people who can access this data. We need to make it harder to get to. We need to increase governance,’ etcetera, but they were sort of conflating governance and access as the same thing, and it’s not the same thing.

It really affected businesses, and the ones who say, ‘We’ll give you all the information you need to do your job effectively, and we’ll let you automate that feedback loop as much as you need, as long as we can tell that you’re using it effectively.’ That kind of works. It’s like, ‘Hey, no you just can’t use it. Sorry.’

Coté:
I think that’s a good example, and it gets to the … There’s a bridging thing between there that I always … Whenever I encounter it, I’m delighted by it, which is sort of never minding the Office of No. The Office of No always reminds me of security people in a software development context who … The most secure thing is to do nothing, so let’s start with that.

Simon Elisha:
Knock it off. No users.

Coté:
Especially with data, it seems like the thing that’s missing is, I don’t know whether you want to call it training, or just stories, or lore, or explaining, ‘Well, if you have access to all this data, here’s how you do something helpful with it.’

Those are the stories I’m always interested in finding. If you look through our case studies and things like that, you can get hints of how companies have moved to the Office of Yes, if you will.

Whenever we talk about culture and process, I think we’re talking about this thing I can’t describe really well, which is sort of, ‘Well, now what do you do with this?’

Simon Elisha:
So what?

Coté:
Yeah. We have this wonderful array of hammers, so what should we build?

Simon Elisha:
You’re right. It’s those examples that tend to resonate with people a lot. When I was at that conference, one of the examples I shared with the audience was around this health insurer who was having a lot of trouble with their call center.

That’s because if you’re ever around a call center, you know that the purpose of a call center is actually not to take calls, because it costs you money the more calls you take, so there’s a really big focus in most organizations of reducing the load on the call center.

They were, ‘We’ve got this website, and we’ve got this call center, and people keep ringing the call center. Something must be wrong with the website.’

Which is fair enough. Okay, so it’s not working as in it’s functional, but people who are ringing aren’t finding the information, but it’s there, so what’s going on?

We actually did a data science engagement where they trolled through all the call records and created kind of word clouds, and subject clouds, etcetera, to understand what were people calling about, and then correlating that with what the website was to say, ‘Where do we locate this information on the website?’

They were able to find, really, 50 links between the two where they could say, ‘We’re getting X percent of calls around this particular topic, because it’s buried three links deep. If we surface this up much higher, it would be much more easier to find on the website. We’ll reduce call volume by X percent.’

That, to me, was an awesome example of correlating traditionally disperate data together in a way that actually made sense. You talk to any business owner about that, they’re, ‘I get that. That’s what I … I want some of that.’

Coté:
Yeah. No, and I think that’s an example of what almost daily I have to remind myself of, is I always assume that people are using technology to its fullest, which is sort of, ‘Well, I’m sure you’ve gotten together at least an Excel spreadsheet and tried to categorize what you care about, right?’ Again and again, it’s not the case of ignorance or even stupidity. It’s just, ‘No, I didn’t even realize that that was possible.’

I always think of that one, now what was the guy’s name, John Connor in the first Terminator movie? There’s this scene where what’s-her-face asks him if he can defeat the Terminator. He looks down at this sawed-off shotgun he has and he’s, ‘With these tools or these weapons, I don’t know.’

It’s a similar thing I think that businesses have, is they just have such … They’ve got that sawed-off shotgun and some robot from the future coming after them. They know what needs to be done, but it’s really hard to figure out how to get the right kind of tools to get out of a battle metaphor.

Simon Elisha:
Exactly. It is hard, and also you end up in that kind of operational mindset, where you’re in the business so much, that you’re not looking at the business from an alternate view and saying, ‘Well, surely there’s a better way we can do this.’

If you can’t get your head out of what’s going on day-to-day it can be very hard, and then as you said, if you don’t know what is even possible, there’s less of an inducement for you to bother to do that differently. There can be no better way to do things.

I kind of take an alternate view of things in all things, and I try and look and say, ‘Whatever we’re doing, we’re definitely not doing the best way way we can do it,’ so just assume that the way you’re doing it sucks, and there’s something better out there. Let’s explore that and see if there’s a better way to do that.

I think that applies to many technical domains where they think, ‘I’ve got this now. It’s perfect.’ It’s, ‘Well, it ain’t.’

Coté:
Yeah. No, and just to finish off the question of the type of topics I’m interested in talking with people about. It would be great if there’s any listeners who want to volunteer themselves to fill in all these gaps of possibilities.

There was someone else that … I was talking to someone else yesterday, and they were saying that they had a pretty mature microservices architecture. One of the problems you have with when you’re doing microservices, one of the notions being that you let these teams … You use lose a lot of your advantage, being that your architecture ends up being the communication paths of the organization that you have.

If you’ve got five teams, you’re going to have five subsystems essentially. To use it to their advantage, basically, there’s an architectural principal in microservices that’s behind the API, let them do whatever they want. Don’t really do much governance back there, and so forth and so on, which for old school Java people like me, immediately you’re, ‘So you’re going to have a mess.’ These people are going to do something in Scala. These ones will do it in PHP. That seems wonderful.

We were talking about that, and then what this guy was saying is, ‘Well, it would seem to build up a bunch of technical debt,’ because someone writes something in Scala and then they leave, and then no one knows Scala. I don’t know why I’m picking on Scala, whatever.

Simon Elisha:
Something.

Coté:
They write something in Ada.

Simon Elisha:
Lisp.

Coté:
Yeah. Then they leave, and then no one knows how to deal with this, but he said, ‘Nowadays, you can do things so rapidly, and if you have the right kind of process in place, you basically just rewrite it all and it’s not that big of a deal.’

It reminded me of the metaphor of every now and then, the forest just burns out all the underbrush and they rejuvenate.

Simon Elisha:
Yeah, it just cleans it up. You raise a really interesting point that’s super salient to microservices, which is the big question of how big is a microservice? I’ve seen no consistent answer, but there’s a really good live answer that I’ve experienced myself, which is a company called REA in Australia, who are super smart folks on Agile and Cloud, and they do the whole thing.

They came up with a real easy benchmark for their microservices. They said, ‘It’s something that you can rewrite in two days,’ so it’s kind of like a time-bound thing, rather than saying, ‘It’s this many lines of code,’ or ‘This many things,’ because depending on the language you choose it will be a different number of lines of code. They said, ‘If you can do it in two days, that looks like a microservice.’

Coté:
Yeah. No, that’s interesting. To kind of wrap it up in a … I used to be really good at wrapping presents, and I’ve been wrapping them recently, and I don’t know what happened.

Simon Elisha:
Lost the skills.

Coté:
Like in the same way that my handwriting has gone to crap, my ability to wrap presents is terrible. To wrap it up in an appropriately sloppy bow, I think that’s an example of there’s almost this pristine Utopic goal of microservices and what that enables. That sounds good, but that seems impossible.

As we were just discussing, there’s a few … I don’t know if they’re necessarily Gladwellian, counter-intuitive, turns out type of junk, but it’s on those things you wouldn’t necessarily think of, which is, ‘Well, so it seems like you would have a mess of doing all this,’ but people who have been doing microservices, one of the things that they rely on, to use your example, is you have to be able to write it in two days. Once you redefine the scoping in what a microservice is to that, then you can start to imagine how this isn’t sort of like a suicidal architectural thing. This is actually going to be beneficial, and it doesn’t seem so crazy.

Simon Elisha:
This could actually work.

Coté:
Yeah, right. I think, hopefully, I’m going what I could bring to the podcast is, whether it’s the sort of, as I like to think of it, the dry cleaning end, the business side of the end, or maybe the every now and then dry cleaning; the kind of architectural end of the developer.

There’s a lot of little things like that where you just make common what seems sort of fantastical, and you explain how it’s actually panning out and working.

I think in software development, nowadays in particular, there’s a huge lack of that, and it’s fun just to document those things.

Simon Elisha:
Absolutely. Share what’s happening out there.

Coté:
Stick it in people’s ears. Stuff like that.

Simon Elisha:
Yeah, exactly. Exactly. With that we might wind it up, but I guess the main programming note of today is that they’ll be many, many voices on the podcast going forward, which is fantastic. Lots more content. Lots more varied content.

I think Coté and I may actually chat to one another time from time to time, time zones permitting, but you’ll get lots of good content from a variety of sources, as ever.

If you have feedback, we’d love to hear from you. That’s podcast@pivotal.io. We do get a lot of listener feedback, which is great, and we respond to everything we get, which is also good, too.

Please tell others of the podcast, and keep on listening. Again, welcome, Coté. Good to have you on board.

Coté:
Yeah. It’ll be fun.

Simon Elisha:
Until then, keep on building.

Announcer:
Thanks for listening to the All Things Pivotal podcast. If you enjoyed it, please share it with others. We love hearing your feedback, so please send any comments or suggestions to podcast@pivotal.io.

About the Author

Simon Elisha is CTO & Senior Manager of Field Engineering for Australia & New Zealand at Pivotal. With over 24 years industry experience in everything from Mainframes to the latest Cloud architectures - Simon brings a refreshing and insightful view of the business value of IT. Passionate about technology, he is a pragmatist who looks for the best solution to the task at hand. He has held roles at EDS, PricewaterhouseCoopers, VERITAS Software, Hitachi Data Systems, Cisco Systems and Amazon Web Services.

Previous
Pivotal Cloud Foundry 1.6 Now Available
Pivotal Cloud Foundry 1.6 Now Available

Looking at the similarities for the most successful software companies, there are three development tenets ...

Next
Apple Watch 2.0 With TDD Setup
Apple Watch 2.0 With TDD Setup

It is now possible to create native apps for Apple Watch! There are some changes as to how we communicate b...

×

Subscribe to our Newsletter

!
Thank you!
Error - something went wrong!