Developer Experience
September 21, 2023
10
min read

Unpacking Platform Engineering: A Conversation with Abby Bangser of Syntasso

Katy Andreeva
Growth Marketer

Have you ever wondered what it takes to successfully navigate the ever-evolving world of Platform Engineering and Developer Experience? Prepare to uncover the answers as we walk through this dynamic landscape with Abby Bangser, the Principal Engineer at Syntasso.

Abby is not your typical tech expert; she's a hands-on software delivery professional with a unique blend of skills and experiences that span Business Analyst, Quality Analyst, DevOps, Platform Engineering, SRE, and Infrastructure Engineering roles. Her passion for quality-driven, value-focused delivery sets the stage for an enriching exploration of platform engineering.

Join us as we delve into the depths of platform engineering, where Abby's insights will help you confidently navigate this intricate landscape. Whether you're a pro or just starting your journey, Abby's wisdom will help you level up your understanding and approach. Below, you'll find a summary of the invaluable insights shared in this conversation.


Defining Platform Engineering: Enabling Collaboration and Efficiency

Let's begin by defining platform engineering. How do you characterize it, and what are the driving factors for organizations to adopt this approach?

Abby Bangser: Platform engineering, as defined by the CNCF working group, is a set of capabilities designed to support users and customers across an organization. It's essentially an internal team providing services to other internal teams. While there may be various definitions floating around, the core idea is to enable experts to run services that benefit a broader audience. It's about reducing friction between teams and ensuring that expertise is effectively shared. Platform engineering aligns with the principles of DevOps, focusing on both external customer-facing software and internal software.

TJ Randall: It's not a case of DevOps versus platform engineering; it's more about how they complement each other.

Abby Bangser: Absolutely. Both DevOps and platform engineering are crucial. DevOps aims to break down silos and promote collaboration, while platform engineering focuses on providing services that empower others. They are two sides of the same coin, working together to enhance an organization's capabilities.

TJ Randall: It seems like a collaborative approach is key, and there shouldn't be any conflict between the two. Do you find that organizations naturally grasp this synergy?

Abby Bangser: It varies. The challenge with platform engineering is that it often feels like a natural extension of what organizations are already doing. This nuance can make it challenging for teams that have embraced DevOps principles to shift their mindset toward providing services for their customers. 

Organizations need to understand that their customers may have different needs and preferences than their internal teams, even though both are composed of engineers.

The Platform Maturity Model: A Blueprint for Success

Let's delve into the platform maturity model. What prompted its creation, and why do you believe the market needs it?

‚Äć
Abby Bangser: Developing the platform maturity model stemmed from our collective experience at Syntasso. 

We've been involved in platform engineering for years, drawing from our work with Cloud Foundry and VMware. We observed common challenges and listened to customer feedback, and it became evident that organizations needed a tool to differentiate between their current practices and the potential of platform engineering. 

This model is about recognizing the limitations of existing approaches and providing a vision for what's achievable. We wanted to offer something tangible to the industry after the CNCF whitepaper work.

TJ Randall: It's like providing a roadmap for organizations to understand where they stand and where they can improve. What motivated you to donate this model to the CNCF?

Abby Bangser: We wanted to ensure this model remained vendor-neutral and benefitted the entire industry. By donating it to the CNCF, we could leverage their diverse and experienced community to refine further and enhance the model.

What matters most is that the model is useful rather than having our name associated. The CNCF's collaborative environment was perfect for refining and evolving this tool.

Measuring Platform Engineering Success: Metrics, Investment, and Collaboration

Metrics play a crucial role in any model like this. How should organizations approach measuring their progress along this maturity model?

Abby Bangser: Measuring progress is crucial but can be tricky. Metrics come in qualitative and quantitative, depending on your organization's size.

For qualitative measurements, use consistent surveys to gain insights. Ask questions like, "Are you enthusiastic about building new services?" or "When was the last time you felt frustrated with internal tools?" Keeping survey questions consistent is essential.

