Many of you gasped at the title of this post:
“Become a manager? Has he lost his mind?! I’ll be a coder ’til the day I die!”
I’m not implying that you should give up your coding gloves and step into the ranks of full-time management, but you gain incredible perspective about what makes good and bad developers once you’ve managed a few of them. Even if you never become a full-fledged supervisor, managing a project, being a technical lead, or running your own business are all suitable ways to experience what makes a “better” developer from a different angle.
Before working in software I was a project manager for a large electrical contractor in the bay area. So naturally, when I began my technology career, I quickly moved from writing software to leading projects and managing other developers. Over the next few years I continued to function as a lead/PM until I became the manager of 10 DBAs and developers for the City of Pasadena. And let me tell you, I learned more about what makes a good developer from a management perspective in my short tenure at the City, than in the previous two or three working as a consultant.
Lesson #1: What Makes Someone the Best
One of the first things you’ll learn is who your best developers are and why. And it’s not what you think; often times it’s not the most technically savvy person in a group, rather it’s the one who’s able to make things work with the least amount of management intervention. If you think you have a lot of things to worry about, your manager has to put up with 5 or 10 times more context switches than you do. And when your most critical asset is time, someone who may not be the end-all be-all of personality or technical ability, but who’s able to do a lot of coding without bothering you every few minutes, that developer is worth his weight in platinum.
Lesson #2: It’s Easy to Complain about Your Boss Until You Have to Do His Job
I can’t tell you the shock I felt when I realized for the first time that as a manager the success or failure of a project didn’t rest solely in my hands. The project’s success, and ultimately my success, rested in the hands of programmers whom I had to motivate, work with to ensure they were building the correct software to our development standards, all the while being told by customers and management that we should be doing it faster, for less money, and with less people. It was a horrendous tug-of-war with me in the middle.
In software, as in business, every decision is a compromise. If you’re on the losing end of that compromise it’s easy to complain that the person made a bad decision. For the most part, unless you have an evil boss, she is trying to make the best decisions she can. Trust me, someone who makes a compromise is better than someone who makes no decision at all.
Lesson #3: How to Self-Manage
As a supervisor you can’t get any work done unless your developers learn to be self-sufficient. A large portion of your time should be spent putting out fires (since there are always ample fires to fight), not performing basic developer-related tasks (“For the hundredth time, we use i for our For-Loop variable, not j!”). So as a developer, if you can make something work while bothering your boss even one less time per day, you’re taking a huge burden from his shoulders.
Lesson #4: Do What It Takes to Achieve Results
I’m not an advocate of an unhealthy lifestyle, in fact I’m the guy who takes three week vacations to Africa, but one of the facts of our industry is that there are times when it’s necessary to work overtime. Do what it takes to hit the deadline; don’t make your boss ask you, or worse, order you to stay late. As a developer you can read the writing on the wall and should know well in advance when you need to tell your spouse you’ll be late for dinner. (Note: Some managers even obtain an online MBA to improve their management skill set.)
When it comes time to play, show up and get the job done.
Lesson #5: No Surprises
Surprises are never a good thing in the business world.
I remember being told the day before launch that we weren’t going to hit the deadline. I asked how long they’d known about it and they said a week and a half. Ugh.
If your boss doesn’t require email updates, drop her a 1 or 2 sentence email twice a week letting her know what you did over the last few days and how things are going. I bet it will become standard practice for the entire group. “Pushing” information is a big help when trying to manage many people, and it helps eliminate surprises. Don’t be afraid to share bad news. Bad news in advance is 10-times better than bad news the day everyone else hears about it.
Walk a Mile in My Shoes
Even if you never become a manager, try to walk a mile in your boss’s shoes once in a while. It won’t take long to realize how much you can learn from looking at your job from a different perspective.