Exploring approaches CTOs and Engineering Leaders can deploy to strike the ideal balance between autonomy and adhering to coherent standards across their teams
Great post as usual Sergio. This is an area where I've also taken notes to write something. TLDR; I see premature standardization harming the org same as premature optimization harms the code. So I'd like to read more practical tips and thoughts on how you set boundaries on what should be standardized and what shouldn't. In my mind, Wardly maps can be [ab]used for this. Also I'm a fan of map/reduce approach: when things aren't clear, allow parallel solutions and then converge when there's a clear winner (as opposed to setting the boundaries upfront and allowing experimentation only within the pre-set tech landscape). Any thoughts on that?
I'm also a big fan of what you call the Map/Reduce approach as long as this is happening in a coordinated and structured way - i.e. how are we going to evaluate the best solution - and not as an internal competition - i.e. I don't like "their" solution, I think I can build a better one in secret
Definitely something that could be worth a post on its own!
🎯 in the few cases I've seen that's exactly what happened. No coordination, lots of competition, and hard feelings when the choice was made. However, it'd be great to read your perspective how to do it right. There's another implementation of what I call map/reduce which is called "10 to 3 to 1 design method" which is associated to Apple.
Great post as usual Sergio. This is an area where I've also taken notes to write something. TLDR; I see premature standardization harming the org same as premature optimization harms the code. So I'd like to read more practical tips and thoughts on how you set boundaries on what should be standardized and what shouldn't. In my mind, Wardly maps can be [ab]used for this. Also I'm a fan of map/reduce approach: when things aren't clear, allow parallel solutions and then converge when there's a clear winner (as opposed to setting the boundaries upfront and allowing experimentation only within the pre-set tech landscape). Any thoughts on that?
Thanks Alex,
I'm also a big fan of what you call the Map/Reduce approach as long as this is happening in a coordinated and structured way - i.e. how are we going to evaluate the best solution - and not as an internal competition - i.e. I don't like "their" solution, I think I can build a better one in secret
Definitely something that could be worth a post on its own!
Thanks a lot for the input
🎯 in the few cases I've seen that's exactly what happened. No coordination, lots of competition, and hard feelings when the choice was made. However, it'd be great to read your perspective how to do it right. There's another implementation of what I call map/reduce which is called "10 to 3 to 1 design method" which is associated to Apple.
Thanks for the follow-up.
I was not aware of the "10 to 3 to 1" design method, but it makes a lot of sense.
I've noted down the idea of writing an entire article on the subject in the upcoming future!