Quantitative metrics involve numbers, like daily active users or monthly user counts. To measure progress effectively, analyze both types of data consistently.

TJ Randall: That's a great point. Consistency in gathering data and adapting metrics to your specific goals and organization size is crucial. Metrics are a compass for improvement.

Levels of Maturity in Platform Engineering: Scaling and Optimization

Let's discuss the different maturity levels in the model. Can you provide some insights into how organizations at levels three and four operate daily?

Abby Bangser: Absolutely. Level three, often called "scaled" (although this name might change), is where organizations aim to balance agility and a customer-focused approach. 

They want to keep that scrappy startup feel even as they grow. Teams prioritize being customer-centric, and this mindset runs throughout the entire organization. It's not just product managers; everyone on the team actively interacts with customers and their requirements. 

The key is balancing scaling and staying connected with your customers.

TJ Randall: Maintaining that customer-centric approach is critical even at the scaled level. What about organizations operating at level four?

Abby Bangser: Level four is known as the "optimized" level. At this stage, organizations have mastered self-service and scalability. They've fine-tuned their platform engineering methods so that a small team of platform engineers can serve a much larger customer base. This optimization leads to higher efficiency and less friction. 

It's all about achieving a state where the platform runs smoothly, and users can effortlessly access and use its services.

Embracing Continuous Optimization: The Ongoing Journey

Even after reaching a specific goal, like scaling up, there's still much learning within the organization. It's similar to refining your go-to-customer strategy, even if it's not the typical go-to-market approach. The aim is to keep optimizing, even at your current stage.

Abby Bangser: Absolutely. What you're aiming for or possibly working toward. Continuously adapting and optimizing is essential to reach the optimized level. Instead of something you have to be overly deliberate about, it becomes part of your regular cycle. 

When you're at levels three and four, you might still incorporate this into your workflows and get comfortable with ongoing improvements.

Enhancing Developer Experience: Onboarding and Transition

We often focus on developers, particularly when they join a large organization, regarding their onboarding experience and overall developer journey. It can be a significant challenge. I assume these organizations conduct self-assessments, evaluating the performance of their platform engineering team and the services they deliver. 

Additionally, do you frequently discuss onboarding and integrating new team members into the platform as you develop the model and collaborate with customers?

Abby Bangser: Many people often think about onboarding. They typically focus on newcomers, whether they are new services or newly hired engineers. That's why I slightly shifted away from your question about recommended metrics, as there isn't a one-size-fits-all metric; it depends on your specific goals. 

Here's the intriguing part: the top priority for a platform may only sometimes be improving the developer experience. It could be cost savings, security compliance, or standardization. Organizations invest in internal services for various reasons, not solely to make software developers happy, although that's important too.

Suppose you want to emphasize onboarding, especially in a rapidly growing organization where new engineers join frequently. In that case, you'll want to define what you expect them to achieve in week one, month one, or month six, depending on your onboarding schedule. Then, you can assess if they've met those expectations and work on smoothing the process to achieve those capabilities and efficiencies.

TJ Randall: Absolutely, you're spot on. When it comes to developer experience, the primary goal is to ensure they have excellent experiences. But a positive experience can mean more than just enjoyment. It also means making the process of onboarding onto a new and complex platform seamless. That's a valuable experience, even if it's not measured by asking, "Do you like working with these technology stacks?" Instead, it's about how easily you can adapt to new technology.

Another aspect we often discuss with customers is when they're transitioning to new platform technologies as part of their modernization efforts. In such cases, you have a platform engineering group creating these services. The transition process becomes another part of the developer experience story. How efficiently can we help experienced individuals move to the new technology stack?

Abby Bangser: Yes, I've had a similar conversation with another member of the CNCF working group, Andre, who works at Ada in Toronto. 

During our discussion, Andre and his platform team's product manager, Rob, shared insights. They talked extensively about dealing with power users of their current offerings who resist adopting the easier, lower cognitive load-managed offerings they're developing.

