Michael Lopp's book Managing Humans has a classy introduction done with an elegant use of pictures. Besides it's elegant front cover and a classy promotional web-site, what I particularly like about the book is the keep-your-feet-on-the-ground tone filled with humility that resonates throughout the book as you read it.
For a book which is supposed to teach young and budding managers to how Manage Humans and not just develop your coding skills, Michael's advice to young managers, that they should continue coding even after becoming managers, comes as a pleasant surprise.
|
If you follow my advice and remove yourself from the code, then you are removing yourself from the act of creation. This act is why I don’t really sweat outsourcing. Automatons don’t build, they process. While good process can save a lot of money, it’s not going to bring anything new to the world. With smaller teams doing more for less, removing yourself from the code strikes me as a bad career move. Even in a monstrous company laden with policy,process, and politics, you can’t forget how to develop software. And how to develop software is changing. Now. Right under your feet, this very second. |
Michael, in his book, seems to address multiple concerns budding managers have when continuing to write code for a small part of the day after they get their first promotion to a managerial role. Of all these concerns, he addresses the concern that managers who write code end up confusing their team and make the team wonder if they are a managers on a developer, rather elegantly:
|
Good. I mean it. I’m happy you’re about to confuse your team by swimming in the developer pool. The simple fact is that well-defined roles in software development are fading. User interface guys are doing what can only be called development in JavaScript and CSS. Developers are learning more about interaction design. Everybody is talking to everybody else and they’re learning from each other’s mistakes, stealing each other’s code, and there is no reason that a manager shouldn’t be participating in this massive global cross-pollination information cluster-fuck. |
As a part of my day job I interview countless budding-managers who stopped writing code at the very first opportunity they got. These are folks who have barely been promoted for less than a couple of years and they decided to quit coding the day they got that promotion letter; even before they made it through leading a couple of successful projects or proved themselves as a very good people person or a decently acceptable manager. Talk to them for a few minutes in an interview and invariably the same story evolves:
Fred was desperately looking for a promotion. Fred 'somehow' managed to get promoted. Fred stopped writing code and locked himself in an ivory tower from where he looked down upon all who write code. Needless to say that Fred also started believing that his job role demands that he goes around the office with a lot of serious looking printouts of documents in his hands, suggesting everyone follow the processes he is laying out, asking everyone what the status of their task is and periodically yelling at developers to make them work harder.
So, at the first opportunity Fred got, he quit coding. He left it for good! After all he had to grow in his life and in order to do that it was really important that he stopped writing code all-together, right?
Wrong.
Steve Yege's advice for folks who desperately want to quit coding at the first management opportunity that they get is rather strong and direct:
|
If you want to manage badly enough, then you will manage, badly enough. Hence, before you jump in, stop and think about why you want it. Are you tired of engineering, or were you perhaps never very good at it? If so, technical management isn't much of an escape, because your engineers will know, and they won't respect you. |
Witting some code or participating and contributing actively in process of software development during the day, even if your organization expects you to just manage teams, has it's own set of advantages. Michael, in his book, advices managers on continuing to write code and having fun creating software even after they receive that promotion. Writing code and being actively involved with the project, Michael feels, can help managers communicate better with their teams:
|
I’m not wishing confusion and chaos on your team. I’m actually wishing better communication on it. My belief is that if you are building the product and touching the features, you’ll be closer to your team. But, more importantly, you’ll be closer to how software development is constantly changing in your organization. |
Jeff Atwood questions how important writing code really is:
|
Am I really telling developers to stop writing code? No, not really. Developers are already good at writing code. It's why they became software developers in the first place. Writing reams of code just digs you deeper into an already deeply specialized skill. What I am proposing is that we spend less time coding and more time developing skills in other areas that complement our coding skills. Become a better writer. Become a better speaker. Improve your personal skills. Participate in the community. Try to spend some time talking to people instead of the compiler. That's how you distinguish yourself from your peers. And that's ultimately how you become a better software developer, too. Of course, this isn't a zero-sum game. You can have it both ways. Ideally, you'd write code, and then write or talk about the code in a way that inspires and illuminates other people. But we don't have an infinite amount of time, either. If you have to choose between writing code and writing about code, remember which side of the equation is more important-- and balance accordingly. |
As much as it might sound that Jeff gives more importance to abilities that complement coding besides writing code, even Jeff seems to think that all these activities combine are largely useless if you are not playing active part in the process of creation:
|
But I refuse to become a full-time blogger. I think that's a cop-out. If I look at the people I respect most in the industry, the people I view as role models-- Paul Graham, Joel Spolsky, Steve Yegge, Eric Sink, Rich Skrenta, Marc Andreesen, Wil Shipley, Douglas Crockford, Scott Guthrie-- they all have one thing in common. They're not just excellent writers and communicators. They build stuff, too. The world has enough vapid commentary blogs. I want to build stuff-- and talk about it. |
Writing a little bit of code also acts as a good reality check on how good at building software you really are. I've often said that the confusion and turmoil in our profession makes writing software very similar to fighting a war. If you're going to learn the art of leading an army in a war why not learn it from some of the best warriors in history:
|
Alexander was very much war oriented and therefore did not put off his battles to marry and have children, even though this would leave the kingdom without a ruler in the event of his death. He was much more concerned with his fame than with what would happen to his empire should he be killed. As a general and leader Alexander was closely involved with his wars and his men. Unlike most generals or rulers he did not stay on the defensive side of his assault to ensure his safety but rather joined his men and led them on attacks. |
Let's face it. While fighting a war things are bound to get ugly. If you're not prepared to go out there and take a few shots yourself do you really expect your team to follow you and help you through the difficult times?
Even if you don't write code that runs on production, at-least participate in some form of supportive activity in the project and own a task. If nothing else, write a few unit tests to help your team improve the quality of what they are building. If you're not supposed to code actively in your project, start a small open source project and continue to hone your coding skills there.
Bottom line: Do whatever it takes to make sure that you're speaking the same language as the rest of your development team and not mangementese.
If you're a budding manager who's just got his own team to lead (not manage), a brand new project to run and if you're wondering whether you should stop writing code completely and just focus on your managerial skills, here's my advice to you: don't even think about it.
Remember, how to develop software is changing. Now. Right under your feet, this very second. And it might be changing very silently and subtly but it's changing faster than most of us think. If you're going to lead really smart software development teams, not spending at-least a few minutes a day writing code and failing to learn how software development is changing and evolving can be the single most devastating thing for your career.
Sure, learn how to manage humans and how to write about code besides writing code. I've myself advised individuals to turn themselves into a one man army. But even as you learn these other skills, don't forget to dedicate a few minutes a day to the bits and bytes when you roll your sleeves and write better code than what you wrote yesterday. Remember, at the end of the day Gant charts and CMM won't get your projects done or make you successful. Your own competency, your team's competency and your and your team's collective knowledge of how software development is changing and evolving will.
Some of the best managers I've worked with are folks who have rolled their sleeves and helped me 'on the field' when I was fighting with learning a new technology at a client's office. They've joined me in the battlefield and fought side by side with me. Quite literally. Other's have gone out and taken care of doing requirement sessions with the clients and writing and formatting use-case documents when we were running short of business analysts.
Quite a few of them have owned modules of code while I've also seen a few of them relentlessly tweaking HTML or giving ideas on usability and end user experience of the applications. Yes, I've been perpetually confused about whether they are Managers, HTML writers, Business Analysts, Mentors or Developers; But none the less, I've enjoyed working with them as much as I enjoy working with a smart bunch of developers.
So you got your promotion and your business card now reads 'Project Manager', Eh? Good.
Now go ahead, open that IDE and write some code Mr. Manager. It's nothing to be ashamed of. On the contrary, it's something to feel proud about. Seriously.
Comments are closed.