Listening to the voices as you build for developer experience
Along with my team, I’ve spent many fun years on a mission – developing frameworks and curating tools to improve the developer experience at Mastercard. I’ve made some mistakes and gained valuable insights, so I thought I’d share some of my learnings.
My first learning is that you need to deliver incremental value quickly. From my time leading developer enablement teams, I’ve experienced that there is a narrow window of opportunity to fill gaps. Innovative product-focussed software engineers will invest time in solving an enterprise problem in their group in a way that works for them. That way may not scale, it may not adhere to all the organisations’ engineering principles. Still, it gets them quickly to a solution.
Crafting the perfect solution and waiting until it has every enterprise-required feature might deliver the best enterprise tool. However, if teams have already self-solved the challenge, be prepared for adoption challenges.
To avoid this, engage early and encourage code contributions from across the organisation with a commitment to prioritise those contributions as features on your enterprise roadmap.
That leads me to another significant learning. Prioritise continuous developer engagement. Internal tools and frameworks need the same product management practices as our external products. After all, our internal customers are building our products for our external customers. Soliciting feedback is crucial to shaping a good roadmap and tools strategy. Use as many communication channels and techniques as possible and dedicate time to planning hackathons where developers use your tools and provide feedback.
If you’re working on enterprise tools, you will hear that taking a ‘one size fits all’ approach will alienate parts of your organisation. There is a delicate balancing act to embed the required standards and design principles in enterprise tools and frameworks and provide flexibility to override the default behavior. Choose carefully, as certain design principles and security requirements are imperative to ensure software’s safe and smooth running. You can’t please everyone all the time.
Finally, remember to design for evolution. Technology is ever-changing, as will the tools and frameworks. Deliver a pipeline of change that allows easy, or better yet, seamless, adoption for your customers. That requires a longer-term view of your technology evolution strategy and roadmap but will repay you a thousand times with efficiency and adoption across your organisation. You will sometimes have to pivot to an unexpected change, don’t resist the change. Could you find a way to make it happen? A good approach is to think of your organisation as a microcosm of technology adopters, from innovators to late-stage adopters. Introduce change with groups who can easily consume change and who can take on the risk of uncertainty and beta test with them. You can scale this to other groups using their feedback and contributions.
Above all, support your team, listen to your customers, be firm on the non-negotiables and enjoy the learning journey.
By Olivia Leonard, SVP, Software Engineering, Mastercard UK&I
