DOP 82: Where You Live Shouldn't Define Your Pay

Transcript

Olaf: [00:00:00]
It's a very interesting topic that happens because yeah, you only get a pat on the back, nice work, or are you all part of the company and do you also all gain when things are going well?

Darin:
This is DevOps Paradox episode number 82. Where You Live Shouldn't Define Your Pay

Darin:
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin: [00:01:16]
So Viktor, in last week's livestream, if you're listening to this, you know we have a livestream on YouTube, right?

Viktor: [00:01:25]
Yeah, I noticed.

Darin: [00:01:27]
Well, I'm glad you noticed because you're usually there. If you're interested in learning more about that youtube.com/devopsparadox. But that's not why we're here today, but in last week's episode that we did and whatever that date was, because all the days are running together again, we were talking about Flux and Argo CD and Argo Rollouts, and we've spent lots of time, probably an inordinate amount of time talking about why those things are great, but we tend to talk about it purely from a technical aspect.

Viktor: [00:02:06]
Yeah. Is there any other aspect?

Darin: [00:02:09]
Well, it's usually the people that are paying us is the other aspect. It's the business side, right? In our day jobs, we actually work for software vendors. So it's our clients paying us money. So there is other people paying us money.

Viktor: [00:02:24]
Let them continue doing that.

Darin: [00:02:26]
Yes. Please continue paying money. Today we've got a guest on. We have Olaf from Vamp. Olaf, thanks for joining us today.

Olaf: [00:02:35]
Yeah, thanks for having me.

Darin: [00:02:37]
Why don't you give a quick introduction of yourself and then just a very, very short overview of Vamp.

Olaf: [00:02:44]
My name is Olaf. I'm a CTO, co-founder of Vamp. I've got like 25 plus years of background in the internet industry. When I started out, I was a programmer. Did a lot of Allaire ColdFusion, ASP, the classical ASP, PHP programming, building websites, content management systems, eCommerce platforms. Then I moved up more into architectural design, consultancy. As it always goes, at some point you become more of a manager kind of role, which is boring. So I tried to also be as hands on as possible. And for the last, I think almost six years, I'm working on Vamp with a team in Amsterdam and also distributed in other countries. Here we're building a solution that tries to make life easier for product managers, product owners, e-commerce managers to allow you to do controlled go live, which is observability and controllability on how you deliver new software updates and functionalities to your audience. I'm basically making sure that our vision stays on track, that we are up to date with all the technology innovations in the field. We were just having a prerecording chat and then I mentioned that when we started, there was no Kubernetes. I think it was Docker zero dot something that triggered the birth of Vamp or Magnetic as it was called these days. So a lot of things are changing and happening. That's a interesting task. We really hope that we can make all these cool technological innovations that are in the cloud native space that are happening here also easy to adopt and to use for less technical roles that can get value out of it.

Darin: [00:04:40]
I want to go back to a point in your bio. ColdFusion and ASP.

Olaf: [00:04:47]
Yeah.

Darin: [00:04:48]
Not ASP.NET, but real ASP.

Olaf: [00:04:52]
The old stuff before PHP came to the surface.

Darin: [00:04:57]
Okay. Just making sure I heard you right. Please don't tell me that any of that is at the core of what you're doing today.

Olaf: [00:05:02]
No, luckily not. I actually noticed that ColdFusion is still, uh,

Darin: [00:05:08]
highly active, highly active. Yes,

Viktor: [00:05:13]
That's because nothing goes out of this industry, kind of. We just build layers on top of previous layers, but whatever was there before, stays forever.

Olaf: [00:05:23]
Yeah and it was also running on Solaris systems, so I guess mainframes running it.

Darin: [00:05:30]
Well, you have to remember too, behind ColdFusion is Adobe, so they don't let anything die. Unlike other people in this space, Google. Why did this approach even other than what we were talking about at the top, somebody has to pay the money, so usually it's not the technical people paying the money. What was the triggering point for you to think about doing basically coming at the orchestration at this angle? From the business side?

