Management 5 Scenarios for High Velocity Engineering Managers

What To Do When You’re Screwed

Cabel Sasser of Panic dropped a shirt off with me shortly before my first presentation at WWDC.

panic rulez!For those of you still using Lynx, the shirt reads, “Hi, I make macintosh software.”

While Jimmy Eats World was ripping the tunes at the WWDC campus bash, I proudly wore the aforementioned shirt all over the campus. Co-workers quickly pointed out, “You don’t make software anymore… you tell others to make software.”

That’s right.

I do.

Let’s get started.

You’re a manager now. Congratulations. Either you sucked at programming and wanted to try a different influence avenue or you’re fed up with every other manager you’ve worked for and now you’re going to REALLY GOING TO SHOW US how it’s done.

I’m here to help.

Your first five years as a manager are going to be full of lessons galore. Lesson #1 begins the moment someone asks you a question and you realize they’re asking you not because you actually know the answer, but because the term manager is in your title and they’ll believe any reasonable answer. Some folks call that power, I call it responsibility.

There are other lessons, as well. There’s the big three: hire, fire, and layoff. All of those are a nice kick in the teeth that’ll be the source of significant insomnia. There’s the little stuff, too. You’ll find yourself saying “We” a lot. You’ll notice you’re repeating yourself… saying the exactly same thing to twelve different people. Some of it’s entertaining, some of it’s dull, but it none of it compares to when you’re Screwed.

The state of being screwed is unique. You know when things are going smoothly because you can arrive in the morning and quietly sip your hot beverage until your first meeting at 11am. Screwed is the opposite. Screwed is being accosted the moment you walk out of the elevator and being unable to even check your mail… until Winter.

Screwed is mental paralysis.

Screwed is career panic.

Screwed is also an opportunity to hit it out of the park. Overcoming screwed will give you confidence, experience, and respect, but you need to figure out how screwed you actually are and then figure out and how to fix it. If you aren’t interested in unscrewing yourself, I’d suggest this article is not for you. I’m assuming you have passion regarding your professional career. You want to do more. You want make more money and, if it all works out well, you want to change the world.

Maybe I haven’t been kicked in the shins enough, but it baffles me when I run into folks who are coasting through life. Doing the bare minimum to get by and… enjoying it? What exactly are you enjoying? Hey, maybe your day job isn’t your gig, but I like mine, so let’s begin:

#1) I’m Missing A Document and People are Yelling at Me

Screwedness: Low

Early on the product development process, everyone is talking about writing it down. Marketing specifications, engineering specifications… specs, specs, specs. Milestones are often constructed around these specifications, but, usually, these milestones come and go and no one really gets fussy about missing or incomplete specifications. That’s the good news.

The absence of a particular document really isn’t that relevant to your screwedness. The real question is “Who is asking for said specification and why?”

If the requestor is someone who has a legitimate need for the information, your potential screw-i-tude is high. Someone somewhere is not able to do their job and that means someone could fail in their work and that’s bad because they’re going to be pissed off and pointing at you.

A tip: Don’t confuse the request for information as a request for a complete answer. You completionists out there do this a lot. “I must answer the question thoroughly and completely; therefore, I must start by selecting a template for the information that best structures my response and BLAH BLAH BLAH”… two weeks later and the requestor has moved on. You have officially missed your window to sound like you know what you’re talking about and, guess what, you’ve also been pegged as hard to work with / unreliable. Way to go.

Larger organizations really believe they need to document more and they’re right. Communication in big organizations is tricky because everyone’s got an opinion and you never know who is going to have a bright idea. Big company policy on requiring documentation is furthered by layers of management struggling to ascertain/measure what is actually going on in large groups of people. (See: Status Reports Must Die)

If you’re feeling screwed by the absence of some important document, again, look at who is giving you that screwed feeling and ask yourself, “Is this an honest request for facts or a management boondoggle?” If the answer is facts then face-to-face communication is always the way to go especially if time is of the essence.

This section reads like I’m anti-documentation which is silly because HELLO I WRITE A WEBLOG. Remember the context of this column, “When you’re screwed…”. I’m talking about situations when it appears the sky is falling and you need to move quickly. I could easily argue that diligent and frequent documentation is a handy way to avoid sky-falling-situations because writing stuff down is a great way to make information scale… because you don’t.

#2) A Significant Development Tool Does Not Exist on My Team

Screwedness: Varies by tool

There are an endless pile of tools engineers are fond of using in their development process, but there are only four that they really need:

  • Editor
  • Compiler
  • Version control
  • Bug tracking

I’ve never seen any engineering organization that hasn’t had some form of an editor and compiler, but I’ve been shocked to find both version control and bug tracking missing when I’ve walked in the door.

