The CTO Podcast Feature Flags with Split.io CTO Patricio Echague
Sep 21, 2022
45:11
Do you dream of more harmony between product and engineering teams when releasing features? This week’s show dives deep into the world of features. Patricio Echague, CTO and co-founder of Split.io, shares how to avoid causing trauma to your engineering teams with pushes to production. He joins Etienne de Bruin to discuss the fundamentals of updating code in a way that empowers teams across your company.
Some ideas you’ll hear them explore are:
As a CTO, whether you're at a highly scaled organization or just starting, the value you create is through the code you've written. In updating that code, trunk-based development is the way to go.
Though you can use other branching techniques to use feature flags, they are more powerful when they are developed with a trunk-based methodology.
When using feature flags, you should start by placing them as high in the stack as possible and then moving them down as needed. If a feature flag has at least two conditions, two possible states, it gets exponential. This will create difficulty if you have to change many feature flags.
You can try to mitigate the animosity between product and engineering by giving them independence.
Any mature feature flag will help you identify when flags are no longer being engaged and used.
If you have a monolith code base, you can move towards trunk based by peeling off areas of the monolith that haven't changed often and have a unit of domain, and then putting that into microservice and giving some teams autonomy to iterate on that service alone.
Resources
Patricio Echague on the Web | LinkedIn | Twitter
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.ctopod.com
Some ideas you’ll hear them explore are:
As a CTO, whether you're at a highly scaled organization or just starting, the value you create is through the code you've written. In updating that code, trunk-based development is the way to go.
Though you can use other branching techniques to use feature flags, they are more powerful when they are developed with a trunk-based methodology.
When using feature flags, you should start by placing them as high in the stack as possible and then moving them down as needed. If a feature flag has at least two conditions, two possible states, it gets exponential. This will create difficulty if you have to change many feature flags.
You can try to mitigate the animosity between product and engineering by giving them independence.
Any mature feature flag will help you identify when flags are no longer being engaged and used.
If you have a monolith code base, you can move towards trunk based by peeling off areas of the monolith that haven't changed often and have a unit of domain, and then putting that into microservice and giving some teams autonomy to iterate on that service alone.
Resources
Patricio Echague on the Web | LinkedIn | Twitter
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.ctopod.com