December 2017 Archives

I've noticed that the startup-flavored tech industry has certain preferences when it comes to your job-title. They like them flat. A job tree can look like this:

1. Intern (write software as a student)
2. Software Engineer (write software as a full time salaried employee)
3. Lead Software Engineer (does manager things in addition to software things)
4. Manager (mostly does manager things; if they used to be a Software Engineer, maybe some of that if there is time)

Short and to the point. The argument in favor of this is pretty well put by:

A flat hierarchy keeps us from having to rank everyone against some arbitrary rules. What, really, is the quantifiable difference between a 'junior' and a 'senior' engineer? We are all engineers. If you do manager things, you're a lead. When you put Eclipse/Vim/VisualStudio behind you, then you're a manager.

No need to judge some engineers as better than other engineers. Easy. Simple. Understandable.

Over in the part of the tech-industry that isn't dominated by startups, but is dominated by, say, US Federal contracting rules you have a very different hierarchy.

1. Associate Systems Engineer
2. Junior Systems Engineer
3. Systems Engineer
4. Senior Systems Engineer
5. Lead Systems Engineer (may do some managery things, may not)
6. Principal Systems Engineer (the top title for technical stuff)

Because civil service is like that, each of those has a defined job title, with responsibilities, and skill requirements. Such job-reqs read similar to:

Diagnose and troubleshoots problems involving multiple interconnected systems. Proposes complete systems and integrates them. Work is highly independent, and is effective in coordinating work with other separate systems teams. May assume a team-lead role.

Or for a more junior role:

Diagnose and troubleshoot problems for a single system in an interconnected ecosystem. Proposes changes to specific systems and integrates them. Follows direction when implementing new systems. Work is somewhat independent, guided by senior engineers.

Due to the different incentive, win US government contracting agreements versus not having to judge engineers as better/worse than each other, having multiple classes of 'systems engineer' makes sense for the non-startup case.

I'm arguing that the startup-stance (flat) is more unfair. Yes, you don't have to judge people as 'better-than'.

On the job-title, at least.

Salaries are another story. Those work very much like Enterprise Pricing Agreements, where no two agreements look the same. List-price is only the opening bid of a protracted negotiation, after all. This makes sense, as hiring a tech-person is a 6-figure annual recurring cost in most large US job-markets (after you factor in fringe benefits, employer-side taxes etc). That's an Enterprise contract right there, no wonder each one is a unique snowflake of specialness.

I guarantee that the person deciding what a potential hire's salary is going to be is going to consider time-in-the-field, experience with our given technologies, ability to operate in a fast paced & changing environment, and ability to make change as the factors in the initial offer. All things that were involved in the job-req example I posted above. Sub-consciously certain unconscious biases factor in, such as race and gender.

By the time a new Software Engineer walks in the door for their first day they've already been judged better/worse than their peers. Just, no one knows it because it isn't in the job title.

If the company is one that bases annual compensation improvements on the previous year's performance, this judgment happens every year and compounds. Which is how you can get a hypothetical 7 person team that looks like this:

1. Lead Software Engineer, $185,000/yr
2. Software Engineer, $122,000/yr
3. Software Engineer, $105,000/yr
4. Software Engineer, $170,000/yr
5. Software Engineer, $150,000/yr
6. Software Engineer, $135,000/yr
7. Software Engineer, $130,000/yr

Why is Engineer 4 paid so much more? Probably because they were the second hire after the Lead, meaning they have more years of increase under their belts, and possibly a guilt-raise when Engineer 1 was picked for Lead when they weren't after the 3rd hire happened and the team suddenly needed a Lead.

One job-title, $65,000 spread in annual compensation. Obviously, no one has been judged better or worse than each other.

Riiiiight.

Then something like #TalkPay happens. Engineer number 4 says in Slack, "I'm making 170K. #TalkPay". Engineer number 3 chokes on her coffee. Suddenly, five engineers are now hammering to get raises because they had no idea the company was willing to pay that much for a non-Lead.

Now, if that same series were done but with a Fed-style job series?

1. Lead Software Engineer, $185,000/yr
2. Junior Software Engineer, $122,000/yr
3. Associate Software Engineer, $105,000/yr
4. Senior Software Engineer, $170,000/yr
5. Senior Software Engineer, $150,000/yr
6. Software Engineer, $135,000/yr
7. Software Engineer, $130,000/yr

Only one person will be banging on doors, Engineer number 5. Having a job-series allows you to have overt pay disparity without having to pretend everyone is equal to everyone else. It makes overt the judgment that is already being made, which makes the system more fair.

Is this the best of all possible worlds?

