Sequential vs. Parallel projects on a small team
At first glance, there are some things that are stochastic in engineering management. Keeping turnover low is one. Keeping projects on timeline is another. But it could be that everything in engineering management is stochastic, which would mean that the expectations of engineering managers should be wholly different than in general management. Can you treat stochastic processes as a black box? Is it all risk management?
Maybe that's how insurance companies work. It's a black box that reduces the risk of its business turning a profit by diversifying. Instead of holding a single policy, they hold many, and they spread them out across different categories.
The analogous situation for a software company would maybe be
Insurance:policy :: Startup:project
Insurance:portfolio :: startup::roadmap (concurrency included)
On a small team, do you get less risk from a sequential roadmap or from a concurrent one?
Let's say you have two projects: A and B. If you work on A and B concurrently, your cash burn is higher during those projects than they would be if they were performed sequentially (even though total cash spent is the same). If you're cash constrained, you don't have much of a choice.
If you run the projects in parallel, you have two different teams. Their success or failure has a limited effect on the other. If A fails, it doesn't necessarily have much of an impact on B. If B succeeds, it doesn't change A's outcome much. If either of them succeed (or both), you have the makings of an outstanding learning opportunity - each team could retro and present their findings to the other. Win win.
If you run the projects sequentially, you could have one team. You keep your cash burn lower (even though you're spending the same amount - just over a longer time period). If project A fails, you could argue that it imperils the success of project B if morale took a big hit. One way to mitigate this would be to perform an honest retro, and as long as the team is bought into making improvements, the failure of A could actually strengthen the odds of B succeeding. If the retro isn't honest, or isn't well run, or the team isn't interested in improving, then B has been negatively impacted by the failure of A. If A succeeds, it could embolden the team on B, maybe even to a fault - it's often tempting to let success misguide your efforts. What worked for A doesn't necessarily mean it will work for B.
In summary: running A and B in parallel decreases execution risk, exposes the team to more learning opportunities, and increases short term cash burn. Running A and B sequentially keeps cash burn lower but increases the risks associated with failure.