Category: advice

How to negotiate a better contracting rate

In any transaction, the person with more information and more experience usually comes out ahead. That’s why the typical consumer negotiating with a full-time salesman is at a huge disadvantage. A car dealer, for example, might negotiate several sales every week, while you only do it every two to three years.

So people making big decisions — new car, new house, new job — do as much research as they can, trying to level the playing field just a little bit. And lots of the information they come up with is flat out wrong.

One of the most damaging pieces of advice to follow when looking for a job is to rely on a headhunter’s self-interest to get you the best rate. The idea – which seems quite reasonable on the surface – is that the headhunter’s commission is a percentage of your salary. Obviously they want this number to be as high as possible. It’s easy to believe that their self-interest lines up with yours.

The first flaw with this idea is that the headhunter doesn’t get anything if someone else gets the job. If there are multiple qualified applicants, you are on the wrong side of a bidding war. The contractor doesn’t want to price you out of the running, so the incentive is to lowball your rate.

The second flaw is that every day the headhunter spends searching for your perfect job is day they don’t spend finding a job for the dozen other people they’re working with. They make more money by placing more people than they do by placing fewer people at higher rates. 30% of $70k x 3 is more than 30% of $80k x 2. Their incentive favors the quick hit, not protecting your interests.

So what do you do about it?

  • Stop thinking of the headhunter as your own personal agent.

    They’re doing a job for you, but they are more interested in getting you something than in getting you the best thing.

  • Know what you’ll accept before taking the interview.

    Have a bottom line that you won’t go below. Based on what you hear in the interview, you may decide to demand even more to accept the conditions. But your lower limit should never be negotiable.

  • Ask what the range is for the position up front.

    There’s no point in wasting time on a position that you’ll never take.

  • Never give up something for nothing.

    If they want you to travel and you don’t want to do it, ask for extra vacation in return. If they want you to be on call, ask for comp time. Never give up one of your demands without getting a concession in return.

  • Get it in writing.

    You can’t deposit a promise in the bank, or buy groceries with verbal assurances.

So are all headhunters ready to sell you out at a moment’s notice? Of course not, even if onlyto preserve their reputation. But if you want to avoid being disappointed, you should never forget that your best interest only sometimes matches up with the headhunter’s interests.

How To Triple Your Output By Cutting Your Output In Half

The fastest typist I’ve ever seen was a guy I used to work with. When he started going it sounded like a machine gun. Our standard line when people asked the rest of us about him was, “Yeah, he types over 150 words per minute … and about 40 of them are spelled right.”

Even after you ran his stuff through a spell checker, you’d have to proof-read very carefully to catch the places where “there” and “their” were mixed up. Where single letters showed up at random because the spell checker skips one-letter “words”. Where he left out words or just plain didn’t make any sense.

It usually took longer to fix his stuff that it would have taken to do it yourself from scratch. So why did we put up with it? Well, he was the boss. Keen.

But like anything else in life, you can at least learn something from the situation. What I learned from him was that it doesn’t matter how much you produce if no one wants it. Or put another way: Anything you do for someone else that isn’t up to their standards doesn’t count.

For an example of an entire industry that’s working as hard as possible to ignore this simple truth, compare television today to what it looked like in the 1950s.

The golden age

Back then there were three networks. How many prime-time shows did they collectively produce per week? Counting 8-11 p.m. Monday through Friday, that’s three 1-hour slots x five days x three networks = 45 hours of programming. Lets say a third of those hours were broken up into half-hour shows, so a total of 60 shows per week.

Let’s assume that to have a consistently great show you needed six extremely talented writers and actors. (Yes, there’s a lot more to it. This is just an example.) The fewer good people you have, the less often your show will be good. To fill 60 shows, you might have the following mix:

Show quality Talented staff
per show		 # of shows Total
talented staff
Consistently great 6 1 6
Excellent 5 2 10
Very good 4 2 8
Good 3 18 54
Sometimes good 2 35 70
Generally poor 1 2 2
Total 60 150

Obviously every network would like their shows to be better. But for whatever reasons there are only 150 people with the level of talent needed to produce a weekly show.

Double the output