For these power users to consider switching, the transparency and improvement must be substantial, like a 10x or even 100x enhancement. This presents a unique challenge as they need to weigh whether it's worth making these improvements and encouraging the transition for users who may still need to see the benefits. It's led to some thought-provoking discussions on where to focus their efforts and which aspects of the user experience are most crucial to enhance.

TJ Randall: It's possible to have multiple layers of development teams within an organization. In a larger organization, you can assess and identify areas where you're performing well and scaling effectively, but you might also encounter some challenges or "lag" in specific areas.

Regarding metrics, it would be beneficial to measure these aspects in a way that highlights areas needing attention. This lets you pinpoint where to refocus your efforts, especially when tackling potentially more challenging transitions.

Abby Bangser: We're not suggesting that a team must fit into a specific 'level one' or 'level two' category. Instead, consider these as separate levers you can adjust and invest in as needed.

While some may be interconnected in a way that improving one depends on another, it's not impossible to address them individually. You don't have to work on them simultaneously or at the same pace."

TJ Randall: That's great insight.

Investment for Platform Metrics: Understanding the Funding Landscape

Where do you find in these organizations that you work with - who's funding these metrics? These programs today exist across all different-sized companies. Who's generally investing this in the organization?

Abby Bangser: We've observed that funding plays a significant role in shaping how a platform is developed. This is why investment is a crucial aspect of the platform's success.

When funding comes from an individual director's budget or a more narrowly focused budget, it tends to be more provisional, similar to what we'd call 'level one.' It's often more of a voluntary or temporary investment, project-based, resulting in small wins but limited overall impact.

On the other hand, when the budget comes from a higher-level technology investment, you start to see consistent and substantial investment, which is where real improvements begin to show.

However, the most significant benefits arise when investments come from individuals who aren't solely technologists, such as CIOs, chief product officers, or chief customer success officers. They recognize that by investing in the ability to align business processes with internal technology needs and offering standardized support across the organization, there's a substantial increase in investment and positive outcomes for the platform.

TJ Randall: We're back to breaking down the silos, right? At the end of the day.

Abby Bangser: Absolutely, it's all about reducing friction between these silos ‚Äď no doubt about that. While we may not necessarily need to break them down completely, it's important to acknowledge the unique strengths within each silo and ensure they work together smoothly. The key is mutual respect, open communication, and offering support when necessary to maintain a harmonious collaboration across these specialized areas.

The Future of Platform Metrics: Shaping the Path Ahead

Looking forward, what do you hope to see in terms of the adoption of this platform maturity model within the CNCF community and beyond? Where do you hope it goes in the future?

Abby Bangser: I hope this sparks really good conversations. These frameworks have a lot of potential applications, and the platform space genuinely needs these tools. There's room for various iterations and enhancements, and I hope that it becomes a preferred tool or a frequently used resource that continues to evolve and improve over the years. There are exciting opportunities here, and they can provide significant value.

TJ Randall: This is a valuable contribution to the entire community. Thank you so much, Abby. It's been a fantastic conversation, and we appreciate you sharing your insights about the model and platform engineering as a whole. Thanks once again for being here with us today.

Instruqt: Your Bridge to Success in Platform Engineering and Development

As we conclude our insightful discussion with Abby Bangser on Platform Engineering and Developer Experience, it's clear that this ever-evolving field demands a strategic approach. The challenges and opportunities presented by Platform Engineering require a powerful solution.

Instruqt steps in as the ideal partner for organizations seeking to enable their teams with practical, hands-on training. In a dynamic environment where continuous optimization is key, Instruqt offers a powerful platform to build and scale your training programs in a dynamic environment where continuous optimization is key.

By embracing hands-on learning in a controlled environment, you can ensure that your team gains practical experience without the fear of crashing production systems. With Instruqt, you can onboard new talent efficiently, provide ongoing training, and keep your workforce up-to-date with the latest technologies.

In a world where innovation and collaboration drive success, Instruqt is your strategic ally, enabling your organization to thrive in Platform Engineering and Developer Experience. Discover the future of training and development with Instruqt.

