EMPOWERING IT TRANSFORMATION
How a Product Manager for IT Enablement Contributes to our Technology Transition
At the beginning of 2024, I joined Essent as a Product Manager for the IT Enablement department called 'I Empower'. Over the last 13 years, I have worked in diverse IT-related roles, including Agile Coaching, Software Delivery, and Project and Product Management. After spending recent years as an Agile Area Lead, I now see an opportunity to focus fully on the Product Manager role. This was especially appealing to me as I finished my Master's in Digital Business a few years ago and saw a chance to bring my digital transformation vision into practice.
As a Product Manager, I lead a team of Product Owners. The DevOps teams that my Product Owners are leading are all focused on internal IT platforms (or 'IT4IT' in short). Therefore, I realize more and more that the placement of a Product Manager (PM) with a 'business hat' to lead the IT Enablement teams is both innovative and transformative. I believe that this organizational design choice is directly impacting the ability of Essent to transition into a tech company. In this article, I aim to explore the organizational structure underpinning our IT ambitions and highlight the advantages of adopting a product perspective on internal products.
The growth of our IT department
Traditionally, IT Enablement departments with names as 'IT Operations', 'Shared Services' used to operate in silos. They would focus on technical solutions, cost-effective purchasing, and minimization of hands-on processes to further optimize their costs. In my experience, these kinds of IT departments were viewed by higher management as 'cost-centers' rather than business assets.
When Essent IT embarked on its journey to become a tech company (see this article), the number of DevOps teams in the Agile Release Trains (ART) began to grow rapidly, resulting in a classic need for specialization between DevOps teams. It was in this process that in the second half of 2023, the 'I Empower' ART was born, and during 2024, more teams were added to this new ART to provide platform and enablement services that take away mental load from the DevOps teams in other ARTs.
Democratic management structure
Currently, our IT department is organized in seven distinct Agile Release Trains, each being led by a Product Manager, a Lead Solution Architect, and an Engineering Manager. This setup is inspired by the SAFe framework that we largely adopted. At Essent, these triangles are often referred to as 'The three amigos'. This is a form of democratic leadership that fosters shared responsibility, collaboration, and collective decision-making. Each of the amigos brings their responsibilities to the table:
The Product Manager: Defines the vision, priorities, and roadmap for the product(s) and projects, the product manager leads the product owner team
The Engineering Manager: Focuses on the smooth coordination of engineering execution while supporting engineers in their growth, as well as holding budget responsibility for the department
Lead Solution Architect: Ensures that system architecture and technical infrastructure align with IT strategy, with a focus on scalability, performance, and technology adoption
Logically, the Product department, where the Product Managers and Product Owners are in is placed within the Essent Business. This means that my colleague Product Managers are part of the same product team, and we are working closely together to achieve alignment between all the ARTs. This structure ensures that alignment with business goals is high.
On the other hand, I do feel that bringing a product mindset to internal tooling and processes is a new way of working. Both inside and outside Essent, many IT Platform departments are run by Engineering Managers or IT Operations Managers.
The benefits of viewing software engineers as customers
So what makes the difference when leading a platform ART from a product perspective? In my view, it is about changing the way we look at our platform users. They are customers. Are they the same type of customers as our energy consumers? No, they are not. If a consumer has a problem with their app, for example, they need Essent IT to solve it for them. Our internal platform customers are far more complex to predict because they can solve most problems themselves: they are software engineers!
For the Product Owners within the I Empower ART, this means we not only need to build easy-to-use platforms that are scalable, secure, and high-performing, but we also need to ensure that engineers use them because they solve their problems. We don’t want to ‘manage’ software engineers into using centrally developed products. Instead, our goal is to make platforms so effective and intuitive that engineers adopt them willingly, seeing them as the best solution to their challenges.
Furthermore, our platforms mustn’t be just tools for engineers but environments where they can actively contribute. This is where enablement and collaboration come into play. By adopting practices like GitOps and innersourcing, we empower our engineers to contribute directly to the evolution of these platforms, creating a dynamic relationship where feedback and improvements flow seamlessly. This collaboration ensures platforms remain relevant, adaptable, and effective for the organization’s needs.
Becoming a tech company
The place where we are now – on the road to becoming a tech company – also means that as an organization, we are more often entering uncharted terrain. Finding solutions for problems that haven’t been solved before, or moving beyond just applying best practices. An example of this is the application of the ‘Team Topologies’ team layout. This is a well-known framework for organizing different types of teams around value creation. In this model, platform teams are defined as teams that provide self-service, reusable infrastructure, focusing on reliability, scalability, and efficiency. Enablement teams, on the other hand, focus on helping stream-aligned teams adopt and optimize the use of platforms, tools, and practices, acting as collaborators rather than building core functionalities themselves.
In the last few months, we have been making a significant shift by rethinking the roles of 'platform teams' and 'enablement teams’. By integrating enabling capabilities into our platform teams, we are unlocking more value around the platforms themselves. For instance, our cloud platform team not only develops robust, automated solutions but also provides cloud consultations to enable stream-aligned teams to leverage our Cloud offerings optimally. Similarly, our Typescript backend team is actively engaging the whole Typescript community within Essent to ensure optimal co-creation of the monorepo, as was highlighted in an earlier post.
This way of organizing our supporting teams also brings a huge benefit from a staffing perspective. As the room for growth and innovation in each of our foundational teams is large there is also an almost unlimited amount of interesting software engineering work to do. This means that instead of viewing our ‘Shared services’ as a cost center, we are viewing them as a key enabler for delivering on our IT transformation strategy.
I am proud to be part of the journey of Essent in becoming a tech company. It is an interesting path that not only strengthens our internal capabilities but also positions us to deliver better products, satisfy the needs of our customers, and enables us to thrive as an organization as a whole. For companies looking to adopt a similar approach, our door is always open!