Olaf: [00:06:00]
I've always been playing my role as an intermediate between technical people and business people. So I try to link these worlds together. As I said, I've built my own custom content management systems and they happen organically because first we built these websites and then we got these phone calls from the business or marketing, can you change this heading or can you change that image? At some point you get fed up. I'm going to build you a form so you can do it yourself and then they're like, okay, that's nice. And then I do it and I change it and then I break it and then they're like, can I paste this Word document in there? And then you're like I'm going to give you this WYSIWYG editor so you can start doing more like the markup yourself and then they break it again and then you need to fix that. At some point what happens, and I think this is the same pattern that we see over and over again. Also with, I mean, Salesforce the same. Can I do it myself as a marketeer, as an eCommerce manager, as a business person? Can I basically bypass this irritating IT people that are always too busy and say, no, no, no, it is not possible, this is too hard, and can I do things myself to a certain extent. I believe there's always these edge cases and very complex cases. But at some point, the patterns kind of become apparent. This is the same with e-commerce and content management systems, with CRM, with ERP, with mail stuff, inbound/outbound marketing. And I think for what we call release orchestration or release management, these patterns also start to become kind of apparent. I've got a background in eCommerce and transactional platforms and in the end, it's always the business person, the product manager, the platform owner that is kind of like, okay, is this feature done yet? Is it available for me to look at? Can I send it to this client that is pushing me for it for weeks already? And it's like a fairly manual exercise. People coordinating all the time. And when people need to talk a lot and coordinate a lot, there's the potential for noise and irritation and basically issues and errors. So if we provide tools that make this a process of delivering functionalities and software to the end user, to the client, easier or automated and give insights, observability into the quality of this release and bring basically these two worlds together of the technical deployment as we call it where you have the CICD pipelines, pushing things into infrastructure and then having the business side of things, getting a notification and it says, okay, this thing is technically ready to be released, to go live and then allowing that role to have more buttons, sliders, options, to control the segmentation of the traffic, who's going, where, geo, device, percentage based, but also give him that options to put in metrics and observe these metrics, analytics, click through rates, basket value next to the technical metrics that we need to observe obviously to see if things are healthy and then giving you the option to set it up yourself and have it manually or automatically run every time that your team is pushing a new version of the software through the CICD pipeline. So that's how it works. We believe that there's a lot of value in bypassing this manual coordination and allowing the less technical roles more tools to automate these things and observe how things are going, which allows the technical people, the DevOps engineers, the SRE engineers, to move to more interesting and valuable areas of the stack where it's harder to automate these things and basically apply their value and their insights over there. I hope that makes kind of sense.

Viktor: [00:10:20]
So the way, how I interpret that is let's give nontechnical people tools so that they don't actually prevent us from doing our job anymore by sending constant emails and phone calls.

Olaf: [00:10:39]
That's maybe a little cynical view of it, but you know how it works. People are irritating each other because one side is harassing the other side. Is it done yet? Is it done yet? I need it now. And the other side is kind of like, why don't these guys inform me? By basically hooking it up by automation, by sharing metrics and basically allowing different kinds of views on the same kind of information, you streamline the process and you reduce the friction. You can have a cynical view. Okay. We allow people to not bother each other too much, but the pattern is for me, it's totally apparent. I think Salesforce is the number one example where in the past you need to wait two years for some kind of CRM system to be developed in house custom built implemented, integrated, but most scenarios are not that hard. I mean, yeah, there's always a little part of complex edge cases but 80% is kind of common and the same, even though people think they are different and they're unique. Typically most scenarios are kind of common and then Salesforce came along and said, yeah, you can just enter your credit card, create like a little form and then you have a database behind it and there you have your own base CRM system. Who wants to wait two years to have this project implemented and typically failing because it needs to cater for too many scenarios. So I believe this pattern is quite common. I mean, we saw it with flagging tools, like LaunchDarkly and Split IO. Flagging is there for 20 years already. I mean, but now as a SaaS, it becomes easier for, from the developers also to apply. I believe it makes sense to provide those tooling to less technical people so they can start using it with a safety net around it. With guiding rails, basically.