Have you ever wondered what it takes to successfully navigate the ever-evolving world of Platform Engineering and Developer Experience? Prepare to uncover the answers as we walk through this dynamic landscape with Abby Bangser, the Principal Engineer at Syntasso.

Abby is not your typical tech expert; she's a hands-on software delivery professional with a unique blend of skills and experiences that span Business Analyst, Quality Analyst, DevOps, Platform Engineering, SRE, and Infrastructure Engineering roles. Her passion for quality-driven, value-focused delivery sets the stage for an enriching exploration of platform engineering.

Join us as we delve into the depths of platform engineering, where Abby's insights will help you confidently navigate this intricate landscape. Whether you're a pro or just starting your journey, Abby's wisdom will help you level up your understanding and approach. Below, you'll find a summary of the invaluable insights shared in this conversation.


Defining Platform Engineering: Enabling Collaboration and Efficiency

Let's begin by defining platform engineering. How do you characterize it, and what are the driving factors for organizations to adopt this approach?

Abby Bangser: Platform engineering, as defined by the CNCF working group, is a set of capabilities designed to support users and customers across an organization. It's essentially an internal team providing services to other internal teams. While there may be various definitions floating around, the core idea is to enable experts to run services that benefit a broader audience. It's about reducing friction between teams and ensuring that expertise is effectively shared. Platform engineering aligns with the principles of DevOps, focusing on both external customer-facing software and internal software.

TJ Randall: It's not a case of DevOps versus platform engineering; it's more about how they complement each other.

Abby Bangser: Absolutely. Both DevOps and platform engineering are crucial. DevOps aims to break down silos and promote collaboration, while platform engineering focuses on providing services that empower others. They are two sides of the same coin, working together to enhance an organization's capabilities.

TJ Randall: It seems like a collaborative approach is key, and there shouldn't be any conflict between the two. Do you find that organizations naturally grasp this synergy?

Abby Bangser: It varies. The challenge with platform engineering is that it often feels like a natural extension of what organizations are already doing. This nuance can make it challenging for teams that have embraced DevOps principles to shift their mindset toward providing services for their customers. 

Organizations need to understand that their customers may have different needs and preferences than their internal teams, even though both are composed of engineers.

The Platform Maturity Model: A Blueprint for Success

Let's delve into the platform maturity model. What prompted its creation, and why do you believe the market needs it?

‚Äć
Abby Bangser: Developing the platform maturity model stemmed from our collective experience at Syntasso. 

We've been involved in platform engineering for years, drawing from our work with Cloud Foundry and VMware. We observed common challenges and listened to customer feedback, and it became evident that organizations needed a tool to differentiate between their current practices and the potential of platform engineering. 

This model is about recognizing the limitations of existing approaches and providing a vision for what's achievable. We wanted to offer something tangible to the industry after the CNCF whitepaper work.

TJ Randall: It's like providing a roadmap for organizations to understand where they stand and where they can improve. What motivated you to donate this model to the CNCF?

Abby Bangser: We wanted to ensure this model remained vendor-neutral and benefitted the entire industry. By donating it to the CNCF, we could leverage their diverse and experienced community to refine further and enhance the model.

What matters most is that the model is useful rather than having our name associated. The CNCF's collaborative environment was perfect for refining and evolving this tool.

Measuring Platform Engineering Success: Metrics, Investment, and Collaboration

Metrics play a crucial role in any model like this. How should organizations approach measuring their progress along this maturity model?

Abby Bangser: Measuring progress is crucial but can be tricky. Metrics come in qualitative and quantitative, depending on your organization's size.

For qualitative measurements, use consistent surveys to gain insights. Ask questions like, "Are you enthusiastic about building new services?" or "When was the last time you felt frustrated with internal tools?" Keeping survey questions consistent is essential.

Quantitative metrics involve numbers, like daily active users or monthly user counts. To measure progress effectively, analyze both types of data consistently.

TJ Randall: That's a great point. Consistency in gathering data and adapting metrics to your specific goals and organization size is crucial. Metrics are a compass for improvement.

Levels of Maturity in Platform Engineering: Scaling and Optimization

