5 ms·

This is just another Waterfall By Another Name process and as a developer all I got out of this was don't work at Jam (whoever that is). > When developers pick

This is just another Waterfall By Another Name process and as a developer all I got out of this was don't work at Jam (whoever that is). > When developers pick up tickets that don't have all the information they need, they need to spend more cycles investigating and waiting for follow up information from the broader team. This could also be interpreted as adding layers of friction between the people experiencing problems and the people fixing those problems. This generally leads to worse outcomes. > After product spec and kick-off, the next step is for engineering to spend a little bit of time writing a technical plan. Oh good, a spec tossed over the fence in yet another meeting, and then another spec before any lines of code are written. No thanks. > Having milestones put on the calendar also gives us the flexibility to move them when needed, but makes it so that we consciously need to decide to move them, rather than letting dates slip by. The dates slip by because software estimation is akin to the Halting Problem. You aren't fixing that, just making your managers feel better. > Having a daily check in on the project status helps us recognize when we are drifting off track and need to make decisions about whether to change the date or re-prioritize what's in scope. Even more meetings, hooray! > All of the tips above are things we started doing as a direct result of something one of us suggested in a retro. Retros are awesome, and are so important. And more meetings about what went wrong in the prior meetings. FAANG doesn't do this. Hire great people, trust them, communicate async frequently, coordinate planning infrequently. This reads like a manifesto for "we hired a bunch of subpar developers and don't give them any ownership or empowerment". Pass.

kodah 4y ago
> FAANG doesn't do this. Hire great people, trust them, communicate async frequently, coordinate planning infrequently. This reads like a manifesto for "we hired a bunch of subpar developers and don't give them any ownership or empowerment". Pass. I work at a high performing remote-first company. This is how we do it. Ownership where I work includes an engineer, a TPM, sometimes an exec or manager. The gist is that there's individual ownership over: - Technical outcomes - Business outcomes - Customer outcomes - Integration outcomes Sometimes it can take us a while to agree on direction, but that's okay. For the (potential) slowness with respect to direction, it makes identifying, prioritizing, and fixing bugs much more simple. It also speeds up incident response quite a bit.
- ianlevesque 4y ago
  You mentioned outcomes four times so you're probably doing okay. That was notably lacking in Jam's blog post.
  - kodah 4y ago
    Sorry, I probably worded this poorly. I was trying to say that I agree with you and adding on what we do.
huustory07 4y ago
> FAANG doesn't do this. FAANG doesn't do what? All of these are what I've done at FAANG companies and on multiple teams.
- ianlevesque 4y ago
  Daily stand ups with constant re-estimating.
  - huustory07 4y ago
    That's not what you said in your comment so I don't know what you are trying to say. I'm confused by what parts of this you think FAANG companies don't do. This pretty much nails it although it might look slightly different.
BigJono 4y ago
IME the part of this that most teams fuck up is the "communicate async frequently" bit. Without that everything falls apart. Most of the agile meeting nonsense is an ineffective bandaid fix to the same problem.
solatic 4y ago
> Hire great people, trust them, Hoo boy. Reality is so much more complicated. When you hire someone, you think that they're great, you hope that your estimation of them proves out, but it's not really possible to know. Even people who come with great portfolios, great recommendations, the fact of the matter is that your company has its own culture and its own people in different roles, and it's simply not possible to know with 100% certainty that people will truly fit into your organization until you place them into their new role and see how things play out. Furthermore, nobody comes in with full expertise on every level of the stack. Nobody is an expert also in UX, also in your frontend stack, also in your backend stack, also in your datastores, also in security, also in compliance concerns, also in observability. You must build a collaborative culture if you want to ensure that all concerns are handled. You can build a culture where you trust the people you hire in general. But "trust" is not a euphemism for "let people go play cowboy from their desk in the corner and it doesn't matter that we don't know what they're doing because we trust them." The key foundation of that trust is knowing in which area the organization trusts you to be proficient and, in turn, trusting others in the organization with expertise in other areas, at least until a "great" hire proves to be unworthy of that trust. > more meetings... don't give them any ownership or empowerment You can do both. You can build a culture where you split a typical eight hour workday for individual contributors into no more than 2 hours (i.e. usually less) in meetings, 4 hours for planned issues discussed in those meetings, at least 2 hours (i.e. when meetings take less than 2 hours) for unplanned concerns which may include any number of the following: planned issues taking longer than planned, production outages, talking to customers, working on stuff the individual contributor thinks is important ("ownership/empowerment"), etc. Hire people who are arrogant enough in their area of expertise that they will loudly and energetically share that strength with others, and humble enough to listen to others with expertise in other areas.
- twelve40 4y ago
  > simply not possible to know with 100% certainty within 1 month tops its completely obvious who is pulling their weight and who isn't. Even without micromanagement or any kind of management at all really, it just becomes obvious for newhires after a few weeks.