Fast forward a couple of decades. Now there are six networks. The talent requirements to produce a good show are the same, but there aren’t suddenly twice as many talented people available to do the work. The chart above might now look a little something like this:

Show quality Talented staff
per show		 # of shows Total
talented staff
Consistently great 6 1 6
Excellent 5 1 5
Very good 4 1 4
Good 3 6 18
Sometimes good 2 21 42
Generally poor 1 75 75
Unwatchable – bad 0 15 0
Total 120 150

Notice how many shows had to drop into the lower categories to make this work. The contrast is really obvious when you look at the two outcomes side-by-side.

writer-chart

With twice as many total shows, there are fewer shows that are even sometimes good. By doubling the total output, there are fewer than half as many shows that are ever acceptable to the audience. And there are only a third as many shows that are usually good.

These numbers are obviously a gross oversimplification, but they illustrate a point: By increasing the output without increasing a limited, but required resource the overall quality declines faster than the total output increases.

500 channels and nothing’s on

Now fast-forward to today. There are literally hundreds of networks trying to fill 24 hours every day. Sure, with the amount of money available in the industry today there may be more people willing to work there.

But if my assumption is at all close to reality, then we would expect to see shows that clearly don’t have anyone talented working on them. We might even see shows where they simply send a camera crew out to film people without a script. We might call this a “reality” show.

So you’re not in the TV business. How does this apply to you? Everywhere in the example above, replace “talented staff” with “attention”. How much undivided attention do you have each day? How many ways are you dividing it? By trying to do more things, are you doing fewer things well?

It’s time to cheat on your publisher

With the current generation of high-speed digital printers, print-on-demand [POD] publishers are making aspiring authors feel wanted like they’ve never been wanted before. It seems like everywhere you look there’s another slick come-on … free ISBN numbers, your own storefront, listings on Amazon.com.

For someone getting propositioned for the first time, it’s easy to fall into a deep relationship with whoever offers the nicest package. The smart ones make it really easy to say “yes”. It’s just so simple and comfortable, let them take care of everything for you.

I bet you can see this coming

Then something goes wrong and you realize how dependent you’ve become. All those links on your blog pointing to the order page. All the people you’ve told where to find you. The PayPal account you set up to take the payments.

It sure was easier to get into this relationship than it is to get out. You tell yourself the problem — whatever it is — isn’t really that bad, come to think of it. At least it’s not bad enough to be worth the pain of finding someone new.

You don’t think that time is going to come? Well, you may be right. Through some combination of luck, work and compatibility you may have found the perfect partner for the rest of your publishing life. But do you really want to jump into things that deeply without seeing what else the world has to offer you?

So what’s the alternative?

The great thing about all these options is that you can try lots of them without guilt. You realize, if think about it, that they’re hooking up with every other writer on the planet just as fast as they can. You’re nothing special to them, so why should they be anything special to you?

So play the field. Sign up everywhere you can find that doesn’t have setup fees. Upload, test, experiment, enjoy the thrill of it all. And see who actually gives you what you really want: sales.

Are you wasting your time being productive?

Most people think that wasting time means you’re not doing anything. Maybe they include not doing anything productive. But can you be doing something productive and still wasting time?

To answer the question, let’s go back several years to a time before optical mice were common. I was working the helpdesk at a law firm. I got a call from an attorney that his cursor was skipping around the screen erratically. It was pretty obvious from his description that there was gunk in his mouse.

I had just started explaining to him how to remove the mouse ball to clean it out, when my supervisor tapped me on the shoulder and told me to bring him up a new mouse. I said, “But it only takes five minutes to clean it out.”

She told me, “He bills $600 an hour. Bring him a new mouse.”

I didn’t know the term at the time, but she had just taught me a lesson in opportunity cost. If whatever you’re doing is less valuable than what you could be working on instead, you are wasting time.

Hate the game if you want, don’t pretend it isn’t being played

When I was in college I worked at a bar that had a pool room. I played a lot when it was slow and after hours. I got pretty good on those tables. Only “pretty good” and only on those tables … I knew where the dead spots were in the rails.

