Tech Life Too bad I'm wrong


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.


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 Code1 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.”


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.

  1. This doesn’t work anymore. I’m sad. 

9 Responses

  1. Avish 17 years ago

    I sincerely agree (being an extremely new manager who didn’t stop developing).

    Also, if your managing position doesn’t allow you to continue developing, open source software is always there, waiting quietly for you to dive into it in your free time. True, you lose touch with your software, but at least you don’t lose touch with software development.

    I did that when I couldn’t code on my own project and it kept me sane – and taught me a few things about devving, so when I came back I had some loot to share with the others.

  2. zorkerman 17 years ago

    Do you have any manager trainees in Austin? Do they need employees?

  3. Thanks Rands, I’ve been asking myself those questions for a while now. I’m more of a co-ordinator than a manager, but I end up doing a lot of the tasks that people people ascribe to ‘Manager’. Having a fimiliarity with the innards of the project without burying myself in them has definitely been helpful.

  4. arteebee 17 years ago

    I hear where you’re coming from. But I think it is very dangerous advice.

    If you assume that people, especially new managers have way too much to do, and not nearly enough time to do it in…

    And if you assume that when people are overloaded and stressed, they fall back to doing what they know best, what they are most comfortable doing…

    And if you assume that what former programmers/new managers know best and are most comfortable doing is writing code, not managing their team…

    … then you have a real recipe for trouble. I am thinking of one high-profile developent team where I work that promoted engineers into managers, and each time the manager attempted to continue being an active programmer on the team as well, and each time the attempt at management ended horrifically. I saw this happen three times in a row. In at least two of the cases, the “failed manager” went on to become very successful engineering managers with other teams. With no coding responsibilities.

    Trying to balance both at the same time can be done, but it’s a huge challenge. More than most first-time managers can handle, I would guess.

  5. Thejesh GN 17 years ago

    Thanks for the article. It boosted my confidence.

  6. James Martin 17 years ago

    Brilliant. This is the first time since I began down the “management” track that I’ve actually felt someone else understands my reasoning for poking around in the build system, fixing up the regression suite and grabbing hold of the occasional bug and providing a patch.

    If nothing else, staying in touch with my inner-developer makes me feel like I’m still doing the thing that made me love this business in the first place: What other industry provides you a blank canvas for solving interesting problems?

  7. Man Ager 17 years ago

    I agree with Rands that the software development world is changing but since that’s always been true, I don’t find it a a compelling enough reason on its own to keep dirty.

    Other reasons to keep your hands dirty include:

    1. Respect from the great developers on your team. The incompetent ones won’t like it but the great ones will. Of course, I’m assuming you’re also a great developer for if you are not, then don’t bother trying to be dirty as it will pay off only in derision.

    2. It takes one to know one. Think about how you hire great developers. If you weren’t one yourself with current skills and experience how could you get a) respect as above b) ask the questions you need to know that you’ve got a live one and c) be able to correct for dysfunctional team interviews (you know, where you rely on your team to screen candidates yet losers make it through the process anyway because everyone thought that someone else was asking the hard questions) and d) be able to paint an accurate picture for candidates on what is really going on and what real-world expectations are and finally e) be able to competently back-fill yourself or via hiring when your best developer(s) decide to do something new.

    3. You really can’t judge the quality of the work unless you really understand it. Think about staff reviews for a moment. There’s little moral stance to review a developer if you can’t judge them as an equal or superior.

    4. Your junior people need to know that they can aspire to something larger and still remain engaged and interested in the details.

    5. You might change jobs in the future and be expected to a) pass interviews b) create.

    Happy dirt.

  8. You’d mentioned it was depressing to think that more code reuse leads to “… we’re all just a bunch of integration automatons using duct tape…”.

    But my experience, and what we’ve seen in how people use code search, is mostly the opposite. The best analogy I can think of is the difference between a modern surgeon’s precise cut at exactly the right location, when compared to some medieval barber whacking off an arm.

    Most programmers can, given enough time, motivation and caffeine, wind up coding a solution to a problem. It takes a higher level of skill to figure out the true essence of what needs to be created, then find (and more importantly evaluation) what’s out there that might help, understand integration issues, and then cleanly graft the right piece of existing code into the correct location.

    So I see code reuse as both rewarding more skilled and experienced developers, while freeing them to focus on the truely challenging coding problems.

    — Ken

  9. I couldn’t agree more — and I’ve been giving many reasons why a technical manager in software developments should “keep his/her hands dirty” in my talks. I’ll be cribbing some things from this thread in future talks (including the tutorial on the subject that I’m scheduled to give at OSCON’07:-).