5 ms·

Your scenario can be a lose-lose situation as it applies to the question. Speaking from experience, you can do the “agile” approach do fail fast, release faster

Your scenario can be a lose-lose situation as it applies to the question. Speaking from experience, you can do the “agile” approach do fail fast, release faster, but with no buy-in from leadership to address the breaks in the future, your compounding problems on problems. So, short-term, you have happy leaders who see releases as they want, and unhappy devs who are in a shitshow of code. Long-term, if your startup is either acquired or starts to grow a strong revenue stream, leaders need to appease their new owners or their influx of new customers, and you can’t slow down because either a.) the new board needs to be impressed to justify their large acqui-investment, or b.) your new customer base is too big to risk losing. So you keep building on bad code, maybe squeezing in a few skunkwork refactored that only the dev peer reviewing and QA know about, and accept any delay on release as the result. The approach should be somewhere in between, ideally with the engineering team being empowered to tell leadership “yo, we have a bomb of bugs just waiting to burst if we add one more feature with duct tape, let’s prioritize time to address it”. If leadership doesn’t trust your team, then you have bad leadership.

darkerside 6y ago
Is there any situation under which leadership shouldn't buy in to exactly what tech wants to do?
- pletsch 6y ago
  Does a captain of a ship do exactly what his crew wants all the time? No, because they're steering a ship and sometimes they have to make moves that not everyone will agree with.
  - mondoshawan 6y ago
    Erm... That's not how sailing works. Yes, the Captain needs buy-in all the time, since they are ultimately responsible for the ship and crew both in the eyes of the law and survival wise. Also, most of the time the crew is at the helm. Source: I'm a trained sailor.
- chasd00 6y ago
  Scotty wasn't on the bridge, he didn't know what was out the window.
  - karatestomp 6y ago
    Point of order: Scotty was frequently on the bridge commanding the ship, and there's a strong argument to be made that he was the second-best at the job, after Kirk. Certainly 3rd best.
    - chasd00 6y ago
      i voted you up, it was a risky analogy given my limited knowledge of Star Trek compared to the majority here :)
- adrianN 6y ago
  Hopefully there are situations where the leadership has more information available than the engineers.
- darkerside 6y ago
  This is a little embarrassing. I asked what I thought was a well-designed question to frame the problem in a way that made my own conclusion obvious. Clearly, I missed the mark, so I'll be more straightforward now. Engineers below the upper senior levels typically operate with an "infinite" mindset in making these choices. We all laugh at the relevant XKCD[0] because there's a grain of truth in there. This isn't a knock on engineering, it's just the nature of operating at the lowest levels. You become involved in the problem and you solve for local maxima. Leadership done well is going to offering transparency to the people on the ground level, communicating timelines and strategy in a way that is relevant to the problem at hand, so people know, for example, how long they can spend solving a particular problem. Where this sometimes goes wrong is, the higher you go in leadership, the lesser certainty there is. There are no "right" answers, there isn't perfect information, and yet, decisions must be made. If engineering is operating on different base assumptions, those decisions will look wrong (and they might be). And yet, someone needs to get people aligned and moving forward, because moving fast in the wrong direction is typically better than moving too slow, even in the right direction. [0] https://xkcd.com/974/ https://xkcd.com/974/
  - SAI_Peregrinus 6y ago
    Or this one, which provides good info on whether to take the time to automate something: https://xkcd.com/1205/ https://xkcd.com/1205/
rezonant 6y ago
So much this. There is such a thing as YAGNI in the early and tight days of a startup but tech debt is something that needs to be constantly addressed, and you as a manager need to trust your team to put in the proper engineering as a solution grows. Is quick and dirty fine for a prototype or MVP? In theory yes, but understand that a lot of devs have seen that turn into the final product (with customers on it within days of the "prototype" being finished in some cases). I've seen it with some of the worst codebases I've ever encountered, and those "prototypes" and "MVPs" were never overhauled with a scalable architecture, and the startups end up running out of steam because they did not invest in their product codebase, or better, have a sustainable pace of development that allows the solution to constantly remain high quality. Don't have the runway for that? Are you managing the startup as well as you could? Why did you tell your investors that you could do it in five months of dev time?

darkerside 6y ago

Is there any situation under which leadership shouldn't buy in to exactly what tech wants to do?

pletsch 6y ago
Does a captain of a ship do exactly what his crew wants all the time? No, because they're steering a ship and sometimes they have to make moves that not everyone will agree with.
- mondoshawan 6y ago
  Erm... That's not how sailing works. Yes, the Captain needs buy-in all the time, since they are ultimately responsible for the ship and crew both in the eyes of the law and survival wise. Also, most of the time the crew is at the helm. Source: I'm a trained sailor.
chasd00 6y ago
Scotty wasn't on the bridge, he didn't know what was out the window.
- karatestomp 6y ago
  Point of order: Scotty was frequently on the bridge commanding the ship, and there's a strong argument to be made that he was the second-best at the job, after Kirk. Certainly 3rd best.
  - chasd00 6y ago
    i voted you up, it was a risky analogy given my limited knowledge of Star Trek compared to the majority here :)
adrianN 6y ago
Hopefully there are situations where the leadership has more information available than the engineers.
darkerside 6y ago
This is a little embarrassing. I asked what I thought was a well-designed question to frame the problem in a way that made my own conclusion obvious. Clearly, I missed the mark, so I'll be more straightforward now. Engineers below the upper senior levels typically operate with an "infinite" mindset in making these choices. We all laugh at the relevant XKCD[0] because there's a grain of truth in there. This isn't a knock on engineering, it's just the nature of operating at the lowest levels. You become involved in the problem and you solve for local maxima. Leadership done well is going to offering transparency to the people on the ground level, communicating timelines and strategy in a way that is relevant to the problem at hand, so people know, for example, how long they can spend solving a particular problem. Where this sometimes goes wrong is, the higher you go in leadership, the lesser certainty there is. There are no "right" answers, there isn't perfect information, and yet, decisions must be made. If engineering is operating on different base assumptions, those decisions will look wrong (and they might be). And yet, someone needs to get people aligned and moving forward, because moving fast in the wrong direction is typically better than moving too slow, even in the right direction. [0] https://xkcd.com/974/ https://xkcd.com/974/
- SAI_Peregrinus 6y ago
  Or this one, which provides good info on whether to take the time to automate something: https://xkcd.com/1205/ https://xkcd.com/1205/

rezonant 6y ago

So much this. There is such a thing as YAGNI in the early and tight days of a startup but tech debt is something that needs to be constantly addressed, and you as a manager need to trust your team to put in the proper engineering as a solution grows. Is quick and dirty fine for a prototype or MVP? In theory yes, but understand that a lot of devs have seen that turn into the final product (with customers on it within days of the "prototype" being finished in some cases). I've seen it with some of the worst codebases I've ever encountered, and those "prototypes" and "MVPs" were never overhauled with a scalable architecture, and the startups end up running out of steam because they did not invest in their product codebase, or better, have a sustainable pace of development that allows the solution to constantly remain high quality. Don't have the runway for that? Are you managing the startup as well as you could? Why did you tell your investors that you could do it in five months of dev time?