I have worked for several heads of development. All were good people. All managed differently. Some were curt, some loyal, some inclusive, and some neglectful. I have learned much from working with them. Here is some of what I have learned.
A healthy development organization is one that has
- Staff with a range and overlap of skills & experiences.
- Work that is finished when all steps are complete.
- Communication is balanced between structured & unstructured.
- Achievements are celebrated.
In a larger organization these points are easier to achieve, but even a small organization must position itself to attain them.
You need to have a staff with a range of skills & experience and without large gaps in either. For example, having three junior developers and an architect is not healthy. Beyond the one bus problem is the problem that the larger the gap the more likely the organization will create a implementation that is of irregular consistency. Consistency enables an organization to potentially use many more of its staff to resolve bugs and add improvements. You don't want to have anyone say "Andrew wrote that. I don't touch it without his input."
The work of a software product is not just code. We all know that, but the pressure to release the implementation alone is great. I am a firm advocate in documentation and testing. Testing is easier for developers to accept as it is a channel for more coding; coding is something they want to get good at and enjoy doing it even when the effort is going badly. Getting development documentation written is an uphill struggle.
I have only ever worked at one organization where developers prepared documentation without acrimony and that was the CASE company Cadre. I was an apprentice programmer at the time and ready to accept, without question, everything I learned there. I have since come to be more selective, but the importance of documentation has remained. Documentation is a part of my third point about communications. Communications includes all its in-person and online forms. Communication is about coming to a common understanding and then achieving consensus.
A software project has a product goal and an implementation goal. The product's goal, ie having an implementation that works, is the easy part of software development. Having an implementation that the development organization can support is much harder. The initial expression of the implementation is not code, but a written design. This written design might only consist of a few diagrams and an enumeration of constraints and problem areas, but having it written down means that someone made the effort to attain a comprehensive grasp of the product implementation and to communicate it to others. From that the development staff can begin to come to a common understanding. There are other documentation needs, but for now, lets start with an upfront design!
My last point is one coders and heads of development publicly dismiss, even belittle, but privately value when it is done well. So much of a developer's work is unseen. The reviewer finds problems. Who finds successes? (We don't even have a title for such a role!) Developers want others to know about their trials (their stories), and for their accomplishments and improvements to be acknowledged. None of this is needed for the product. All of this is needed for a healthy development organization.
 I am going to use the term software development and not software engineering. My ego is buffed by the engineering term, but, frankly, software development is far from an engineering discipline as the term is used in other inventive organizations. Our work is, with the best of meanings, craft.