Thread by @aleixmorgadas

1/ We have been debating with some colleagues about the importance of learning about our decisions within the organization, and how the fast rotation of talent that's happening lately is affecting the decision-making outcomes quality.

2/ Here we had the supposition that the feedback cycle between a decision is made and understanding the consequences are long enough. We always thrive for fast feedback loops, yet we acknowledge that that's not always possible.

3/ It's not the same doing TDD within a unit test - feedback cycle of seconds-minutes vs a business decision and go-to-market strategy that can take months.

We are talking about the latter. Where those business learnings are most valuable for the organization

4/ The fast rotation that's happening is harming the long-term learnings about the business and how we're innovating. We need to adapt ourselves to the new reality.

5/ Old paradigm: People staying in the organization for several years, able to handle a huge germane cognitive load on the business domain.

Intrinsic and extraneous cognitive load is "low" because of years of experience.

6/ No urge need to invest in best practices, manage cognitive load. #BusinessAsUsual

#TechnicalDebt is manageable by the senior team members

7/ New paradigm: High rotation within the organization, especially senior positions. Unable to handle the germane cognitive load because Intrinsic and extraneous are high
TechnicalDebt is no longer manageable by seniors. Even hired seniors unable to address it

8/ Urge to keep TechnicalDebt low and apply best practices to keep delivering value with a reasonable lead time

Unable to handle non-core business processes and domain, start using SaaS, buying solutions, or externalizing to cover those areas. DDD shines here

9/People's time and effort need to be properly managed and allocated to business-critical initiatives where the ROI is higher.

Yet, make decisions based on the assumption of high rotation and no long-lived teams. Here #DynamincReteaming makes a huge impact

10/ When you find the stream of value becomes slower and the cognitive load becomes unmanageable, causing huge onboarding times until team members are productive (+ a month). You need to start investing in reducing that cognitive load. @TeamTopologies here!

@TeamTopologies 11/ Combine #DomainDrivenDesign and #TeamTopologies to find the core domains, what to externalize, what to internalize, and what to buy, plus arrange the teams for a fast flow of change.

Focus on a product/business mindset over technological complexity.

@TeamTopologies 12/ During the process, document properly the decisions to bring more organizational knowledge about the problem to solve. Architectural Decisions Records help here or other Lean Documentation practices.

Testable Business Hypotheses are awesome here!

@TeamTopologies 13/ Use proper analytics tooling to measure and base your decisions on data. Data becomes a key asset to invest in a high-rotating industry. People might rotate, but data stays.

Use data reports for informed decision-making, make those explicit in docs.

@TeamTopologies 14/ Plus, must exist a close collaboration between business and development. You can no longer push business like sales adding more people without properly coordinating that growth with Engineering and Product.

By not doing so, you will burnout teams.

@TeamTopologies 15/ The time to heal a burnout team is way higher than the value you can obtain on quick growth wins.

Being a market leader will depend more on how you design the product to delight customers rather than sales/marketing capacity to grow the ROI numbers.

@TeamTopologies 16/ Thanks to all the true players behind all that research, effort, and time dedicated to pushing the cutting-edge knowledge about the different fields!

@TeamTopologies 17/ I'm really inspired by all your work! @VaughnVernon @suksr @manupaisable @matthewpskelton @heidihelfand @johncutlefish

@TeamTopologies @VaughnVernon @suksr @manupaisable @matthewpskelton @heidihelfand @johncutlefish 18/ Any mistake on this thread is solely mine based on poorly interpretation or understanding of those topics. I'm still learning here!

Yet, I feel that sharing my ideas/conclusions can help me resonate about them and learn faster 🤓

@TeamTopologies @VaughnVernon @suksr @manupaisable @matthewpskelton @heidihelfand @johncutlefish 19/ There is one last part that mentions @VaughnVernon and @tjaskula in their book.

Understanding technical decisions and software strategy should be also understood by business people
goodreads.com/book/show/5578…

@TeamTopologies @VaughnVernon @suksr @manupaisable @matthewpskelton @heidihelfand @johncutlefish @tjaskula 20/ By having a bigger knowledge by business about technical strategy, they can make better questions and understanding of the implications.

Ensuring that the software will support the long term regardless of the software/product talent rotation

@TeamTopologies @VaughnVernon @suksr @manupaisable @matthewpskelton @heidihelfand @johncutlefish @tjaskula 21/ Business asking sensible technical questions should not harm our ego but be happy about the bigger implication of business on thinking of Software as a key investment rather than a cost center.