devopsy.kinsta.cloud

Category: Platform Engineering

How Good Developers Become Good Engineering Managers

Being a good engineering manager means that, to some degree, you have a natural affinity for the work involved. And if you’re a good developer, you likely already have some of those innate skills and attributes.

But simply having the skills doesn’t mean you’ll enjoy being an engineering manager. For example, the nature of the role is that you’re no longer the one writing the code. I’ve known great architects who became great managers, but they ended up going back to being individual contributors (ICs) because they missed working with nitty-gritty coding details and the joy that brought them.

It helps to take a realistic inventory of your skillset and preferred working style before making the transition. There are certain competencies you should have completely dialed in, and other tips to know that will help your transition.

Basic Skills of a Good Engineering Manager

If you’re a good engineer, you likely already have the following foundational skills that also make a good engineering manager. With these in your toolbox, you’ll have a better chance at success.

1. Attention to detail. The buck stops with the engineering manager. You need to know when to push and ask questions and how to set outcomes for your team’s accountability. If you work loosely as an IC and need reminders about your own work, you probably won’t do well as a manager.
2. Amazing personal planning skills. As an engineering manager, you’ll be planning an entire team’s work. If you’re terrible at planning your own work, maybe the engineering manager role isn’t for you.
3. Speak intelligently about broad technical topics. If you’re a good developer, this shouldn’t be a concern. You’ll need this knowledge to advocate for your team and justify their work to upper management.
4. Team player attitude. Even as an IC, you should have a collaborative, team-oriented mindset. It goes without saying that you’ll need this when leading others.
5. Interest in managing others. This might seem obvious, but if you don’t have a natural interest in managing others and in the people side of engineering, you’ll be unhappy as an engineering manager.

Making the Transition From Developer to Engineering Manager

If you can do all of the above and are ready to make the transition from developer to engineering manager, here’s what to be aware of as you navigate that process. These tips aren’t meant to deter or discourage you but rather provide a helpful dose of reality.

Satisfaction in your work takes new forms. If you’re an excellent developer, you know the value you bring and likely get personal satisfaction out of the contributions you make. As a manager, it’s harder to see the direct value you provide. Shift your mindset and realize that now, you’re the one enabling developers to do that rewarding work, and that’s the value you provide. You’ll learn to take enjoyment and fulfillment from your team’s accomplishments.

People take up a lot of your time. What most frequently catches new engineering managers off guard are the people-related aspects of the role. They’re not prepared for how much time managing people takes. I’ve seen it over and over again where a new manager thinks they can still set aside time to code, but you really have to prioritize learning the craft of management.

Remember to communicate upward. In the absence of information, it’s human nature to assume the worst. When I was at BitBucket, I assumed that because I had always done a good job, the leaders would think my team was crushing it. The opposite was true; leadership thought everything was on fire.

I started sending updates every two weeks to various levels of management, and that’s when I learned the power of upward communication. I realized I needed to sell my team’s work, contributions and challenges. Learn what higher-level leaders are looking for and then give them that information regularly.

Context-switching is part of the job. As an IC, constant context switches kill your day. But being an engineering manager means dealing with endless context-switching. Going to multiple meetings is baked into the job, and you’ll still have to find ways to block off time to get other work done.

Shield your team. You also need to be prepared to help protect your team from context-switching. You might learn information that’s important to your team during your many meetings, but not all of that needs to be communicated with them. Filter out the junk so it doesn’t rain down on them and they can maintain their flow.

Being an engineering manager can be a rewarding role that has a considerable impact on an organization. The more prepared you are for the realities of the role and its differences from being a developer, the more you’ll enjoy it and the more successful you’ll be.

May 1, 2023
Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: A new Linux kernel drops and layoffs at Amazon Web Services point to trouble. (more…)

April 27, 2023
Platform Reality Has a Surprising Amount of Detail
Developer platforms and the platform teams that create them have been the center of attention for quite some time now. There have been many (wildly different) opinions about the subject, ranging from how bad the notion of a platform team is to how essential platforms are to make an organization’s DevOps journey to cloud native successful.

