Basically, there's a spectrum which has at its ends two extremes:
1. R&D
2. Maintenance
These aren't about the actual activities performed; R&D could also be something like finding product-market fit at a startup and maintenance could also be working in product/engineering on, say the MS Word team. Just two opposite ways of operating.
In R&D mode, you want to encourage diverging ideas and err on the side of just trying if something works, which typically means you hire small teams of people who think differently, don't anchor too much to the past and avoid excessive layers of management and bureaucracy.
This is because you want to EXPAND the scope of possible actions and outcomes.
In maintenance mode, you want to get things just right every time and minimize the downside. For example, a radical redesign of MS Word would be a horrible idea because the entire world is used to a design they've known for 20 years. Here, you want people who keep things more or less the same. The same is true for internal infrastructure like billing, APIs, etc. This requires people who are less creative, but extremely thorough.
This is because you want to CONTRACT the potential scope of actions and outcomes.
1. R&D 2. Maintenance
These aren't about the actual activities performed; R&D could also be something like finding product-market fit at a startup and maintenance could also be working in product/engineering on, say the MS Word team. Just two opposite ways of operating.
In R&D mode, you want to encourage diverging ideas and err on the side of just trying if something works, which typically means you hire small teams of people who think differently, don't anchor too much to the past and avoid excessive layers of management and bureaucracy.
This is because you want to EXPAND the scope of possible actions and outcomes.
In maintenance mode, you want to get things just right every time and minimize the downside. For example, a radical redesign of MS Word would be a horrible idea because the entire world is used to a design they've known for 20 years. Here, you want people who keep things more or less the same. The same is true for internal infrastructure like billing, APIs, etc. This requires people who are less creative, but extremely thorough.
This is because you want to CONTRACT the potential scope of actions and outcomes.