If the FBI wins against Apple, we all lose

The following is a letter I’ve written my US Senators and Representative regarding the FBI’s attempt to force Apple to provide a backdoor into their iOS encryption framework.

Dear $CongressCritter,

I am strongly against the FBI’s attempt to force Apple to provide a backdoor into their iOS encryption framework.

I am not an iPhone user, but as a 15-year veteran of the tech industry, I am intimately familiar with the importance of encryption in today’s technology ecosystem. If the FBI were to force Apple into providing a backdoor into their encryption framework, there is little to ensure that this capability is limited to this one case and absolutely nothing to prevent others from using it once created. To expect that the custom iOS provided to the FBI would never get into the hands of hackers and enemy states is naive and dangerous. Nor is there anything to prevent the FBI or other government security agencies from using this against US citizens in the future.

Forcing Apple to provide a backdoor sets a terrible precedent. It will negatively impact the US technology sector, and thereby the US economy, as individuals and businesses (both within the US and outside of it) stop purchasing US-made equipment knowing that the US government has, or can have, a route into their data.

Privacy and security are inherently at odds with one another and I acknowledge that it is hard to find a balance between the two. But the US government should be directing tech companies to do a better job of protecting citizen’s privacy, not providing backdoors to allow the US government and others to violate that privacy.

Please put pressure on the FBI to withdraw their request from Apple and make it clear that American citizens need strong encryption to protect our privacy and the US economy.

Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.

— Benjamin Franklin

Sincerely,
Casey Peel

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.

My tech industry career advice

Spending time with some of our interns who are just getting started in their careers got me thinking about my own. So I sat down and made a list of things that I think shaped my career in the tech industry. Note that I’ve only worked for a few large companies in my 15-year career and while I’m happy with my career trajectory, others might have found it too slow or boring.

“Advice”, as a wise woman once said, “is a form of nostalgia. Dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than it’s worth.” And, like her, I’ll dispense mine now:

Write up weekly status reports for yourself. I started this habit a decade ago when working for a remote manager. Every Friday I would make a high-level bulleted list of what I accomplished that week. At the end of the month I bundled those up and sent them to my manager. This helped my manager know what I was doing and gave him something tangible to use with his peers when promotions and other employee rankings happened. More importantly it helped me keep track of when I was slacking for a week. It also helped me write up my end-of-year self-evaluation for that employer. I continue doing this today. They aren’t very detailed and sometimes they happen a week late if I forget, but it provides at least a trail of breadcrumbs to follow later.

Attend division/company-wide meetings. Often these optional meetings are boring but I still recommend making the effort to attend the important ones (engineering lunches, quarterly meetings, etc). The mostly important reason is that this is your company.1 You’ll get insight into how it’s doing, how the competition is doing, the direction of the company, and what’s going on with other parts of the company you aren’t familiar with. The other reason is that while individual contributors’ attendance is generally optional, managers’ attendance is generally mandatory. As political as this may seem, being seen at these events is good for your career. When managers get together to discuss promotions and rankings you’ll have a small leg up on your peers that didn’t attend these meetings.

Seek out and accept every opportunity to speak with customers. Many times we engineers are siloed away from interaction with customers. But customers are where the money comes from and any interaction you can have with them is good both from understanding how they are using your product as well as tying your name to that customer account in management’s mind. Customer interaction can come in many forms, like assisting support with problem tickets, helping run product betas, shadowing someone going on-site, or presenting at conferences. The closer you tie yourself to customers the better you’ll understand how to make your product and company succeed.

Say yes until you have to say no. I hate saying no to a request, whether it be direction from my manager or a request for help from a coworker. So I say yes. In fact, I say yes even when I really don’t want to do it if I think it’s good for my career like presenting at company conferences. I say yes until I’m almost drowning and then I start saying no. Both skills are important – you can’t do it all – but I’ve found defaulting to yes to be good for my career.

Don’t wait for your manager to figure out you need a promotion. Your career is your own and it’s your responsibility to manage it. Before my last promotion I felt I was performing at the level above where I was. I went out and found the job descriptions for my current position and two above me and did an honest evaluation of where I fit. It was clear to me that I was easily performing my current position’s requirements and could present a very strong case that I was performing at the level above me (having a years worth of status reports to fall back on certainly helped). It was also crystal-clear that I wasn’t performing at a position two levels above me. During my next one-on-one with my manager I told him what I had found and said I’d like to present the case that I deserved a promotion. He readily agreed and I followed up with an email presenting the one-level-up job description and how I thought I fit into it. He used the data I provided in the promotion discussion with his peers and I got the promotion. If I hadn’t got the promotion I would have put the onus on him to determine what I needed to do to get it.

Do what you love. This is last but it’s the most important. We spend entirely too much time at our jobs to hate what we do. There are times with any job when it’s a slog and not all that fun, but that should be transient. It that’s the norm: look for something else. Life’s too short to not enjoy what you do. Those of us in tech have it really good right now as even during the worst of the recession tech jobs were numerous for good people. Besides, the more you love your job the better you’ll be at it. And if this involves quitting your industry all together and becoming a mountain man in Alaska: do it.

1 And you never know if you might be recognized in the meeting!

Oracle+Sun: Oh my!

The purchase of Sun by Oracle just a couple of days ago was a shocker to just about everyone. Sun employees were a bit shocked (according to a friend who works there) as were IBM employees who were assuming there were backroom discussions still going on between Sun and IBM.

The buyout is going to make things interesting in the Identity Management space — which means it’s going to make things interesting for me. Just in case you’ve been living under a rock, the product I work on is called IBM Tivoli Identity Manager and is considered one of the top 5 identity management solutions according to Burton Group. The other four major players in the space are Novell, CA, Oracle, and Sun.

The possibility of IBM buying Sun was creating mini clouds of doubt in my mind given that it was virtually impossible they would keep both ITIM and Sun’s product, one of them was getting the axe. Thankfully I don’t have to worry about that anymore.

Instead we get a nice jumble of confusion in the marketplace if Oracle’s product or Sun’s product is going to get the axe. Good news for ITIM, however you slice it.