Since early this year, the CNCF TAG App Delivery team has been working on a whitepaper about platforms. It explains what platforms are, why they are needed and how platform teams might work to create them. Furthermore, there’s an abundance of end-user talks at conferences that show how platform teams and their platforms were essential in enabling developers at scale. Even on the KubeCon + CloudNativeCon keynote stage, we’ve seen success stories of platform teams like the one at Mercedes Benz.

Developer Platforms Should Enable Developers

There is no silver bullet to successful platform teams and platforms. However, it is important to understand that the main goal of a developer platform is to enable developers. It is essential for platform teams to focus on delivering that value, which is why we are seeing a trend to introduce actual product ownership and product management roles to platform teams.

The CNCF whitepaper stated that the three core jobs of a platform team as follows:
1. Research platform user requirements and plan a feature roadmap.
2. Market, evangelize and advocate for the platform’s proposed values.
3. Manage and develop interfaces for using and observing capabilities and services including portals, APIs, documentation and templates and CLI tools.
I couldn’t agree more. But the reality of day-to-day business for many platform teams means they rarely get to focus on those three jobs.

Reality Has Detail

The situation reminded me of a blog post I read a few years ago, titled “Reality has a surprising amount of detail.” The author explained how it is easy for people to get stuck even when faced with a task that might look simple from the outside. They explain how a task as simple as building wooden stairs can, in its many subtasks, become quite complex. Furthermore, when faced with reality, even the tasks that seemed plannable get more complex and need real-life adjustments.

Most engineers have had analog experiences in their day-to-day work. We can translate this notion into platform engineering quite well. Building a developer platform sounds straightforward at the onset. However, once we get into it, it becomes a rabbit hole of figuring out the CNCF landscape, adding company-specific glue, compliance, security, fixing bugs, getting deep into the open source projects and sometimes, faced with the reality of open source, even becoming contributors and maintainers of such projects.

Now, I’m not saying that it’s all bad. All these things can be great and rewarding in their own way. Especially with a community like the CNCF, participating and contributing to open source can be a very rewarding experience. You’ll make lots of friends, learn DevOps and development skills and might even further your career significantly.

While it’s a lot of work, there is a risk that every platform team basically reinvents the wheel. This is because an organization’s requirements seem too large to rely on a single product (or even a suite of products). We end up with bespoke platforms that need a lot of attention. These platforms also have platform teams that don’t have enough time to focus on the higher-level jobs that they were tasked with.

Platform Evolution

Over the years talking to and working with platform teams we have built a model of prototypical platform evolution and its risks at each stage.

Usually, a platform team starts with the task of building a developer platform to enable the product teams to build great software and deliver value to the end users.

As they build the platform from the first Kubernetes clusters to observability tooling to security, the backlog for features constantly grows. Even with a growing platform team and sub-teams for certain technology areas, there’s a risk that some of these backlog items never get attention. Especially, delayable, non-critical, daunting tasks (like upgrading to the next Kubernetes release) often fall victim to this problem.

Next, when it comes to operations, the platform team needs to limit the possibilities and breadth of what they offer. Operations responsibility for functionality that is outside of those limits, (for example, a specialized data store) goes back to the product teams themselves, which results in developer distraction.

Even with a wide coverage of the platform, Day 2 and operations, the next big task for the platform team is advocating for adoption. This is not just marketing for their platform, but also means the platform team has to build user-friendly interfaces and documentation. The risks and alternatives we often see here are that product teams build their own mini-platforms and systems that result in shadow IT. Another common risk is ending up with several competing platforms within big enterprises that are hard to integrate and centralize, which in turn leads to inefficiencies.

Once we get over the adoption hurdles, it is the platform team’s job to deliver value and high-level capabilities to the product teams’ developers. However, at this stage, often the platform teams have grown and might encompass several sub-teams for technology areas. Additionally, some areas like security might already be under central IT control. The risk we see here is that the capabilities offered are reduced to technology silos. They might cover all areas like observability, connectivity, security and release engineering, but to achieve real maturity, a platform team needs to offer capabilities that span several of those areas.