Darin: [00:12:40]
What is the biggest objection? Whether it's the Vamp context or just your life context. What's the biggest objection when you start suggesting to business, Hey, you can take care of this yourself.

Olaf: [00:12:59]
What we hear is like, Oh wow, I'm not sure if I'm the person that can make a call on this. Maybe we need to talk to my technical people in the team, because they make decisions on these kinds of things. So I guess the biggest blocker or objection is people being afraid that this is too technical for them to make a decision upon, but I'm always stressing the point that technology follows process. So I'm asking them, how do you want to work? How do you want to go live with software functionality? What would be the ideal process for you and the dashboards and the views and the controls that you would like to have in the ideal world, if you ignore all your knowledge about technology and ignore all that cloud native hype around it and if you can describe or draw on the paper the way you want to control your go live process, and if you would put that to a, I don't know, to a company or freelancer. So this is how I would like to work. He or she will probably say, okay, I can build you something like this. Typically this dialogue is not happening because I think a lot of the product managers or business people are pushed away from the technical aspects and if you don't understand the technical aspects to some kind of level, you cannot make informed decisions or you cannot be creative and think like, okay, if this technology exists, how can we leverage it? How can we use it? Would this be possible? It seems that this dialogue that we had in the past, it's kind of obstructed by all the hype and the complexity that is kind of introduced with all these layers of containers and schedulers and cluster managers and ingress and egress and service mesh and at some point, people are kind of like, even the technical people like us, we are having a hard time to keep track of all this technology to understand how mature it is, how to use it, let alone a technical person. But I think in the end, they should say, this is how I want to work. Make it happen.

Darin: [00:15:14]
why is it that you think that the product owners tend to not want to be technical?

Olaf: [00:15:22]
I don't know if that's the common case. I mean, it's an answer to the question, what do you see happening often where people say, okay, this is maybe not my forte to make a decision. I don't know. Maybe it's a lot to take in. To think about. Maybe they come from a different angle. Maybe they come from, I don't know, project manager, scrum or something background with less technical background, or maybe we as techies, try to keep people away from our domains and maybe make it sound a little bit magical and let me do my thing and you do your thing. That's also something that happens.

Darin: [00:16:04]
So let's, let's go back one more time to your ColdFusion days.

Olaf: [00:16:10]
you see my gray hairs.

Darin: [00:16:13]
I have just as many, and that's the reason why, because I did. It doesn't matter what I did. I did lots of stuff. I'm guessing you got started in the late eighties, early nineties. Okay. Well then I'm older than you, which is usually the case for every guest that's on here. So you started in the early nineties. You've seen the progression of things happen. We saw when somebody introduced CruiseControl to you for the first time or CruiseControl.NET since you're an ASP person. I'm assuming that was probably in your chain at some point. Please tell me it was.

Olaf: [00:16:55]
I know, I know what it is.

Darin: [00:16:57]
okay. You know what it is. All right, good enough. Now you spin through the next 25 years to where we are today. Could you have even guessed of all the changes that's happened just in the space of, because my background is very similar to yours, the e-com, loyalty space, all those kinds of things. That's where I've been for most of my career. Could you have guessed that Kubernetes would have become a thing instead of racking and stacking servers? If you could talk to your 25 year old self, what would you tell them now?

