Any nontrivial programming solution is a group effort, divided into tasks that can be done (eventually) individually. In other words, task division and keeping track of work accomplishment is a major requirement for making successful software. Normally the responsible for managing the tasks and for managing the work plan is the project manager / development manager. In contrast, the system engineer is responsible for the architecture, the requirements and the quality of the solution. This causes conflicts of interest.
The conflict between the system engineer and the development manager are inherent by design, creating a feedback loop for managing quality vs. effort. In turn, the conflict also generates interpersonal stresses on top of the stresses described above.
Include also the fact that the design is a limiting factor for the developer and you have a mix of stresses very difficult to manage.
There are several methods for handling this stress, depending on the situation an people involved, can have different degree of success.
- Use authority – since the system engineer is responsible of the quality, there is a large pressure for delivering a good product. This method rarely works, as the manager might have the same clout.
- Use meetings as joint decisions – Since meeting seem as a place for sharing ideas, one might argue that also decisions take place in meeting, but unfortunately this is not the case.
- Have one on one design sessions – This is a method that often works because the development manager has normally quite interesting experience and can provide insights on the design. Often, the joint design is adopted by the manager, and can be much more easily sold to the rest of the programmers.
In spite the design is a limiting factor, to help everybody work together, there should be enough freedom for the developer to leverage its initiatives. This is more cultural than general, but in the companies I like to work the programmer is supposed to provide more than line of codes, but be creative and think of ways to improve the overall solution. On the other hand, the developer must adhere to the guidelines and architecture. It’s a bit like having a herd of cats you need to keep them not leaving the guarded zone.
Keeping the right mix of personal touch and rigid structure can help everybody get along together and be in a productive and fun work environment.
If you read this far, you should follow me on twitter here.
Incoming search terms:
- herding stray cats