What is Engineering Enablement
The number of job postings looking for engineering “enablers” has grown over the past few months, so has the number of people holding the “Engineering Enablement” title on LinkedIn.
I’ve been asked a lot lately to explain what Engineering Enablement really means, so I thought it might be helpful to provide an overview of the trending function called Engineering Enablement: Why it’s needed, Who needs it, and What problems can be solved by building a team of enablers. The information in this article comes from my own experience.
Engineering Enablement is a new title that provides a more accurate description of a role or team that is already available in many organizations. Some will call it “Platform Engineering”. Others will call it “DevEx” (Developer/Development Experience). But in the end — When asked to describe their job and responsibilities — it will always come down to enabling the developers and the business to perform better.
So here is my definition of Engineering enablement:
Engineering Enablement teams’ main goal is to reduce complexity and improve development velocity and time to market by providing self-service solutions, engineering standards, and best practices. The team aims to enable developers to focus on business logic and puts an emphasis on developer experience and product quality (Delivered to production).
Engineering Enablement can take many forms. It can be a guild. It can be a squad or a task force that is made up of different individual contributors who have been tasked with solving a specific issue. Or it can be a formal team and role in the organization. Anyway — They don’t just appear overnight. It is a gradual process that depends on an organization’s maturity.
What do they do?
Part of the team’s job is to eliminate bottlenecks, improve collaboration, provide an outstanding top-level development experience, and accelerate team productivity via self-service of infrastructure, tooling, and templates.
A different but equally important part of the team’s job is to architect, build, and refactor major software components to improve the availability, resilience, and performance of the systems. This can be done by introducing the right technologies and enforcing engineering standards like true microservices design and separation of concerns. They are also in charge of defining strategic tooling direction for the engineering department via a combination of product evaluations, engineering-focused research and development, prototypes, and proof of concepts.
Even though it makes sense to look at Engineering Enablement teams as an extension of DevOps/SRE/Ops teams. They should be viewed as a stand-alone product (feature) team that is serving customers (other developers/stakeholders) within the organization. They will usually own some key functionalities that are used by all other teams.
Who are they?
Typically, the core team is made up of experienced engineers that can handle multiple, sometimes conflicting priorities and deliver successful projects in an uncertain environment. In addition to experience working in a fast-paced environment with a willingness to pitch in whenever necessary to get things done, the team members should also have excellent interpersonal skills because of the nature of the team and the close work with all the other teams.
In every organization, there are some developers that are simply more interested in understanding problems in production environments as well as development environments in more detail. They identify solutions and share them with their colleagues. These developers will probably be the most suitable candidates to form the team because they know exactly what challenges their friends are facing and exactly what they should focus on to improve the situation.
Motivation for building an Engineering Enablement team
A recent study by McKinsey found that companies that nurture their developers perform five times better.
Improving business performance through software development comes down to empowering developers, creating the right environment for them to innovate, and removing points of friction. Industry leaders refer to this capability as “developer Velocity”. And the way I see it — that’s the exact mission statement of engineering enablement teams.
Do I need an Engineering Enablement team in my organization?
Well, to answer this question let’s perform a small exercise. Think of the biggest pain points that your product (feature) teams experience these days. Try to identify what causes these issues. Be honest with yourself answering the following question: Would dedicated engineering time for a short time improve the situation and benefit the whole organization? If the answer is yes, you probably need an engineering enablement function in your organization. Consider forming a task force with a single goal to address this issue. Make sure to gather metrics about the situation before and after the task force effort. A successful project will give you a lot of credit for your future engineering enablement team.
NOTE: If you decide to use a separate team model, make sure the product teams are fully involved in the process and decision-making. Their input is essential. Also, Make sure they are still challenged with technological projects and that they have the autonomy to do their work as they see fit.
Feedback
Disagree with my definition? Think I missed something? Please let me know your thoughts in the comments or on Twitter @talkimhi