ilrwbwrkhv 4y ago
Absolutely. The Jam product itself is a clear reflection of poor practices. It is buggy, slow and really bad.
lawn 4y ago
> FAANG doesn't do this. They also have ridiculous interview practices that have nothing to do with the work you will be doing. It's not automatically good just because FAANG does it.
- jackblemming 4y ago
  People don't seem to get this, no matter how much it's explained. Google can piss away millions and be generally idiotic because it's in a duopoly. Your mom and pop software shop can't.
Aeolun 4y ago
> Oh good, a spec tossed over the fence in yet another meeting, and then another spec before any lines of code are written. No thanks. If you have a random spec tossed over to your side you absolutely have to translate all the garbage to technical terms first, not doing that just leads to all your developers constantly asking WTH they’re actually supposed to build. That said, this whole story does sound exactly like what we’re doing at our F500 enterprise. I very much doubt it makes anything more agile.

kodah 4y ago

> FAANG doesn't do this. Hire great people, trust them, communicate async frequently, coordinate planning infrequently. This reads like a manifesto for "we hired a bunch of subpar developers and don't give them any ownership or empowerment". Pass. I work at a high performing remote-first company. This is how we do it. Ownership where I work includes an engineer, a TPM, sometimes an exec or manager. The gist is that there's individual ownership over: - Technical outcomes - Business outcomes - Customer outcomes - Integration outcomes Sometimes it can take us a while to agree on direction, but that's okay. For the (potential) slowness with respect to direction, it makes identifying, prioritizing, and fixing bugs much more simple. It also speeds up incident response quite a bit.

ianlevesque 4y ago
You mentioned outcomes four times so you're probably doing okay. That was notably lacking in Jam's blog post.
- kodah 4y ago
  Sorry, I probably worded this poorly. I was trying to say that I agree with you and adding on what we do.

huustory07 4y ago

> FAANG doesn't do this. FAANG doesn't do what? All of these are what I've done at FAANG companies and on multiple teams.

ianlevesque 4y ago
Daily stand ups with constant re-estimating.
- huustory07 4y ago
  That's not what you said in your comment so I don't know what you are trying to say. I'm confused by what parts of this you think FAANG companies don't do. This pretty much nails it although it might look slightly different.

BigJono 4y ago

IME the part of this that most teams fuck up is the "communicate async frequently" bit. Without that everything falls apart. Most of the agile meeting nonsense is an ineffective bandaid fix to the same problem.

solatic 4y ago

> Hire great people, trust them, Hoo boy. Reality is so much more complicated. When you hire someone, you think that they're great, you hope that your estimation of them proves out, but it's not really possible to know. Even people who come with great portfolios, great recommendations, the fact of the matter is that your company has its own culture and its own people in different roles, and it's simply not possible to know with 100% certainty that people will truly fit into your organization until you place them into their new role and see how things play out. Furthermore, nobody comes in with full expertise on every level of the stack. Nobody is an expert also in UX, also in your frontend stack, also in your backend stack, also in your datastores, also in security, also in compliance concerns, also in observability. You must build a collaborative culture if you want to ensure that all concerns are handled. You can build a culture where you trust the people you hire in general. But "trust" is not a euphemism for "let people go play cowboy from their desk in the corner and it doesn't matter that we don't know what they're doing because we trust them." The key foundation of that trust is knowing in which area the organization trusts you to be proficient and, in turn, trusting others in the organization with expertise in other areas, at least until a "great" hire proves to be unworthy of that trust. > more meetings... don't give them any ownership or empowerment You can do both. You can build a culture where you split a typical eight hour workday for individual contributors into no more than 2 hours (i.e. usually less) in meetings, 4 hours for planned issues discussed in those meetings, at least 2 hours (i.e. when meetings take less than 2 hours) for unplanned concerns which may include any number of the following: planned issues taking longer than planned, production outages, talking to customers, working on stuff the individual contributor thinks is important ("ownership/empowerment"), etc. Hire people who are arrogant enough in their area of expertise that they will loudly and energetically share that strength with others, and humble enough to listen to others with expertise in other areas.

twelve40 4y ago
> simply not possible to know with 100% certainty within 1 month tops its completely obvious who is pulling their weight and who isn't. Even without micromanagement or any kind of management at all really, it just becomes obvious for newhires after a few weeks.

ilrwbwrkhv 4y ago

Absolutely. The Jam product itself is a clear reflection of poor practices. It is buggy, slow and really bad.

lawn 4y ago

> FAANG doesn't do this. They also have ridiculous interview practices that have nothing to do with the work you will be doing. It's not automatically good just because FAANG does it.

jackblemming 4y ago
People don't seem to get this, no matter how much it's explained. Google can piss away millions and be generally idiotic because it's in a duopoly. Your mom and pop software shop can't.

Aeolun 4y ago

> Oh good, a spec tossed over the fence in yet another meeting, and then another spec before any lines of code are written. No thanks. If you have a random spec tossed over to your side you absolutely have to translate all the garbage to technical terms first, not doing that just leads to all your developers constantly asking WTH they’re actually supposed to build. That said, this whole story does sound exactly like what we’re doing at our F500 enterprise. I very much doubt it makes anything more agile.