Who hasn’t heard stories about managers who don’t have a clue what their engineers, architects or quality officers are trying to achieve? And who has tried to go over their manager’s head to try and fix the problem that way? Out of frustration, or to strenghten their own position, like this lady? I know I did, on a few occasions, and in one case I actually did it - be it without much success.
Earlier this week I was talking to an system architect and friend, working at a high tech electronics company. He’s running into something that is related, and that I have experienced in the past as well - something which we agreed could be called ‘authority inversion’.
The issue with going over your boss’s head is that you contact his boss (substitute manager if you don’t like the word boss), to get support for your ideas and have your boss instructed to implement them. Not a very decent thing to do, unless your relation with the person in question is really screwed up. In the case we were discussing, a similar thing happens, but with architects instead of managers. When engineers, regardless of their core discipline like software engineering or electronisch engineering, become more experienced, they eventually get a promotion. They become designers, or architects and are assigned responsibility for technical quality and soundness of systems, or parts of systems, and for guiding other engineers in achieving that.
‘Guiding’ is the key word here: they have no formal authority, because they are not part of line or project management - in the end the project manager or the development manager is the one to make the final call. This is not necessarily a bad thing, these people have been assigned responsibility for time and budget while the designer or architect was not. However, it can become problematic when the deadline gets nearer and the team contains a few engineers who feel like doing things their own way. Unfortunately, every team of more than 5 people tends to have at least one of those. They do their job, and they are very good at it to a certain level, but they are allergic to making agreements on interface, showing concern for other people’s key interests and tend to focus on their key technical interests.
At some point, near the deadline of a project, the architect is confronted with choices made by these people that were not communicated or which they refused to reverse when communication was in place. At that point, the deadline is so close, as well as the end of the budget, that the architect’s arguments about long term quality guarantees are overruled for the sake of time-to-market and delivering-on-budget. This is what we agreed to call ‘authority inversion’: an architect or designer is asked to take responsibility for quality of design, and made a recognised authority in that area. Some of the members on the projects he works on do not go along with that, and in the end get their way in front of the project manager or line manager. ‘It works now, and it’s too expensive or too late to fix it. If it becomes a problem later on, others will deal with it’, is the final remark in a lot of cases.
Painful, for the architect, and painful for software or systems architecture as a discipline. There are still a lot of people who think we have a high tech industry that can sustain itself and it’s products by this way of working, who don’t believe we need requirements engineering, architecture or test management - but also not agile development or model driven development. As long as we have to deal with authority inversion as described here, we have a long way to go.
Just to make sure: this is not a rant against engineers, or meant to say they don’t believe in quality. Every engineer believes in quality, but not all of them see what is important for overall system quality, and that makes them dangerous when combined with ignorant managers.