It’s been three and a half years since I closed Sublime Text and entered the world of Outlook and PowerPoint. In a lot of ways management has been what I thought it would be. There are poltics. There are constant temptations to compromise for my benefit over the developers on my teams. There are boring budgeting and strategy meetings. There are e-mails. So. Many. E-mails.
Overall, however, management has, for me, been exactly what I set out for it to be at the beginning. I willfully entered management to be the manager I always wanted — and often needed — when I was a developer. I work hard to cut back bureaucracy, politics, and process from my teams. I look for ways to empower developers to self-lead and self-manage their craft. I strive to be there for developers when needed and be completely invisibile to them when I’m not.
I entered management thinking I’d be the lone developer amongst the MBAs fighting to make things better for my people. As it turns out, that isn’t the case. Yes, there are always a few sour grapes in the bunch, but on the whole my peers and superiors in IT have been on the same page as me. They, too, are fighting the good fight for the developers.
Developers, do you want to know what you’re managers are doing each and every day? Managers are fielding questions, concerns, and other fires from non-technical business folk. Some of these folk are well intentioned. Some of these folk are looking to place blame. Some of these folk are attempting to play political chess with IT as a pawn. In each e-mail, meeting, and call your manager is trying to parse the subcontext of what’s going on. She or he is trying to do her or his part to keep your team safe.
There are meetings that are nominally about one thing, but could quite possibly be about cutting IT budget; i.e. getting rid of developers. There are seemingly stupid support tickets that are actually about something much more. There are hallway conversations and lunches where your manager is marketing the team’s ideas and skills. There are long, long e-mail chains where your manager is stopping really bad ideas before they ever seen the light of day. There are series of meetings over months and months where your manager is working with the business to persuade them to see an innovative idea or a new way of doing something.
All of this work is, rightly, invisible to developers. Developers might hear of boring meetings or stressful personalities on the business or client side from time to time, but not much more. When your manager put aside solving problems through code she or he took on solving problems through listening, communicating, and persuasion. Let me let you in on a secret, computers are much easier to work with than people. People have no debug mode and aren’t exactly rational or deterministic.
I say all of this not to elevate the role of management or to play a sad song for managers on my tiny violin. Managers are well rewarded for what they do. I say all of this to let developers in on a little career growth secret that I wish I was aware of earlier in my career: show empathy to your manager.
Managers are not all powerful. Sometimes they cannot stop a bad process from happening. Sometimes they won’t be able to stop the client from asking to develop that really stupid project that you already know will fail. When that happens, show a little empathy for your managers. Let them know that you know they did all they could to prevent it and that even though this one got through, you are thankful for the many others that didn’t. Register your concerns about the situation. Share your thoughts on how things could be. And then, once you’ve done this, work with your manager to solve the current situation in a way that sets the foundation for a better future direction. This will put you in a special place in your manager’s mind, a good place for career growth.
You see, most developers don’t show empathy. They lecture management on how the business should work or how this or that person should act. The manager, of course, knows how things should be, but people aren’t computers and it isn’t just a matter of putting a reasoned, rational plan infront of everyone. Change is complex. Change takes time — and sometimes compromise. Developers who talk like this to their managers are talking about something they don’t truly understand. Developers who do this are adding stress and frustration to the very person working hard on their behalf.
Who do you think will get to be on the team for the cool new greenfield project starting up with an amazing product owner? Be the developer your managers can turn to for solutions, not complaints and pontificating.
