7 Things Executives Can Learn From Software Engineers

Given that today every company is a tech company, the overlap between technologists and executives becomes greater and greater. Don’t worry - the CFO doesn’t need to be able to build a Kubernetes cluster! However, many of the well-known practices in engineering can apply to organizational leadership skills.

After all, the root of the DevOps movement is sharing learnings between different teams - in this case, app developers and ops teams - to improve performance across the organization as whole.

At INS1GHTS 2021: Build the Better Future, Matt Stratton, Staff Developer Advocate at Pulumi, provided a new take on what executives can learn from their software engineers.

Keep reading for key lessons that an executive team can absorb from software engineering and operations, or watch the full session replay below for a deeper dive.

And for more INS1GHTS like these, don't miss INS1GHTS Days September: Connecting Applications and Audiences, from Edge-to-Cloud.

1: The Power of Iteration

Iteration is commonly misunderstood. A great example of what iteration looks like compared to incremental work is painting. Working in an iterative manner when painting involves creating a “minimum viable product” at each stage, gathering feedback, and adjusting plans accordingly. With an incremental approach, you finish a section of work completely before moving on to the next.

The end result is the same - a completed painting - except with an iterative approach, you are able to gather feedback and change course throughout the whole process. Given how fast business moves today, an iterative approach better positions leaders for success.

2: Small Teams Move Fast

We’re all likely familiar with the concept of a “two pizza team” at this point, which states that teams should be small enough that they can feed all team members with two pizzas.

There are a few things to keep in mind to make small team structures successful:

• There still needs to be “glue work” between your teams to ensure everyone is working toward the same higher objectives

• Teams should be trusted to complete the work they are tasked with in the manner they think is best (avoid micromanaging)

• Don’t forget Conway’s Law, which states that organizations design systems that mirror their own communication structure. Or put more simply: “you ship your org chart”.

• Software contracts extend to your teams.

3: Fast Feedback

Everyone says they love feedback - but what do we mean by feedback, exactly? To empower your organization to operate efficiently, teams require a short feedback loop that allows them to iterate.

To be successful at providing fast feedback, you need to:

• Set success criteria that is measurable

• Get changes in front of users quickly

• Automate feedback where possible

4: Trust But Verify

Engineers build processes assuming that people will try to do the right thing, but also build things in their pipelines to check. It’s important to balance these two concepts in an organization - assuming best intentions, but also setting up processes that account for the fact that people make mistakes. Guardrails can help make doing the right thing, the easy thing.

5: Collaboration Over Competition

Most organizations strive to be collaborative, and may even consider their environment collaborative. Yet many neglect that power structures can actually create unintended consequences that encourage competition over collaboration. For example, if your team is evaluated on minimizing downtime, it can disincentivize changes and improvements (which can increase the likelihood of downtime).

The Westrum Model illustrates this well. Generative organizations innovate more than bureaucratic or pathological organizations because they drive high cooperation, look at failure as a learning opportunity, and share risks across the organization.

6: Community Spirit

Developers love to work in communities as a way to learn from others who are solving similar problems. While executives often attend round tables and conferences as a way to learn from their peers, this tends to be treated more as networking, and less as a way to openly share learnings. Fewer things have to be secret than we often assume, and can be shared to help peers facing similar challenges.

7: Learning Culture

Engineers have become pretty adept at building strong learning cultures within the tech organization. When incidents like downtime or an outage occur, engineering teams will conduct blameless post mortems or retrospectives. Engineers will also often go through shadow rotations. These are typically thought of as something for more junior tech employees, but leaders can also benefit from getting a deeper understanding of how other parts of the business work.

As John Allspaw of Adaptive Capacity Labs has said, “Incidents are unplanned investments; their costs have already been incurred. Your org’s challenge is to get ROI on those events”. Ultimately, teams need to evolve past the impulse to blame and punish, as it has the unintended effect of disincentivizing the knowledge sharing required to learn from incidents.