If I bet anything on the game, it was usually who bought the next round. Sometimes we couldn’t drink as fast as we played, and we’d go for a dollar a game. We were all friends, and it was just to make the game more interesting.

But every so often someone would come in who none of us recognized. You could usually tell really fast who was better than just a casual player. Sometimes they’d see if they could get a game for $5. I’d always take them up on it. And I always won the first game.

Then they’d ask for a rematch … let them win their money back. I’d take that game, too. Sometimes I’d win, sometimes not. But I was breaking even so I didn’t care. It was usually after the second game that they’d look at their watch and realize they had somewhere they needed to be. But they had time for one more game.

How about one last round for $50?

No.

How about $30?

No.

Come on, give me a chance to win it back!

No, you’re a better pool player than I am. But you suck at reading people. You thought I didn’t know you were throwing the first two games.

That’s when they’d get pissed. It wasn’t fair that I took their money even though they could beat me without trying hard. I was just a punk-ass bitch that couldn’t carry their stick.

Yup. But I had their money, and they were leaving.

If I wanted to, I could have spent the equivalent of a full-time job becoming a professional level pool player. I would have run into diminishing returns as I was going up against ever stronger competition. It would have dominated my life, and the only way to make a steady living would be constant travel.

Plus there’d be no retirement plan. Your earnings stop the moment you stop playing. The skills don’t translate to anything else worthwhile.

So I stayed in school and learned to be a programmer, which doesn’t suffer from any of those negatives. </sarcasm>

Hmm, that came out a lot longer (and a lot faster) than I expected. It all started from one idea, though: You don’t win by being better, you win by playing better. And you start by knowing what game you’re playing.

When you’re in an interview, you’re playing the “get the job” game. Once you have the job you’re in the “impress the decision-makers” game. If you go the uISV route you’re in the “sell the most product” game.

Being better at coding is one of the plays in each of those playbooks. But it’s not the one they keep score with.

Is your resume hot or not?

Getting a job is like getting a date.

  1. There may or may not be rules to it.
  2. It may or may not be fair.
  3. They may be so desperate it doesn’t matter what you say. But do you want to hook up with someone who’s desperate?
  4. Or maybe it doesn’t matter what you say because they’ve decided the answer is “no” before you opened your mouth.
  5. The more in-demand you are, the more choosy you can afford to be. But if you want to get this job — or this date — then you’re probably going to have to say what they want to hear. Good luck figuring out what that is.

How to Finish IT Projects Faster with Less Documentation

If you’re responsible for running an IT project you want things to be done on time and within budget. So how do you set your schedule and budget? Hopefully you define what you want to accomplish, and then ask the developers how long it’s going to take. If you’re putting out a request for proposal (RFP) you’ll have several different answers to that question. Typically the highest consideration in the selection is the total proposed cost. But really, the total time is a better choice.

Why that’s true is based not on ideas about processes, but on ideas about people.

Consultants live and die by billable hours. In the short term, they don’t have any incentive to finish their current project any faster. But in the long term, finishing faster should lead to more work as clients come to respect their ability to meet a deadline. If project managers and clients learn to value that behavior, that is.

How it Could Be

Let’s look at a production support issue for an example. Production support is completely different from most project work in one very important way: the problem is well defined. Something worked on Monday, it doesn’t work on Tuesday. Make it work just like Monday again.

For something with six-figure impact per hour of downtime – and if you think that’s an artificially-high number you’ve never worked with credit card processing – you don’t want a programmer with an impressive resume, dozens of certifications, and decades of experience with your primary programming language. You want Bob, the guy who wrote the system from scratch and demands $1k per hour with a four-hour minimum.

Once you’ve got Bob and his hand-picked team of support people, you get out of their way and let them work. Status reports might be no more than, “We’ve found the problem … We’ve identified the solution … We’re ready to test the fix … It’s live.”

How it Is

But when it comes to new development, companies play it “safe” and look for the best qualifications on paper. They hire based on keyword matching and offer rates based on industry standards for a given skill set. They require specific processes and deliverables (pet peeve: when did “deliverable” become a noun?) and status reporting becomes a significant percentage of the total budget.

Why the Difference?