Let's discuss the different maturity levels in the model. Can you provide some insights into how organizations at levels three and four operate daily?

Abby Bangser: Absolutely. Level three, often called "scaled" (although this name might change), is where organizations aim to balance agility and a customer-focused approach. 

They want to keep that scrappy startup feel even as they grow. Teams prioritize being customer-centric, and this mindset runs throughout the entire organization. It's not just product managers; everyone on the team actively interacts with customers and their requirements. 

The key is balancing scaling and staying connected with your customers.

TJ Randall: Maintaining that customer-centric approach is critical even at the scaled level. What about organizations operating at level four?

Abby Bangser: Level four is known as the "optimized" level. At this stage, organizations have mastered self-service and scalability. They've fine-tuned their platform engineering methods so that a small team of platform engineers can serve a much larger customer base. This optimization leads to higher efficiency and less friction. 

It's all about achieving a state where the platform runs smoothly, and users can effortlessly access and use its services.

Embracing Continuous Optimization: The Ongoing Journey

Even after reaching a specific goal, like scaling up, there's still much learning within the organization. It's similar to refining your go-to-customer strategy, even if it's not the typical go-to-market approach. The aim is to keep optimizing, even at your current stage.

Abby Bangser: Absolutely. What you're aiming for or possibly working toward. Continuously adapting and optimizing is essential to reach the optimized level. Instead of something you have to be overly deliberate about, it becomes part of your regular cycle. 

When you're at levels three and four, you might still incorporate this into your workflows and get comfortable with ongoing improvements.

Enhancing Developer Experience: Onboarding and Transition

We often focus on developers, particularly when they join a large organization, regarding their onboarding experience and overall developer journey. It can be a significant challenge. I assume these organizations conduct self-assessments, evaluating the performance of their platform engineering team and the services they deliver. 

Additionally, do you frequently discuss onboarding and integrating new team members into the platform as you develop the model and collaborate with customers?

Abby Bangser: Many people often think about onboarding. They typically focus on newcomers, whether they are new services or newly hired engineers. That's why I slightly shifted away from your question about recommended metrics, as there isn't a one-size-fits-all metric; it depends on your specific goals. 

Here's the intriguing part: the top priority for a platform may only sometimes be improving the developer experience. It could be cost savings, security compliance, or standardization. Organizations invest in internal services for various reasons, not solely to make software developers happy, although that's important too.

Suppose you want to emphasize onboarding, especially in a rapidly growing organization where new engineers join frequently. In that case, you'll want to define what you expect them to achieve in week one, month one, or month six, depending on your onboarding schedule. Then, you can assess if they've met those expectations and work on smoothing the process to achieve those capabilities and efficiencies.

TJ Randall: Absolutely, you're spot on. When it comes to developer experience, the primary goal is to ensure they have excellent experiences. But a positive experience can mean more than just enjoyment. It also means making the process of onboarding onto a new and complex platform seamless. That's a valuable experience, even if it's not measured by asking, "Do you like working with these technology stacks?" Instead, it's about how easily you can adapt to new technology.

Another aspect we often discuss with customers is when they're transitioning to new platform technologies as part of their modernization efforts. In such cases, you have a platform engineering group creating these services. The transition process becomes another part of the developer experience story. How efficiently can we help experienced individuals move to the new technology stack?

Abby Bangser: Yes, I've had a similar conversation with another member of the CNCF working group, Andre, who works at Ada in Toronto. 

During our discussion, Andre and his platform team's product manager, Rob, shared insights. They talked extensively about dealing with power users of their current offerings who resist adopting the easier, lower cognitive load-managed offerings they're developing.

For these power users to consider switching, the transparency and improvement must be substantial, like a 10x or even 100x enhancement. This presents a unique challenge as they need to weigh whether it's worth making these improvements and encouraging the transition for users who may still need to see the benefits. It's led to some thought-provoking discussions on where to focus their efforts and which aspects of the user experience are most crucial to enhance.

