4 ms·

This sounds like fundamentally a business problem (we have finite resource, is product A or B our priority?) and trying to solve it with choices in the technolo

This sounds like fundamentally a business problem (we have finite resource, is product A or B our priority?) and trying to solve it with choices in the technology division. Well, here be dragons. Based on my experiences, the idea that a genuine bottleneck in tech is being made visible to customer division management and senior management, is generally an authentic way to ensure realism creeps back into the prioritisation and funding processes.

koonsolo 3y ago
A platform team might have a very unevenly distributed workload. Some weeks nothing has to be done on the platform, everything works fine. Then all of a sudden 2 teams request some extra features. How many people do you put in the platform team? Either you put too many in there, and they are basically idle the time in between. Or you put a limited team, and once even a single team requests something they will have to wait for the developments, let alone 2 requests at the same time. The OP describes an excellent solution: the team that needs the feature, pays for it in man-hours. In fact, those developers that need it, are pretty familiar with using it, so most of the time capable of doing some developments on it. They can also schedule in the work in their project. The teams that will need it afterwards will get it for free. It's actually an excellent solution.
- CraigJPerry 3y ago
  >> A platform team might have a very unevenly distributed workload. But When would this hypothetical occur? If the platform is new-ish, there’s always going to be more work to be done than there are people to do it so there’s no variation in workload - there’s just lots to be done. When the platform is established and operating in self-service mode, so think Amazon S3, were in a mode where we’re really not expecting features to be added, more about bugfixes and operational capacity at that point. >> the team that needs the feature, pays for it in man-hours there’s no free lunch. These developers don’t really care about the platform, they have bigger fish to fry. You need to ensure that infra doesn’t become a tragedy of the commons.
  - koonsolo 3y ago
    Let's say you offer a custom built UX design system with components. Most of it is written. At some point, you need a big component that doesn't exist yet, but other teams could benefit from that. This is such a situation, and it happens all the time in internal products. Either you over invest, you under invest, or the solution proposed here: jit developments where you can allocate resources as you need them. > These developers don’t really care about the platform They care as much as it helps them. The overall vision is steered by the architect responible for that internal product/platform, as said by OP.
    - CraigJPerry 3y ago
      >> jit developments where you can allocate resources as you need them Again there’s just no free lunch here, you’ve got a generalist writing a specialist component. In your example, how confident are you that the full stack product team developer is acutely aware of, i don’t know , let’s say accessibility practices or maybe performance tradeoffs for constructing this component? The specialist in the platform team member knows this intimately, it’s their specialism.
      - koonsolo 3y ago
        You discuss the developments with the architect before development, and then have your code reviewed afterwards. But hey, if you want some experts to sit idle until some real work comes in, that's all fine by me.
tsimionescu 3y ago
Sure, it's fundamentally a business problem. But it's very hard to do product planning when you need to take into account global priorities for the platform team. Plus, you need to spend time to even estimate the cost of Feature A and Feature B, so you actually end up with several rounds of discussions where you first prioritise spending time on the estimation, then the feature itself etc. Not to mention, if this is a deep platform feature, it's probably only a prerequisite for an actual customer facing-feature that requires additional work, which gets delayed by all the estimation work and so on. Additionally, this overall means that no one can plan in advance any features that depend on the platform, since global business priorities are constantly shifting. Not to mention the political angle, where more adept business leaders can always push through their pet platform features to the detriment of what are more obvious business goals. Or at least, it will always seem this way to teams whose requirements keep falling through the cracks.
- CraigJPerry 3y ago
  >> you need to You don’t NEED to do anything, it’s all choices. If product A is my breadwinner, i might not even need product B to estimate workload impacts for their feature request because my business strategy might be such that i’ll be allocating the resources based on business priority of product A. Trying to second guess this by making tech a black hole with no levers to pull by the business is fundamentally unsound. >> where more adept business leaders can always push through their … Or at least, it will always seem this way I mean i think you’re calling out the solution with the problem. Just strive to be a better operator, level up to their ability. Exceedingly hard to do but overall win for everyone.
  - tsimionescu 3y ago
    If you're the person in charge of planning product A's road map, you do need to take into account platform schedules, and those do depend on every other product that uses the platform. And of course the choice is sometimes simple, but it's often not. It's often the case that both Product A and Product B are breadwinners. One might need a feature that can bring $1M in revenue, and take between 3-4 months, and another might have a feature that should bring in $200k in revenue, but take 0.5-1 month. Which do you prioritize? What if both must be done by some date, but for one there is a chance to push a customer to accept a later date, but it's not sure yet? What happens when it later turns out that the estimation was overly optimistic and it will take twice as long? > Just strive to be a better operator, level up to their ability. Exceedingly hard to do but overall win for everyone. Politics in an org is a 0-sum game. If I win, someone else loses, and then their team is going to be the one that feels frustrated, and we're back to square one.

