#11 - Understanding Technical Debt with StepSize

Each year Apollo organizes the GraphQL Summit to pull like-minded professionals together to explore, celebrate and learn about GraphQL. John Masse had the opportunity to speak at this year's conference to share his lessons learned as an early adopter of GraphQL. In this episode of the Pragmatic Lead podcast, Alex and John discuss GraphQL as a transformational technology while re-reviewing the early adopter talk.

We are drawn to patterns and recipes to help us solve problems in our work, but in reality, what works for one case does not always work for another. Many times when leaders apply their recipes to new environments, unexpected consequences emerge. Humans habitually leverage patterns almost exclusively, blinding us by our own intellectual biases. Developing a mindset that welcomes complexity science into our minds will unlock our ability to apply leadership skills to many types of situations. We believe there is something here to uncover. Dave Snowden, Founder of Cognitive Edge and inventor of the Cynefin Framework, joins us to discuss complexity and human nature. In this episode, we still explore the high-level nuances of complexity thinking and some of the language around Cynefin and Complexity. By the end of this episode, we hope you find enough value to explore Cynefin and Complexity Science independently. Related articles A leader's framework for decision making. Resources Cognitive Edge Cynefin on Google Scholar The Sense Maker Application Connect with Dave Snowden Dave Snowden on Twitter Dave Snowden on LinkedIn  

In episode 11 of the Pragmatic Lead Podcast, Alexander Omeyer, CEO and Co-Founder of StepSize, joins us to dive deep into the meaning of technical debt and argue the nuances of what it takes to manage technical debt well. Are we filing for bankruptcy each time we rewrite an application? Is it really considered debt if we are spending time reshaping the code to accurately represent the business domain we are creating for?   StepSize Measure and prioritize technical debt with StepSize. The website https://www.stepsize.com/ Alexandre Omeyer LinkedIn https://www.linkedin.com/in/alexandre-omeyer-060a0175/    Twitter https://twitter.com/AlexOmeyer    Managing Tech Debt Blog https://www.stepsize.com/blog  

Join us in an exploratory conversation Join us on our journey into Cynefin, a framework for sense-making. For over twenty years, Dave Snowden has been helping leaders break out of a tendency to use the same solutions for different settings. Cynefin is the first, and this time the only, framework that allows leaders to ground their leadership skills in the reality of what is going on around them. Join us in a conversation as Alex and John do their best to explore the Cynefin map and real-world design stories to help apply the complex thinking that Cynefin requires. Additional resources The Cynefin Framework described on Wikipedia Our recommended starting point for Cynefin: Making Sense of Complexity - an introduction to Cynefin The enabling constraint as defined by Tom McCallum Dave Snowden on LinkedIn

Even though infrastructure problems are different from the front end, they are still relevant and important to solve, in some cases, it's even more fun because the impact can be much greater. Creating and maintaining consistency through constraints in order to provide a better experience for end-users. Or improving productivity for developers through consistent tools and standards.

AI is new, lots of people are struggling to understand what it means, where the benefits are. When engineers, leaders, business people hear AI they may get excited by the opportunity to innovate and intimidated by the lack of understanding at the same time. Engineering (AI) managers play an important role to be a bridge between business, product, and technology. It's also the case with any technology but AI being new, requires a more delicate approach. AI transformation and the common misconceptions around AI. Challenges when it comes to AI transformation. The role of an AI translator and a career path to get there.

Being a parent is difficult. Being a parent with a full-time job at the time of COVID makes it very difficult. There are many challenges we all have to face when working from home. We're talking to Tara about her experience being an engineering manager and staying with 2 kids at home at the same time, and how she was able to make it work. There is also a fun side, since kids are active and creative they will make anyone smile.

Dev sprint is a dedicated time for the engineering team to come up with a technical plan, better prepare for the execution of the goals, address technical debt, and more. John and Alex are discussing how they work with their teams and some ideas for dev sprint and how it went for them.

Not everyone is comfortable with the business side of the software. Many people charge less than they should. You're providing the value to somebody, something that they can't do or won't do themselves. We take for granted the fact that we can do it. We discuss our past experience, how started in the industry, and our thinking on setting your price.

Know how to measure technical debt. It's usually an umbrella term to describe different risks and complexities in the software.   Instead of re-writing a legacy system consider evaluating its current state and looking at the product and business goals. Interviewing the people who work on the system can give you a good sense of the urgency. Look how many escalations or production issues the product has over the past months or years. Use retrospectives with your team to understand what can we do to make us more productive, to increase the velocity.   You can divide the tech debt into engineering and business debt. The latter is measuring the time to market, end-user experience, and stability. Software is enabling the business and that's why it needs to be ahead to provide the right opportunity for the business.   Identify and prioritize the work. In order to get buy-in from the stakeholders, you need to back it up with the data, estimates, and return on investment.   Big migration and refactoring are not always the right solution and even can introduce more problems. Because the complexity in the legacy system is hidden until you open it up during the migration. This can lead to the increased scope and more pressure to deliver.