December 2013 Archives

Unions and tech-workers

My fellow technologists are some of the most rabid anti-union people I know. However, I believe there is a kind of union that we can actually benefit from. Read on.

By far the biggest complaint I hear against unions is this one:

BozoBob does a fifth of the work I do and he gets paid the same. How the **** is that fair? ****ing unions!

With a distant second of:

BozoBob has been here fifteen years and does half of what I do. So why the **** am I getting laid off and not him? Seniority?? ****ing unions!

Now that the big critiques are on the table, to look at what unions could bring to the the tech worker market I'll need to set some definitions.

Tech Worker(a): The intuitive definition of this is, "People who work in tech the way I do", which for readers of this blog is primarily the systems administration space and closely adjacent areas like software engineering and network engineering. These are people who work with tech, tend to be highly skilled, and also tend to be highly mobile; if a job is crappy, get a new one, there is always one out there for you.

Tech Worker(b): Now there is a different class of worker out there. These are people who work for tech, so the food service workers at the Google Cafeteria, the massage therapist working for a tech startup, the accountants who do the taxes, the travel specialists who arrange conference travel, the driver of the shuttle bus that brings workers from the affordable part of town to the company campus. These are the people who work for tech who aren't getting six figure salaries and can't necessarily leave a crappy job for a new one at the drop of a hat.

Exempt Employees: A bit of a labor-relations term, but this refers to the Fair Labor Standards Act definition of an employee who is exempt from mandatory overtime. There is a lot of labor law, and worse, case-law, that goes into defining who is owed what for hours worked and I'm not going to get into that here. Employers really like to employ nothing but exempt employees because it means they don't have to track hours worked, and don't have to pay anything extra if everyone is putting in 60 hour weeks.

Tech Worker(a) is almost always Exempt.

Non-Exempt Employees: As you'd expect, these employees earn overtime and are almost always hourly. And frequently part-timers. In many cases employers set rules in place to prevent the earning of overtime unless specifically cleared, which in turn guarantees a maximum 40 hour work-week for these employees.

Tech Worker(b) is often Non-Exempt.

Independent Contractors: a.k.a. "1099 workers". These are not employees of the company, they're employes of another company paid to do something the company wants. That 'other company' may be the employee themselves acting in a corporate way, or it could be a personal-resource firm. Such workers rarely have benefits provided by the company itself, expecting the contracted company to provide for it. They only get 'overtime' if it has been specifically negotiated.