Many of the advanced capabilities that we see with more mature end users cover several or all technology areas. Think about a simple high-level capability, like progressive rollouts. It starts with release engineering capabilities to build and deploy the software. From there, we need connectivity capabilities to dynamically route traffic to the new service. Then we need observability capabilities to observe our new version and from there have automated feedback loops to roll back or go forward with the rollout to production. And if that wasn’t enough, as we’re a security-aware organization, we want the whole software supply chain that facilitates this to be secure and trusted.

Question for the curious cloud native enthusiasts: How many tools do you need to integrate to achieve the above “simple” high-level capability in an automated way? And this is only one of many capabilities.

PaaS-Like Platforms Without the Downsides

So, while platforms and platform teams are definitely the way to go, we need to be aware of the amount of work and effort required.

We need to be aware of the risks and strive towards building highly integrated platforms that deliver high-level capabilities to the product teams.

However, cloud-native developer platforms, while having similar goals to the PaaS systems of the past, should not follow the same approach of full abstraction. If we just abstract away into bespoke systems that hide everything from the user, we go back to the world of PaaS where at some point the end-user developers hit limits and build workarounds around the platforms.

Additionally, if we build these bespoke internal platforms, we’ll be stuck with them and need to maintain and evolve everything by ourselves.

Or, to go back to the blog post I referenced earlier, “At every step and every level there’s an abundance of detail with material consequences.” And we have to remember what we care about. The way to avoid both of these downsides is to bet on open source and stand on the shoulder of giants.

By building our platforms on open source and using as many of the established or soon-to–be-established standards of our community we can avoid our platforms becoming bespoke. Recent developments like Cluster API, Gateway API and sigstore are some good examples.

Furthermore, we need to make our abstractions poke-able. While our platforms should come out of the box with user-friendly interfaces and sensible production defaults that enable new product teams to onboard quickly and get their jobs done without having to bother with deep understandings of the underlying technology, we need to keep them open to mature users that know their way around and want to tweak it to their needs. We achieve this by giving mature users the option to access said open standards and APIs safely.

This is the strength that we gain from a community like the CNCF, so we should use it to build great platform products that stay true to the core of open source and strive to make our product teams as happy and successful as possible. And remember to be happy with ourselves as successful and appreciated platform teams.
April 25, 2023
How Platform Engineering Makes Software Sustainable
The world is constantly becoming more and more aware of the importance of sustainability in every aspect of our daily lives from buying groceries to traveling, and the IT world is no exception. Indeed, sustainability is already gaining importance in software development. For example, in the latest version of Thoughtworks’ Technology Radar, “carbon efficiency as an architectural characteristic” is one of the new techniques of interest. Moreover, in its research “Predicts 2023: Environmental Sustainability Is Now an IT Sourcing Imperative,” Gartner states that “by 2026, 75% of organizations will increase business with IT vendors that have demonstrable sustainability goals and timelines, and will seek to replace vendors that do not.”

This shows that there is a growing need for sustainability. How is the software development industry responding to this need? Many great initiatives are arising, but platform engineering, in particular, helps make software more sustainable.

What is Platform Engineering?

According to Gartner’s definition, platform engineering is “the discipline of building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management.” This trend has gained momentum in the last few years, and an increasing number of organizations are adopting internal developer platforms (IDPs) to scale their development process. IDPs allow developers to self-service the technology they need, whether it is infrastructure, runtime resources or ready-to-use services. This helps speed up the development process and ensures higher-quality software.

Platform engineering is becoming more and more popular and foundational. According to Gartner, “by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery.” Therefore, given the expected widespread adoption of IDPs in the next few years, sustainability emerges as a requirement. Ignoring or underestimating the importance of sustainability may cause organizations to waste all the benefits ensured by an internal developer platform.

