Thanks Raul for your feedback! I will try to write new posts with those guidelines so they are more clear. Let me give you a short summary of each of them 😁.
"Business should provide a sandbox for teams to fail."
Business should be mature enough to handle failures from teams. For example, if your company incomes are managed by a single team which delivers the core domain, the pressure of delivery on that team makes the organization less reliable and error-prone.
If you build an organization where your stability as a business is distributed across teams, you can actually stand failures and learn from them, which ensures that teams can learn from the business feedback and improve.
Business should understand that you are not building software for today, but for the next 5 years at least.
“Infrastructure is cheap in terms of budget, but expensive in cognitive load.“
Infrastructure, by means of any hardware or service that you need to run your software, today is quite cheap for any mid-size company. However, teams that need to handle a lot of infrastructure, suffer in terms of value delivery, because understanding how third-party services communicate and interconnect between them is harder than just a single project with code.
For example, cloud architectures in AWS that depend on several lambdas, S3 buckets, IAM Roles and SQS queues can be cheap (depending on the load) but managing and understanding them for a team is hard. A guideline that I usually have for the design of my software is: a person should be able to understand the solution in less than 1 week and be able to commit in the second day.
"Teams decide how they communicate globally in the organization."
There are several team formats and patterns (I recommend the book Team Topologies, which is amazing) but for me the most important decision a team should take around their own organization is how they communicate within the organization.
Most of the times, teams are not alone in an organization, they need to communicate with other teams and stakeholders, and this communication can lead to a lot of trouble if not handled correctly. Helping teams to decide how they communicate based on their needs is as step towards success.
Thanks for your feedback!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks Raul for your feedback! I will try to write new posts with those guidelines so they are more clear. Let me give you a short summary of each of them 😁.
Business should be mature enough to handle failures from teams. For example, if your company incomes are managed by a single team which delivers the core domain, the pressure of delivery on that team makes the organization less reliable and error-prone.
If you build an organization where your stability as a business is distributed across teams, you can actually stand failures and learn from them, which ensures that teams can learn from the business feedback and improve.
Business should understand that you are not building software for today, but for the next 5 years at least.
Infrastructure, by means of any hardware or service that you need to run your software, today is quite cheap for any mid-size company. However, teams that need to handle a lot of infrastructure, suffer in terms of value delivery, because understanding how third-party services communicate and interconnect between them is harder than just a single project with code.
For example, cloud architectures in AWS that depend on several lambdas, S3 buckets, IAM Roles and SQS queues can be cheap (depending on the load) but managing and understanding them for a team is hard. A guideline that I usually have for the design of my software is: a person should be able to understand the solution in less than 1 week and be able to commit in the second day.
There are several team formats and patterns (I recommend the book Team Topologies, which is amazing) but for me the most important decision a team should take around their own organization is how they communicate within the organization.
Most of the times, teams are not alone in an organization, they need to communicate with other teams and stakeholders, and this communication can lead to a lot of trouble if not handled correctly. Helping teams to decide how they communicate based on their needs is as step towards success.
Thanks for your feedback!