In this series, we pulled aside folks from across our engineering department to talk about confidence. From the technical executives to folks on the ground in engineering, management and site reliability, we wanted to know what “confidence” meant to them, and how it had changed over the course of their careers.

In this interview, we spoke to CircleCI VP of Platform, Mike Stahnke. We hope you enjoy it.


What does having confidence as an engineer mean to you?

I guess it means that you have a lot of predictability about what’s going to happen. If you’re confident, when you perform an action, you have a pretty good idea what the outcome will be. So, that could be, if I deploy this code, I know it’s going to work, or if I launch this feature, people are going to buy it. Or if I run this compile job, it works. If I challenge somebody, am I going to get the outcome that I expect to get out of that? Do I have the confidence to challenge somebody on a particular thing? Can you say more there?

Well I mean, sometimes you have to be confident to have a hard conversation. It’s not always easy to tell somebody something they don’t want to hear or something that’s just difficult to talk about. It takes a certain amount of confidence and that’s why you prepare; that’s why you think about it ahead of time or take notes. A lot of times, people think people in leadership are kind of soulless and that they view people as cells in a spreadsheet. I can tell you that that’s not the case for basically every leader I’ve ever worked with. Anytime they had to put somebody on a performance plan or something like that, that was hard for them.

How has confidence changed for you throughout your career?

It’s probably lowered more as I’ve gotten more senior. Part of that is because I was a very cocky 22-year-old, and part of that is because true knowledge is knowing you know nothing. And so as you learn more and more about what more there is to learn. You know that you just don’t have all the answers, and that’s why you have other people around you, or different staff that specialize in different things. So I would say that a lot of my journey in my career has been like becoming less confident in what I work on, which I think is probably not intuitive to how most people would expect that to go.

a lot of my journey in my career has been like becoming less confident in what I work on, which I think is probably not intuitive to how most people would expect that to go.

How do you handle situations you’re unsure about?

Well, I think, “what do I need to gain confidence?” So I find myself asking, “what would have to be true for X, Y, or Z to happen, and how sure am I about those things?” And it’s a lot more about gaining confidence using data, as well as gaining confidence with things on a longer time horizon. The biggest difference from when I was an IC, is that when I made a decision, I could figure out in very short order if it were good or if it were bad. It could be a day, or a week. It usually wasn’t too far beyond that to figure out I made the right call or I didn’t.

Now if I find out in six months, I’m doing great for some of the decisions that I have to make on a regular basis. And some of them, it takes years to figure out if that was the right call at that time or not. You’re always making the best decision you can with the information you have. But you just don’t have that same feedback cycle to know and learn and improve at the same speed. So you have to take a more cautious approach about it and try and get more information upfront. In those cases, the impact of it being wrong is so different than saying, “I pushed a code deploy, it didn’t work. I’ll push another one. Cool.”

What are some pivotal experiences that have affected your confidence level?

I think some of the earliest ones were speaking at conferences. Doing public speaking in a room full of 60 or 70 people that wanted to hear what I had to say about a topic…it’s pretty exciting. I’ve never been terrified of public speaking, but to have people that want to hear what you have to say on a topic is really confidence-inspiring.

I used to work with a woman who was terrified of it, and now she’s a way better public speaker than I am. At the time, she was preparing to give a presentation to 200 people. And I said, here’s all you need to know: “The thing that you’re talking about right now? There’s no one in the world that knows more about this topic than you do. Literally no one. And so no one’s going to ask you a question that’s smarter than you are because you already know all the answers.” She later told me that that was the advice that changed her entire outlook on how she speaks.

I also think some other moments, like a big promotion, can be very rewarding, very confidence-inspiring. When I first made director, that was a really big deal to me. But I also think there are other things, like respect from your peers. Do they listen to you? Does your voice carry weight for them? And if it does, that can inspire a lot of confidence, because people you respect are listening to you. Then you know things are probably going pretty well.

When I first made director, that was a really big deal to me. But I also think there are other things, like respect from your peers. Do they listen to you? Does your voice carry weight for them? And if it does, that can inspire a lot of confidence

How do you move forward when you’re stuck, or not sure you can achieve the result you’re hoping for?

Usually I’ll start with some type of crying or panicking. Then it really depends. The first thing I usually ask is what’s the impact, or cost, of being wrong? If it’s a pretty small cost, then move forward, see what happens. If it’s a gigantic cost, it might mean getting more experts, pulling in more people, or collaborating more heavily. Anything to get some more perspectives. Or, I’ll ask, “Can I chop this thing up into smaller decisions that get me in the right direction, versus one giant decision?” What do you think about confidence in code?

It’s what we’re all striving for, right? You want an engineering system that’s basically the equivalent of a factory. You put in raw materials at one end, you get an output out the other end that is in a known shape and has known properties. That’s one of the things that’s always interested me about automation, and in particular CI. It’s the factory floor for software building. And so if I put in bits on one end and I get out a software product on the other or a value or a solution out the other, that’s great. The confidence you want in there is that I can make a change and it doesn’t change the overall form of the thing I’m building on the other side, that it’s still within all the quality measurements.

And that’s pretty much what CI is: a confidence-gathering process that’s automated.

What are you able to do when you’re confident in the code you’re writing?

You can move way faster. You can also make changes in a more complete and holistic way. “Side-effect free” changes might be a better way to describe it. When you have good test coverage, you can start making changes, and if a test fails, you understand why that test failed. In a lot of cases, tests really end up documenting how things are supposed to happen. Knowing how things are supposed to happen is a rare luxury that I don’t think is appreciated enough. A lot of times software works the way it does by happenstance, versus intentional design. If you have tests, the behavior is at least intentional enough that it was documented.

And so if you have good tests, you can refactor, pull things out, extract them, break one service into two or combine five services into one; whatever you need to do because you have that confidence to move and shape whatever you’re doing. And so you can map to either customer needs, or scale needs, or deployment needs or anything else.

And I think that’s what confidence is: it’s how fast can you make a change and know it works. Not think it works, know it works.

Do you ever get imposter syndrome?

Sure, but not that often. I think part of that is because I’ve basically come to the conclusion that everybody is an imposter at all times. And so, we’re all on the same playing field. Everybody knows something more than I do about something, and possibly many, many somethings. And so everybody’s here and working in the positions that they’re in because they bring value there. When I look at a peer of mine or somebody I work with on a regular basis, they have different skill sets than I do, and I think that’s great.

That has definitely been some of the advice I’ve given to people over the years so many times. “You might feel like an imposter, but you can do X, Y, and Z that no one else can do at the level you can,” or “You can see things coming in a different way”. Like their vision in this space is very different. They usually say something like, “I can’t write code as well as this other person.” And I’ll say, “You’re right. That’s not why I hired you.”

When I go sit in a room full of CTOs, and I’m a VP, I’m like, “Wow, do I belong here?” And inevitably there are certain things that I know way more about than most of the CTOs do, and there are certain things that they know way more about than I do. And that’s just the way the world works.

There will be situations that are hard that will make you say, “Wow, I am over my head here.” And that’s going to happen all the time. And if it doesn’t, you’re not learning.


Sign up to try CircleCI and start building confidence in your code