How to move fast and not break things as a remote company
This is just another Waterfall By Another Name process and as a developer all I got out of this was don&#x27;t work at Jam (whoever that is).<p>&gt; When developers pick up tickets that don&#x27;t have all the information they need, they need to spend more cycles investigating and waiting for follow up information from the broader team.<p>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.<p>&gt; After product spec and kick-off, the next step is for engineering to spend a little bit of time writing a technical plan.<p>Oh good, a spec tossed over the fence in yet another meeting, and then <i>another</i> spec before any lines of code are written. No thanks.<p>&gt; 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.<p>The dates slip by because software estimation is akin to the Halting Problem. You aren&#x27;t fixing that, just making your managers feel better.<p>&gt; 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&#x27;s in scope.<p>Even more meetings, hooray!<p>&gt; 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.<p>And more meetings about what went wrong in the prior meetings.<p>FAANG doesn&#x27;t do this. Hire great people, trust them, communicate async frequently, coordinate planning infrequently. This reads like a manifesto for &quot;we hired a bunch of subpar developers and don&#x27;t give them any ownership or empowerment&quot;. Pass.