Leadership for Engineering Enablement Teams
Support the unique needs of engineering enablement teams with a different brand of leadership.
Over the last few years, I had the opportunity to run a mix of product engineering and engineering enablement teams. This included teams responsible for shared libraries and services, infrastructure, build tooling, and developer experience.1
In retrospect, the engineering enablement teams were quite successful, and had a lot of organizational impact. They helped introduce continuous deployment, adopt DevOps practices, migrate to the public cloud, and continuously improve the developer experience. But they also ran into unexpected challenges that were not shared by their product engineering counterparts. This made me realize engineering enablement teams have different needs from their leadership.
If you’re starting a new enablement team, or taking over leadership of an existing one, chances are good you’ll face similar challenges. Here, I’ll share some of the things I learned, and suggest what you can do about them.
Spend Time on Marketing
Product managers don’t just help engineering teams decide what problems to solve. They also work hard to market their products internally and externally. They create awareness, drive adoption, author documentation, and support product launches. But if you run an engineering enablement team, that person is probably you.2
This means you have to get your work in front of an internal audience, and convince them to adopt it. Even if you’ve built something that clearly improves the engineering experience, people will be busy, and wary of change. And it’ll be even harder to get traction if you’re introducing new technologies or ideas that are unfamiliar. Perhaps you’re launching the first component library in your organization, or implementing a new test automation framework, or integrating security tools with your build pipeline? It won’t be enough to show the work: You also have to explain the benefit — repeatedly, in different forums — and help teams get over any barriers to adoption.
If you don’t market a solution enough to get broad adoption, you may find product engineering teams muddling along with painful but familiar processes — at great cost to the organization. For example, if your front-end tools team can’t get adoption for their standardized library stack, product engineers may just continue to manually update third party dependencies sporadically, each on their own schedule. It’s hard for teams to quantify this wasted effort, and hard to justify an upfront investment to achieve some benefit later.
Worse still, teams may come up with their own solutions to problems you’ve already handled. This results in confusion, incoherence, or outright internal competition.
Here are some ways you and your team can market your work internally:
Show your work in all-hands meetings, weekly demos, communities of practice, and other forums. It’s rarely enough to show something once, so you need to keep reminding people of the products and services you provide.
Regularly share internal blog posts, how-to videos, and other content to help engineers get started. Create great documentation, and make sure it can be found. Run hands-on workshops and Q&A sessions, and offer proactive support in Slack. All of this creates visibility, lowers the barrier of entry, and demonstrates long-term commitment to your work.
Update internal self service tools to ensure new projects adopt your work by default, and existing ones get automatically migrated. You’ll have an easier time creating awareness and achieving adoption if you integrate directly with the tools engineers already use.
Share success stories, and publicly celebrate teams that have achieved benefits from using your work. This creates a sense of excitement and pride around improving engineering practices, and helps build strong relationships with your internal customers.
Find influential engineers and keen early adopters in the organization, and work with them on new capabilities. If you can identify a handful of true fans, they’ll enjoy being consulted, help improve your product, and spread the word over time. When you’re working on something big — like a design system — consider creating an official community around it.
As any startup founder will tell you, building a thing is only a small part of making it successful. You need to spend way more time than you think on marketing, education, and evangelism.
Seek Leadership Buy-In
Even if you’ve mastered the art of internal marketing, it’s hard to achieve broad adoption for things that require cultural change. Introducing DevOps practices is a great example, or adopting something like continuous deployment. These types of transitions require a long-term commitment, with ongoing investment in tooling, education, and support. To pull this off, you need to secure leadership buy-in for your vision.
When working with your leadership, you’ll need to explain what you’re doing, and why it’s important. You should also be clear about what help you’re asking for — whether it’s space in leadership presentations, a time commitment from product engineering teams, or something else. And ideally, you should make sure engineering incentives are lined up to support your work. For example, if you’re trying to improve operational maturity, you need to make sure the leadership team recognize and celebrate proactive, sustainable behaviors, rather than individual heroics when something falls over in production.
One thing you might not want to ask for is any sort of top-down directive to use your enablement services. This creates resentment among product engineers, and removes your incentive to build the best possible product for your internal customers. For better long-term outcomes, focus on securing investment and public support, and let your work stand on its own merits.
Also consider senior leaders in your product management and design groups. Many engineering enablement projects will be highly relevant to them — whether it’s developer tooling to build product features faster, component libraries to achieve a more consistent user experience, or instrumentation for better product analytics. If these stakeholders understand what you do, they can be amazing allies in the organization. Help them out by showing how your work has a positive impact, and by articulating how they can support you. In return, they’ll help you out by creating visibility and driving adoption.
Very few technical transitions happen successfully without leadership engagement. And leaders of all stripes will be less familiar with engineering enablement concerns than they are with the product your organization sells to customers. If you want to increase the success and impact of your engineering enablement teams, it’s your job to ensure the leadership team understand and agree with what you’re doing, and help you pull your projects forward.
Show the Team Their Work Matters
Engineering enablement teams can have amazing impact, especially in larger organizations. With hundreds of engineers, even small improvements in the developer workflow add up to meaningful gains. Also, like all craftspeople, engineers love their tools. They’re especially appreciative of automation, and robust platform services that abstract away concerns like consistent instrumentation, backup and restore, and management of security vulnerabilities in third-party dependencies.
Despite all of this, I’ve found engineering enablement teams often struggle with their sense of achievement. While product engineers get a regular dopamine hit every time they ship a new feature to customers, enablement teams create leverage — and leverage is hard to see or measure. As a result, enablement engineers fret about whether what they’re doing is really important, whether anyone values their contribution, or if they’ll become redundant when there’s “nothing left to improve”.
As an engineering enablement leader, you have to show the team how their work has value. Here are a few ways you can do this:
Spend time on a clear vision and mission for the team. This will guide the team’s efforts in a manner that doesn’t have a specific end condition. It also helps generate and prioritize ideas for how to continuously improve the developer experience.
Measure engineering effectiveness and efficiency across all product engineering teams. This helps you identify areas that need work, evaluate the outcomes of experiments, and track the impact you’re having over time. Making this data public can be a powerful motivator for your team. One way to do this is through a monthly report card.
Measure and publicize usage of the tools you build. When you create tools to automate manual workflows, it’s often astonishing how much use they get — and hence how much time they save. Engineers and leaders love to see this kind of data.
Share regular demos and retrospectives with the wider organization, perhaps on a monthly basis. This is a good way to celebrate your achievements, and highlight how they benefitted other engineering teams. It’s also a great opportunity to call out where the pain points are now, and what you’re planning to do about them.
Offer interested engineers the opportunity to rotate between product engineering and engineering enablement teams, for a few months at a time. This builds empathy and appreciation between the different roles, and lets enablement engineers experience the impact of their work firsthand.
It’s super fun to run engineering enablement teams, but they need a different brand of leadership: You’re no longer just an engineering manager, but also a product manager, product marketer, evangelist, educator, and cheerleader. You need to build leadership support for your team, get word out about the work you do, and show your engineers how their efforts matter. If you do this, your team can amplify the impact of all engineers across the organization.
If you like to use Team Topologies terminology, what I refer to as engineering enablement covers both platform teams and enabling teams. When I talk about product engineering teams, I mean stream-aligned teams.
Incidentally, this makes engineering enablement a good place for engineering leaders to learn some product management fundamentals.