Platform Engineering for Economically Sustainable Software

To survive and operate properly in the market, a company has to be economically sustainable and therefore stable. Usually, software is an asset that contributes to revenue generation for the company, but it still has maintenance costs. To make software economically sustainable, the total cost of ownership (TCO) needs to be lower than the generated income.

An internal developer platform can lower software product costs, making them more sustainable. How so? In a nutshell, by sharing resources that can serve multiple products and can be reused across multiple projects. Such resources include, but are not limited to, capabilities, processes, infrastructure, configuration, etc. Since the platform at scale manages shared capabilities, there product teams won’t waste time and effort replicating it every time. While lowering the TCO, this characteristic of platforms also contributes to reducing the software’s time to market.

Moreover, platform costs are shared across the whole organization and are not part of the TCO of each software product. This helps software to be more sustainable from an economic point of view.

Platform Engineering for Environmentally Sustainable Software

When talking about sustainability, most people usually think about the environment. While respecting the environment is one of the most important factors, it is important to note that sustainability is not limited to this aspect.

An internal developer platform can help software be more sustainable on two levels.
- Observability: The platform should collect and easily expose metrics on the environmental impact of the software. Such metrics can include hardware resource usage, energy consumption and CO2 footprint.
- Optimization: The platform should foster the adoption of sustainable patterns, like the ones provided by the Green Software Foundation. It should also include solutions that actively help reduce energy consumption, such as kube-green.
It is important that both of these capabilities are present and implemented in the platform. Observability without optimization is useless, and optimization without observability cannot be done.

Platform Engineering for Socially Sustainable Software

When speaking about sustainability, social responsibility cannot be forgotten. The first social responsibility of each organization is toward its members and employees. Does developer self-service also have social implications? Yes, it does; mainly by improving the developer experience.

Indeed, an internal developer platform helps organizations’ members to:
- Reduce friction between teams: Since everyone can have everything they need right when they need it, there will no longer be bottlenecks and misunderstandings between different teams. This contributes to a better working environment where everyone feels welcome and more productive.
- Decrease repetitive tasks and cognitive load for developers: Since the platform will manage and automate interactions with infrastructure and runtime, developers will no longer need to waste time and energy on such out-of-scope secondary tasks. This way, developers are more focused on their actual job of developing new features and they will feel more satisfied.
- Enable work from anywhere at anytime: Since the platform can provide all technology and capabilities whenever a developer needs them, it will no longer be required that people work together in the same location and at the same time. In other words, IDPs enable remote and asynchronous ways of working. This allows organizations to offer remote working and to create distributed teams, ensuring a better work-life balance for the team members.
All of this brings happier employees that will be more productive and satisfied with their work, which will reduce turnover.

Conclusion

The need for a more sustainable world is gaining momentum and involves every industry, including software development. No wonder Gartner included sustainable technology in the “Top 10 Strategic Technology Trends for 2023,” along with platform engineering. As platform engineering is being adopted by more and more organizations to accelerate software development, sustainability has to be addressed.

An internal developer platform can help developers build more sustainable software. Platform engineering can help in all of these aspects, improving not only the developer experience but also the organization and the environment. This is just the beginning of the sustainable path platforms should follow, but the outlook is very encouraging.
April 11, 2023
Android Apps Must Let Users Delete Data ¦ RISC-V in the Data Center

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Google forces apps to make deleting users’ data easier, and the RISC-V drumbeat grows louder. (more…)

April 6, 2023
Orgs Shift Toward Centralizing Automation Initiatives

A survey published today found that 75% of respondents recognized that automation silos hamper their ability to unify cloud operations across functions.

Conducted by CloudBolt Software, the survey polled 350 senior IT and DevOps leaders at organizations with more than 3,000 employees. On a positive note, the survey found 57% of respondents were starting to pursue a more centralized approach to automation, with a total of 88% acknowledging that having all previous and new automation centralized for the entire organization would ensure compliance, bolster security, enable business continuity, encourage reuse and reduce risk.

