Well-balanced article and very well written. Some observations from my personal experience:
- the main difficulty here is often not technical but of values: Sam and Tom disagree with each other. They know the technics but usually hate them and find them wasteful and abusive. Often,they aren't even able to explain why they think their approach is better than the other one and in which context. They will cite books, articles, blog post... They can even bring data and metrics to prove their point, but it will very often be done without a good understanding of the base principles underlying them, and more importantly, a lack of alignment on the common values shared by the team. Our role as manager becomes one of facilitator, encouraging the conversation to go deeper, asking Tom and Sam to acknowledge the pros and cons on both side, and asking them to find a common path on how to reach the best of both worlds in a collaborative way (all things you mentioned already, I'm just adding the underlying quest for a shared alignment here).
- I found too that iterative and incremental software development is the best approach here. Unfortunately, even if that method is known for over 40 years, it is still badly understand. In particular, the heuristic aspect of it, where the amount of doc, design, test, development, etc is always changing for each iteration, is something where I found people having the most resistance too. Tom will want to always be in development mode, Sam will want to pass more time in design, and Rhena will complain that not enough time is passed on tests. But overall, the real obstacle here is the fear to not have a definitive answer, to have to use your judgement to figure when the amount of X is good enough, and to not be afraid to be wrong about it. And that requires psychological safety, trust and, more importantly, courage and humility.
Thank you! Yes, aligning values and fostering psychological safety are indeed key. Helping the team embrace collaboration and navigate uncertainty with courage and trust is crucial. Appreciate your perspective!
In my experience we have seen both type of developers. The speed of hot fixes really matters for critical application support and maintenance. We use staggered approach to deal with tech debts. Have you seen MACH architecture ( https://machalliance.org/) style-it brings best of both worlds - specifically designed for commerce and content management domains.
It is designed to be composable, hence resembles individual functions as LEGO blocks, thus pick and chose. IMO, interesting option in SaaS based model - those designed as cloud
Interesting take on how to get the best of both archetypes as an engineering leader. I also agree that it depends on the context and what the situation demands. Nice writeup Rafa!
Well-balanced article and very well written. Some observations from my personal experience:
- the main difficulty here is often not technical but of values: Sam and Tom disagree with each other. They know the technics but usually hate them and find them wasteful and abusive. Often,they aren't even able to explain why they think their approach is better than the other one and in which context. They will cite books, articles, blog post... They can even bring data and metrics to prove their point, but it will very often be done without a good understanding of the base principles underlying them, and more importantly, a lack of alignment on the common values shared by the team. Our role as manager becomes one of facilitator, encouraging the conversation to go deeper, asking Tom and Sam to acknowledge the pros and cons on both side, and asking them to find a common path on how to reach the best of both worlds in a collaborative way (all things you mentioned already, I'm just adding the underlying quest for a shared alignment here).
- I found too that iterative and incremental software development is the best approach here. Unfortunately, even if that method is known for over 40 years, it is still badly understand. In particular, the heuristic aspect of it, where the amount of doc, design, test, development, etc is always changing for each iteration, is something where I found people having the most resistance too. Tom will want to always be in development mode, Sam will want to pass more time in design, and Rhena will complain that not enough time is passed on tests. But overall, the real obstacle here is the fear to not have a definitive answer, to have to use your judgement to figure when the amount of X is good enough, and to not be afraid to be wrong about it. And that requires psychological safety, trust and, more importantly, courage and humility.
Thank you! Yes, aligning values and fostering psychological safety are indeed key. Helping the team embrace collaboration and navigate uncertainty with courage and trust is crucial. Appreciate your perspective!
In my experience we have seen both type of developers. The speed of hot fixes really matters for critical application support and maintenance. We use staggered approach to deal with tech debts. Have you seen MACH architecture ( https://machalliance.org/) style-it brings best of both worlds - specifically designed for commerce and content management domains.
I learned recently about MACH. If you're using microservices, it's a great framework. Thanks for your comment!
It is designed to be composable, hence resembles individual functions as LEGO blocks, thus pick and chose. IMO, interesting option in SaaS based model - those designed as cloud
native, api first based microservices.
Interesting take on how to get the best of both archetypes as an engineering leader. I also agree that it depends on the context and what the situation demands. Nice writeup Rafa!
As usual, context and the unique of each situation, is what truly matters! Thanks Gaurav!