This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
/poll "<!channel> What chapter is everyone on? (answers anonymous)" "have not started" "chapter 1" "chapter 2" "chapter 3" "chapter 4" "chapter 5" "chapter 6" "chapter 7" "chapter 8" "done!" anonymous
I'm curious, for those who work for a company whose primary business is NOT software, but work in IT with teams who deliver software, does your leadership have trouble seeing how some of these lessons apply to your organization? What are their objections? What is your response?
I'm curious, for those who work for a company whose primary business is NOT software, but work in IT with teams who deliver software, does your leadership have trouble seeing how some of these lessons apply to your organization? What are their objections? What is your response?
My aha moment in ch 3: In my practice, I’ve been using inverse Conway with coupling and cohesion as org design principles for some time with good outcomes, even going as far as using OO API design as a metaphor. So far my approach has been empirical. The aha moment for me is that you’ve extracted a model and design patterns from a similar inspiration and that model makes for a kind of theory that (1) helps me understand why what I’ve been doing in practice is working and (2) makes it viable to extend and improve the model through ‘scientific’ experimentation. Which I imagine might be what the next part of the book is about.
Hey everyone <!here> on earlier chapters! And realistically anyone further ahead who wants some extra reading... I've got additional resources the authors compiled by chapter. Chapter 1 1. This great post by Henry Mintzberg illustrates the problem with org charts and the idea of communityship over leadership: http://www.mintzberg.org/blog/communityship-beyond-leadership - "Effective organizations are communities of human beings, not collections of human resources." 2. The work of Naomi Stanford around organization design, here's a quick sample on the myths of organization design: https://naomistanford.com/2019/07/08/five-myths-of-organisation-design/ 3. For advanced thinking about organization structures, technology landscapes, and situational awareness see the work of Simon Wardley. For examples, his talk at QCon London 2019: https://www.infoq.com/presentations/stuational-awareness/ 4. For the laughs: http://bonkersworld.net/organizational-charts
Hey everyone <!here> on earlier chapters! And realistically anyone further ahead who wants some extra reading... I've got additional resources the authors compiled by chapter. Chapter 1 1. This great post by Henry Mintzberg illustrates the problem with org charts and the idea of communityship over leadership: http://www.mintzberg.org/blog/communityship-beyond-leadership - "Effective organizations are communities of human beings, not collections of human resources." 2. The work of Naomi Stanford around organization design, here's a quick sample on the myths of organization design: https://naomistanford.com/2019/07/08/five-myths-of-organisation-design/ 3. For advanced thinking about organization structures, technology landscapes, and situational awareness see the work of Simon Wardley. For examples, his talk at QCon London 2019: https://www.infoq.com/presentations/stuational-awareness/ 4. For the laughs: http://bonkersworld.net/organizational-charts
I work at a company whose primary business IS software and even here there are objections and resistance and Taylorism. Upper management has no clear focus on flow or feedback or continuous improvement so all we can do is nurture the grass-roots efforts here and there. It’s odd to be very familiar with agile, DevOps, lean software, CI/CD, etc but located too far down the food chain to be heard effectively.
Chapter 3 topic It was great to see the case studies on space design, I'm currently going through this process and described (without having seen it) fig 3.4 only yesterday (I was complaining about lack of wall space). What I found interesting was that CDL switched to large, portable, but still substantial, whiteboards and Autotrader mentioned everyone involved in this stream of business sits on the same floor: marketing people, sales people, developers... - what does this do for acoustics and noise levels? I'm currently trying to describe the need for engineering teams to be able to work at a team quiet or warmly humming level independent of a neighboring team. How are people's noise levels in the office, and what's worked / not worked / thought it would work but was definitely a bad idea?
<!here> Question from the authors for chapter 5! For anyone on digital (or audio), pages 79-98 are the beginning of chapter 5 through the start of the section called "Avoid Team Silos in the Flow of Change".
<!here> Question from the authors for chapter 5! For anyone on digital (or audio), pages 79-98 are the beginning of chapter 5 through the start of the section called "Avoid Team Silos in the Flow of Change".