There’s a very short list of new manager “must do’s” in the Rands Management Rule Book. The brevity of this list comes from the fact that a must is an absolute and when it comes to people, there are very few absolutes. A clever way to manage one person is a disaster when applied to another. This makes the first item on the Management Must-Do List:

Stay flexible.

The only constant in management is that believing you’ve seen it all is a bad idea. Staying flexible is the only stance to adopt when constant change is the only constant.

Paradoxically, the second item on the list is surprisingly inflexible and it’s still a personal favorite of mine because I believe it helps set the stage for management growth. It reads:

Stop coding.

The theory is this: if you want to be a manager, you must learn to trust those who work for you to take care of the job of coding. This advice can be hard to digest, especially for new managers. It’s likely that one of the reasons they became managers is due to their productive developers, and their first reaction when things go to crap is to revert to the skills that built up their confidence. That’s writing code.

When I see a new manager fall back to coding, I tell the manager, “I know you can code. The question is, can you manage? You’re no longer responsible for yourself, you’re responsible for the team, and I want to see you figure out how to get the team to solve this problem without you coding. Your job is to figure out how to get yourself to scale. I want lots of you, not just one.”

Good advice, huh? Scale, management, and responsibility. Very buzzword compliant. Too bad I’m wrong.

Wrong?

Yup. Wrong. Not totally, but enough that I might need to make some calls to past co-workers and apologize. “That not coding pitch of mine? Wrong. Yeah. Start programming again. Start with Python or Ruby. Yeah. I mean it. Your career depends on it.”

When I began my career as a developer at Borland, I was part of the Paradox for Windows team and this was a big one. Just on the application development team, we had 13 developers. If you included the heads from the various other teams who provided essential technology like the core database engine, graphing engine, and core application services, you’re talking 50 engineers directly contributing to the product.

No team that I’ve been on since then has even been close in terms of size. In fact, with each passing year, the size of the engineering teams contributing to my products has steadily shrunk. What’s going on? Are we getting collectively smarter as developers? Nope, we’re just distributing the load.

What have we, as developers, been doing for the past 20 years? Well, we’ve been writing a crapload of code. Piles of it. So much of it that we decided that maybe it was a good idea to make it easy to share by open sourcing it. Thankfully the Internet showed up which made this sharing trivial. If you’re a developer, try this right now. Go search Google Code¹ for your name and find some code you forgot about that everyone can see. Scary, huh? Didn’t think your code lived forever. It does.

Code lives forever. Good code not only lives, it grows as those who value it make sure that it doesn’t become stale. It’s this pile of high-value, well-maintained code that is helping shrink the average size of the engineering team because it’s allowing us to focus less on writing new code and more on integrating existing code to get the job done with fewer people and in less time.

There’s a depressing line of reasoning here, the idea that we’re all just a bunch of integration automatons using duct tape to connect different pre-existing moving parts to create slightly different versions of the same thing. It’s this train of thought that has a lot of senior management teams excited about outsourcing. “Anyone who can use Google and has some duct tape can do this, so why are we paying big bucks for our local automatons?”

We’re paying these management types some pretty big bucks to think this crap up. Still, it brings up my final point that there are eager, bright developers all over the planet and they’re eager and bright even though they haven’t spent a moment in an accredited university. Oh yeah, and there are lots more of them coming.

I’m not suggesting that you should be worried about your job because some bright fellow overseas is gunning for you, I’m suggesting that you should be worried about your job because the evolution of how software development occurs might be moving faster than you. You’ve been working for ten years in your job, five years as a manager, and you’re thinking, “I know how to develop software”. And you do. Right now.

Stop Coding?

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.

You have issues. I understand. Let’s hear them.

“Rands, I’m on the Director track and if I keep coding no one is going to think I can scale.”

My first question to you is this: from where you are sitting in your soon-to-be-Director chair, do you see software development changing within your company? If the answer is yes, my next question is: how is it changing, and what are you going to do about it? If your answer is no, then you need to move your chair because, I swear to you, software development is changing right this second. How in the world are you going to scale if you’re slowly forgetting how software is made?

My advice is not that you start assigning yourself tons of features in the next release. My advice is that you take action so that you stay in touch with how your team builds stuff. You can do this as a Director or a VP. More on this in a moment.

“Uh, Rands, someone has to referee. Someone has to have the vision. If I code, I’m going to lose perspective on my job.”

You still need to referee, you still need to massage decisions, and you still need to spend 30 minutes every Monday morning walking around the block four times with that engineer who needs to walk through his weekly “We’re Doomed” rant, but you also need to lose perspective about your job and you do not need to be a full-time coder to do this.

My advice for losing perspective:

1) Use the development environment to build the product. This means you must be familiar with your team’s tools including the build system, version control, and programming language. This task is going to keep you in touch with the language your team uses to talk about how they get stuff done. And it will also allow you to continue to use your favorite text editor… which rocks.

2) Be able to draw a detailed architectural diagram describing your product on any whiteboard at any time. I’m not talking about the three boxes and two arrows versions. You need to know the detailed one, the hard one that isn’t pretty and is tricky to explain. This is your map for understanding just about everything about your product. It changes over time and you should be able to understand why those changes are occurring.

3) Own a feature. I’m literally cringing as I write this because it is fraught with danger, but I don’t think you can really do #1 or #2 without a feature that is yours. Owning a feature not only forces you to actively participate in the development process, it also switches your context from “Manager responsible for everything” to “Person who owns a thing”. This is a humble, unassuming perspective which will remind you of the importance of small decisions.

I’m still cringing. Someone is already yelling at me, “MANAGERS OWNING FEATURES??!?!” (And I agree.) You are still a manager, so make it a small feature, ok? You’ve still got a lot to do. If you can’t imagine owning a feature, my backup advice is to fix some bugs. You won’t get the joy of ownership, but you’ll gain an understanding of the construction of the product that you’ll never get walking the hallway.

4) Write a test script. I still do this late in the product cycle when folks are losing their minds. This is a simple script that you run with each build. Think of it as your checklist for understanding what your product does. Show it to co-workers. Do it often.

“Rands, if I code, I’m going to confuse my team. They’re not going to know if I’m a manager or a developer.”

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.

Besides, you want to be a part of a team of interchangeable parts. Not only does this make your team more nimble, it presents each person with the opportunity to see the product and the company from a vastly different perspective. How much more are you going to respect quiet Frank the Build Guy when you see the simple elegance of his build scripts?

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 that you’ll be closer to your team. But, more importantly, you’ll be closer to how software development is constantly changing in your organization.

One Absolute

A co-worker at Borland once gently and firmly corrected me when I called her a coder.

“Rands, a coder is a mindless machine. A monkey. A coder does nothing relevant except lay down boring lines of useless code. I am a software developer.”

She was right and she would’ve hated my advice for new managers to stop coding. Not because I was suggesting that they were coders, but more that I was proactively telling them to start ignoring one of the most important parts of their jobs: software development.

So, I’ve revised my advice. You can stop coding, but…

Stay flexible and don’t stop developing.