Rather than taking a more holistic approach, well over half of respondents (57%) reported automation efforts are limited to specific silos. On average, organizations are employing 27 different automation tools their organizations have deployed, using one or a few as they see fit, with little to no consistency across teams. More than half (55%) of respondents said they have four or more separate automation teams, with 95% noting that each of those teams operates in their own silo.

CloudBolt CTO Rick Kilcoyne said that lack of continuity clearly creates inefficiencies and redundancies that conspire to raise the total cost of IT. The challenge is that each team tends to favor one approach to automating a silo with little to no regard for a larger overall strategy to create an automation standard, he said.

That approach also creates issues whenever a member of one of those teams leaves an organization, he noted. In fact, the survey found 77% of respondents reported that continuity is at risk any time a vital member of the team leaves.

CloudBolt has been making a case for a federated automation platform that can be invoked either via application programming interfaces (APIs) or a graphical user interface (GUI) that provides access to low-code tools. The goal is to make the platform equally accessible to DevOps teams or IT administrators that tend to lack programming skills, and do so in a way that doesn’t require individual teams to replace their automation platform of choice. Instead, each of the automation platforms can be programmatically invoked via a central framework, said Kilcoyne. That approach eliminates any political debate over the potential need to replace one team’s favored automation platform with another, noted Kilcoyne.

Regardless of who is accessing the platform, most organizations would be well-advised to develop a center of excellence for automation, he added.

DevOps teams have always been committed to ruthlessly automating as many IT processes as possible, but in many cases, that has resulted in a plethora of automation tools being employed. In effect, automation may have become too much of a good thing. One approach to regaining control over those platforms is to create a platform engineering team that centralizes the management of DevOps workflows.

Regardless of approach, Kilcoyne said the most important thing for any team to do before automating an IT workflow is to first understand how to manually set it up. Too many IT teams are trying to apply automation to processes they don’t really understand with mixed results, he added.

The one thing that is certain, especially with the rise of artificial intelligence (AI), is the management of IT is going to become more automated.

April 6, 2023
env0 Extends Workflow Platform for Provisioning Infrastructure

env0 today announced it has added support for additional infrastructure-as-code (IaC) tools and the Microsoft Azure DevOps platform to its workflow automation and management platform.

Fresh from raising an additional $35 million in funding, env0 CEO Ohad Maislish said while Terraform remains the most widely used IaC tool, there are now more organizations using alternatives such as CloudFormation from Amazon Web Services (AWS) along with Pulumi and Terragrunt.

Other capabilities added to the env0 platform include automated drift detection, multi-tier workflows, auditing, external logging platform integration, support for plug-ins and expanded role-based access controls and OpenID Connect (OIDC) authentication.

Finally, env0 is extending its existing Terraform support to include support for remote backend, module registry, remote plan, and the ability to plan and apply pull requests. The capabilities are especially critical for organizations that are now building microservices-based applications that require more sophisticated workflows to provision infrastructure resources, noted Maislish.

Most IaC tools are designed to enable developers to address technical implementation and provisioning issues without regard for user experience, security and governance, or business goals. The env0 platform makes it possible to create infrastructure environments with guardrails in place that enable DevOps teams to centrally address governance issues, noted Maislish.

In general, there’s now a lot more focus on continuous delivery (CD) as organizations look to continuously update applications, said Maislish. That requires a more structured approach to provisioning infrastructure across teams of developers that is managed by a platform engineering team, he added. The challenge is that CD is dangerous—in the sense that mistakes can easily be made, noted Maislish.

It’s not clear whether organizations are embracing platform engineering to centralize the management of DevOps workflows, but the number of organizations that have mastered CD best practices remains low. Most organizations are adept at continuous integration (CI), but given the number of unique platforms on which applications are deployed, CD has proven more challenging to adopt. In theory, a platform engineering team should make it easier for DevOps teams to define a consistent approach to CD that could be adopted across an organization.

