Just making a fact correction (I spent 8 years at Skype and know both the founders and the Estonian original engineering team well). Skype was initially built by 4 Estonian engineers (no Swedes or Danes). Yes, the co-founders were a Swede and a Dane (both non technical - one a visionary product guy, the other an experienced business guy), but the engineering team was 4 Estonians. Lets give credit where credit is due. More Swedish engineers would join later to form the audio and video codec teams out of Stockholm, but v1 of Skype was built with a very small Estonian team.
Thanks for the correction! I'll also tuck this away for future reference. I think I confused the business folks with the engineers. Estonians are some the sharpest technical people I've ever worked with. I miss Tallinn.
Also a fan of Cope! (He did some agile trainings at Skype, indeed.) Here's the most memorable tidbit from our training. We had some task, each group was to design a birthday card or a spaceship factory or something, one of those constrained exercises which turn out to be a surprisingly good metaphor for a product design cycle. There's some rules, and there was some clear metrics for success, as well. He said, "And by the way, I know which group is going to come out best." And he wrote it on a card, taped to the back of the easel. Afterwards, he showed us, and sure enough, it was. He said, "It's very predictable. Blue team, here, is the most diverse." (My team, the four white dudes, came in last. 😊) Absolutely true story.
How is it that Jim Coplien has talked and written about organizational patterns since the 90s, yet he just learned about this stuff. Goes to show how fringe complex systems theory still is. These insights are so well known and so well understood by the complex systems community.
@@tnosugar he talked about how he learned about all this complexity science stuff. My point is not about Jim Coplien (he is one of the few industry gurus I have true a decades old admiration for), it about how complexity science thinking has still not penetrated into other fields,.
@@BorislavIordanov That's true. However, we are entering an age where it will become mainstream. Things are falling into place, in terms of adopting this mindset and approach to science, in various domains. I'm Sorry I didn't get the sentiment of your initial comment. James has been my mentor over the years and he's simply a treasure.
I've been dealing deeply in "complexity science" at least since 1987 (which was before the 1990s.) The patterns work reflects that quite well, I think, and some of the earlier work I did with Jerry Weinberg. I had also met Deming in the 1980s, and you can view much of his work through a complexity lens. Yes, I spend some time exploring the complexity roots with the audience here (for the reasons you mention) but I don't think the solutions are well appreciated. The stupid hierarchical decisions of the industry stand testimony to that. The "agile people" like to talk about their tools solving complex problems, and that's true, but they don't really understand the solutions. They advocate ever moving forward with inspecting and adapting rather than doing set-based design, so we get local optima. They spout "empowerment" and ignore the essential coupling between teams, and you end up with monsters like Spotify whose teams synchronize only annually and whose respective user interfaces offer an end-user-punishing smorgasbord of mutually incompatible UX metaphors. It's also about understanding people rather than academic formalisms. and to, for example, lead one's TH-cam comment by lamenting the state of the art rather than wrongfully and presumably stating that the speaker was ignorant. I can see you tried to recover - nice try - but too little too late.
@@jamescoplien5257Appreciate the reply and the clarification, and I do share the sentiment w.r.t. the agile crowd. For me, as a software practitioner, it has been a great source of frustration to have to contend with lack of basic understanding of complexity concepts. Complexity in the software world is (wrongly seen as) something you can always manage and even get rid of, given enough time and/or the right idea. Noting also that I have neither tried nor do I feel the need to "recover" from anything. My comment is a judgement (not a presumption) based on me having read all your books, listened to many of your talks and specifically on what you said in that talk. I stand by it - I have never seen you show a modicum of sensitivity to these issues anywhere else. And I say this with great respect. If I'm wrong, that's great, but irrelevant since, most importantly, my comment was not about you, but about the fact that basic concepts of complexity so important to software engineering are foreign to its practitioners and even to its thought leaders.
2 ปีที่แล้ว +2
How an acyclic graph is not a hierarchy? How can it be resilient to network partition without cycles? If you only have one path to another node (no cycle), that path is critical.
In Kanban the service delivery team is self-managed in the sense that the Kanban system helps with managing the demand vs. throughput by visualization and setting limits . You don't need a manager because policies on how to work are explicit and agreed upon between consumer and service delivery team. Changing policies is not done by a manager but rather collaboratively between teams.
aren't you describing the role of product managers?
2 ปีที่แล้ว
I always tell my team managers that their role has two main tasks: A) make the non-obvious obvious. B) help creating and "debugging" communication channels across people and teams. B) makes them basically hubs "gardeners" if you like. Note they are not hubs themselves by default, and that it is often the error they made first.
@@l_combo It can just as easily describe a Product Owner. The difference is "manager" implies control and the title of Jim's talk has the phrase "self-organising".
^^ typical case of "the real world" really meaning "in my world". Don't confuse reality with "how we have responded where I've worked", or "what we've done to protect our closely held beliefs"
Just making a fact correction (I spent 8 years at Skype and know both the founders and the Estonian original engineering team well). Skype was initially built by 4 Estonian engineers (no Swedes or Danes). Yes, the co-founders were a Swede and a Dane (both non technical - one a visionary product guy, the other an experienced business guy), but the engineering team was 4 Estonians. Lets give credit where credit is due. More Swedish engineers would join later to form the audio and video codec teams out of Stockholm, but v1 of Skype was built with a very small Estonian team.
Thanks for the correction! I'll also tuck this away for future reference. I think I confused the business folks with the engineers.
Estonians are some the sharpest technical people I've ever worked with. I miss Tallinn.
Also a fan of Cope! (He did some agile trainings at Skype, indeed.)
Here's the most memorable tidbit from our training. We had some task, each group was to design a birthday card or a spaceship factory or something, one of those constrained exercises which turn out to be a surprisingly good metaphor for a product design cycle. There's some rules, and there was some clear metrics for success, as well.
He said, "And by the way, I know which group is going to come out best." And he wrote it on a card, taped to the back of the easel. Afterwards, he showed us, and sure enough, it was. He said, "It's very predictable. Blue team, here, is the most diverse."
(My team, the four white dudes, came in last. 😊) Absolutely true story.
What is the average distance of James Coplien to reality ?
A million miles from your reality, probably. Dig into what this guy has done in research and org transformation before posting opinions.
Lots of managers in this thread LOL.
How is it that Jim Coplien has talked and written about organizational patterns since the 90s, yet he just learned about this stuff. Goes to show how fringe complex systems theory still is. These insights are so well known and so well understood by the complex systems community.
Because what he's presenting here is based on empirical data specifically from his own work in organizational design. It's not from a book.
@@tnosugar he talked about how he learned about all this complexity science stuff. My point is not about Jim Coplien (he is one of the few industry gurus I have true a decades old admiration for), it about how complexity science thinking has still not penetrated into other fields,.
@@BorislavIordanov That's true. However, we are entering an age where it will become mainstream. Things are falling into place, in terms of adopting this mindset and approach to science, in various domains. I'm Sorry I didn't get the sentiment of your initial comment. James has been my mentor over the years and he's simply a treasure.
I've been dealing deeply in "complexity science" at least since 1987 (which was before the 1990s.) The patterns work reflects that quite well, I think, and some of the earlier work I did with Jerry Weinberg. I had also met Deming in the 1980s, and you can view much of his work through a complexity lens. Yes, I spend some time exploring the complexity roots with the audience here (for the reasons you mention) but I don't think the solutions are well appreciated. The stupid hierarchical decisions of the industry stand testimony to that.
The "agile people" like to talk about their tools solving complex problems, and that's true, but they don't really understand the solutions. They advocate ever moving forward with inspecting and adapting rather than doing set-based design, so we get local optima. They spout "empowerment" and ignore the essential coupling between teams, and you end up with monsters like Spotify whose teams synchronize only annually and whose respective user interfaces offer an end-user-punishing smorgasbord of mutually incompatible UX metaphors.
It's also about understanding people rather than academic formalisms. and to, for example, lead one's TH-cam comment by lamenting the state of the art rather than wrongfully and presumably stating that the speaker was ignorant. I can see you tried to recover - nice try - but too little too late.
@@jamescoplien5257Appreciate the reply and the clarification, and I do share the sentiment w.r.t. the agile crowd. For me, as a software practitioner, it has been a great source of frustration to have to contend with lack of basic understanding of complexity concepts. Complexity in the software world is (wrongly seen as) something you can always manage and even get rid of, given enough time and/or the right idea.
Noting also that I have neither tried nor do I feel the need to "recover" from anything. My comment is a judgement (not a presumption) based on me having read all your books, listened to many of your talks and specifically on what you said in that talk. I stand by it - I have never seen you show a modicum of sensitivity to these issues anywhere else. And I say this with great respect. If I'm wrong, that's great, but irrelevant since, most importantly, my comment was not about you, but about the fact that basic concepts of complexity so important to software engineering are foreign to its practitioners and even to its thought leaders.
How an acyclic graph is not a hierarchy? How can it be resilient to network partition without cycles? If you only have one path to another node (no cycle), that path is critical.
interesting, a Hub reminds me the idea of a "tracker" in p2p networks. Without a tracker p2p machines cannot connect to each other.
Please say more.
I agree that agile teams should be self managing but managers are needed. Not to manage the team but the demand, business engagement etc.
In Kanban the service delivery team is self-managed in the sense that the Kanban system helps with managing the demand vs. throughput by visualization and setting limits . You don't need a manager because policies on how to work are explicit and agreed upon between consumer and service delivery team. Changing policies is not done by a manager but rather collaboratively between teams.
aren't you describing the role of product managers?
I always tell my team managers that their role has two main tasks:
A) make the non-obvious obvious.
B) help creating and "debugging" communication channels across people and teams.
B) makes them basically hubs "gardeners" if you like. Note they are not hubs themselves by default, and that it is often the error they made first.
@@l_combo It can just as easily describe a Product Owner. The difference is "manager" implies control and the title of Jim's talk has the phrase "self-organising".
Totally agree. Managers should manage people - not development. Even "scaled" development organizations should (and can and do) self-manage.
cynical and egotistical, not much related to reality, world is complex
^^ typical case of "the real world" really meaning "in my world". Don't confuse reality with "how we have responded where I've worked", or "what we've done to protect our closely held beliefs"