Team Topologies, Cognitive Load & Complex Systems | Matthew Skelton In The Engineering Room Ep. 12
HTML-код
- Опубликовано: 4 авг 2024
- The "Engineering Room" is a monthly series of conversations with people who are influential in the software industry. In this episode Dave Farley, author of "Continuous Delivery", "Modern Software Engineering" and others, talks to Matthew Skelton co-author of one of the most significant software books of the last 10 years - “Team Topologies”, about the ingredients for long-term, viable, sustainable and understandable software development.
Matthew Skelton is co-author of "Team Topologies: organizing business and technology teams for fast flow". He is Head of Consulting at Conflux and specialises in Continuous Delivery, operability, and organisation dynamics for modern software systems.
In this conversation with Dave, he talks about the ecosystem necessary to build and nurture software, and the wide range of topics that impact on the effectiveness, and performance of development teams. The approach that his book "Team Topologies" describes is to use team structure as a tool, guided by the idea of managing the cognitive load of the team. This talk ranges from how to deal with the complex adaptive system that we inhabit when undertaking software development, to the structure of software development being more like an ant colony than an organised, predictable hierarchy.
--------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
-------------------------------------------------------------------------------------
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
_____________________________________________________
LINKS:
📕 "Team Topologies" by Matthew Skelton and Manuel Pais ➡️ amzn.to/2Y0NdSO
🔖 Get my FREE guide "How to Organise SW Teams" when you join the CD Mail List
➡️ www.subscribepage.com/organis...
📕"Extreme Programming Explained: Embrace Change" by Kent Beck ➡️ amzn.to/2GpQRjE
🔖 Matthew Skelton on "Why are Deployment Pipelines Important" ➡️ bit.ly/3UhrNLG
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here
➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📕 The Origin Of Wealth: Evolution, Complexity, and the Radical Remaking of Economics, by Eric Beinhocker ➡️ amzn.to/3H4CgqT
📕 Thinking in Promises, by Mark Burgess ➡️ amzn.to/3V7Dk1i
-------------------------------------------------------------------------------------
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
__________________________________________________
CHAPTERS
00:00 Welcome and Introduction to Matthew Skelton
01:25 Helping CEOs and CTOs rethink the building and running of software-enriched services
04:20 The wider ecosystem of writing code
06:40 The relationships between different practices, processes and systems
09:38 Shu Ha Ri - understanding what we are doing and why
10:32 The serious responsibility for all-pervasive sw which affects everything we do - even life and death
15:46 Organising around Team Cognitive Load
19:38 General applicability of Information System concepts
21:25 Two mindsets of Software Engineering
24:38 Creative problem-solving v the production line
26:25 Evolution - exploration in small steps, guided towards our intent, adapting to the tech' environment
32:20 Embracing Change
35:32 Paradigm shift: established approaches and patterns no longer fit
43:20 Helping businesses understand, adapt and adopt new ways of working to survive
48:30 The fans, the haters and the 'hard of understanding'
50:00 Control and decision-making in distributed organisations - the ant colony
1:00:20 Team autonomy and fast flow
1:03:52 Remote working and interactions between decoupled teams
1:09:09 Constraints that help improve design and free up creativity
1:14:00 Thanks to Matthew and wrap up 
Наука
Learn how to work as a highly functional software development team with helpful tips in my FREE guide to "Organising SW Dev Teams" which you can get here ➡ www.subscribepage.com/organise-teams-guide
Dave, these kinds of episodes are fantastic. But not the visual noise: Advertising around the people; rotating color borders; zooming in background. These are seriously distracting.
That’s right, only animate when there is a meaning behind it and it’s really necessary.
i find it better to focus on the video with all the movement around him. like ambient music
Dave, you are my hero. I am sitting here writing a document trying to put into words that I believe my team and me need to stop worrying about any of the other measures and simply focus on maintainability as the primary focus. I think that approach will allow all of the other features of quality code to be side effects rather than primary goals. Things that happen because we are trying to reach better maintainability rather than things to strive for in and of themselves.
I have also with your guidance been on a journey to understanding what TDD means and how it affects me, and ... I think the main thing that I have learned from that is exactly that.
To me, TDD's primary goal is an enabler of maintainability and changeability of code. The other things that get touted good quality code are things you need if you don't use TDD in order to ensure maintainability of your code.
This stuff is hard. I have no idea yet how to convey it, so I just like people to the same sources and hope they come to some of the same conclusions.
Love the content. Can you distribute the engineering room as a podcast as well? The format is perfect
Thanks for the positive feedback, and your suggestion 🤔
Thank you for another great thought-provoking video! My career has been defined by the great team or two I have managed to be a part of. Something even more important than sharing top skills within a team is how they have your back. That is what transforms a group into a team. Also, I'd like to point out that people who work on mobile phone software have a term for a phone that does not connect to anything: it is called a brick.
I have (mostly) worked remotely since 1991 when I was told to do so after an acquisition landed me in a cubicle in a huge open sales office where phonecalls were announced over the intercom and the colleague seated next to me spent all day talking on the phone to his mother in Russian. Every few minutes a plaintive "Ma-ma!" My productivity went through the roof. After that, except for a few years after an employer was destroyed in the twin towers, I worked for companies with an office on the other side of a continent or an ocean or the planet. One makes adjustments for the time difference but most of the time we simply communicated through code. The occasional email as needed and a weekly stand-up where everyone has 90 second max to give an update. But this can only work when there is a high level of both trust and safety.
Great conversation. I just heard about Matthew's book today and was very happy to see that he already appeared on your channel. Will buy the book today.
I wanna read team topologies now :)
I literally did run out and buy the book on audible while listening to this show. Sounds like a great book that I'm hoping will inform some changes I'd like to make in my own organization around engineering talent structure versus command and control management structure.
I am in Australia at the moment, speaking at the YOW! conferences. Nearly every speaker is mentioning how important this book is, so it is not just me and Matthew who think so 😉I hope you enjoy it.
Team is a utopian concept that everyone sticks to because it is what makes all organization presentations look nice and dandy. In practice, it is the major source of silo work and code quality problems.
That depends on how the team is organised. Though I agree that your characterisation is common, it is not inevitable. I have worked in some great teams in some great organisations, big and small, that didn't suffer from this problem. It is all to do with cognitive load and the siloing is more to do with coupling between teams rather than their existence.
I only disagree on one point, it is dystopian.
Collaboration and research between product and engineering is key in order for an product delivery teams to synthesize.
Matthew, would be interested in the challenges that orgs with traditional bloated sw teams face when adopting team topologies (avoid burnout) based on your fantastic book. Why do they need help?
Was giving serious thought to buying Matthew's book, but not after this.
I really like your thoughts on local decision making in distributed organizations as a response to the sheer unpredictable context we are operating in. You mention being crystal clear on the company and team mission as one recipe for such a governance concept. Can you recommend any sources elaborating further about what it takes to set out a clear mission and have it understood on broad scale in an organization?
My training course on ATDD describes this in a fair amount of detail, a more concise, and free, description of at least one approach is here: ruclips.net/video/gXh0iUt4TXA/видео.html
The book mentions platform and enabling teams being justified at a ratio of 1:6 relative to stream aligned teams. In smaller organizations that have less than 6 teams, how are platform/enablement type concerns addressed? The conversation seems to focus on larger organizations, but I'm sure the principles apply regardless of size.
I'd imagine that a "thinnest viable platform" here might merely be an agreement to use a given technology (eg. CD tool for example), but each team is still responsible for operating these utility systems independently over each other? The economies of scale don't justify an autonomous platform team working on tooling with docs, versioned api, and such, but we don't want the overhead of constant cross team collaboration that would be required either. Would each team just do their own thing? This may be somewhat subjective, but I'm curious if Dave or Matthew have further insight.
Love the content. Thanks as always.
It helps when the product and engineering teams can speak the same language as it relates to continuous delivery
in my experience things are getting worse. somehow "we" expect someone who was taught how to code in java (as an example) to magically learn a 10-element-large tech stack on the side and not mess it up despite having incomplete specifications all while using 30 different 3rd party libraries. i myself spent 95% of my time writing "real code" in 2002, but in 2022 i fight infrastructure > 50% of the time + writing more code to satisfy some cloud stuff requirement instead of the actual logic i want to write. i lost the ability to run/test things locally. feedback cycles have become too long. i can't "just run it" anymore, i have to perform a few rituals first, in the right order, in the right way. one mistake, and it just does not work. and if it finally *does* work, the deployment itself is so complex that it breaks things again.
we're making things more complex instead of simpler.
at least for me this means my 20+ years of experience are only really relevant for ~25% of the time, and even then, frameworks/infrastructure are severely limiting my options. i have elegant solutions in my head but can barely apply them. every 5 meters there's a technological barrier. i am not one bit faster than random junior engineer X because we both spend our time fighting unnecessary problems that just should not exist.
is it like that in every modern software company? the last three i worked for have transitioned from a monolith to "awesome microservices" which brought no advantage in overall productivity (that i could see) but added a ton of overhead. everything that made me fast/productive was the ability to abstract annoying complexity away. "modern" development styles took exactly that away.
Moreover, this leads to management and software development must not be managed. Every individual has to produce a product.
Management is needed when the environment or organisation is dysfunctional
So, the elephant in the room, and why F500s can't do this: a high-performing delivery system with autonomous teams simply does not need the same number of managers and leaders as a legacy organization. F500 as a rule implies legacy.
There are CTOs of companies that actually know something about technology? Sounds like fairy tales.
The problem of our industry is we have too much programmers but very few software engineers. That's why I am a bit disappointed... I am done working with programmers. I want to work with software engineers. Maybe it is the lack of unionization. We could have programmers... But they must be supervised by software engineers with appropriated university degree.
Does a university degree really make you a good software engineer? Or is it rather an experimentation/data driven mindset?
I feel like I've seen sufficiently many university taught engineers keep the status quo without daring to challenge existing inefficient processes to know degrees aren't what make a real difference.
@@Beat0X None and both. University (should) teach principles. Not technologies. It's really hard to get principles without studying (without the orientation of a professor) and It's not the same thing that reading. The learning process flows easily and more profoundly (when you go to universities with the right mindset). Not challenge the status quo is a byproduct of group thinking. Any group suffers this problem. It is just more painful see this in a place where "supposely" is the place for innovation and creativity. Do you really think that a company does not suffer the same problem? Even google has this problem. Companies challege the status quo only when the company existence is on the line or they have free money to spend.
For instance, Matthew Skelton is talking about complex systems. Do you even know what a complex systems really is? Spoiler alert: it has nothing to do with computer programs. This is a new complex and super interesting research area (my research area). I haven't finished to watch the whole video but I can see that davi farley don't quite get the whole complexity of what Matthew really means... It took me a lot to start to understand system theory and even more complex system theory.
@@BrunoGabrielAraujoLebtag hey Bruno. What are you researching about complex systems specifically? Also, is there any specific type of system you are specializing in? Something else, are you Brazilian (guessing from your name)?
@@BrunoGabrielAraujoLebtag Of course I don't think companies don't suffer from this just wanted to balance out the notion that academia was the answer. It's really a question of mindset going into academia for example but in general also enabling environments in academia or in companies. One thing that I've seen academia suffer from a lot and sometimes industry too is sole ownership of projects that die out when the single contributor graduates or leaves the company... It just seems so wasteful to develop in such a manner.
Evolution is the weakest information theory.
No, no, no... there's a third mindset, and it is the only one that works... software development teams are building products, every commit, every sprint, every release is a product. The mindset of building a product is the only one that exists. Nurturing an ecosystem won't provide finished products, but ongoing efforts to finish something that never ends. Production machine won't work and this is the most obvious as software development is not measured in lines of code.
All fancy words and terminology used in this conversation is useless jargon. A team that's not shipping products isn't working.
I've been in the Nurturing environment and it is the most frustrating environment I've ever been as nothing gets finished ever. Horrible.
Modern software development sucks. If I was starting over again I wouldn't go near it.