3 ms·

Having been on both sides of this (as a developer and later a senior manager with product/feature responsibility), I'd say it can be both. A really good manager

Having been on both sides of this (as a developer and later a senior manager with product/feature responsibility), I'd say it can be both. A really good manager/executive has enough knowledge and experience to ask the right questions and parse the answers even when they are technical. Sadly, many managers aren't that good (at least yet). On the other side, a really good developer has the knowledge and experience to frame the problem in an understandable business context when communicating the issue and options to management. Some of the best work experiences I've ever had were in orgs with such experienced developers and managers. Working together we were often able to solve apparently intractable problems with creative options which would never have been conceived absent the clarity of thought and communication on both sides.

420official 4y ago
This thinking implies nothing is worth doing unless it has a clearly articulable direct business value whereas a lot of technical debt simply doesn't. When the only people affected by a problem are people who have already spent their money or people who have no autonomy it's unlikely the decision makers will decide to investigate and fix it. If you're lucky you can convince decision makers that there is an impact to hiring or efficiency but in my experience these arguments are extremely challenging to make in the face of other stuff that decision makers feel directly impact business, and for good reason. I'd say this is a big reason autonomy is crucial when it comes to cultivating a curious team because without autonomy you are limited to things that can achieve consensus in an environment where people inherently have different interests to attend to. I feel like the "20% time" paradigm where one day out of the week is left up to the developer to schedule (within reason) is the right way to balance the conflicts of interest and still leave room for people to be curious.

420official 4y ago

This thinking implies nothing is worth doing unless it has a clearly articulable direct business value whereas a lot of technical debt simply doesn't. When the only people affected by a problem are people who have already spent their money or people who have no autonomy it's unlikely the decision makers will decide to investigate and fix it. If you're lucky you can convince decision makers that there is an impact to hiring or efficiency but in my experience these arguments are extremely challenging to make in the face of other stuff that decision makers feel directly impact business, and for good reason. I'd say this is a big reason autonomy is crucial when it comes to cultivating a curious team because without autonomy you are limited to things that can achieve consensus in an environment where people inherently have different interests to attend to. I feel like the "20% time" paradigm where one day out of the week is left up to the developer to schedule (within reason) is the right way to balance the conflicts of interest and still leave room for people to be curious.