Only solve one new problem at a time
This post actually doesn&#x27;t resonate with me at all (and I&#x27;ve always respected Ben).  I feel like I&#x27;m <i>constantly</i> solving a multitude of problems and actively look for opportunities where I can introduce new tech that hits on multiple disparate streams at once (I have neither the bandwidth as an org or the personal time to operate in a different manner), typically coupled with other new tech; even that is orthogonal to running dozens of work streams concurrently, which isn&#x27;t exactly outside the gist of the article.  Even getting a sufficiently complex product&#x2F;program off the ground necessitates solving countless problems at once, otherwise the architecture has no chance of supporting growth.  Perhaps I&#x27;m at the stage where advice like this doesn&#x27;t apply, but looking back over my career, I can&#x27;t really identify a point at which it did.<p>To change my phrasing -- If someone manages a large team, let&#x27;s assume that they are responsible for all that the team does and can be viewed as a single entity, synonymous with a single engineer working at high bandwidth.  That entity is absolutely not solving singular problems at once.  Individual engineers within that team are not working in isolation from one another and they all have interconnect impact unless their delivery is absolutely rote.  In order to move at a speed necessary for on-time results on complex problems, the advice proposed in the article <i>must</i> be violated.