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

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.

Ooops.

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.

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.