4 ms·

> In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experien

by hysan 5y ago

> In the second case, I got the sense that leadership didn't really grasp how costly the context switching was for us due to not having much collective experience working in mobile (not to mention the rude awakening of having to deal with iOS dev dependencies). This is something I’m dealing with in my current job. I would love to hear how people have been successful at conveying this to leadership.

thr0wawayf00 5y ago
I started asking my boss to commit me to 6 months on a new stack if that's what they really needed me to do, making the argument that it takes at least a month to really become productive and several more to internalize the concepts. He understood and agreed that the constant context switching didn't make much sense because it slowed us down, but he couldn't make any promises. Things didn't change and I left a few months later when I got a better offer.
rkeene2 5y ago
In the past I've explained this as a comparison of Costs and Outcomes. The total cost of the plan, and the outcomes (mostly as benefits). In the GP's example it could have been, for example, the cost in time for the existing to develop the iOS application, the opportunity cost that's being given up by causing schedule slippages, and the discretionary effort of staff based on doing unfavorable work for the benefits of reducing management complexity, upskilling existing staff, and gaining a wider variety of experience within the team. Alternatives such as using a supplier to build the iOS have their own costs and outcomes. For example, cost in terms of capital dollars, a technical person still needs to invest time in finding the correct supplier, a technical person still needs to invest time into creating the specification to build upon (even if you find a supplier which can do agile and incremental delivery/iteration), and management overhead for managing the team and/or relationship with the supplier. Further, since the product is something that needs to be maintained (presumably), a maintenance plan of some sort will need to be put into place, and for the benefit of getting it done more quickly, a better product by developers interested and competent in the domain the total cost will likely be lower, and other projects will slip less. There's also the advantage that if management has to put in capital dollars then they are more likely to take the project seriously and fund its maintenance and reward those involved, especially if that's accounted for up front.

by hysan 5y ago

thr0wawayf00 5y ago

I started asking my boss to commit me to 6 months on a new stack if that's what they really needed me to do, making the argument that it takes at least a month to really become productive and several more to internalize the concepts. He understood and agreed that the constant context switching didn't make much sense because it slowed us down, but he couldn't make any promises. Things didn't change and I left a few months later when I got a better offer.

rkeene2 5y ago

In the past I've explained this as a comparison of Costs and Outcomes. The total cost of the plan, and the outcomes (mostly as benefits). In the GP's example it could have been, for example, the cost in time for the existing to develop the iOS application, the opportunity cost that's being given up by causing schedule slippages, and the discretionary effort of staff based on doing unfavorable work for the benefits of reducing management complexity, upskilling existing staff, and gaining a wider variety of experience within the team. Alternatives such as using a supplier to build the iOS have their own costs and outcomes. For example, cost in terms of capital dollars, a technical person still needs to invest time in finding the correct supplier, a technical person still needs to invest time into creating the specification to build upon (even if you find a supplier which can do agile and incremental delivery/iteration), and management overhead for managing the team and/or relationship with the supplier. Further, since the product is something that needs to be maintained (presumably), a maintenance plan of some sort will need to be put into place, and for the benefit of getting it done more quickly, a better product by developers interested and competent in the domain the total cost will likely be lower, and other projects will slip less. There's also the advantage that if management has to put in capital dollars then they are more likely to take the project seriously and fund its maintenance and reward those involved, especially if that's accounted for up front.