Olaf: [00:17:41]
That's a very interesting question. I don't think I could have guessed. The thing is, I think we started, we had these monoliths and they became harder to maintain and to scale dynamically. ECommerce and digital online grew. So basically we put more people to it. It's like the mythical man month topics and then at some point somebody came along and said okay, we try to do modular things and let's put it in the service microservice, service oriented architecture. 2.0 came along effectively creating a distributed application which is hard by itself. Then I think the Borg paper from Google, which is their internal pre Kubernetes thing that they used for their distributed systems and their container workloads became more interesting to people. The fact that people sliced up their monolithic applications into services, wrapped them in containers because Docker has its advantages, especially for development and when you're dynamic, you want to scale stuff, but then you need something to orchestrate it and to manage the clusters. We also had Marathon of course, Mesos and Marathon in those days in the early five, six years ago. But Kubernetes became very interesting to a lot of people. I think became more popular because it rose with the advent of Go, which was around the same time. So I think that also helped. The question still is in every project that comes along is are microservices solving your problem? Are containers solving the problem that you're having? Is Kubernetes solving your problem? I think to be honest, I'm maybe a little bit cynical there, I think eight out of 10 times the answer is nope. If you have a fairly basic application and you have maintainability issues, I don't think slicing it up in microservices and containerizing them, running them on a container scheduler is typically solving your problems, or at least the balance is tricky because you need to solve a lot of other things. Service discovery, all those stuff around it. I don't think I could have predicted this. No.

Viktor: [00:20:13]
One of the issues I see is that, as you indirectly said, industry's really moving very fast, too fast, basically for almost everybody to follow. On top of that speed, I think that engineering is forced in a way to move at the similar speed. Cannot move at the same one, but similar speed. Right. And then really that creates a lot of friction with management, which I will be cynical now, but I think that if let's say if engineering changed like three times in the last X three, whatever that is in the last 15 years, the management just improved 0.5 or something like that, there is that discrepancy of being able to really follow what your people are doing. People you are in charge with. I mean, now I know that product manager, at least as a role, is not really in charge of people, but still somehow. There is really that issue that, Hey, I just spent three years wrapping my head around what containers are and you're talking to me about Kubernetes right. That's just too much to swallow for a normal non technical person. That creates that level of distrust in a way. I don't trust you. I don't know what you're doing because I have no idea. I don't understand what you're talking about. Right. But yet I am the person who needs to put the signature behind everything you do. And what am I going to do? Blind signature kind of. Should I empower you so I don't need to sign anything? Should I sign without knowing what's going on? What should I do? That is a challenge for nontechnical people, I guess. A huge one.

Olaf: [00:22:00]
Yeah, definitely. Definitely. Yeah. I mean, you have to have some kind of basic knowledge or understanding about the foundational technology to understand if it's actually a real tricky thing to solve. But on the other hand, everybody's talking about outcome based or performance based working. If you have a good relationship with your technical peers and you can talk about the process and the KPIs that you want to see changing, it should be possible to find a common ground and say, okay, is this possible? Is this possible we can work in this way. The tricky thing here is that there's a lot of cargo culting going on in the tech space. So people are basically adopting Kubernetes or they're adopting Istio or any service mesh. It's like microservices. I do microservices, now I'm Netflix. Oh, well it doesn't work that way. I do Kubernetes, now I'm Google. No. It doesn't work that way. Load balancers. Proxies. HAProxy. NGINX. They were there for 20 years already. We can do these things like canary releasing already. People would just go in, change the configuration, reload. There you are. Boom. But adding layer on layer on layer on layer of abstraction makes it even hard for the technical people to understand what's going on on the HTTP level on TCP. What are these iptables that are basically generated below these proxies? We're talking about ingress using a controller, using Envoy or HAProxy, creating iptables. it's like layer on layer on layer. If you don't grasp what actually happens when you create a route on an ingress or on a mesh, you kind of have the tendency to start doing what you read in a blog or a tutorial. You almost cargo culted, or just do it as it's described to you. And then somebody comes along and says, but this is how I want to work. Can you create this way of working for me? This custom process. And then you're like, Hmm, let me look in the O'Reilly book. Hmm, it's not written there, so no, it's not possible. Kubernetes doesn't describe this way of working. This is how you should work. In the past and I mean, these are great times, but in the past where we were more like closer to the lower OSI layers, we would say, I think we could make this work. I think we can if I connect these things in this way. Would this work for you? And then the, the other person would say, yeah, I think so. Let's give it a try. I think we're all moving away by the complexity issue correctly assessed by the speed of things being added. We're moving away farther from the real details of the thing. And then it becomes harder to have a meaningful dialogue too.