Regardless of the DevOps approach, the overall goal is to improve developer productivity. The problem is that in the absence of any guardrails, developers have been provisioning cloud infrastructure as best they can. Not surprisingly, cloud computing environments are rife with misconfigurations that create vulnerabilities that cybercriminals have become more adept at exploiting. The fundamental issue is not such much the cloud infrastructure that is available as much as it is the processes employed to provision the resources. In their rush to build and deploy applications, developers will sometimes ignore best practices unless guardrails force the issue.

One way or another, IT organizations are exercising more control over cloud computing environments as the security of software supply chains becomes a bigger issue. The only thing that remains to be resolved now is how to put much-needed guardrails in place in a way that adds the least amount of friction possible.

March 29, 2023
How to Supercharge Your Engineering Teams

With the economy still bleak, data and engineering teams that were already struggling to keep pace with business needs are now facing a potential hiring freeze or worse in 2023. That’s why there’s never been a more important time to maximize the productivity and impact of your teams, but the question is how to identify the big changes that move the needle in performance. Incremental adjustments that save a sliver of time here and there are not hard to come by, but what teams need are the breakthroughs that yield giant leaps in productivity and efficiency. Rather than a 10% improvement, it’s the 10x improvements that drive lasting gains.

As an engineer and CEO of a software company, I’m constantly looking for ways to boost the productivity of our teams. Our guiding principle is simple: Maximize the impact per hour invested for every individual. To do that, we must ensure that individuals maximize the time spent flexing their superpowers, minimize busy work and reduce dependencies on others that delay work or tie them up in meetings. While counterintuitive at first, we consistently find that collections of well-aligned, independently executing individuals produce a far greater impact than a large team swarming on a project. Put another way; the individual impact goes up when the number of people you depend on to deliver the result goes down.

I’ve developed an approach over the years that has allowed me to identify several opportunities for step-change advancements in productivity and efficiency, and I’d like to share it here, along with two concrete examples. I will also share an exercise we run with our teams to help identify and execute these opportunities.

First, here are my two main criteria for identifying the projects and tasks where we can effect changes that will have an outsized impact on the company:

● Big resource-consumers: Work that’s essential to the business but consumes a large amount of engineering and other resources is a top candidate for optimization.
● Big impact, easy win: Areas that will have a significant impact on company performance if we can do them faster and with higher frequency are also great candidates—even if they’re not consuming a ton of resources.

Here are two examples that illustrate each of those criteria and where we were able to see massive gains in productivity, quality of service, or both.

Tackling Big Resource-Consumers

At Ascend.io, we provide a platform for building and automating data pipelines, which requires us to build connectors into a huge variety of data sources. At one time, building a new connector required multiple engineers to spend two to three weeks writing more than 5,000 lines of code that spanned four microservices in three different languages. As we added more customers and needed to support more data sources, this quickly became unsustainable.

When we looked at this process, we saw two issues: Engineers were writing custom code for each connector in a way that would be better served by a common framework. Moreover, the process required engineers from multiple teams and disciplines to work together and coordinate their priorities. As soon as you get dependencies that require engineers to coordinate with others and wait on the outcomes of other people’s work, you’re wasting time.

We addressed this by designing a new development framework that exploits commonalities across the connectors we build. This now requires far less unique code and removes the need for multiple engineers to work together. In most cases, one person can build a new connector in days with 100 lines of code. This made us far more nimble and freed up engineering time to do other valuable work.

Achieving High Impact

Like most companies building software, we need to convey the capabilities of our product to new and existing users to ensure they receive maximum benefit from their use of Ascend. With new features and enhancements being released on a weekly basis, there is a lot to keep up with. This is high-impact work, however, and if we can do it in a vastly better way, it drives an outsized impact for Ascend and our customers.

For us, building these automated product tours typically required a product marketer or product manager to design the customer journey, and one or more engineers on a sustained basis to build the actions into the product. This again creates dependencies that slow progress and require significant manual coding.

