Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: My Stint as a Chameleon - Constance Caramanolis, KubeCon + CloudNativeCon EU 2020 Co-Chair

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Keynote: My Stint as a Chameleon - Constance Caramanolis, KubeCon + CloudNativeCon Europe 2020 Co-Chair & Principal Software Engineer, Splunk

https://sched.co/ZfH3

A

Throughout my career, I've always fudged the definitions of my role, and this year I took it to the extreme. I led a design partner program to work with users to do everything under the sun in a short amount of time, like all projects are right and in the short amount of time we had to migrate users, the back end they're using the ui frameworks.

A

I work on open, telemetry as well, and so part of it was also getting feedback for open telemetry, build user relationships, gather more feedback, oh and still make sure that they liked us at the end of it.

A

I didn't realize that this I didn't realize this at the time, but it required me to act impersonate roles, I've never done before or know much about. So this isn't a migration story or talk focus on tech. This is about the different roles and people involved in a product life cycle and what I learned from them.

A

I can say that this has made me a better engineer and it helped me grow my career, maybe if you're at a stage where you don't know what to do next. This can maybe help you so who am I well I'm a principal software engineer at splunk I came through an acquisition of a star stelled up that was focusing on tracing.

A

I work on open telemetry, both as a contributor to the collector and on the governance committee and in previous life. I was at lyft I used to work on envoy and I was at microsoft in various projects.

A

So going back to the design partner program I was mentioning about is that I had to gather data for various organizations right and people for people who work in sales, pms, vps engineers, marketing support and I had to learn what they actually needed. And so what are these roles? What were the roles that I needed to adapt or to learn so the many roles right, that's chameleon right blending in or I also like to say one of the many hats I wore so one of the money ads I wore was software engineer.

A

Thankfully, this is very natural for me right and hopefully natural for a lot of you, so I don't need to describe too much, but it's, but you know, I view it as delivering a product that fixes a problem right. We want to. We want to tackle big problems.

A

Next one is product management right. This is painting the picture where we should go, it's creating a focus and that's all the different. You know possibilities out there right this. I view this as being really refining. What is our target support right? They get a lot of attention right, they're around for general questions and when things go wrong and they have to strike a fine balance between acknowledging things, acknowledging issues and questions quickly and getting the actual answers and resolution done quickly, then there's customer success right. This is about building momentum, ensuring successful adoption right.

A

There is a difference between begrudgingly, using a project product or actually being in love with it and advocating for it and just wanting to interact with it more and then there's sales engineer right. This is about getting something working. It's usually about working. It's usually working with all these different roles. You know vps engineers, business and trying to come up with some form of solution that would work for them. So let's take a little tour of all the different roles. Let's start with software engineering right.

A

So what are some of the takeaways I took from this project? One is that reference documentation is not user documentation right reference documentation, you know, is explain. I view it as explaining what is already in there versus user documentation is explaining how these features can solve a problem right, a problem isn't necessarily oh, how do I turn on a flag? But how do I solve? You know an inf, a larger infrastructure issue or something like that.

A

Another thing is that it's really rewarding right. It's, I think it's part of why so many of us come to kubecon, is to see what we've built and contribute to is used in value right to see all these logos up on the screen to know that you joined you were contributing to it, something really valuable and something, but I kind of forgot how much you know. I love that about the role.

A

One also really fun thing is that it gave me the ability to go into details, especially since I was working with so many users, so many different users from different backgrounds trying to solve different problems right is that every so often there would be a question about you know why, specifically for focusing on tracing is like you know. Why would I want to you know, add instrumentation from a databases and then, after you know, being able to go into the actual details of like one, how to do it?

A

Why you can do it whatever ways around it? You know if you do it, don't that's really fun, because one who doesn't like you know having a little debate about different implementations right, it's like a fun, it's a fun whiteboarding session, right and so yeah. This this program gave me the opportunity to do this with all these different inputs and users.

A

A

Product management, this role isn't art right. It's about being able to see the forest for the trees because usually right product management is getting so many requests. There's so many different problems you can solve, and so when there is a clear vision of where we go, it helps everyone else. Focus.

A

Right and to be able to actually come up with the clear vision is, it requires so much active listening. It is when getting all these different inputs right, helping me tons of inputs, you just don't agree with and listen to them and also trying to understand what is the motivation for these people? You know where do these problems come from? What are the motivations for what their, what solutions are? Looking for?

A

It's a really it's a very active role, but I think out of the I have two favorite takeaways from my entire experience, and this was one of the first one. Is that the question shapes the answer right. It's kind of like leading the witness, if you're to ask someone. Do you think this feature is useful you're going to get an answer of either yes or no chances?

A

Are you might get a yeah, probably because either someone's being nice or you know, they can see a way that they could shape a feature to work for them, but that doesn't really give us a lot of answers. It doesn't give us much to go on and, if we're to rephrase that question of what problems do you need to solve that aren't being solved today?

A

That opens it up for one just unstructured. You know thinking you're, not framing a solution based you're, not flaming the feature based on the existing solution and after there can be so much more diagonal like in terms of like why? What how who.

A

