Rags' full question: Hello and welcome, InfoQ audience. My name is Rags Srinivas and with me I have Mike Maas from Cisco. Mike, would you take a moment to introduce yourself? We are at the Evans conference, by the way. Evans Data Corporation developer relations conference, to be precise.
Yes. My name is Mike Maas. I am a technical evangelist for Cisco for the Internet of Everything. I guess one of the reasons why I am here is obviously as an evangelist and I am focused on reaching out to developers and understanding their needs and kind of understanding the bigger pieces and elements that I need to do my job more effectively.
I have worked on a lot of different things and a lot of different technologies. The key to it, though, I think is – I am kind of skipping to the second part of your question – does it help to be a developer evangelist? I want to say yes, but it is not based on skills. That is certainly part of it, but those come and go. I think it is something a little bit more fundamental. There is a creative drive in developers that you should probably have as an evangelist. Now, by no means if you are not technical at all, can you not be a technical evangelist. It is really about the technology. But you have to have a certain passion for it that you find inherently in developers and if you don’t have that, you will not be successful.
I would say that there are other things in my development career that help – you know, being able to talk code or to do code live and find your way out of situations and be able to kind of investigate not only competitor solutions, but your own solutions for the technical merits and find things that you can discuss as an evangelist about your solution and your product is useful if you definitely have some type of technical background. And often times, the broader it is, the better. Because you find yourself not only talking about your solution, but your customer’s solution and how that fits into technology and knowing what they are doing is just as useful. It kind of means that you have to be a very utility player when it comes to being a developer.
3. [...] But why should enterprises, in general, care, why should Cisco care about reaching developers?
Rags' full question: Apple, I think, pioneered the evangelism programming and if I remember correctly, a guy Kawasaki was the first technology evangelist and it makes sense for Apple to care about developers because of the broader app store which really reaches millions of users, you know, thousands, hundreds of thousands of developers maybe. But why should enterprises, in general, care, why should Cisco care about reaching developers?
It is a good question. Again, like everything, it’s complicated, there is a complicated answer. The simplest answer I think I could give, the very simplest answer is – it’s about money, right? The more people that you get developing on your ecosystem, the more money you get flushed into your ecosystem. That is why Apple has a strong developer relations program, that’s why they get people into their ecosystem so they can feel it. In terms of other enterprises, that definitely holds true for some of it – it is brand, it’s excitement, it is challenge, it’s a number of things. You know, you can engage a particular developer section for reasons other than money.
And then it is something even more core or fundamental. You could be doing it because you really want people to use your solution for good or for the evil, but for fun, for having a purpose – to actually show that things are being done on your platform. To do that, you need to reach the developers because they are the ones who are going to make it, they are going to build it. It does not happen on its own unless you do it and going outside your own walls for things like a Hackathon or some type of technology event often times brings fresh insight into how people perceive your product and how they are going to use it and new ways that they can use it because they are going to come in with their own domain expertise and they are going to say “”Wow, that is a really interesting widget.
Have you ever thought of using it like this?” And you are going to go “Wow, that is amazing!” So, having a vibrant developer relations program, a developer community is important not only to make money, because if you have a platform and it is not being used, it is not even a platform, but if it is important for your business to also get excitement and marketing and reach out to the people who create something new on it, then you have to have developers. They are the creators.
Rags: A lot of times, the developers relations work is talking to your own product groups, telling them “Your documentation sucks” or whatever.
In the kindest way possible, yes.
4. You did a checklist in your talk. Can you briefly elaborate on that?
Sure. Our evangelists at Cisco really are the opinion piece between internal and external developers, external product groups and internal product groups, the technologies that are being used inside as well as outside, but in that role, we have to communicate clearly, simply and effectively to the internal groups about what we see is potentially lacking in their own documentation, missing sample code or there are elements that we feel would be a benefit to developers and we are at conferences like this to understand developers. We do our own outreach, we do survey, so we are pretty well hooked into that.
The internal groups – maybe not so much. They may have a concept of their developer, like the focus for which they built a product or they know about, but it is not as broad and general as it needs to be for a company that is trying to reach across domains, across technologies to create something compelling. So, what we have done is we have come up with a score card that is very open. We are very open: we score them, we review it with them and we try to work with them to improve and in every case, we have. There is low hanging fruit for certain things, there is “Don’t lock your documentation into a word document”, at the very least, let’s move it to pdf, let’s move it to html, let’s move it to this particular format.
Rags: Baby steps.
Baby steps, yes. But, we improve your score along the way. So, it is a good way to communicate where you are at which is valuable not only for us, but for them, because they can turn around, take that back to their own management and say “This is where we are at with our engagement and developer relations. These are the things that have been identified.” They can agree or disagree with it, but generally, most of them, have no problem understanding “Yes, we understand we need tutorials. We need this piece.” Some of it does not apply, especially when we start talking about APIs and relationships to the product, but it is generally accepted as a good way to proceed because it is a fact that it gives them clear steps for success which is not something you have when you are developing a product sometimes and then again, we can use it as a center piece for communicating where we are going as a group, as a team and that includes both them and us.
So, it is a useful measuring stick, if you will – stick is a bad term because we are not beating them with it – but just to let them know where they are and let us know where everybody is because then you can kind of compare across where the collaboration technologies are and you can look at all those and see the scores: where are the IoT techniques at? – you can go and look at those. So, it is a good way to roll up status and also find commonality. One of the things we identified was that we need more sample code, across the board. So we got efforts to make that happen, not just for one unit, but for every unit.
So, that is really what it is used for. It is a tool for helping everybody get to the gold standard, the great micro-portal that has all the information, the developer needs and satisfies its journey. Again, going back to the core principles, this is based off of developing the personas, coming up with those journeys that we have identified in talking to lots of developers and going through a lot of data to come up with that check list that says “This is really what they are expecting”. And if you do not have that, then you are out of line and you are going to get a red score but it is easy to move in there. We are going to help you. You have the writers to help you, you have the tools to help you and that is an important piece.
Rags' full question: That is great. So, that kind of gives an overall measure for how you are coming to get with developer. But, personally, how do you measure your own success? How do you improve on a day-to-day, year-to-year basis?
That is a good question. Management feedback is always “Good job, guys. We really knocked it out of the park” It is often times one of those big flags, it is easy to get your attention because usually they define the path that we have to go down, they define the criteria for success and then we try to step up to it. But I think that the other piece of it is that what we really are is a service organization and we serve the internal customers, the stakeholders, the external customers, the external developers and what we are interested in – at least I have been trying to push – is satisfaction, measuring satisfaction.
Every key point role we touch something that a developer or an internal stakeholder does. Asking them “What was your relationship with our program like?” internally – I mean is fair game to go and talk to a program manager for a technology and ask them “Did you get what you needed from us?” Those are the things that we are looking to measure. There is some question about how we are going to do it, but that is all going to rolled up too. But there is no doubt – that is the way to explain it, because we invariably get questions about “It cost a lot of money to put that Hackthon in – what did you get out of it?” Which is why, whenever we go into it, we always ask and we make sure we understand the goals for it: Is it a marketing exercise? Is it excitement building? Is it advertising of a released product? Is it to develop apps?
We make sure that you understand a lot of the goals before we get into this. Any endeavor – whether it is a training session or whatever – you try and make sure you have those goals and that is our immediate balances: “Did we succeed in what we set out to do?” The larger question often comes from management and executive guidance, but then at a tactical level, we are really looking to measure satisfaction, down to the page. Was this page helpful to you? Was this interaction helpful to you? Did you get what you needed from your support ticket? Every chance that you get to measure their feedback produces a score through which you can identify where you may need to spend more money or invest time. That is really what we are looking for. So that is why we value them.
6. Throwing open-source in – that kind of changes the conversation. Does it or does it not?
We have an open-source evangelist, we use a lot of open-source, we try to contribute a lot of open-source back to a lot of open-source projects.
7. OpenStack?
Yes, it is a good example – the cloud services. The thing I could say is that the complications come from licensing, they come from inclusion and making sure that we do not expose ourselves unreasonably to pollution, to API pollution or any of the concerns of the large company trying to use and contribute open-source material in general and I think we have done a pretty good job of it. We have processes in place, we have a whole area that is focused on open-source, including it in Cisco in particular. It is a challenge because the perception is the companies are more interested in proprietary and that I can tell you from the inside Cisco that is not true.
I think that what happens with proprietary software sometimes that things get added in the process get so involved into trying to contribute back that it never gives contributed back. I mean engineers inside are the same as engineers outside - they want to contribute, they are very social creatures, they want to take the cool stuff that we have and give it. I can’t think of any time where we have tried to create something proprietary just to screw with open-source or with competitors. I think it is not as common as people think.
It is hard work. I kind of sometimes pine for my days when the only challenges I had where in the computer, in the code. You run around a lot, you have a lot of things on your mind all the time. The problems sometimes are a little tactical which is still interesting, but also social. You find yourself walking around with things in your head which you cannot talk about or you have to mask your own feelings about certain technologies. It is very strange. Developers are very open people which is, I think, one of the ways that they can tell when somebody is not being honest with them. I think they have a good sense for it . You know what? It sounds like marketing. You are hiding something from me by telling me this other stuff.
But you still get to give back to the code. I mean, I have written a lot of code for training sessions and kind of against new technologies which is another benefit: you get often times access to the coolest stuff before anybody else because you are going to be the one that is going to go out on the road and talk about it or be expected to be an expert in it. I guess that is another thing: when you cover an area like mine where there are several different projects, you have to be an expert in several different projects. It is difficult and you spend a lot of time in the personal communications, talking to people on the engineering team, on the marketing team, on their management team just to get a sense of their positioning, how that fits for larger pieces of the company, where it is going, what are the weaknesses. There is a lot to it. I do not like to think of myself as a marketer but it is definitely some of the skills that I have picked up moving into this job.
Right. Well, let me take it simpler, before I build complex. The simple thing is that it is just still the internet. We call it the Internet of Everything in Cisco because it deals with processes, people, data and things. It’s not just the internet of devices there is a lot more to it. We are about the tools and technologies that you need to pull it all together and Cisco is a great company for that because we have the infrastructure, we have management tools, we have a lot of things that bring all that information together. But, fundamentally it is still just the internet. It is connecting the unconnected and how that relates to you as a developer often turns very personal.
It is difficult for me to go into your domain and say: “Internet of Everything is going to change your life because”. YOU know why it is going to change your life, you know what the value of having a sensor or some type of other information can have for your business. For me, the biggest thing about IoE is efficiency. I try not to talk too much about residential scale because that is kind of a different playground in Cisco, but NEST is about efficiency. That same kind of concept applies to fleet telematics where you are trying to get the most out of your fleet with information. Do not send trucks that do not need to go there. Send them in fewer cycles if the thing that they need to pick up is not going to fill up a truck.
Have information about where the heat is building so that you can effectively turn it off compared to maybe where the people are in a building. You know, every question that I have encountered about IoE is really about efficiency: either fiscal efficiency, like we are going to save a lot more money – energy efficiency, people efficiency, routing traffic, getting yourself from one place to another more quickly at the scale of a city or down to a scale of a building. Now these are the things that IoE helps to solve and it is really how you can take the tools that Cisco and other companies have and the analytics that other companies have and bring that into your domain and figure out how to save money.
That is difficult because that is the part where you have to go “What is it that is causing us a lot of money?” and how we could fix that and how we use the extra information that we could easily acquire from a network or if we put this device in every bus, what information we could do or what information we could get from it, but also, what other services we could provide. You have something like a hardened router in a bus that not only gives information about the bus and the occupants, but also provides Wifi or has some other types of services ….in it. That is something that adds more value to your business and it may be public transportation services. I could go on for hours.
I mean it literally is everything, everything that you can think of that has some relationship to the world around us is fair game for the Internet of Everything and the last thing I have to say is that what is most disruptive about it – it is kind of a cruel word – is that information from one domain can be useful for other domain and that is something that we have not necessarily had in the past where you could take – the classic example is the city departments: the Utility Department does not necessarily talk to the Police Department, does not necessarily talk to the Fire Department but if they did, imagine the kind of thing that you could do.
You could improve city services, you could improve response time. There is a number of efficiency gains that you could get from it just by combining the data, getting it out of its silos and across the vertical platform and the information that you could get in terms of air quality from things that already exist from water towers or light poles – connected lighting is an interesting proposition for Cisco because it is not only about saving money on things like LED, but it also then becomes a connected point that you can do to measure the health of your building, your city. I could go on for hours. It is fascinating.
Rags: Yes, thanks for taking us through the life of an evangelist. Thank you very much for watching.
Thank you.