The Three Golden Rules Of Engineering Management

I have been managing Software Engineers for a little over 24 years now and I can honestly say that what I have learned can be broken down into three basic rules …

(1) The Engineers Don't Work for Me, I Work for Them.
I remove blockages. My job is not to control the Engineers, it is to get them operating at peak efficiency so I can get my job done on time. My job is to get the Engineers the tools and knowledge necessary for them to excel. My job is to hold all Engineers accountable for the work scope estimates they give for various use-cases. Once an Engineer, the Product Manager and myself agree a use-case is well understood and an estimate can be given (and this means all reasonable questions posed by the Engineer who will do the work [an important distinction] and myself have been answered by Product [which itself is a bone of contention between Product and Engineering]) I need to make sure said estimate is reasonable (some times Engineers need to be saved from themselves, they often think more highly of themselves then they should) and then met.

(2) A Happy Engineer is a Productive Engineer.
Engineers are typically bright, conscientious people. They want to feel like they accomplished something great today and got paid reasonably well for it. They tend to realize a stable work environment holds value and so they are often reasonable regarding the trade-offs between stability, interesting work and compensation, but rule number one when managing Engineers is you can't bore a good Engineer to death and expect them to be productive. Good Engineers want a real challenge every day. Challenges which result in software people actually use is really reward enough for a good Engineer.

(3) Happy Engineers like Exact Specifications and Dislike Micromanagement.
The establishment of a periodic release cycle requires a user-story to use-case interaction between the Engineering and Product functions within an organization. Additionally, the Engineers need to provide work scope estimates at the use-case level, no lower. Further division into hourly tasks and the attempt to manage at that microscopic a level with good Engineers is counter-productive. The user-story to use-case process which must be done in a collaborative manner between Product and Development is always contentious. The initial set of use-cases will often prove inadequate regardless of how many hours the two sides spend in collaboration. At some point they will need to give in to each other and "do the best they can" for a first release. The establishment early on in the project of a document trail which chronicles what Product thought it was asking for (and associated dates), coupled with an Engineering log which describes what Engineering thought it was being asked to do (also including associated dates), often aids in post-mortem analysis.