The breakthrough for us was a tool called Intercom, which allows you to build sophisticated product tours without needing to write code. Our product team can now build more interesting and complex product tours for customers, and our engineers can stay focused on building new features instead of the code needed to showcase them. What’s more, they are able to design, test and deploy these tours independent of our product and code deployment cycle, further freeing them to iterate as fast as possible.

A Thought Experiment

So how do you actually find these opportunities for 10x improvement? I run the following thought experiment with our teams several times a year to uncover these opportunities:

Imagine your workload scales 10x overnight and you absolutely must meet this increased need, but without hiring more engineers or working more hours. How do you do it?

It’s amazing what this exercise can uncover—but there are ground rules and it can take time to see results. Coming up with these big ideas is a skill like any other, and most people are not great at it the first time they try it. Your first iteration may produce no options to pursue—some may have high-impact ideas but with even higher investment requirements, while others may reject the premise outright. That’s normal. So, don’t insist they sit in a room until they dream up that 10x breakthrough, because it will be demoralizing. Instead, plant the seeds by establishing the above framework and then let the ideas start to grow.

More likely, a few days later, they’ll be out for a hike or chatting with an old co-worker and they’ll suddenly have the germ of an idea. That may still not be the winning solution, but someone else will build on it, and then someone else and, finally, you iterate your way to a breakthrough. Pulling the team back together and embracing the “yes, and” approach can be both energizing and highly productive.

Brainstorming like this is fast and free, and you only need one great idea to have a material impact. We run this exercise a few times a year and have come up with several big ideas that were game-changers for the company. Besides the examples above, we also moved key parts of our software development from Scala and Go to Python a few years ago, which is a much more efficient language (as measured by developer time) and allows our engineers to build things much faster.

Software engineering is a complex beast that often spans many teams working on multiple processes in parallel. But that complexity is also your opportunity: Every complex system has room for optimization, especially at companies that moved fast in the beginning to build a product and find market fit. Now is the time to lift your gaze, look around and ask where significant gains can be made. They almost certainly exist, and a 10x improvement could be what allows you to not only survive the turbulent year ahead but emerge with a thriving team and business on the other side.

March 27, 2023
Linux Tweak Brings Big Speedup ¦ DCs in SPAAACE (Redux) ¦ Atlassian Fires 500

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Intel optimizes Linux multithreaded networking, data centers in space (again), and more DevOps toolmaker layoffs. (more…)

March 8, 2023
Strategies To Consider When Adopting Platform Engineering
Platform engineering helps centralize the responsibilities associated with maintaining internal infrastructure. And it continues to be an emerging discipline—according to the 2023 State of DevOps Report, 51% of organizations have already adopted platform engineering within the last three years, and 93% said it’s a step in the right direction.

I recently met with Hope Lynch, senior director of platform at Cloudbees, to gain some insights on implementing platform engineering. According to Lynch, platform engineering has emerged at a critical juncture. Developers are overloaded, burnout is on the rise and tooling sprawl is starting to rear its ugly head. To respond to these trends, platform engineering has emerged to take the heavy load off internal software infrastructure management. But the practice requires keenly balancing responsibility with control and treating the platform as a product.

Interestingly, Lynch believes that many IT departments—whether they know it or not—are already implementing some form of platform engineering. They might just need to work out the kinks. Below, we’ll define platform engineering as it relates to DevOps and share some best practices to consider when rolling out (or reiterating) a platform engineering plan within your organization.

State of DevOps and Platform Engineering

So, what is the state of platform engineering and DevOps? Contrary to the salacious ‘DevOps is dead,’ headlines, Lynch doesn’t believe DevOps is going anywhere. Instead, platform engineering is helping overburdened developers, having emerged at a time when developers and operations seem to be at a crossroads.

Developers are now responsible for coding, security, deployment and infrastructure maintenance. “Developers are talented and creative, but everyone has only so much capacity,” said Lynch. She believes platform teams can relieve some of these pressures by creating standard builds and common CI/CD pipelines. “I see it as a partnership between the DevOps teams and platform operations teams.”

