Performance reviews season being in full swing, got me thinking about role of managers in it, expectations from Individual Contributor's (IC) side, distinguishing good and bad managers, and "management" in general.
As developers, we like to have shortest feedback loop possible. If code doesn't compile, you can see the error immediately. If it doesn't pass the test, you can quickly see what part needs to be changed. When there's a possibility that business logic (especially in some corner case) is incorrect, much more time will pass before error will be noticed and fixed.
Each increase in "scope" of work increases feedback loop as well. While some error in code will probably uncover itself quite quickly, problem in architecture has a high chance of being unnoticed until product will become more popular, and would need to scale (and that's actually a good problem to have, but it's even better if developer thought about that possibility in advance, and architecture is scalable in the first place).
The higher the level, the longer the feedback loop is. If manager doesn't make a broad swing, radically changing lots of things at once, and the situation is not perceived as being absolutely awful when new manager comes - chances are changes won't be obvious for some time. Slightly adjusting processes, setting up stronger relations with "neighbouring" teams, insulating team from direct (and often unreasonable) demands from other managers (often higher in the chain of command) - all this things may not be immediately evident for the team, but would improve their life in the long run.
Another thing making it harder for the ICs in the team to "evaluate" their manager is lack of visibility on "levers" available to managers. Some thing can be quite easily changed on a team level, while others are really set in stone on a company level. In one Q&A with manager that was quite "high" on the ladder he was asked about certain evaluation "criteria" that was perceived by ICs as being applicable only in rare cases, and otherwise doing more harm then good. Reponse from manager was that he tried changing that, but after pushing for changes for several months, received a response that "it's intended to be so" - so "it's a feature, not a bug". While it was considered exactly as a "bug" by most ICs.
Last point that makes it harder to evaluate changes in work environment, their usefulnes, and - indirectly - "quality" of managers that inroduced those changes - is Hawthorne effect. You can read it in detail via the link, but what it causes is basically changes might be perceived as improval in working conditions, regardless if results / productivity actually improved or not. Hence it's very hard to understand how change affected productivity - is the change actually for the better, or it's just change for the sake of change. That makes evaluation not only of managers, but processes in general complicated - you not only have to find some objective measures of team's performance (hopefully it's not lines of code or merged PRs), but also to understand what changes actually made the difference.
Comments