3 ms·

> ...making them finally write a quick, limited capability prototype is a MAJOR effort. Fair, but why is that. I've been talked into just-for-now solutions ove

> ...making them finally write a quick, limited capability prototype is a MAJOR effort. Fair, but why is that. I've been talked into just-for-now solutions over and over in my career. Rarely does the org actually go back and clean it up in a timely fashion. It's possible, regardless of servantness, that leaders don't have a good reputation for following through and finishing things.

AndrewUnmuted 8y ago
The market doesn't any longer condone leadership where finishing and following through matter the most. We're in a race to the bottom as we barrel ever further down an economic rabbit hole. I can't, therefore, blame "leaders" for the conditions you correctly point out.
- dfjliasjg 8y ago
  That is 100% a leadership problem. There is a cult around Minimum Viable Product but that can be mitigated by technical leaders who are willing to stonewall the business leaders on unit tests and documentation. I don't even bother telling them that testing and documentation are separate tasks and roll it into development time.
hobs 8y ago
Rarely? Try never. Then its now your job to support the mess from now on. You can call me a recalcitrant developer if you want, but its like asking "Oh, well what bridge can you build in two weeks?" Sometimes you should build a raft instead of trying to pretend you can build major infrastructure in no time flat.
- andyidsinga 8y ago
  The raft metaphor is a good one. I've often used a similar one: "first we build a go-kart. It's a cool little go-kart, and will help us overcome certain barriers to adoption with a certain kind of customer for whom a go-kart meets their needs." I find that the main arguments against the raft/go-kart strategy (from the the business leader) are along the lines of "we need a Ferrari man! not a go-kart; our target customers won't even consider a go-kart". Its at this point that an very important discussion has to be had about how customer development and barriers to adoption are overcome. BTW - the applies to both new product development and features for existing products. This is not easy. This discussion must include "Look, the experts who are building this are telling you ________ and ________; you can choose to accept that or continue down a path of uncertainty and investigation until they come up with another set of recommendations...". The goal for the technical leader is to setup a set of options for the business leaders to choose - none of which are allowed to be chaos. If chaos is the norm, either the business leader or technical leader will be removed - or the business will likely fail due to that chaos and its effects on the team.
  - s73v3r_ 8y ago
    I don't know if this is a good time in history to be referring to "experts".
    - andyidsinga 8y ago
      Hmmm. I understand why you say that - alas, yes in the political environment experts are cast negatively. In the above context, I'm talking about the people we hire to do the things that need to get done to move a business forward - we hire them for their expertise and skills. When I'm talking about the people I've hired - to management, peers in other groups etc - I refer to them as "the experts who are building the ________, tasked with accomplishing ________" and so on. It reminds people that they're here for a reason - to contibute ..and not here by random coincidence.

AndrewUnmuted 8y ago

The market doesn't any longer condone leadership where finishing and following through matter the most. We're in a race to the bottom as we barrel ever further down an economic rabbit hole. I can't, therefore, blame "leaders" for the conditions you correctly point out.

dfjliasjg 8y ago
That is 100% a leadership problem. There is a cult around Minimum Viable Product but that can be mitigated by technical leaders who are willing to stonewall the business leaders on unit tests and documentation. I don't even bother telling them that testing and documentation are separate tasks and roll it into development time.

hobs 8y ago

Rarely? Try never. Then its now your job to support the mess from now on. You can call me a recalcitrant developer if you want, but its like asking "Oh, well what bridge can you build in two weeks?" Sometimes you should build a raft instead of trying to pretend you can build major infrastructure in no time flat.

andyidsinga 8y ago
The raft metaphor is a good one. I've often used a similar one: "first we build a go-kart. It's a cool little go-kart, and will help us overcome certain barriers to adoption with a certain kind of customer for whom a go-kart meets their needs." I find that the main arguments against the raft/go-kart strategy (from the the business leader) are along the lines of "we need a Ferrari man! not a go-kart; our target customers won't even consider a go-kart". Its at this point that an very important discussion has to be had about how customer development and barriers to adoption are overcome. BTW - the applies to both new product development and features for existing products. This is not easy. This discussion must include "Look, the experts who are building this are telling you ________ and ________; you can choose to accept that or continue down a path of uncertainty and investigation until they come up with another set of recommendations...". The goal for the technical leader is to setup a set of options for the business leaders to choose - none of which are allowed to be chaos. If chaos is the norm, either the business leader or technical leader will be removed - or the business will likely fail due to that chaos and its effects on the team.
- s73v3r_ 8y ago
  I don't know if this is a good time in history to be referring to "experts".
  - andyidsinga 8y ago
    Hmmm. I understand why you say that - alas, yes in the political environment experts are cast negatively. In the above context, I'm talking about the people we hire to do the things that need to get done to move a business forward - we hire them for their expertise and skills. When I'm talking about the people I've hired - to management, peers in other groups etc - I refer to them as "the experts who are building the ________, tasked with accomplishing ________" and so on. It reminds people that they're here for a reason - to contibute ..and not here by random coincidence.