um I can go on about this for hours, and so I just want to reiterate that, like the question shapes the answers, like think about what question you're asking and if it is leading to an answer, you want right. We should be going into this trying to get as much data as possible and then, after look for commonalities,.

A

Support now support definitely deserves the metal armor on this because they answer so many questions and they're also there when things go wrong, and so it's not always fun to get that type of attention. So what are? What are the takeaways one? Is that they're in a unique position to see commonality when you're answering questions from users of all different backgrounds, you're able to see? Oh well, maybe you know this one feature needs better documentation or you know whatever configuration we provided. We thought it was intuitive, but there's so many.

A

You know there's a few things here that we just need to put better safeguards in.

A

One is documentation.

A

If something isn't written, we really something's written down, there's no way for other people to know and, as you know, if we're looking as a whole product life cycle as a team right, all these different roles is that we need to write what we know down, because there's going to be someone like someone in support who's going to have to try and answer a question for a user or a customer, and if there's no documentation, it puts them in a really bad spot.

A

Another thing is that you know, especially since they are gathering you know, gathering questions and seeing so many issues from different ways, as a software engineer is that I should you know, help create tools that simplify the data collection, because if you're debugging, something or you know, you're asking for help and someone's like okay grab, my configuration grab me the metrics grab the logs. Oh grab me this other little example here and have all these steps that it takes right. It is going to be really difficult to one close.

A

This loop, really quickly right support, is trying to acknowledge an issue and resolve issues as quickly as possible, normal asterisks there, and so we should try to make that process better and, of course, documentation. Please, everyone write more docs.

A

Let's talk about customer success right. This is this is an interesting one, because it's something that I think we kind of think that happens magically right. If you provide something- and you know it seems, useful people will come and that's kind of right, but like the first thing is that it's like it's all about a lot of it is about communication, and trust is that there needs to be established ways to say what is going on. What is what is going on? What is going wrong? What's going right, what is to come?

A

I need to build it and build that trust right very similar to how you know we pub, like projects, will release vision, docs and post issues right. It's very similar, it's very similar to that.

A

The one thing that is a little painful about this is that it is slow right. This doesn't happen overnight and it's something that you just need to write out: it's not something that can be rushed and to talk about my favorite. My second favorite takeaway is this. Is that success is more than technology.

A

It's about successful adoption right is that we can build the coolest piece of technology that maybe sells everything, but if it is incredibly difficult to use, you know engineers incorporating into their infrastructure, find that it's really brittle to build, or you know, there's just so many ways to configure that it just you can't even actually you just can't figure it out without you know, you know, 10 people reviewing it, that is technically adoption, but uh that is succe, but that isn't successful. Adoption that is begrudgingly adoption and so going back to product lifecycle.

A

Is that and also the cncf projects that we are all building products we just forget about that and that we actually and the people are building products for are usually other engineers, and so when it comes to thinking about successful adoption, we need to think about how do we make our lives better for the engineers who are using it day to day for the engineers who don't even realize that they're using it but one day they might get a page that their kubernetes, you know positive, you know their kubernetes pods are restarting, they never know they know.

A

Kubernetes is a word. They think it's a word but like how do you make it easy for even those who don't have to work on a day to day? You know be able to respond to those pages and move forward.

A

So I really encourage all you to think about what successful adoption means and last sales engineer. What does it mean to be a sales engineer right? It's what's really interesting about sales engineers, and you know you don't necessarily have to be selling something to have sales in here view it as a person that is the hype you know as a promoter in marketing who is trying to get other people to be like hey, we're, solving your issue, we can help. You come up with an mvp right.

A

So what does that kind of look like it things to like bring back to like my role as an engineer, software engineer say that minimal via a bull product is where to start. No, I'm going to admit these two takeaways, the first two takeaways for sales engineers are so well known, but they're always really hard to apply right. Is that especially like from a minimal vial product right? Is that once we see that there's a problem we're going to want to solve?

A

All of it, we want to you know, come up with a solution that can get us right from a to z right away, instead of acknowledging that we're going to have to go from a to b to c so start small right find something that provides value right away because I'll get to because afterwards, but part of that is like from getting anywhere is that perfection is the enemy is good enough.

A

Now, as someone who practices perfection, paralysis daily, I logically understand this, but I still don't buy this reasoning, but I'm trying to work through it right is that, since you know all this any form of adoption of a product or project right is always an iterative process.

A

So going back to the mvp, you just need to start somewhere they're going to be bugs. Yes, it is scary, makes me scared too, but we need to work through them, and the last part is that you need data to make a decision. If you don't have an mvp, if you don't at least try it and see how it works, there's no way. You know there's very little way to actually understand if something's gonna work for you, and so that's where you need to put on your cowboy hat and just try something new.

A

So what is my challenge for? All of you is that I really encourage all of you to try on a new hat right. I.

A

You know I I've made a lot of mistakes doing this during this program um and well, that's just a different story, but the thing is that it did teach me a lot and what was really fun about it is like for the first time in a really long time is that I was out of my waters, trying to do something new and trying to blend into all these different walls, exactly like this chameleon here and so see. If there's something that you can learn from these other roles.

A

Thank you very much.