If you ever find yourself in this situation, your first job… before you even sit down at your desk… is to get these tools in place and in use or you and your organization will be forever screwed. Any engineering organization with more than two people will fall flat on it’s face as soon as the product development process gains any sort of momentum unless version control and bug tracking are in use.

These tools empower engineers by allowing the entire team to:

  • Collaborate without stepping on each others toes. You do this, I’ll do that.
  • Be accountable for their work. Who’s got that checked out? Who’s bug is this anyway?
  • Measure their work. How many bugs do I have? How about you?
  • Remember what they did. Uh, who the hell checked in this crap?

You’ll find early on in your management stint that main reason people make the trek to your office is that they need conflict resolution. Once the conflict participants stop yelling, you need to get them looking at facts because facts will ground them and grounded means less yelling. All of the tools I describe above are excellent repositories of cold hard facts and that can help.

#3) I Can’t Stand My Product/Program Manager or They Plain Don’t Exist

Screwedness: Medium

As an engineering manager, you need to have two significant peers. First, you have a product manager… marketing. This person represents your conduit to your customer and their needs. Second, you have your program manager. This is your process and communication czar.

The program manager role is a bit harder to define because most engineering managers confuse a program manager’s role with their own. A program manager owns the entire process of shipping a product. Think of it like this, you, the engineering manager, hand a DVD with your final product to the program manager and they make sure it shows up in Fry’s in the right box. Don’t think that isn’t a huge amount of work because it is.

Again, both product and program managers are information brokers. For the product manager, they represent the customers needs… they tell you what the customer wants and you build it. Once you’re done, they tell you how it went. The program manager’s information is organizational. For any given question, they know the answer or know who to ask. Good ones are also process wienies which means things just don’t fall through the cracks around them.

Program Manager Sidebar: My strong belief in the role of program manager comes from first hand screwedness. My start-up was twenty folks when I arrived as the first engineering manager. Over the coming two years, we grew to 250 people where I was managing three product lines. The executive management team created the program office around that time and I was immediately suspect. “What do these boobs do? Take meeting notes? Jesus, what a waste.” Wrong wrong wrong. Good program managers are detail drivers. They handle the piles of minutia surrounding a release and you’ll be shocked the amount of time they’ll save the average engineering manager.

If you’re unable to work with these co-workers or if they just don’t exist, you’re pretty much at the same state of screwedness. You’re going to have to do their jobs for them and that means less time to actually be an engineering manager. This isn’t going to feel like screwed because you’ll be busy, but you are, bit by bit, cheating your team and your product out your time while you making sure the box art looks right.

Of the two, a missing or moronic product manager is probably more of an issue since their data affects the work of your entire team. You’ll likely make things worse when, if pressed for time, you declare, “Well, I know what’s best for the customer.” Again, wrong. Unless your product is targetted at software engineering managers then it’s unlikely your opinion is relevant. Sorry.

#4) My Product is Nowhere Near Done

Screwedness: Less than you think (hopefully)

Let’s first remember that product development team loses their minds the last month of any significant product development cycle. Really. They’re insane. They’ve been staring at this damned product for so long that they’ve developed a serious emotional attachment with the bits and that means irrational, goofy behavior that is not based on reality.

This is you. Mr. Insane Engineering Manager. It’s two weeks until your product ships and you are sure there is no way you’re going to make it. Your claim is, “The product is crap”

Now, there are two possibilities both of which are equally possible. First, you might be too close to the product to make a quality judgment. Your intimacy with your product has clouded your judgment and what you’d consider ready for prime time has nothing to do with what a customer would be happy with it. If, in a moment of lucidity, you realize that this the situation you’re in, it’s best to find a person/party who’s judgment you trust and get a sanity check. Your instinct will be to go to your QA organization, but they’re likely equally in love with the product and probably more wacked about quality than you.

Maybe your boss? Maybe another engineering manager? I don’t know who, but it’s got to be someone who has not spent the last three months living and breathing this product that’s NEVER GOING TO SHIP. When you do find a designated sane person, they should ask questions like this:

  1. Are the features done? How done? Are they testable?
  2. How many bugs are left?
  3. How many bugs are you fixing on a daily basis?
  4. How many bugs are you willing to ship with?
  5. What’s your bug deferral criteria?
  6. What’s your update strategy?

This sane person’s job is not to decide for you. Their job is to be neutral and to help you frame your decision by asking great questions. As a rookie manager, you’re not going to seek external input because you’ll think asking for help is a sign of weakness and, boy, are you wrong. Asking for help of team members allows these folks to apply their unique experience to whatever the problem might be and that’s how you make better decisions while also building a stronger team. Asking for help is a big deal. Do it. Often.

