It’s Not All Engineering
IT managers often begin their careers as engineers, problem solvers, and innovators. If you are a technical person who aspires to a management role you must learn to embrace and work with budget and priority constraints.
Some consider the term “manager” an epithet. For them, the term conjures images of a clueless boss—someone whose technical skills (if they ever existed) have atrophied while they fussed with spreadsheets and status reports. They see managers as impediments to work.
Done well, the role of manager in a modern IT organization is essential, but it can be a significant career and mind set change for someone used to solving technical problems as an individual contributor.
A recent conversation with a new manager reminded me how little some engineers understand the role and motivations of management. We were discussing how overworked this manager’s team was. They had recently lost a couple of staff and were scrambling to hire replacements and bring them up to speed. He was feeling a lot of pressure to sustain his team’s performance.
His team is responsible for a piece of middleware that acts as a traffic cop and message router for the exchange of data among several mission critical client systems. At present the interfaces use XML to package the data. One of the partners in the data exchange is replacing a system and the replacement uses JSON, a different format. The manager explained that changing over to JSON was probably a good strategic move for the whole organization and he was considering directing his team to convert all interfaces for all partners from XML to JSON.
I said, “I don’t have an informed opinion about whether XML or JSON is the right choice in the long term, but your team is stretched thin right now. What is the priority of this conversion and who is paying for it? How soon does this need to happen? Could the JSON conversion be delayed until next year?”
He grinned sheepishly, “I’m thinking like an engineer and not a manager. This is an interesting engineering issue and long-term, JSON may be a better solution, but it might be reasonable to ask the client to have their vendor create an XML interface for now, or perhaps we build a JSON to XML translator for that specific system so that we don’t have to make significant changes to the middleware and other client systems right now.”
That brief conversation sums up an important message. In most organizations there is tension between the “best” engineering solution to a problem and the resources and priorities of the organization. Managers and executives must remain aware of that tension and prepared to explore and recommend trade-offs.
People in engineering and technical disciplines like to solve problems, and it’s easy to lose sight of the larger organizational context when presented with a juicy technical challenge. Good managers and executives constantly ask, “Is this the best use of our resources right now?” The answer to that question can mean choosing sub-optimal solutions that can be implemented cheaply to partially solve a problem or delaying a solution altogether in support of higher priority needs.
Managers and engineers have different roles. Both roles are necessary. Neither is easy. If you aspire to management, recognize that this will be a lane change and you will need to cultivate a different perspective to do the job well. If you are an engineer and observe what appears to be a sub-optimal decision, it’s fair to ask (politely and possibly privately), “Why are we making this choice?” If you are a manager juggling competing priorities, it may improve team morale if you take the time to explain the rationale for your choices that don’t seem obvious to your engineers.
It isn’t that managers become evil or stop caring about good engineering when they are promoted, they just find themselves trying to reconcile multiple competing priorities with limited resources.