TJ Randall: It's possible to have multiple layers of development teams within an organization. In a larger organization, you can assess and identify areas where you're performing well and scaling effectively, but you might also encounter some challenges or "lag" in specific areas.

Regarding metrics, it would be beneficial to measure these aspects in a way that highlights areas needing attention. This lets you pinpoint where to refocus your efforts, especially when tackling potentially more challenging transitions.

Abby Bangser: We're not suggesting that a team must fit into a specific 'level one' or 'level two' category. Instead, consider these as separate levers you can adjust and invest in as needed.

While some may be interconnected in a way that improving one depends on another, it's not impossible to address them individually. You don't have to work on them simultaneously or at the same pace."

TJ Randall: That's great insight.

Investment for Platform Metrics: Understanding the Funding Landscape

Where do you find in these organizations that you work with - who's funding these metrics? These programs today exist across all different-sized companies. Who's generally investing this in the organization?

Abby Bangser: We've observed that funding plays a significant role in shaping how a platform is developed. This is why investment is a crucial aspect of the platform's success.

When funding comes from an individual director's budget or a more narrowly focused budget, it tends to be more provisional, similar to what we'd call 'level one.' It's often more of a voluntary or temporary investment, project-based, resulting in small wins but limited overall impact.

On the other hand, when the budget comes from a higher-level technology investment, you start to see consistent and substantial investment, which is where real improvements begin to show.

However, the most significant benefits arise when investments come from individuals who aren't solely technologists, such as CIOs, chief product officers, or chief customer success officers. They recognize that by investing in the ability to align business processes with internal technology needs and offering standardized support across the organization, there's a substantial increase in investment and positive outcomes for the platform.

TJ Randall: We're back to breaking down the silos, right? At the end of the day.

Abby Bangser: Absolutely, it's all about reducing friction between these silos ‚Äď no doubt about that. While we may not necessarily need to break them down completely, it's important to acknowledge the unique strengths within each silo and ensure they work together smoothly. The key is mutual respect, open communication, and offering support when necessary to maintain a harmonious collaboration across these specialized areas.

The Future of Platform Metrics: Shaping the Path Ahead

Looking forward, what do you hope to see in terms of the adoption of this platform maturity model within the CNCF community and beyond? Where do you hope it goes in the future?

Abby Bangser: I hope this sparks really good conversations. These frameworks have a lot of potential applications, and the platform space genuinely needs these tools. There's room for various iterations and enhancements, and I hope that it becomes a preferred tool or a frequently used resource that continues to evolve and improve over the years. There are exciting opportunities here, and they can provide significant value.

TJ Randall: This is a valuable contribution to the entire community. Thank you so much, Abby. It's been a fantastic conversation, and we appreciate you sharing your insights about the model and platform engineering as a whole. Thanks once again for being here with us today.

Instruqt: Your Bridge to Success in Platform Engineering and Development

As we conclude our insightful discussion with Abby Bangser on Platform Engineering and Developer Experience, it's clear that this ever-evolving field demands a strategic approach. The challenges and opportunities presented by Platform Engineering require a powerful solution.

Instruqt steps in as the ideal partner for organizations seeking to enable their teams with practical, hands-on training. In a dynamic environment where continuous optimization is key, Instruqt offers a powerful platform to build and scale your training programs in a dynamic environment where continuous optimization is key.

By embracing hands-on learning in a controlled environment, you can ensure that your team gains practical experience without the fear of crashing production systems. With Instruqt, you can onboard new talent efficiently, provide ongoing training, and keep your workforce up-to-date with the latest technologies.

In a world where innovation and collaboration drive success, Instruqt is your strategic ally, enabling your organization to thrive in Platform Engineering and Developer Experience. Discover the future of training and development with Instruqt.

Sign up for newsletter

Here you'll get a quarterly newsletter made for growth-minded people

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Sign up for newsletter

Here you'll get a quarterly newsletter made for growth-minded people

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Try Instruqt Yourself

Get a closer look at how Instruqt can help you sell smarter and train better.

Take a self-guided tour of Instruqt