This draft was originally made on September 18th, 2018, and contains nothing but the title. So what was it that I wanted to say about managers in software? I suppose some of it may have been covered in the article I’ve done since on Politicians vs entrepeneurs.
But I think this may be more related to a point I made in an earlier article:
The way I see it, there are two types of architects:
- The architect who designs the system upfront, documents it, and then passes on the designs to the team of engineers that build it.
- The architect who works as an active member of the team of engineers building the system
I think a similar rough binary division can be made with (project) managers in software:
- Managers with a background in management
- Managers with a background in software development, or at least a closely related field of engineering
I have found that in practice, you will run into type 1 more often. I suppose that is because there are more managers of this type, and they are cheaper to hire.
Related to this, I suppose you can also have a rough binary division of how to manage a team/project. There are a number of stakeholders, and the manager will be a linking pin between them. Roughly you’d have the upper management (to which the manager reports), the client and the team.
- The manager considers himself a representative of upper management and the client, and negotiates on their behalf with the team
- The manager considers himself part of the team, and negotiates with the upper management and client as a representative of the team
Now these management approaches tend to overlap strongly with the manager types. The reason for that is probably that without a technical background it is difficult to actually be a part of the team, as you will only superficially understand the technical details. It’s just ‘safer’ to try and please management and the client. Firstly because you understand the project better at their level, and secondly because it’s straightforward to just try and deliver the goals that they set.
However, that means you are working inside the limitations set by upper management and the client. In order to get the full potential out of your team, and thereby the developed product, you really need to get the team’s input. Allow them to signal potential roadblocks early, and allow them to suggest alternative solutions. In the end, it will just come down to upper management wanting to get the best possible return on investment, and the client to get the best possible solution to their problem.
So that is what a manager should try to do: look at the bigger picture, because upper management and clients often think they know what they want, but their ideas are rarely the best possible solutions to what they want. So with a talented and inspired team, you can usually think outside the box and suggest better ideas. The key is to show upper management and the client that the solution is better than the one they were expecting. That should convince them, as it gives them what they want, even more and better than what they were expecting.
In turn, the team is also more happy because they can give valuable input and develop solutions that they believe in, rather than just going through the motions, and doing what others order them to do, knowing it’s not going to result in the best product they could have made.
Scali's OpenBlog™ 