Career levels across Seattle-area tech employers

Disclaimer: These thoughts and opinions are my own and not my employer’s, although if you didn’t know that already you’re clearly not paying attention.

EMC Isilon recently refreshed their career level definitions and it got me thinking of how difficult it is to map levels from one company to another. EMC uses a P1-P7 numbering system, IBM uses a band 6-band 9 numbering system, Microsoft uses levels numbered 59-68, Amazon calls theirs levels L1-L10, etc. How is anyone suppose to make sense of this mess across companies? So I set out to do what any engineer would do: determine if there was a mapping between them.

From my experience at IBM, pre-acquisition Isilon, and now EMC I was able to do some of the mappings myself. I then reached out to friends who have worked for at least one of the three and asked how their current companies mapped to it. The following table includes the results thus-far:

IBM pre-EMC Isilon EMC Microsoft Amazon
P1 – Entry 59/60
band 6 SDE 1 P2 – Intermediate 61 L4 – college hires
band 7 SDE 2 P3 – Senior 62 L5 – mid-career
band 8 SDE 3 P4 – Principal 63 L6 – Senior
band 9 P5 – Consultant 64 L7 – Principal
STSM Staff P6 – Senior Consultant 65/66/67 – Principal L8 – Senior Principal
Distinguished Engineer Distinguished Engineer L7 – Lead /
Distinguished Engineer
68 – Partner L10 – Distinguished Engineer
Fellow Fellow Fellow

Discussion frameworks, not absolutes

The chart above is useful primarily as a framework for discussion. Even within a large company the skills for someone at given level may not map closely to others at that same level. Add cross-company evaluations into the mix and the above is, at best, a guideline.

Why is this important?

People change jobs frequently in the tech industry (no surprise given employees who stay in companies longer than 2 years get paid 50% less). My 10-year career at IBM and 4+ years (so far) at EMC makes me an outlier in a field where most of the resumes I see have people staying just 1-2 years between jobs.

The chart above can be useful when changing jobs across companies. When I left IBM to come work at Isilon this would have come in very handy. Instead of moving from my band 9 position at IBM to at least an SDE3 or Staff position at Isilon, I moved over as an SDE2 — two steps down. Next time I’ll have more data to make a solid lateral (or upward!?) transition.1

Levels !== Pay

Everyone I’ve talked to has confirmed that pay does not directly map to levels. It is common for the upper end of the pay range of level X to overlap greatly with level X+1 and maybe even border the lower end of level X+2.

What about Company X?

I’d love to get other large tech companies like Google and Facebook on here, I just haven’t found anyone willing to share their insight. If you have overlap with one of the above drop me an email and lets fill in the blanks.

1 FWIW, I currently have no intention of leaving EMC Isilon for another job.

IBM releases salary adjustments

Today IBM released the result of this year’s salary plan (ie: raises) to the masses. I had high hopes since we (IBM and Tivoli) had such a great 2006.

This year the bucket that my team’s salary adjustments came from (at whatever level that is determined) wasn’t all that big to begin with. To complicate matters more, IBM decided to focus on adjusting folks Market Reference Point (MRP)1 this year at the expense of rewarding their top contributors. What this means is that everyone that was below 100% of their MRP had a good chance of getting something to get them closer to 100%. After the MRP adjustments were determined, that money was taken out of the bucket and whatever was left was to give Performance raises based on your PBC rating. Performance raises are generally handed out to folks with a PBC rating of 1, 2+, and often 2. This year the money remaining for the Performance raises was so small that they were only able to give Performance raises for people who made a 1 and some of the 2+s.

Overall my odds were pretty good. Moving to Denver decreased my MRP to 88% so I could expect an MRP increase. In addition I received a 1 for 2006 so I was expecting a decent Performance raise as well.

Based on what I received the bucket must have been microscopic in size. I really can’t complain – I still have a job (layoffs occurred within Tivoli just last week) and received at least a small raise. Still, the number pales in comparison to my previous salary adjustments. My manager also said that my percentage increase was the highest at my second-line manager’s level which makes me happy (see, even though the number is small they do still like me) and sad (geeze, that’s the best IBM can do for their employees?). Oh well – it’ll be enough to cover Benjamin’s college books.