(If you've ever wondered why in blazes contractors charge $200/hour for their work, it's because they're having to pay for their own health coverage, both the employee and employer FICA payment, and other such 'invisible' costs of employing someone).

Traditional Unions

The ones everyone loves to hate (see above critiques for the biggest hate-sources) came about as a push-back to excesses business took during industrialization. Textile work, assembly-line work, and all sorts of other big-headcount industries needed workers, and they didn't need particularly skilled workers since most of it was learned on the job. Which meant that if an employer didn't like a worker for some reason, they fired them and got a new one since there was always another hungry mouth to take the job and wouldn't be such a problem.

So if you wanted to keep your job, you kept your mouth shut and didn't make waves. Which in turn meant putting up with working 6 days a week, being asked to work late for big jobs, possibly buying all of your work-equipment at the company store (at company prices), and a whole bunch of other things. When you are a faceless cog in a sea of cogs, saying "I am special!" means you just get replaced with another faceless cog.

DevOps is all about removing "I am special!" virtual-machines from a sea of identical cogs; er, virtual machines. Yes, I do sometimes worry about the robot revolution.

Traditional unions came about as a way to push back against the exploitation business owners found so profitable. If all the faceless cogs band together and say, "Oy, enough with the 12 hour work days already," it's a lot harder to ignore them. The owners sure as hell tried, but once union penetration in a given industry is high enough there isn't a big enough pool of faceless cogs to ruthlessly exploit without side-effects, which in turn means they have to improve working conditions to compete with the unionized workplaces.

Traditional unions as most people understand them work best in industries where workers are easily interchangeable. The power each individual worker has is so small that there is no leverage for them to exploit other than banding together to pool their power. Seniority is a fair proxy of effectiveness as a worker since actual training only goes so far.

Traditional Unions and Tech Worker(a)

Tech Worker(a) is:

  • Highly skilled.
  • Specialized in diverse technologies.
  • There is a shortage of such workers in certain markets.

Tech Worker(a) is not:

  • Interchangeable with each other.
  • Quick to train up from scratch.

Tech Worker(a) is a very poor fit for traditional unions, as they do not fit the profile of 'exploitable class'. This is a problem for the US Civil Service, which is largely unionized; they have a hell of a time retaining this class of tech worker. Those that do stick around in Civil Service do so for reasons other than monetary.

Traditional Unions and Tech Worker(b)

These are workers who could benefit from a traditional union. These workers are working for companies that grew up thinking they only employed type A tech-workers and have a second class of workers supporting them. A lot of the 'support' roles may be filled by Independent Contractors, who in turn just may belong to a union such as the SEIU, IBEW, or CWA; the labor relations part of HR is handled by the contracted agency not the tech-company itself

Tech companies frequently do 'outsource' such services as the ethos of:

Do what you do best,
If you're not the best, pay someone who is the best to do it,
If you can't find someone who is the best, find someone who can be the best and help them become the best.

Is very prominent. This is why the -as-a-service movement is taking off, and the same model works for staffing the company cafeteria and running the employee-shuttle fleet. In many cases, it's not Google we should be pushing to allow unions in their support tier, it's the contractor Google pays to provide the support services. And if it so happens that Google is directly employing these people, then definitely push for collective bargaining.

Tech Worker(b) is the traditionally unionizable class of technical worker. Tech companies resist unions for many reasons, chief among them being they haven't had to deal with them before and they're good at increasing costs; very much against the lean concept.

Non-Traditional Unions

Or, the unions people don't think of as unions.

These come in a couple of different types, from Professional Organizations like AICPA for accountants and NCBTMB for massage therapists, to the wobblies (IWW) which push for unionization across the entire workforce rather than just one sector of it.

LOPSA is starting down the Professional Organization path with the LOPSA Recognized Professional program they announced at LISA 2013.

Professional Organizations often have some interaction with state/county/local government license boards, which gives them some geographic cover. AICPA manages the CPA exam. NCBTMB manages the national certification test, and ABMP does legislative advocacy and provides insurance support for massage therapists. There are others out there, and these tests/exams are in place to ensure that people who claim to be a certain type of professional actually have a minimum amount of knowledge and commitment to continuing education.

Such organizations are less concerned with working conditions than they are with ensuring the profession as a whole is viewed positively, and people know what to expect when they hire that kind of professional. Some do work against professional exploitation and can even bring sanctions down on workplaces who violate codes of conduct. These are unions, they're just named differently.

Professional Organizations and Tech Worker(a)

As I mentioned earlier, LOPSA is taking a step down this road for the Systems Administration profession with their LOPSA Recognized Professional program. This is not without controversy as the audience at LISA13 demonstrated, and the ongoing debate in the mailing lists and elsewhere continue to show. It's a move by a professional organization that represents a minority of the profession attempting to set a standard for the whole profession, for the betterment of that profession.

Vendors have been doing this for years, though not under the guise of a profession. The Cisco series of certifications are commonly used as gatekeeping tests for hiring network engineers. LOPSA is attempting something similar with the profession, we'll see if there is any traction there.

Professional Organizations don't do collective bargaining the way traditional unions do, they're more about indirect influence. LOPSA won't call a strike against, say, ACME Widgets; and even if they did it wouldn't be legal so ACME Widgets would be perfectly in the right to seek legal action. No, they're much more about making sure the profession as a whole is supported and has some form of group advocacy pushing for improvement.

Like traditional unions organizing an industry, Professional Organizations are more effective the more people belong to them. LOPSA represents a minority of systems administrators right now, so they face an uphill battle to professionalize it. In 10 years that may be different, and LOPSA membership may be on most system-adminsitrator resumes.

The Professional Organization is the kind of collective action entity that Tech Worker(a) can actually benefit from. It leaves individual salary and compensation negotiations in the hands of individual workers, and doesn't have any bearing on who gets the axe in a layoff. It can, however, recommend minimum acceptable benefits and compensation levels for these workers which will aid in salary negotiations by individuals. They can provide backstop health and/or liability insurance for independent contractors at rates much better than individuals can obtain. They can provide industry-proficient legal support, or referrals to such. They work with the educational sector to ensure up-and-comers get what they need to join the profession.

Professional Organizations and Tech Worker(b)

Some of these workers already belong to Professional Organizations. The CPAs that do the company books? AICPA. The massage therapist in the headquarters Health Center? ABMP or AMTA. The tech companies that employ them are already used to working with the members of these organizations, and by extension the organizations themselves. Individual barganing is very much a lean concept, and these organizations maintain that.

Tech workers like myself can benefit from collective action. The best template for us is the Professional Organization: active in advocating for the industry, provides support for members, and helps ensure the educational pipeline is adequate for supporting the profession.

Systems Administration can benefit from professional organizations, and so could Software Engineering.

tl;dr: Unions bad. Professional organizations, a kind of union, good. We should get some.


You're on-call and have the on-call phone. Tonight you're going to a Thing that requires formal dress, and that means... a dress. Which in turn means no pockets, and therefore you'll need to set the on-call phone to an audible alert since there is nowhere to put it where vibrate would be felt. And yet, where you're going needs to have phones turned off. How to you go to the Thing and be responsive to the on-call phone?

In olden days it wouldn't be an on-call phone, it would be a pager and pagers are smaller than phones are now. A pager could be tucked into a bra, an iPhone is too big for most people to fit.

It'd be nice if there was a wearable thing that could act as the phone's remote notifier.


It's your week on-call, and you're going to be in a meeting for the next two hours. Things have been hopping lately, and you're expecting to get buzzed. Company culture frowns on having phones out at meetings, but they're at least accepting of watch-standers getting up in the middle of things to deal with emergencies. You can either ignore your pages, or keep checking your phone and get frowned at by the VIPs at this meeting.

A remote notifier would be nifty.

Technology is coming for you!

Smart Watches

These are getting mixed reviews, but they fill this role. Like the calculator watches of elder years, they're big things that are kinda obvious. These would be just fine for the meeting scenario above, but not so much for the formal event where watches, if worn at all, are expected to be dainty things with tiny little watch-faces. The fact of the matter is that these days watches are jewelry and status-symbols not the utilitarian pieces they were before everyone had a watch in their pocket connected to a wireless network's time provider.

Smart Bracelets

These are somewhat dumber versions of the Smart Watch, but they pass for jewelry a lot better. Which matters. Here are a couple, both in pre-release.


This is a vibrating module that fits into a colorful plastic band that looks a lot like those pink/yellow/blue rubber bands people are wearing these days for things like Livestrong. This works on anything with bluetooth, and they even have an extension thingy that allows it to go around your ankle. Yes, people don't even need to know you're wearing it. The removable module even allows a repeat of the old pager-in-the-bra trick.


This product ups the fashion factor a lot versus the Vybe, and is something you could wear where you wouldn't wear an awareness wristband. This is iPhone only for now, but has the added bonus to allowing the notifier to only buzz when specific contacts are calling; providing a nice way to only get buzzed when the on-call system is calling and to ignore seldom contacted relatives calling at bad times.

I'm thinking real hard about getting something along these lines. Pre-release and works with anything? Pre-release and iOS only? Or released and limited to a certain manufacturer? Don't know yet.

There is a market for this


Don't want the person sharing your bedroom to wake up when you get paged?

There's a widget for that.

If you're a deep sleeper and share a bed with a light-sleeper, this just might be the thing you need to let them keep sleeping after that 1:30am call. Or the thing to let you know you need to check your phone in the middle of a meeting. Either way, sysadmins are a market for this thingy!

The tech-perk you don't think of


On reflection "tech company" here is really, "tech company big enough to have a large corporate head-quarters". The startup I just left had:

  • No cafeteria, but we did have a kitchen that we shared our meals at when we went out to get stuff and the once a week company paid lunch. No stove, though.
  • No gym, but the building we rented our space from had a gym floor we could use.
  • No game room, more of a game-nook.
  • No wet bar, but beer did get put into the grocery order once in a while. No hard stuff or wine though.

However, that startup was in year-3 of a significant baby-boom. In my time there we'd had people do work-from-home days, late-start days and early-departure days due to daycare problems. If you're the primary care provider for someone under 4 years old you will only be able to answer the odd email while you're at it and will live for kid-naps.

A corporate daycare perk seems like a win: what parent wouldn't want to check in with their kid over lunch, and companies would get more out of their employees.

On-site day-care has some strict labor requirements though, so it's only for companies big enough to support full time dedicated support people. If they can afford personal trainers or professional chefs five days a week, they're probably big enough to afford day-care professionals.

As I look around the industry with an eye towards further employment, I've noticed a difference of philosophy between startups and the more established players. One easy way to see this difference is on their job postings.

  • If it says RHEL and VMWare on it, they believe in support contracts.
  • If it says CentOS and OpenStack on it, they believe in community support.

For the same reason that tech startups almost never use Windows if they can get away with it, they steer clear of other technologies that come with license costs or mandatory support contracts. Why pay the extra support cost when you can get the same service by hiring extremely smart people and use products with a large peer support community? Startups run lean, and all that extra cost is... cost.

And yet some companies find that they prefer to run with that extra cost. Some, like StackExchange, don't mind the extra licensing costs of their platform (Windows) because they're experts in it and can make it do exactly what they want it to do with a minimum of friction, which means the Minimum Viable Product gets kicked out the door sooner. A quicker MVP means quicker profitability, and that can pay for the added base-cost right there.

Other companies treat support contracts like insurance: something you carry just in case, as a hedge against disaster. Once you grow to a certain size, business continuity insurance investments start making a lot more sense. Running for the brass ring of market dominance without a net makes sense, but once you've grabbed it keeping it needs investment. Backup vendors love to quote statistics on the percentage of business that fail after a major data-loss incident (it's a high percentage), and once you have a business worth protecting it's good to start protecting it.

This is part of why I'm finding that the long established companies tend to use technologies that come with support. Once you've dominated your sector, keeping that dominance means a contract to have technology experts on call 24/7 from the people who wrote it.

"We may not have to call RedHat very often, but when we do they know it'll be a weird one."

So what happens when startups turn into market dominators? All that no-support Open Source stuff is still there...

They start investing in business continuity, just the form may be different from company to company.

  • Some may make the leap from CentOS to RHEL.
  • Some may contract for 3rd party support for their OSS technologies (such as with 10gen for MongoDB).
  • Some may implement more robust backup solutions.
  • Some may extend their existing high-availability systems to handle large-scale local failures (like datacenter or availability-zone outages).
  • Some may acquire actual Business Continuity Insurance.

Investors may drive adoption of some BC investment, or may actively discourage it. I don't know, I haven't been in those board meetings and can argue both ways on it.

Which one do I prefer?

Honestly, I can work for either style. Lean OSS means a steep learning curve and a strong incentive to become a deep-dive troubleshooter of the platform, which I like to be. Insured means someone has my back if I can't figure it out myself, and I'll learn from watching them solve the problem. I'm easy that way.