Lynch views DevOps as more of a practice than a specific job title. And although developers should have control over their DevOps toolchain, she believes they were granted too much responsibility. For example, the amount of effort required to search the market, talk to vendors, and try out tools can all add up significantly.

By creating proven patterns and managing tools, platform engineering teams can help narrow down the options, working behind the scenes to ensure the platform is self-serviceable and continually updated. Of course, this partnership requires regularly collecting feedback to ensure platform teams are enhancing development workflows, not hindering them.

Best Practices for Platform Engineering Adoption

So, what are some best practices that enterprises can apply to their internal DevOps platforms? Lynch shared some areas platform engineering teams should focus on to improve their process. By following these tips, a platform can enhance DevOps principles within a company.
- Be open to feedback from developers. As previously mentioned, platform engineering and development should be partners. Platform engineers should seek to gather as much feedback as possible from developers to improve their experiences and ensure the right DevOps tools are acquired.
- Don’t control everything. As such, a degree of flexibility should be granted—you don’t want to mandate standardized adoption of all tools. Yet, you do want to decrease rogue tooling and sprawl. The platform team should thus work to find a balance and build trust.
- Maintain a DevOps culture. When people discuss DevOps, they often talk about the tools and technology, not why DevOps came to be. “DevOps is here because we were trying to find a way to allow teams to work better together and be high-performing,” said Lynch. As such, we shouldn’t forget to include the people element here. Platform engineering should reinforce a healthy culture with positive dialogues and ensure work is “a fantastic place to be.”
- Treat the platform as a product. When delivering internal-facing tools, your developers are your consumers. Thus, it’s a good practice to treat the platform as a product in its own right. This includes publishing roadmaps and eliciting feedback. “The platform team really needs to win the business of their internal customers, or else they’ll buy or use something else, which could cause shadow IT.”
- Focus on increasing developer experience. As part of viewing internal developers as customers, platform teams should invest in improving the developer experience associated with using the platform. This means reducing friction and integrating new capabilities into preexisting workflows whenever possible.
Goalposts For Platform Engineering Success

For any new initiative to be successful, it must have goalposts and be measured in some capacity. The same is true for platform engineering. So, what are some goalposts that IT leaders should have in mind when introducing platform engineering? According to Lynch, some positive end results include collaboration and efficiency, cost analysis, cybersecurity and tooling centralization.
- Collaboration and efficiency: First, platform engineering should improve work in the best way for everyone, says Lynch. “The people component is always there and should always be a priority,” said Lynch. To reach these goals, she recommends having the right conversations to co-discover bottlenecks in the value stream management of software development.
- Cost optimizations: Secondly, platform engineering is an opportunity for garnering insight into usage rates, which could inform cloud cost analysis. Platform teams can implement specific policies, such as spinning resources up or down to reduce expenses.
- Improved security: Platform engineering teams can be the first to test new products, giving them a unique opportunity to synchronize requirements with security teams. They can also take the reins of continually patching dependencies to reduce vulnerabilities.
- Increasing consistency. In general, another benefit is centralizing tooling control. Because when tens and thousands of developers are each using their own tool, it becomes harder for teams to work together. While some cutting-edge technology organizations may seek to give developers control over the full cycle to increase agility, most will benefit from centralizing procurement and oversight, said Lynch.
The Human Side of Platform Engineering

“Platform engineering, when done right, furthers the principles of DevOps,” said Lynch. And interestingly, it may be the case that teams don’t even realize they are already doing platform engineering. Once they realize they are gravitating toward these ideals, it will be an even greater reinforcer for DevOps and DevOps principles, she said.

Currently, the tech space is in a tricky spot, with rising layoffs and tightening budgets. At many organizations, fewer people are now expected to perform the same high caliber of work. As a result, we need to place more emphasis on retaining the remaining talent and boosting morale. This means caring about what the developer’s experience is like throughout the day and supporting the human side of DevOps. According to Lynch, platform engineering is a natural choice in these circumstances.
February 23, 2023