[1] MRP is based on three factors: band, location, and the pay range given those two criteria. If, at a given band and location, you have an MRP of 100%, then you are in the dead center of the pay range for that band/location pair. If you have an MRP of 80%, then you are paid 80% of the average pay at that band/level. Denver has a higher cost of living than Austin (Denver is at the IBM “national” level and Austin is at the IBM “regional” level) which bumps the 100% MRP mark up by $9,600/year going from Austin to Denver.

A Redpaper: I’m published!

At last, I was involved in writing a document for IBM that has my name on it! I’ve been the person responsible for writing and releasing the IBM Tivoli Identity Manager Tuning Guides for many years now, but since they are really a roll-up of information from a variety of sources, including myself, none of them have any names on them.

Over the past several months I’ve been involved in writing, contributing, and proofing a Redpaper titled Performance Tuning for IBM Tivoli Directory Server. The document came about as a ‘meeting of the minds’ of several IBMers who work with ITDS on a daily basis. My main contributions are sections 6.5 through 6.9 and the corresponding scripts referenced therein. These are the same scripts that we’ve been releasing with the ITIM tuning guides for quite some time now but were seen as useful enough to reach a broader audience. In addition, section 2.4 (and subsections) were based on some early versions of my scripts that were later enhanced by other IBMers. The other authors had no idea until our first meeting that the 2.4 scripts were initially created by me :)

The Abstract of the paper was taken straight from the original introduction which I wrote most of. What I find particularly funny is that the current text is a rewrite of an early draft from the other contributors. After trying to make sense of it during the first review, I threw my hands up in the air and rewrote the whole thing. While I am far from a good writer, I am apparently better than any of the other contributors (likely due to hanging out with mbock, jonobie, and quindo who aren’t allowed to find errors in the doc now that it has been published :).
Abstract behind the cut

2006 PBC Rating: 1!

Earlier this morning I had a call with my manager and received the news about my 2006 Primary Business Commitment (PBC) results – I got a 1!

For the uninitiated: At the beginning of each year, IBM employees write down their goals for the year and put them in the PBC tool. At the end of the year employees write up how close they came to achieve those goals and submit them to management who reviews them. Also at the end of the year management gets together and rates employees according to how well they did compared to their peers. Ratings can be one of the following

  • 1 – Extraordinary
  • 2+ – Exceeded Expectations
  • 2 – Solid Performer/Met Expectations
  • 3 – Needs Improvement
  • 4 – Your Ass Is Getting Fired

Because PBC ratings are tied to bonus payouts, the number of 1s and 2+s are limited – generally at a 3rd line manager level.

I’m excited for several reasons. First, and most obviously, it is great recognition within IBM and the Security organization. Second, it increases the percentage of bonus payout I can expect to get assuming IBM and SWG performed well enough in 2006 to hand out bonuses. And third, having a good PBC rating makes it easier for my management team to let me become a mobile employee for our move to Denver as they can see that I’m a solid performer.

Woohoo! :)

Golden handcuffs

My manager just called me about an hour ago and said he was happy to inform me that I am the recipient of an IBM Equity Award. Apparently these types of awards are management-initiated and require the backing of your 1st, 2nd, and 3rd line managers. After a bit of research I discovered that I have received these twice before and didn’t know it! Equity Award is the fancy label IBM gives to stock-related awards which I received in 2003/06 and 2003/12. (Yes, yes, I know that stocks are equities, lay off.) The previous two Equity Awards were stock options. The new award is a set of Restricted Stock Units (RSUs) who’s label told me absolutely nothing until I read up on it.

Apparently RSUs are a way for IBM to give someone actual stock, instead of stock options. They are similar to options however in that they take time to vest. Whereas IBM options vest 25% over 4 years, RSUs vest 50% every 2 years over 4 years. When they vest you are basically ‘given’ that many shares of stock minus taxes and whatnot. IBM very clearly states that Equity Awards are a mechanism to ‘retain truly exceptional people with the critical skills … to win in the marketplace today and in the future’ [courtesy of the IBM internal website], hence the phrase ‘golden handcuffs’. Looks like IBM wants to keep me around for a while. I’m not altogether certain that stock options (or RSUs) would be enough to retain me if I really wanted to leave (’cause its only money and I’d leave it in a heartbeat if I didn’t like what I was doing for work) but I agree that they are an excellent fringe benefit for staying!

A 4-year vesting time oddly coincides with our current 5-year plan which is nice (more on that in a later post).

In actuality I’d rather IBM pony up to the table when it comes time for annual performance reviews and salary adjustments. We shall see.