As an engineering leader, you have a choice: you can make decisions constantly that drive everyone mad, or you can make your developers love you by enabling them to do the things that they want to do.
Kendall Miller and Rishi Malik discussed at the PagerDuty Summit how if you are leading a team using Kubernetes, there are five ways you can make your dev team love you. Here are the takeaways.
You want to give your developers tools they actually want to use. As a product person, if you're developing tools for other engineers, think about it from this perspective:
Are engineers going to delight in using this, or is it going to be torture for them to use?
The more painful the tooling that you give them, the angrier they'll be and it's the small irritations that add up to a lot of frustration. For example, are you using Teams when devs want to use Slack (or vice versa)? Are you forcing them to use Subversion, when they just want to use Git, or making them use Git when they really just want to be emailing around their code at the end of the day? (Although in the last example, you really should put your foot down).
If something is going to make your developers more productive because it's something they actually want to use, it's going to be worth the cost difference. A CFO may look at a tool and say, "Eh, that's going to be $50 per engineer. That's not going to be worth it." But often, those things pay off very quickly in developer productivity. It may be a line item to a CFO, but to an engineer, this is what you do day in, day out, and it makes a big difference, and it's worth the investment. Putting tools in place that your engineers are familiar with so that they don't have to spend a long time ramping just makes sense.
Avoid giving them one more dashboard to log into, or one more step along the way of developing that becomes painful. Sometimes there is a reason you have to do that, but as much as possible, giving them tools they want to use is going to be something that actually ends up saving you money in the long term, even if it costs you money in the short term.
If you don’t give your devs the time to fix technical debt, they’ll continue to build on the pile of hacks that is your deployment pipeline until everything breaks and you can't get anything out. The pressure to get this chunk of code out, solve x problem, fix an incident or meet a customer deadline is always present. There is a business to run, money to be made and customers to keep happy, but that is the challenge. At some point, you have to do better. Unfortunately, for most companies, that's not the core driver of what they do.
When using Kubernetes, put the tooling in place that helps your devs be consistent and easily see what needs to be cleaned up. With tooling that offers Kubernetes guardrails, like Insights, or incident management like PagerDuty, you can get a clean, consistent interface where your team is building consistently throughout the deployment pipeline. This is going to make the team happier.
Product-based engineers want to work on features that deliver customer value. Unfortunately, and related to the above, you can spend more time dealing with tooling or hacking around tech debt, because you don’t have time to just reboot it all. But that’s the pain. The team will spend more time maintaining the platform or tooling instead of delivering results to customers. It's a shame and drives people nuts. Developers don’t spend enough time building and shipping the code they want.
The majority of us work because we need to make money, provide for ourselves, our families. When your work feels meaningful because you can draw a line to the business value, you (and your devs) will be more engaged. Asking your devs to chip away at something that they know doesn’t matter will get demoralizing and eventually they’ll move on.
The other side of the coin of business value is cost. Devs don’t really want to focus on that, but at some point there will be a financial person that calls into question the expense of a service suggesting “We can't go do this new initiative because it will cost us too much.” That cost could be engineering, time, OpEx (VMs or container cost to run).
Providing the development team with tooling that lets them quickly make small adjustments to the cloud, the Kubernetes or container configuration so they can reduce costs or demonstrate why they need the VMs/containers running will better position them to be successful.
Unfortunately, many don’t know how to reduce cost. They know they’re spending too much, but have no idea how to improve it, and with Kubernetes specifically, it can feel like a black box. Devs need a way to see into what’s happening so that instead of accidentally losing $50,000 in a week, they know where there is overspend and where to reign it in.
Everything in operations is a trade-off. Uptime versus money, easy or high quality QA, super fast or super secure applications. Figuring out what trade-offs make sense is always part of operations, but security is of particular importance.
You need to be secure up to a certain point. When you're a small startup with five users, you need to be secure in a different way than when you're Clover Networks and you're handling payment processing. When you’re in a regulated industry, you have no choice in those security trade-offs. You know exactly what standards you need to meet, and no matter how painful or miserable it is, you have to meet those standards.
When using or implementing security tools that make sense to your development team, that's one less trade-off. It’s important that there is a rationale to security so that everything isn’t simply locked down so productivity stops (or worse, the team works around the security tooling so you end up with something insecure).
If you work in a PCI-compliant environment, there is always a fear a dev will work around a security requirement. As soon as you put a new platform or tool in place, you risk losing the support of the folks in your org who are trying to do the right thing. You can lose visibility into how the platform is being used because if they’re doing “work arounds,” you don’t know what’s happening to make conscious trade-offs.
The way to do security well and ensure a great developer experience is to make sure you have visibility and make it super easy to do the right thing and really hard to do the wrong thing. You don’t want the security team to be the team of “no.” Instead, the way to make developers happy is to make sure all your libraries are up to date, all your dependencies are moving up, as new versions are released and as new vulnerabilities are found, bake that into what you do, bake that visibility into the tooling that you have, and all of a sudden you are much more secure and you're making developers' lives better. It's win-win all around.
Fairwinds Insights helps enable developers to secure Kubernetes. Learn more.
Let’s start with an example. There was an engineer that spent 60 hours outside of work to build a solution to a business problem. He was really excited to show his CTO, but when he did the CTO asked “why is it in Ansible and not Python.” Instead of sharing something of great value and receiving praise, the guardrails were unclear and the pushback makes the engineer cry and eventually quit.
Organizations need to set up rules, make them clear and set the scope so that people have autonomy to go solve problems. But when setting those rules up, set the context and explain the why. In the example above, maybe it was because Python is the default programming language to avoid the challenge of hiring experts outside of Python.
Let people make good decisions when they can't ask the leadership, because leadership can't be in every single decision. Set the why, set the context so that people know the reasoning behind it and can make the best choices.
People want guardrails (especially with Kubernetes), so that they have enough freedom to solve business problems with safety nets in place (so things won't end in tears). Guardrails give everyone comfort to execute.
Conversely, guardrails give freedom in an autonomous way when something is done it doesn't come with the question "Why did you do it that way?" It’s going to keep your devs excited, engaged, enthusiastic, and it's going to keep people in the job for the long term. It's going to make your engineers happy with you as an engineering leader.
Companies should be thinking more about the developer experience.
Implement great tooling so developers can do more faster.
Use tooling that makes life better for folks.
There are a lot of challenges in development, but thinking this way will move the entire industry forward.
There are lots of things out there that make this easier, good tooling, open source. Fairwinds offers Kubernetes users open source tools including Polaris, a policy engine to check to ensure best practices are followed, Goldilocks, to help set resource requests and limits and a number of other tools. In addition, Fairwinds Insights provides Kubernetes governance at scale, giving your engineers guidance and comfort that they can do what they need, in the right way, the first time.