Viktor: [00:25:08]
But that's partly because of the way how we reward different profiles I believe. A manager is motivated directly by money, right? Manager will get bonuses if something is successful and will not get bonuses if something is not successful. That's how management works more or less. That is not really applied to engineering. So the only real interest besides getting a pure salary engineer has, is building his own curriculum.

Olaf: [00:25:40]
Yeah.

Viktor: [00:25:41]
because then it makes perfect sense for an engineer. So you're not at least in my head, right? You're not going to give him a fat check if this was a successful thing. You're going to give it to yourself. So engineering has strong interest to, let's say, to put Kubernetes into every single use case, no matter whether it's helpful or not. Exactly because you're not rewarding him in the same way how are you rewarding decision-makers right.

Olaf: [00:26:09]
Yeah, but I think you hit on a real point. This is a real thing and also a real issue and irritates the hell out of me because it means that new technologies that are super valuable are ignored because they don't look good on your resume because nobody knows about these things, for example. My wife is an organizational psychologist and the first thing that she does when she comes into an organization, she said, we're going to align the KPIs because if not everybody's on the same page about their incentives, how can you work together? I think you have a good point here. If the incentives are not aligned and then one guy is responsible for least amount of outage and the other guy, his incentive is to create the highest amount of innovation. Boom! These people clash. And then people say, Oh yeah, we need to innovate, but not on my watch because I'm basically, I need to keep five times nine up. Maybe it starts with aligning the incentives. The metrics that people need to observe. In the past, I did some scrum master kind of thing, agile, and I encountered some interesting dynamics when I talk with the business. I said like, okay, you asked us for this feature or this epic and can we describe three additional parameters when we describe an Epic? What is the KPI that we want to see change? What is the lift or the decrease up or down percentage wise? What is the time window? And they're like, what are you talking about? So, okay. You're asking for, I don't know, video player on the homepage. What is the KPI that you expect to see change with this video player on the homepage? Stickiness? I dunno, churn decrease and then you can actually calculate the business case. And they're like, ah, this is super hard. Why do I need to enter these things? If we, as scrum team or whatever, need to make an informed decision on the prioritization, what epics we're going to work on, complexity points, whatever, we need to figure out what we actually are improving with this thing. This is about the alignment of the people are actually aligned on the KPIs that you're wanting to see change. If that's not the case, then like you said, we're going to create the best video player in the world. It's going to be technically awesome. And then basically the thing is put up there and nobody's watching anymore that it actually it does something. They're like, we have a cool video player. I don't care if it increases sales. So, yeah, alignment is crucial.

Viktor: [00:28:49]
Even when you do align, which happens rarely, hardly ever kind of when you have company-wide KPIs or when everybody's aligned on the objective, still motivations are different, right? There is still that aspect of you get 100k if you accomplish KPI. I get a tap on the back. Therefore, let me see whether I can build some curriculum so that I can go away type of approach.

Olaf: [00:29:19]
I've been thinking a lot about this. There was an interesting discussion on Twitter, I think because of the working from home now, distributed working is kind of enforced and companies like GitLab and Facebook were like officially condoning like we're going to stay working from home now. And then developers on Twitter were like, this is awesome. I'm going to buy a little farm in Arizona, whatever. And then I've, I've got my salary, which is based on San Francisco. This is good. And then somebody was saying, no, that doesn't work that way, because if you look in your contract, it says, if you're moving to another area where the cost of living is lower then the company's allowed to change or restructure your salary and then the discussion kind of came to the point that you're describing, like, yeah, but do I need to get paid for the value that I create for the company or do I need to get paid for to make a nice living? And then if you're talking about the value that you create for the company, then you need to also have a share maybe in the revenue that comes back. It's a very interesting topic that happens because yeah, you only get a pat on the back, nice work, or are you all part of the company and do you also all gain when things are going well? So I think you're inferring that management or more business related roles are more directly related to revenue based bonuses on targets where engineering roles are more far away from this and they're more incentive to uptime or speed of delivery, I guess, or less issues. Is that kind of what you're saying?

