3 ms·

Restructured several failed projects, and it is never a painless process. A few common warning signs: 0. No mission project summary, or a moving finish-line f

Restructured several failed projects, and it is never a painless process. A few common warning signs: 0. No mission project summary, or a moving finish-line fiasco in progress 1. Top-heavy management budget allocation, or 4 levels of managers involved with zero stakeholder input into the project design/testing stages 2. No hallway testing, or your interface requires explanation and has already failed before coding starts 3. Entrenched incompetence, or people doubling down on failed project inertia rather than recognizing the issues 4. Relative skill value perception in HR, and the trivialization of workmanship standards. Translation: Letting the family Dog drive. 5. Failure to translate business ops needs into actual deliverables 6. Failure to quickly fire people engaged in counterproductive behavior. 7. Perfectionism: nothing is perfect in all use-cases 8. Novelty bias... Translation: Letting the puppy drive.

yashap 4y ago
I’ll also add, “too many cooks in the kitchen from day one.” If you’re starting some ambitious new greenfield project at a company, IMO it’s best to start out with a small team where you can make decisions quickly, and where everyone has a lot of accountability. Think 2-3 devs, maybe one product-y/manager-y person, and that’s it. When I’ve been on greenfield projects that have 10-20 people starting work on it all at the same time, it’s almost guaranteed to fail. Decisions will be slow/tedious, bureaucracy will arrive instantly, individual accountability will be nowhere to be found. With that being said, projects that get boatloads of ppl on day 1 are rarely bullshit projects, per-se. They tend to be good ideas, an important new project, just executed in a way that’s bound to fail.
- kqr 4y ago
  To extend on that: there needs to be a small set of cooks with their actual fingers in the broth (for various reasons including coordination and quick pivots) but that small group should probably consult a much larger group of kitchen staff and customers (read: potential users, collaborators, partners, etc) to figure out if they're going the right direction.
  - yashap 4y ago
    Oh yeah, it’s definitely not about making decisions in isolation - do your research, talk to stakeholders, think them through! Anyone who is given decision making power, and uses that to just do whatever they like with minimal consideration/research/etc., needs to have that power removed. But I do think in the early stages of a project, the number of people ultimately making the decisions (and writing code) needs to be small. More people can be added later, if necessary, but in the early stages of a greenfield project the team must be small. I’ve been on projects where 10-20 people are thrown onto it before a line of code exists and it’s an absolute shit show: decisions take ages, devs are constantly stepping on each other’s toes and extremely unproductive, there’s no personal accountability, etc.
hef19898 4y ago
Just why are you making this comment? Going through points 0, 1, 3, 4 5, 6, 7 and 8 it just hits too close to home... I cannot judge 2, our business processes failed so and continue to do so. If that counts, do I have a Bingo of sorts? Great comment so, because it confirms that I am not the crazy one!

yashap 4y ago

I’ll also add, “too many cooks in the kitchen from day one.” If you’re starting some ambitious new greenfield project at a company, IMO it’s best to start out with a small team where you can make decisions quickly, and where everyone has a lot of accountability. Think 2-3 devs, maybe one product-y/manager-y person, and that’s it. When I’ve been on greenfield projects that have 10-20 people starting work on it all at the same time, it’s almost guaranteed to fail. Decisions will be slow/tedious, bureaucracy will arrive instantly, individual accountability will be nowhere to be found. With that being said, projects that get boatloads of ppl on day 1 are rarely bullshit projects, per-se. They tend to be good ideas, an important new project, just executed in a way that’s bound to fail.

kqr 4y ago
To extend on that: there needs to be a small set of cooks with their actual fingers in the broth (for various reasons including coordination and quick pivots) but that small group should probably consult a much larger group of kitchen staff and customers (read: potential users, collaborators, partners, etc) to figure out if they're going the right direction.
- yashap 4y ago
  Oh yeah, it’s definitely not about making decisions in isolation - do your research, talk to stakeholders, think them through! Anyone who is given decision making power, and uses that to just do whatever they like with minimal consideration/research/etc., needs to have that power removed. But I do think in the early stages of a project, the number of people ultimately making the decisions (and writing code) needs to be small. More people can be added later, if necessary, but in the early stages of a greenfield project the team must be small. I’ve been on projects where 10-20 people are thrown onto it before a line of code exists and it’s an absolute shit show: decisions take ages, devs are constantly stepping on each other’s toes and extremely unproductive, there’s no personal accountability, etc.

hef19898 4y ago

Just why are you making this comment? Going through points 0, 1, 3, 4 5, 6, 7 and 8 it just hits too close to home... I cannot judge 2, our business processes failed so and continue to do so. If that counts, do I have a Bingo of sorts? Great comment so, because it confirms that I am not the crazy one!