Who Should Decide on Implementation Details?

There seems to be different positions in this matter. There are people that think that IT Management should have final say in these matters and people that are convinced that once the general specifications for the architecture and methodology are laid out, the development team (or the development leadership) should follow with the decision on how to implement the solution. While some people will argue to death one way there are people who will argue to death the other way. I say: It depends!

According to SDLC methodology; the feasibility study/discovery phase/analysis will tell us "what" needs to be done. The "what" is comprised of all business requirements gathered in this phase; the scope of the project and any constraints that we may find as determined by the business areas and listed by the Analysts.

The design phase will determine high level "how", or the technical architecture, the system model, and the test conditions. This is where the second group of people mentioned above decide to stop making decisions. The reason they claim for this is well founded and refers to the fact that they may not know the technical details of how to move forward with the next phase or that they will leave the decisions of the next phase to the people that know them much better than them: the development team leads or even the developers. This is a reasonable stopping point for IT management, but sometimes there will be conflicts.

The development phase is where all the programming happens. The final "how" to implement a solution happens at this point. All the technical details and minutiae are implemented here. Unfortunately this is the exact point of disagreement between both groups of people and the first one will suggest that because they are well versed in technical matters and they have seniority, they should have final say in the details being implemented in this phase. While the most novice developers would appreciate some direction from their management/mentors, the most experienced would prefer to be allowed to make those decisions themselves.

While both positions seem to make sense; it is my opinion that each case would be appropriate if certain conditions are met. The obvious examples are:

  • For IT management with technical expertise; novice development teams require more leadership participation if they are well versed in technical matters.
  • For IT management with technical expertise; experienced development teams and experienced development leaders can be left to operate under their own judgment with little supervision if they show good judgment. Experienced developers that show good judgment will know when to ask for clarification to their management.
  • Non-technical management should try not to get involved with the detailed technical decisions.

So far it can be seen that both positions seem to be correct and could coexist without problems. However; not all IT managers are conscious of their technical limitations, and some are even convinced that they are just as good a developer as anyone in their development team. While most IT managers have a strong technical background, not all have been keeping up with the latest technologies and methodologies. Having a strong technical background creates a false sense of security regarding one’s technical skills. Managers who are no longer keeping up with technical issues may fall prey to this false sense of security and may not even be conscious of their situation. On the other hand; a technically savvy manager would keep up with technical expertise and would participate as part of the development team. An IT manager would know how much participation he should provide as part of the development team. Too much and the administrative portion of the management duties will be left unattended. IT managers participation in the development team’s duties is a double edged sword: while technically savvy IT managers may gain their developers respect by doing this; technically challenged IT managers may lose the respect of their development team if they make too many bad technical decisions.

Suggesting and ordering to make a particular technical decision are two completely different things. Managers who are not conscious of how up to par they are will create conflicts if they force developers to implement the wrong technical decision into code or to implement their code in a way that is not technically correct.

Developers may know what and how it needs to be done, they may even raise the issue to their managers; but some IT managers, too mistrusting of their team or not fully aware of all the technical implications may choose the wrong option which unfortunately makes them bad managers no matter how they see it.

I am not saying that all developers should have a confrontational attitude. But if you feel that the wrong technical decision is made, it is the developer’s responsibility to raise the issue and get the technical issue resolved before it becomes too costly to fix. By the same token; I am not saying that all managers should stay out of the developers way, quite the contrary, their suggestion will most likely be received with gratitude when given as a solution to resolve the right technical issue. Even if an IT manager is technically savvy, they should still know when to stand on the sidelines and let their team shine by letting them make those decisions. The result will shine back on the manager. As mentioned above, these two positions can coexist depending on when it is appropriate to take one stance or the other.

There are several morals to this story:

  • IT managers should keep up with technical developments.
  • IT managers should keep an open mind and at the very least research appropriately when their senior developers raise a question on their technical decisions. These situations should also be used as a flag for the manager to get the appropriate technical update.
  • There is nothing wrong when a developer knows more than an IT manager about a subject, use this as an opportunity for learning from the developer.
  • Developers should try to raise the technical issue in the appropriate manner, otherwise they may not be taken seriously.
  • Last and foremost: IT managers should be open-minded and humble enough to know that there is always something new to learn from someone else, even if they are the new guy with little or no experience at all.

About Diego Samuilov

Editor in Chief/Founder Diego Samuilov is an executive, consultant, IT strategist and book, e-book and web published author. Diego has worked in Microsoft’s environments since 1990. Since then, he has successfully filled many positions related to the Software Development lifecycle. Having worked as a developer, analyst, technical lead, project lead, auditor and, since 1996 a project manager, manager, director and VP in the Software Development, Server, Desktop and Mobile environments. Diego is very passionate about the software development process, which has played a great part in his skills development. Since the introduction of the first ever PDA (the Apple Newton MessagePad) in 1994 and Windows CE in 1998 he has pioneered and pushed the envelope in the field of mobile software development. He has developed many solutions used in mobile markets, desktop and server environments. He participates in public and private developer community events. He actively collaborates with the community at support forums and blogs. Diego is the author of "Windows Phone for Everyone" available [HERE].