Viktor: [00:31:08]
Yeah, no, no. I mean, what you just mentioned goes to my nerves, big time. Every once in a while, when I speak with companies about potential employment and all those things and kind, they ask me, where do you live? Why the heck do you care? Kind of like how much do you think that my work is worth? The fact that I live in a, in a cheap place, an expensive place, should have nothing to do with it. It's my choice. It's really my choice. I was kind of almost. Once I was on the verge of renting a PO box in, in San Francisco, so that I can officially say I work remote from San Francisco. Give me, give me 300 K type of stuff.

Olaf: [00:31:55]
Yup. No, I totally get that. On the other hand, I also know cases where people were asking for a Silicon Valley salary and living in some remote village in Poland or something. It's tricky. I mean, yeah. Do you pay for the value that is created or do you pay market level salary and what is it based on? You start to need a discussion on what is important for a person, but yeah, there's a, of course, a danger if you look at cities like Berlin and even I think San Francisco. Let's say there's this elite of software developers that are paid for the value that they create for this elite of companies like Netflix and Amazon that make load of money compared to the mom and pop stores and these people earn the money that is on that level. You know what happens? Rents go up. House price go up and the normal people are pushed out of the area. So it has its pros and it has its cons. It's a complex dynamic. So I don't have the answer too, but it's an interesting discussion to have. We were talking about release orchestration, weren't we?

Darin: [00:33:06]
By the way, this isn't abnormal for us to end up where we've ended up at.

Olaf: [00:33:11]
I like that.

Darin: [00:33:12]
We tend to ramble a bit. Just again, the company is Vamp. Vamp.io. Since they are a .io, they are a cool company.

Olaf: [00:33:22]
Yeah. It's awesome.

Darin: [00:33:23]
And if you're interested in finding out more information, you can go check them out at vamp.io. If you want to follow Olaf, all of his contact information will be down below. Any other closing thoughts around let's say, because I've been trying to keep us away from Vamp a little bit and give us your best, because you are a C level. Actually you're a double C-level, you're a CTO and a cofounder. So give me the best Vamp pitch you can give right now.

Olaf: [00:33:55]
If it's important to you to have a fast release of your software with full control and observability of the quality, then Vamp is the way to go.

Darin: [00:34:10]
there you go. We'll tell, Joey's your marketing person, we'll tell Joey, I put you on,

Olaf: [00:34:15]
On the spot

Darin: [00:34:16]
on the spot for that, because that's typically a Joey answer, right? Joey would be able to rattle that off.

Olaf: [00:34:21]
No, I think, I think we've been playing around with thousands of lines and in the end, I hope that people encounter the issue and then they're trying to look for a solution for it, and then hopefully we're on their radar. If you experience how it can be, then I think that's always where people are really like, wow, I didn't even know this was possible in this way. That's really cool to experience all the time.

Darin: [00:34:49]
You've got a pretty good under your logo section, you got a pretty good set of logos there. A very diverse set of logos. Let's put it that way too.

Olaf: [00:35:00]
Yeah. No specific verticals for us.

Darin: [00:35:03]
No, that's, that's very cool.

Olaf: [00:35:06]
Yeah. Yeah. I mean, if you run an online platform and you need to constantly improve and iterate upon it and you need to keep the shop open, essentially, then you need to have functionalities that Vamp can provide, like zero downtime upgrading, automatic rollbacks, all that stuff. So that's not really specific for any vertical. I mean, that's for SaaS companies, that's for FinTech that's for ecomm. That's relevant for any online platform that is running 24/7 that needs to continuously improve.

Darin: [00:35:41]
okay. Olaf, thanks for hanging out with us today.

Olaf: [00:35:43]
Yeah. Thank you for having me and thank you for having this great conversation.

Darin:
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.

DOP 82: Where You Live Shouldn't Define Your Pay

Show Notes

Guests

Olaf Molenveld

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript