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.
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.
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.
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.
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.
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.
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: th-cam.com/video/gXh0iUt4TXA/w-d-xo.html
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?
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.
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.
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.
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
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.
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.
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
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 🤔
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.
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.
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.
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.
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.
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: th-cam.com/video/gXh0iUt4TXA/w-d-xo.html
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?
Collaboration and research between product and engineering is key in order for an product delivery teams to synthesize.
Was giving serious thought to buying Matthew's book, but not after this.
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.
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.
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
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.
There are CTOs of companies that actually know something about technology? Sounds like fairy tales.
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.