My first engineering management job was with Hewlett Packard in the 1970's. One component of the management training program was a series of prerecorded lectures by Bill Oncken on "Managing Management Time". It was a great class, and I learned a lot. His examples and analogies are far out of date (and often sexist), but the lessons still hold true.
Oncken's basic premise is that the measure of a good manager is his ability to get results from the efforts of others, and the primary tool is "management time". While this may seem obvious, it isn't the metric that is usually applied to engineering managers. Instead, we usually measure him or her by conformance to a budget, a schedule or a set of committed deliverables. In the startup world, we are always in danger of missing on one or more of those more tangible metrics. It is good to measure performance through tangible metrics, but how you achieve those results marks the difference between an inexperienced manager and a seasoned professional.
The inexperienced manager responds to the crisis by shifting his personal time expenditure to vocational work rather than management work. He tackles the technical issue, using the skills he developed as an engineer that in part resulted in his promotion to management. Since time is (mostly) inelastic, that reduces the amount of time he spends on management, that is, on the time spent getting results from the efforts of others. Thus, by Oncken's definition, he responds to a crisis by being a bad manager. It feels good, though, because he is heroically and visibly "taking ownership" of the problem, leading from the front, and he's using familiar and comfortable skills.
Startup engineering is characterized by multiple crises and surprises, sometime stacking up on top of each other. Building a sustainable and scalable engineering team requires that the engineering manager learn to get results through his colleagues and resist the temptation to solve every problem himself. We all love heroes, and love being a hero, but if it happens too often it indicates a deeper set of problems.