There are two reasons expert teams get away with less formal process than is typical, but I can only prove one of them. The public answer business sponsors tell themselves to justify the exception to “official methodology” is that the experts have worked the methodology for so long that they can follow the same procedures without exhaustively documenting all the steps. And there is some truth to that.

But I suspect the larger reason is that experts get the work done so much faster there just isn’t enough time for documentation to build up.

The best athletes make things look easy that most people could not even do. A high jumper might clear six feet without even trying hard. Most people would never come close even with months to try.

The best IT people do the same thing. They complete projects in weeks that other people could never do. As “safe” projects drag on specifications are refined, status reports are produced, contracts are negotiated, updates are requested and provided. Meanwhile the expert team has just released to production – so it must have been a small project.

The hard part for the client is to recognize the difference between a project that went smoothly because it was easy, and one that went smoothly because the team made it look easy. But here’s the secret: You don’t really need to recognize the difference.

How to Do Better

The reason you hired someone else to do the work is because you couldn’t do it yourself. Which means you can’t accurately judge which projects really are hard, and which ones just look hard. So don’t judge the project, judge the people.

The people who seem to always be working on small, simple projects – after all, they always go quickly with no major problems – are better at execution. They will be better no matter what the project is.

Meet the new boss, same as the old boss v2

Sometimes you read something that you can’t summarize without losing a lot. I just can’t find any extra words in this post, so here it is in its entirety:

1) Whatever language is currently popular will be the target of dislike for novel and marginal languages.

2) Substitute technology or methodology for language in #1. In the case of methodology, it seems a straw man suffices.

3) Advocates will point to the success of toy projects to support claims for their language/methodology/technology (LMT).

4) Eventually either scale matters or nothing matters. Success brings scale. An LMT is worthy of consideration only after proving out at scale.

5) Feature velocity matters in early stage Web 2.0 startups with hyperbolic time to market, but that is only a popular topic on the Web for the same reason Hollywood loves to hand out Oscars.

6) Industry success brings baggage. Purity is the sign of an unpopular LMT. The volume of participants alone will otherwise muddy the water.

7) Popularity invites scrutiny. Being unfairly blamed for project failure signals a maturing LMT; unfairly claiming success, immature LMT. Advocates rarely spend much time differentiating success factors.

8 ) You can tell whether a LMT is mature by whether it is easier to find a practitioner or a consultant. Or by whether there is more software written *with* or prose written *about* the LMT.

9) If you stick around the industry long enough, the tech refresh cycle will repeat with different terminology and personalities. The neophytes trying to make their bones will accuse the old guard of being unable to adapt, when really we just don’t want to stay on this treadmill. That’s why making statements like “Java is the new COBOL” are ironic; given time, “N+1 is the new N” for all values of N. It’s the same playbook, every time — but as Harlan Ellison said of fiction, every story has already been told, but nobody was listening the first time.

10) Per #9, I could have written this same post, with little alteration, ten, twenty or thirty years ago. It seems to take ten years of practise to truly understand the value of any LMT. Early adopters do play the important role of exploring all the dead ends and limitations, at their cost. It’s cheaper to watch other people fail, just like it hurts less to watch other people get injured.

11) Lisp is older than I am. There’s a big difference between novel and marginal, although the marginal LMTs try to appear novel by inserting themselves into every tech refresh cycle. Disco will rise again!

12) If an LMT is truly essential, learning it is eventually involuntary. Early adopters assume high risks; on the plus side they generate a lot of fodder for blogs, books, courses and conferences.

13) I wonder if I can get rich writing a book called Agile Lisp for Web 2.0 SOA. At least the consulting and course revenue would be sweet. Maybe I can buy an island. Or at least afford the mortgage payments on a small semi-detached bungalow in the Bay area.

14) It requires support from a major industry player to bootstrap any novel LMT into popularity. The marginal LMTs often are good or even great, but lack sponsors.

15) C/C++ remain fundamental for historical reasons. C is a good compromise between portability and performance — in fact, a C compiler creates more optimal code than humans on modern machine architectures. Even if not using C/C++ for implementation, most advocates of new languages must at least acknowledge how much heavy lifting C/C++ does for them.

