How can the dependency challenge get so bad before companies do something about it? Why does it creep up as a problem? Let's explore this question by discussing four archetypes: Human Load Balancers. Renegades, Insiders, and Platform Saviors.
Loved this little series, thanks for putting it together, John!
Tangentially, I recently read "Modern Software Engineering" by Dave Farley and it touches on how team topology and processes are so interconnected with the way the systems are built (a la Conway's Law). So, particularly regarding that first question on the early signals, one thing I'm now probably biased towards but have definitely been thinking about is the way the software architecture itself is determining the way the dependencies crop up and are then handled.
These archetypes remind me of the various heroes that save the day but perpetuate the need for heroics rather than fixing the org. It's easy for an org to turn a blind eye, mitigation efforts can make things worse.
These critical enablers and linchpin employees have a valuable perspective for troubleshooting the problems if the org can access and leverage that knowledge.
I enjoyed reading this article and learning about the four archetypes. These are very realistic and relatable characters that many of us have encountered or even embodied in our work environments. I appreciate the insights on how these archetypes can contribute to or mask the dependency problem in growing companies, and the questions he poses to help us reflect on our situations. (Which has kept me close to this series!)
I wonder if there are other archetypes that could be added to this list, such as the integrators, the facilitators, or the innovators. How do they cope with dependencies, and what impact do they have on the organization? I would love to hear more about this.
Thank you for sharing this valuable piece of content. I look forward to reading more!
Revisited this today and remembered the Platform Surfer person, I feel I have met a few Platform Surfers in my time
Loved this little series, thanks for putting it together, John!
Tangentially, I recently read "Modern Software Engineering" by Dave Farley and it touches on how team topology and processes are so interconnected with the way the systems are built (a la Conway's Law). So, particularly regarding that first question on the early signals, one thing I'm now probably biased towards but have definitely been thinking about is the way the software architecture itself is determining the way the dependencies crop up and are then handled.
Thanks for this. Very thought provoking. What reading do you recommend for how to fix the issues?
These archetypes remind me of the various heroes that save the day but perpetuate the need for heroics rather than fixing the org. It's easy for an org to turn a blind eye, mitigation efforts can make things worse.
These critical enablers and linchpin employees have a valuable perspective for troubleshooting the problems if the org can access and leverage that knowledge.
I enjoyed reading this article and learning about the four archetypes. These are very realistic and relatable characters that many of us have encountered or even embodied in our work environments. I appreciate the insights on how these archetypes can contribute to or mask the dependency problem in growing companies, and the questions he poses to help us reflect on our situations. (Which has kept me close to this series!)
I wonder if there are other archetypes that could be added to this list, such as the integrators, the facilitators, or the innovators. How do they cope with dependencies, and what impact do they have on the organization? I would love to hear more about this.
Thank you for sharing this valuable piece of content. I look forward to reading more!