That’s situation #1… getting a second opinion. This leads us to situation #2 which is, you’re right… your product is nowhere near ready for customers and you’re fourteen working days from shipping. You and your team are charging forward to the ship date, but most everyone is shaking their heads slowly and murmuring, “It’s not ready”.

And it’s not. No need to get a second opinion. You’re still finishing features. QA is sufficiently pissed off and your program manager is crying in his/her office.

Yes, it’s really not ready.

As an individual contributor, your job is to bitch about the situation. I mean that in a good way. Bitching is one way to conveying data and if your manager is listening, they’ll register it as such. Problem is, you’re the manager and it’s now YOUR JOB to make initiate a course correction because late is better than crap.

If this is your first ever course correction, you’re going to believe you’re more screwed than you are. Here’s the truth: Most everyone believes that engineering is lying when they propose a schedule. It’s what fancy word talkers call a truism. If engineering says it’s going to take a month, it’ll probably take three. Ok, maybe lying is a bit strong. We’re actually not lying, but we’re doing the best we can, I swear. We honestly don’t know how long it’s going to take to finish that feature until we’re halfway done.

Organizations insulate themselves in different ways against the lack of engineering certainty. Some product groups build in slip time. Others have mysteriously named milestones POST ship which are the actual ship dates. The point is: If this the first proposed slip for any given product, you’re going to be pleasantly surprised when the product team says, “How much time do you need?” Didn’t know you were playing poker did you? Well, you are.

DISCLAIMER: If you’re interested in building any sort of credibility in your organization, I suggest that slipping your product late in the game is just bad PR. Any good engineering manager + program manager team is going to build in feature and schedule checkpoints where mid-game adjustments are made that give everyone higher confidence in a final schedule. Last minute schedule changes violates Rule #3 of Rands Management No No’s: “No surprises”.

#5) My Company/Job Sucks or Is About To Suck

Screwedness: High

True story. In the early 90s, Borland was taking it on the chin from Microsoft. Borland’s big transition of their office applications to Windows was going abysmally. The Microsoft monopoly was in full force… they bundled their first version of the Office suite and were underpricing the competition. Good-bye Quattro Pro, Paradox, and dBase.

After years of expansion and a move into a (still) amazing campus, Borland was about to implode and I was aware of this. That’s the first step to get yourself unscrewed in this situation… detection… knowing the ship is sinking even though those execs continue to sound eternally optimistic in those all hands meetings. Of course they sound positive, if the rank and file universally believe the sky is falling, those all hands meetings will become utterly devoid of hands.

What’d I do? I jumped ship. I took my engineering title and moved up the peninsula to a now-defunct database company. Problem was, the new company was in much worse shape than Borland having imploded about a year earlier. I didn’t know this until my hiring manager who had portrayed a portrait of enthusiasm and vision was gone one month after I started. I was suddenly debugging build systems and drinking really bad coffee with a bunch of chronically depressed database developers.


It’s obvious, but there are two parts to getting descrewed when your company sucks. First, detection. There are people still at Borland who, to this very day, are still bitching about that company the same way they were over a decade ago. Let’s call them faux-Bitchers because for all their bitching, they’re never going to do anything about it because bitching about, apparently, is enough.

You are not faux-Bitcher because you’re still with me. You want to do something about your screwedness. You want to make an upwardly mobile move. You want to go somewhere where you’re:

  1. Getting a raise
  2. Getting a promotion
  3. Getting to do something that interests you
  4. Working for a company that doesn’t suck

In my post-Borland move, I succeeded in A and B, but I blew D… and, it later turned out, C. It was my worst career transition ever and it took me a year to get back to a place that I felt I was moving forward. Good managers keep their teams, their products, and their careers full of velocity.


That’s a better term than upward mobility. Constant forward momentum.

How you are going to achieve your own personal velocity is your own deal. My apparently endless stream of management advice is just that… advice. What you really want is my experience, but you can’t have it because there is only one way to get it… you’ve got to put yourself a situation that allows you to get screwed. When you’re deep in it and terrified, maybe some useful acquired advice will pop into your mind or maybe you’ll construct a more elegant solution. Either way, you’ll come out the other side moving faster… or maybe slower.