16) Ditto with Agile and every preceding iterative methodology. Winding the clock back to waterfall is cheating. I’m more sophisticated than a neanderthal, but that won’t work as a pick up line.

17) Per #13, I don’t think so, because writing this post was already a chore, let alone expanding the material to book length. Me an Yegge both need a good editor.

This covers the technology pretty well. All he left out was the reason so much is coming back.

The day I got a lot smarter

One sign of intelligence is the ability to learn from your mistakes. An even better sign is the ability to learn from someone else’s mistakes. Unfortunately, we don’t always have the luxury of watching someone else learn a valuable lesson, and we have to do it ourselves. But if we pay attention, sometimes we get to learn multiple lessons from one mistake. (Lucky us.)

Case in point: Dealing with a crisis. I was managing a group of web developers, and the project lead on an integration with our largest client was going on vacation. He assured me his backup was fully trained, and would be able to deal with any issues. He left on Friday, and we deployed some new code on Monday. Everything looked good.

Time passes …

On Wednesday at about 4 p.m., we got a call asking about an order. We couldn’t find it in our system. From what we could tell, the branch that placed the order wasn’t set up to use our system yet, so we shouldn’t have the order. At 5 I let the backup go home for the day while I worked on writing up what we’d found. I sent an internal email explaining what I believed had happened. I said that I would call the client and explain why we didn’t have the order, and that they should check their old system.

While double-checking the deployment plan, I discovered that the new branch actually was on our new system … as of that Monday. That’s part of what was included in the new code. That’s when I got the shiver down my spine. By that time the backup, whose house was conveniently in a patch of bad cell coverage, was gone. The lead was on vacation. “Okay,” I thought, “I’ve seen most of this code, in fact I’ve written a good bit of it. I can figure this out.”

Stop laughing. It sounded good at the time.

To make a long story short (Too late!) we hadn’t been accepting orders for three days from several branches, but had been returning confirmations for them. It was somewhere around 3 a.m. when I finally thought I knew exactly how many orders we had dropped, though I hadn’t found the actual bug in the code yet. I created a spreadsheet with the list of affected orders. At one point I used Excel’s drag-to-copy feature to fill a range of cells with the branch number for a set of orders.

Did you know Excel will automatically increment a number if you drag to copy? Yes, I know it too. At 11:30 in the morning today I know it. At 3 a.m. that night I apparently didn’t know that. So I sent it to the client with non-existent branch numbers that I didn’t double-check. “Oops” apparently doesn’t quite cover it.

The reveal

The next morning on a conference call with the client, my boss, his boss, and several other people, we were going over the spreadsheet when someone noticed the problem. To me, it seemed obvious that it was a simple cut-and-paste error on the spreadsheet. But someone — a co-worker, believe it or not — decided to ask, “Are you sure? Because I don’t see those other two branches on here either.” After dumbly admitting that I didn’t know anything about any other two branches, I ended the call so I could go figure out what was happening.

Now I had apparently demonstrated that I didn’t actually know what was wrong, that I had no idea of the scope of it, and that I was trying to cover it up. Yay me. We called in the lead (whose vacation was at home doing renovations) and started going through the code. I finally found the cause of the error, and it caused exactly the list of errors that I had sent out early that morning, except for the cut-and-paste error. The “other two branches” turned out to be from the previous night’s email, where I had specifically said those branches were not affected by the problem.

Within two hours, we had the code fixed and all the orders recovered. So everyone’s happy, right? If you think so, then you haven’t yet learned the lessons I did that day.

  1. No matter how urgently someone says they need an answer, the wrong answer won’t help.
  2. If it looks like the wrong answer, it might as well be the wrong answer. This doesn’t mean counter-intuitive answers can’t be right. It means that presentation and the ability to support your conclusion count.
  3. If you didn’t create the problem, always give the person who did the first chance to fix it.
  4. If someone knows more about a topic than you do, have them check your work.
  5. Don’t make important decisions on too little sleep.
  6. Before making a presentation to a client, review the materials with your co-workers.
  7. Don’t make important changes when key people are unavailable.

Looking at that list, I realize I already knew several of those lessons. So why did it take that incident to “learn” them? Because there’s a difference between knowing something, and believing it.