koonsolo 3y ago

A platform team might have a very unevenly distributed workload. Some weeks nothing has to be done on the platform, everything works fine. Then all of a sudden 2 teams request some extra features. How many people do you put in the platform team? Either you put too many in there, and they are basically idle the time in between. Or you put a limited team, and once even a single team requests something they will have to wait for the developments, let alone 2 requests at the same time. The OP describes an excellent solution: the team that needs the feature, pays for it in man-hours. In fact, those developers that need it, are pretty familiar with using it, so most of the time capable of doing some developments on it. They can also schedule in the work in their project. The teams that will need it afterwards will get it for free. It's actually an excellent solution.

CraigJPerry 3y ago
>> A platform team might have a very unevenly distributed workload. But When would this hypothetical occur? If the platform is new-ish, there’s always going to be more work to be done than there are people to do it so there’s no variation in workload - there’s just lots to be done. When the platform is established and operating in self-service mode, so think Amazon S3, were in a mode where we’re really not expecting features to be added, more about bugfixes and operational capacity at that point. >> the team that needs the feature, pays for it in man-hours there’s no free lunch. These developers don’t really care about the platform, they have bigger fish to fry. You need to ensure that infra doesn’t become a tragedy of the commons.
- koonsolo 3y ago
  Let's say you offer a custom built UX design system with components. Most of it is written. At some point, you need a big component that doesn't exist yet, but other teams could benefit from that. This is such a situation, and it happens all the time in internal products. Either you over invest, you under invest, or the solution proposed here: jit developments where you can allocate resources as you need them. > These developers don’t really care about the platform They care as much as it helps them. The overall vision is steered by the architect responible for that internal product/platform, as said by OP.
  - CraigJPerry 3y ago
    >> jit developments where you can allocate resources as you need them Again there’s just no free lunch here, you’ve got a generalist writing a specialist component. In your example, how confident are you that the full stack product team developer is acutely aware of, i don’t know , let’s say accessibility practices or maybe performance tradeoffs for constructing this component? The specialist in the platform team member knows this intimately, it’s their specialism.
    - koonsolo 3y ago
      You discuss the developments with the architect before development, and then have your code reviewed afterwards. But hey, if you want some experts to sit idle until some real work comes in, that's all fine by me.

tsimionescu 3y ago

Sure, it's fundamentally a business problem. But it's very hard to do product planning when you need to take into account global priorities for the platform team. Plus, you need to spend time to even estimate the cost of Feature A and Feature B, so you actually end up with several rounds of discussions where you first prioritise spending time on the estimation, then the feature itself etc. Not to mention, if this is a deep platform feature, it's probably only a prerequisite for an actual customer facing-feature that requires additional work, which gets delayed by all the estimation work and so on. Additionally, this overall means that no one can plan in advance any features that depend on the platform, since global business priorities are constantly shifting. Not to mention the political angle, where more adept business leaders can always push through their pet platform features to the detriment of what are more obvious business goals. Or at least, it will always seem this way to teams whose requirements keep falling through the cracks.

CraigJPerry 3y ago
>> you need to You don’t NEED to do anything, it’s all choices. If product A is my breadwinner, i might not even need product B to estimate workload impacts for their feature request because my business strategy might be such that i’ll be allocating the resources based on business priority of product A. Trying to second guess this by making tech a black hole with no levers to pull by the business is fundamentally unsound. >> where more adept business leaders can always push through their … Or at least, it will always seem this way I mean i think you’re calling out the solution with the problem. Just strive to be a better operator, level up to their ability. Exceedingly hard to do but overall win for everyone.
- tsimionescu 3y ago
  If you're the person in charge of planning product A's road map, you do need to take into account platform schedules, and those do depend on every other product that uses the platform. And of course the choice is sometimes simple, but it's often not. It's often the case that both Product A and Product B are breadwinners. One might need a feature that can bring $1M in revenue, and take between 3-4 months, and another might have a feature that should bring in $200k in revenue, but take 0.5-1 month. Which do you prioritize? What if both must be done by some date, but for one there is a chance to push a customer to accept a later date, but it's not sure yet? What happens when it later turns out that the estimation was overly optimistic and it will take twice as long? > Just strive to be a better operator, level up to their ability. Exceedingly hard to do but overall win for everyone. Politics in an org is a 0-sum game. If I win, someone else loses, and then their team is going to be the one that feels frustrated, and we're back to square one.