Heck no. Balancing unconscious bias mitigation (rigid salary scheduled and titles) versus compensating your high performers (individualized salary negotiations) is a fundamentally hard problem with unhappy people no matter what you pick. But not pretending we're all the same helps keep things somewhat more transparent. It also makes certain kinds of people not getting promotions somewhat more obvious than certain kinds of people getting half the annual raises of everyone else.

Doorknobs are entering the Internet of (unsecured) Things.

However, they've been there for quite some time already. As anyone who has been in a modern hotel any time in the last 30 years knows, metal keys are very much a thing of the past. The Hotel industry made this move for a lot of reasons, a big one being that plastic card is a lot easier to replace than an actual key.

They've also been there for office-access for probably longer, as anyone who has ever had to waive their butt or purse at a scan-pad beside a door knows. Modern versions are beginning to get smartphone hookups, allowing the an expensive (but employee-owned) smartphone with an app on it and enabled Bluetooth to replace that cheap company-owned prox-pass.

They're now moving into residences, and I'm not a fan of this trend. Most of my objection comes from being in Operations for as long as I have. The convenience argument for internet-enabling your doorknob is easy to make:

• Need emergency maintenance when you're on vacation? Allow the maintenance crew in from your phone!
• Assign digital keys to family members you can revoke when they piss you off!
• Kid get their phone stolen? Revoke the stolen key and don't bother with a locksmith to change the locks!
• Want the door to unlock just by walking up to it? Enable Bluetooth on your phone, and the door will unlock itself when you get close!

This is why these systems are selling.

Security

I'm actually mostly OK with the security model on these things. The internals I've looked at involved PKI and client-certificates. When a device like a phone gets a key, that signed client-cert is allowed to access a thingy. If that phone gets stolen, revoke the cert at the CA and the entire thing is toast. The conversation between device and the mothership is done over a TLS connection using client-certificate authentication, which is actually more secure than most banks website logins.

The handshake over Bluetooth is similarly cryptoed, making it less vulnerable to replay attacks.

Where we run into problems is the intersection of life-safety and the flaky nature of most residential internet connections. These things need to be able to let people in the door even when CentryLink is doing that thing it does. If you err on the side of getting in the door, you end up caching valid certs on the lock-devices themselves, opening them up to offline attacks if you can jam their ability to phone home. If you err on the side of security, an internet outage is a denial of access attack.

The Real Objection

It comes down to the differences in the hardware and software replacement cycles, as well as certain rare but significant events like a change of ownership. The unpowered deadbolt in your front door could be 20 years old. It may be vulnerable to things like bump-keys, but you can give the pointy bits of metal (keys) to the next residents on your way to your new place and never have to worry about it. The replacement cycle on the whole deadbolt is probably the same as the replacement cycle of the owners, which is to say 'many years'. The pin settings inside the deadbolt may get changed more often, but the whole thing doesn't get changed much at all.

Contrast this with the modern software ecosystem, where if your security product hasn't had an update in 6 months it's considered horribly out of date. At the same time, due to the iterative nature of most SaaS providers and the APIs they maintain, an API version may get 5 years of support before getting shut down. Build a hardware fleet based on that API, and you have a hardware fleet that ages at the rate of software. Suddenly, that deadbolt needs a complete replacement every 5 years, and costs about 4x what the unpowered one did.

Most folks aren't used to that. In fact, they'll complain about it. A lot.

There is another argument to make about embedded system (that smart deadbolt), and their ability to handle the constantly more computationally expensive crypto-space. Not to mention changing radio-specs like Bluetooth and WiFi that will render old doorknobs unable to speak to the newest iPhone. Which is to say, definitely expect Google and Apple to put out doorknobs in the not too distant future. Amazon is already trying.

All of this make doorknob makers salivate, since it means more doorknobs will be sold per year. Also the analytics over how people use their doors? Priceless. Capitalism!

It also means that doorknob operators, like homeowners, are going to be in for a lot more maintenance work to keep them running. Work that didn't used to be there before. Losing a phone is pretty clear, but what happens when you sell your house?

You can't exactly 'turn over the keys' if they're 100% digital and locked into your Google or Apple identities. Doorknob makers are going to have to have voluntary ownership-transfer protocols.

Involuntary transfer protocols are going to be a big thing. If the old owners didn't transfer, you could be locked out of the house. That could mean a locksmith coming in to break in to your house, and having to replace every deadbolt in the place with brand new. Or it could mean arguing with Google over who owns your home and how to prove it.

Doing it wrong has nasty side-effects. If you've pissed off the wrong people on the internet, you could have griefers coming after your doorknob provider, and you could find yourself completely locked out of your house. The more paranoid will have to get Enterprise contracts and manage their doorknobs themselves so they have full control over the authentication and auth-bypass routes.

Personally, I don't like that added risk-exposure. I don't want my front door able to be socially engineered out of my control. I'll be sticking with direct-interaction token based authentication methods instead of digitally mediated digital token auth methods.