12 Responses

  1. More fantastic writing, Rands, keep it up.

  2. Sorry to says this, but I am really happy that you screwed yourself over and over again so I get to read it. This was a great read, make’s me remember why I come here.

  3. 20 years ago

    Rands: What To Do When You’re Screwed

    Rands makes me laugh. A lot. His articles provide wonderful insight on being a geek in today’s workplace (and being a geek in general).
    His current article addresses how to handle certain levels of “screwedness” as a manager. He begins with his …

  4. Phenomenal! This is great, great stuff. Inspirational, especially for those of us who really need it. Thank you.

  5. some guy 20 years ago

    hi. another great column. the more i read of your management writing, the more i’m being deprogrammed of the classic engineer mentality that to become a manager is to give up interesting work. in a lot of ways, it seems a lot more challenging than coding.

    here’s a screwed situation you didn’t mention that i’d be interested in hearing your take on.

    feature X is holding up shipping the software. an engineer is working on feature X and panicking because he can’t get it working. all of a sudden. he gets some advice from another coworker and proclaims to all and sundry than feature X is working. we take his word for it, because we don’t have a test plan or acceptance criteria and all of that fun stuff in place. yet.

    fast forward to 2 months later, and a maintenance release is being prepared. as we are no longer under a shipping deadline, we write a test plan and spend a few days testing the software. we shake out a lot of bugs and spend a month or so fixing them. in the process we discover feature X doesn’t work, and couldn’t have possibly worked in the original release either.

    obviously we know 2 things : the engineeer who worked on feature X either didn’t really test it or lied, and that nobody is using feature X.

    what do you see as the screwedness of the situation ?

    i’m torn between thinking High because we shipped with a non working feature, and a lower screwedness.. i suppose really it’s Low right now because nobody is using the feature, but as soon as someone does and submits a support request, we go to ScrewedCon 1.

  6. In my (bitter!) experience:

    product manager=somebody who doesn’t want to

    program anymore and probably was never that good

    at it – wants to set the agenda but not do the

    work. The ones I know are incompetent and lazy.

    program manager=somebody who has been exhausted

    by their life in the product development trenches

    and now wants a cosy administration role.

    A colleague commented on reading this post that

    it seems we can’t get one good person anymore,

    so we need a commitee to spread the blame!

  7. In my experience, management looks like such a coast until you actually have to do it. Sure there are lame duck positions here and there, but ultimately you’re talking about having to know about and force people to do all the parts of all their jobs that they find irritating, and to stop them shooting off in the wrong direction. The job is no more difficult no matter how thick or talented your staff are; usually with excellent skills comes overinflated opinions. Pragmatism is the key requirement, and not feeling stress is a blessing.

  8. I really liked this article. I would be interested to hear an extension of #4 where instead of 2 weeks from shipping you are in the middle.

    Our team just slipped several milestones in a row. The good news is that we took the slips seriously and took a hard look at the project and realized that instead of being months from shipping, we are at least a year. How screwed is this?

  9. When a company is sucking is something I’m a pro at detecting. I’ve worked for countless startups and as with most startups, most went under. The thing is, even if you’re a manager, the owner or CEO will not believe you or he’s sucking the company dry before it goes KABOOM.

    I do have one piece of advice. If they are going under and laying people off, ask if they have a severance package (in larger companies). You may be better off looking for another job AND staying there a little longer for the severance package. You can also get references and leave on good terms as you watch your team being sacked.

  10. I can’t agree more with your list of four essential tools. I rarely blog on other people’s content, but I felt the need to expand on that a bit, which I did at my blog.

  11. It can be worse …

    Currently Unemployable and With a Job that Sucks.

    Screwedness: Extreme

    Step1: Becoming unemployable. There are two ways to do that. Simplest, stop learning and accept the status quo. Any status quo. Enjoy your couch and remote. With time the TV becomes optional. At this point you’re already screwed and there’s no need for a step2, but who cares anyway? You already have the perfect life which contains a couch and a remote. In a way, you’re not screwed, but content (i.e. screwed thoroughly and accepting it with a dumb smile on your face).

    The second way of “unemploying” yourself takes lots and lots of effort: develop real software** for real software companies. Let intelligent and competent people mentor you. Find challenging problems, the kind of problems that scare most people away. Solve them. Mentor other people. And learn, learn, learn. Evolve into a software coding/design machine.

    Then rellocate to a city with a fairly small hi-tech market.

    Step 2#: Find a job. Any job. It doesn’t really matter which one. The few competent people, people you could learn from, with real software development experience, are already in a “don’t-care” state of mind. And they are not willing to change.

    How to unscrew yourself. You may try any of the following:

    1) Rellocate back to a hi-tech market where you make sense.

    2) If 1) doesn’t work – reasons varry from risking divorce to you really like the new place – then you can either switch to a dont-care state of mind at work and you get your life elsewhere doing whatever makes you happy. Or if you really do like challenges then figure out how you can make sense and a difference where you are.

    ** Applies for any field, not just software development. Just get good at what you’re doing and you’re on the right track.

  12. Berislav Lopac 18 years ago

    Just one correction: a software development team of any size is screwed if there is no version control, not just of more than two people.