Updating classic workplace sabotage techniques
antipope.org
antipope.org
Both careers are technical and require both concentration and collaboration. Actuaries tend to have their own cubicles (offices for mid-level and higher).
Software developers require much more concentration. So I just assumed that the virtually all software developers would have their own offices because a solo cubicle seemed inadequate for most developer jobs. And of course, who would be dumb enough to use open office for developers? ... well, I got a little surprise.
Everyone tries to undo the damage of a bad floor design with expensive headphones, but it's just not adequate.
Another trait, it took me a while to notice. I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don't know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important. Now I cannot prove the cause and effect sequence because you might say, ``The closed door is symbolic of a closed mind.'' I don't know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing - not much, but enough that they miss fame. -- Richard Hamming
A. Individual office with open door
B. Open plan office
This would create a good enough sense of intimacy and would be obvious to people that when they pass the space of you non-existing door they are entering your space so they should have a reason to do it and you acceptance. And of course, having an actual separate ceiling atop your office is important - the visual part matters, we need the feeling of "private cave" even if we agree to share it most of the time. And open space above only brings anxiety and makes you feel that you are in an open savannah and a predator can jump at you from behind the bushes anytime.
But of course, we live in a plentiful age, obsessed with efficiency (oh, the bitter irony of the contradiction...), so all that wasted space and extra paid on rent because open-office spaces are probably cheaper is a no-no...
Exactly. And Hamming didn't work in an open plan office at Bell Labs. The fact that he writes about open vs. closed doors implies that they had offices with doors.
"I'd imagine the ideal would be individual offices with no doors"
Doors are very useful to have, even if they remain open most of the time:
- Closing your door allows you to have a meeting with a couple of people in your office without disturbing your neighbors.
- If you manage people, you'll need to be able to have private conversations with them (e.g., performance reviews).
- Sometimes, you really need to concentrate on a difficult problem without interruptions.
- You'll occasionally want to be able to have private, personal phone conversations, e.g., with your doctor.
Then I'd use them as some kind of status token, to gamify things a bit. Mangers would have offices with doors by necessity, for private conversations with employees etc. And for the rest, if you are a lead developer, or tech lead or senior developer, than you get a door added to your office. Otherwise the hinges stay, but no door... like a hint of "when you'll get better, you'll get that door" :)
I can't tell you how much time I've lost to the porcelain throne! (I never measured it) but I do know that I want to get ahead, and when I get to do a crap in a cubicle with a door, I'll have made it!
P.S. This is why wifi and laptops are so great. A lot of thinking time can be had on the dunny. To really get your creative juices flowing, encourage your employees to think about direction on the bog. You could get your next Gmail there. Think of it as 10% time, without need to allocate the 10%. Your employees will thank you!
If its a quiet-low-traffic work environment, then open door is perfectly fine, but if not, then it won't provide the quiet that a closed door does. I don't care about privacy, I care about (lack of) noise and distractions.
My ideal setup would provide a communal quiet library-rules room with couches; sound-proofed meeting rooms with doors; breakout areas for groups to sit and talk; hot-desking space; and 1-man offices with doors. Then allow people to use them as preferred or necessary for the work they're currently doing.
Failing that, at a minimum have open-plan + plenty of silent "library rules" space.
> "when you'll get better, you'll get that door"
So, you want to sabotage my work quality until I produce better quality work?
EDIT: Forgot to say that movement (seeing people walk past out of the corner of your eye, for example) can be just as distracting as noise.
Although I wouldn't count myself as successful by any metric, I still think I've picked up a lot of interesting and useful stuff though osmosis, stuff that a lot of people not exposed to the same things only realize a few years later when it hits the mainstream and becomes part of the zeitgeist of Western culture (and so much else that never hits a more general audience but still holds promise within their respective niches if one can connect the dots).
Open office plans force the open-door mode, and make the closed-door mode quite hard (if not impossible for some people) -- not everyone is comfortable wearing headphones all day, people will interrupt you anyway with headphones on, etc.
Open office has you surrounded, including people behind you and in your peripheral vision. It's much less comfortable and causes a little anxiety. And your attention constantly gets ripped around in every direction.
An office with an open door is still better for getting stuff done today than a cubicle, which is still better than open plan.
Ie the right tradeoff might still be to open your office door, but that doesn't say much about putting yourself into an even more exposed position.
If I was in HR I'd be keeping a close eye on you.
This might be the joke
1st. She trashed talked what was done before.
2nd. she took away any coffee or tea provided for employees to use, saying it cost $10000 a year to provide them.
3rd. Then she got a plan for a complete renovation of the office space, so executive officers had offices in the middle of the building that looked out over what would be open plan offices, so that no-one had the slightest bit of privacy at all. This was not done to fit more people in.
4th. Then a move to a completely different state in the country was being talked about.
I am glad I don't work there any more.
Edit: Formatting.
In order to believe that they do, you essentially have to have such an unrealistically hyperbolic discount function that you believe marginal productivity of your workers is nearly worthless compared to the up-front costs of the real estate.
Jim McCarthy, the originator of the "guy in a room" quote, has indicated that it's not to be taken merely metaphorically, that offices encourage isolation and "going dark", and open plan is key to productivity, collaboration, and accountability.
http://www.goodreads.com/book/show/1416996.Dynamics_of_Softw...
In my experience daily standups are often enough to keep everyone on the same page and make sure no one is dashing off in the wrong direction.
I once worked with a programmer who needed to externalize thoughts before he could make sense of them. He needed a sounding board and was constantly talking to anyone who would listen and respond. That was his thought process.
I, on the other hand, need to internalize thoughts before I can make sense of them. I need silence to process and chew on a problem for at least a couple of minutes before I can talk about them to others. That is my thought process.
We worked together on exactly one feature. He would get frustrated because when he talked to me, he got nothing in return. I was too busy listening to respond and as a result he kept talking, which frustrated me to no end because he gave me no time to process what he was saying.
Neither of us got what we needed, so he finished the feature by himself and I moved on to a different one.
My co-worker loved open office plans. I hate them.
Something that doesn't often get mentioned is it also works the other way around: if the quiet programmers exert their influence over the open office so it's quiet, that hampers the efforts of those who need to verbalize to think. The "oppression" goes both ways.
I'm not naive. I don't think companies will ever go back to individual offices for everyone. But putting a soundproof barrier down the center of a bullpen is doable. One side is for the loud folks, the other for the quiet ones. Everyone can hop from one side to the other as needed.
Not when people are having a conversation with the people sat next to / opposite you and you're trying to finish a complicated feature. An office or cubicle would help (but probably not stop these assholes) because it sends the signal that this is a workspace, not a communal chat space.
Also we don't have enough meeting rooms to accommodate even scheduled meetings which means "camping out in empty meeting rooms" is a non-starter of a suggestion, sadly.
I've had VPs ask me about how productive those programmers were with side remarks about seeing them frequently talking with front desk and hr (presumably socially). One was really productive so not really an issue for me but not good having to explain that.
Developers like that are hugely valuable in a start-up, they talk to everyone, get to know what their jobs are, and are the people you go to when you need to know what the problems internal users are facing really are.
I wish it was easier to move from an open space model to a walled one depending on the needs. After a few years I started hating having headphones all day long, so my solution is to get away from my desk and find odd places where few people go, but it's of course not scalable nor comfortable.
I get 15-20 hours of the noise cancelling feature out of a single AAA battery. They'll still work pretty well without the noise cancelling turned on due to their shape.
I have an office room although most colleagues are in open office with low-wall cubicles. Still, I find I can get more done at the hours when office is empty.
Maybe it applies to people slapping together node.js libraries, but otherwise developers need a working environment in which they can focus.
Creativity is not only about innovating at the bleeding edge, but also coming up with effective solutions, optimisation, designing software, organising code, etc. A lot of software development is creative work.
Besides, not being able to focus will also lead to increased stress levels, overlooking bugs and decreased productivity.
The big reason why management likes open office is, in my opinion, that those environments make them feel like they've got more oversight and control.
I work at a startup with open offices (my second) and the absenteeism blows me away. I really believe it is because the office is an unpleasant place to work. But hey, we have ping pong tables!
It seems to me like the real questions here is "what is the percentage of people who are more productive with offices than with an open arrangement?" Based on the comments here on HN, it's skewing toward offices, but I think that might be a self-selection thing. I certainly don't think it's a forgone conclusion that offices are better for everyone.
Incidentally, I have a marginal preference for offices, and I have gone the expensive headphone route. I guess I'm in line with the "HN commenters" sub-population :)
It would be interesting if a researcher tried to quantify this with volunteers from different companies with differing floor plans.
Interestingly, even if one consciously ignores the noise, its effects are still visible in the body through blood pressure spikes, increased stress level hormones, etc.
So, by that vein, do you prefer having lunch breaks where you eat at your desk or do you not care about your work? Which is it? Because clearly working through lunch is more productive, so if that's not your choice then you are lazy and not motivated.
However, open plan offices make it so work time is always noisy and you have to work to avoid making eye contact with others. That's going to make it much harder to be productive, regardless of how much productivity one desires to achieve. Employees who prefer chit-chat to productive work are going to prefer open offices because it decreases productivity on the whole, which means they'll have to compete less with others to appear useful, and because it makes it much easier to start a conversation and otherwise engage in non-work social activity.
To clarify, I'm not saying there's anything wrong with preferring chit-chat to productivity per se (again acknowledging that this is the preference of the vast majority of employed persons), especially when management is sending a clear endorsement of that perspective by literally removing all barriers in the office and throwing everyone into a giant single room. I'm just saying the people who are usually annoyed by open plan offices are usually people who come to work to concentrate on a task and get it accomplished, rather than people who come to work mainly for the external social engagement.
For me, I learned to program as a hobby, from ages 10-18, for fun at home. I mostly worked alone. Learning to work on a team took some time, but even now I often times wish I could work remote. I don't mind getting pinged about things people need, but the constant noise and movement of the office makes me far less productive than I would otherwise be.
However, sometimes it offers me the focus I need to actually work, if I'm in a procrastinating mood. And I think some people probably struggle with this more often than I do.
I feel much more productive working in an open-plan office than working alone. :s
I agree with your sentiment. Being nearby passionate workers is empathetically energetic, and adds motivation for me to do even mundane tasks. I develop a sort of weak rivalry around my peers and I'll rise to the "highest" level that I perceive. It's very encouraging to be around intelligent and motivated people, and being exposed to them is nice.
Conversation/talking can get out of hand, but that depends on both who's contributing and who's not intervening. I've only had open office conversations go too far when nobody wants to tell those involved to stop/quiet down/etc.
I think for a lot of the professions on HN, the solution to "open office bad" is to work remotely, and I think it's very unfortunate when employers disallow/discourage that options, as many people are genuinely more productive at home and/or working odd hours. While there's a pretty decent stigma of "working" from home, there are some people who genuinely are productive and can actually work from home, no quotes needed.
I contract full time as well as working on my own projects. I'm often called in to augment other teams either IRL or remotely and I genuinely do enjoy that, at least in the short term.
The other days though - I wake up early, a full queue, clear scope, plenty of energy, coffee, work while the sun's rising. 11am hits and all of a sudden it's just...lonely. Hit's me like a brick some days. That's usually when I head to a coffee shop or into some co-working space. It's a funny thing.
Edit - Spelling
It makes me mad that people think fixing the problem is wearing headphones.
I wish wish wish! I had some modicum of privacy and sanctuary at work so I could just sit down with only the problems in my screen unless intentionally interrupted.
Unfortunately these do tend to be contracts rather than employment oppties, but that can sometimes be good (higher rates, though you need to buy your own benefits).
When it's just people coding, normally interruptions are things that make sense. How should I build this or that thing? Where can I get help with X?
However, for many years I had a guy in the office who was a pontificator. He would read some news article and start a debate about (inevitably) politics. People would get drawn into it due to his particular style (very opinionated, uninformed) and the debate could easily eat up the entire morning or afternoon. He would literally stand up and announce some funny point he'd come across, loudly.
Ate up enormous amounts of time.
a) saves money on furniture and real estate costs (visible on the bottom line; productivity losses aren't)
b) provides for free a panopticon under which your boss knows where you are and what you are doing, or can at least ask your coworkers and expect them to point you out to him
Surveillance is a useful tool for sucking surplus value from our minds. Open offices make ordinary workers (slackers) uncomfortable because of constant surveillance by management, but work isn't about making workers content. Work is about dominating workers so they produce.
An added benefit of the panopticon pen is that it's harder for devs to slack, sabotage, and organize. A watched worker is an easily controlled worker.
Actuary is respected profession. There is lots of responsibility and they have higher median salary than programmers.
Programmers are dime a dozen. Only top level architects have status. If programmer is highly valued, he usually has some other title than programmer/developer.
Of course, most companies need only a few actuaries, so giving them a handful of offices is easy. If you have a company that's mostly engineers, that's gonna look different to the beancounters.
I also like that we each have a whiteboard, plus whiteboards in the "hallways". Anything important tends to go to text, one way or another.
I'm apprehensive about working in an open-plan office, or some arrangement with a shared desk. One concern is constant movement in my peripheral vision. Another is degradation of communication. I like my text. Having something written means that I don't have to ask someone to repeat themselves again. Add to it: Half my team is remote, so no office layout will change how I communicate with them (IM+email).
Then again, I've never worked in an open plan office. Maybe I'd like it, and the things that I see as potential issues would dissolve away...but it seems like a panopticon-distraction fest, looking at it from the outside.
http://www.wiregrass.edu/images/library/benhillLibrary.jpg
The people who thrive in open office plans can thrive while the people who need some space can have their space.
And it's easier to indicate to the rest of the team that you need to be not disturbed with stuff like those expensive headphones than to go wander the hallways to other people's offices, or have to organize meetings whenever you want to have more than 2 people in a quick huddle.
If you're working from specs on a multi-month timeline, sure, lock me away into an office and I'll come back with what you asked for. But if you want to work quickly, build MVPs, iterate with customer feedback, and change direction quickly, an open floor layout is infinitely better even if it makes a couple antisocial engineers grumble about it on their blog.
The irony is that at one point for a two month crunch period they did give me exactly that (repurposed a meeting room for me and a team mate who was not very talkative). Most productive two months in my entire career. So, management clearly knows the open plan is detrimental to productivity. And yet...
But for me, software is a calling.
It's not for everyone, but in tandem with mandatory-no-meetings beyond a 5 minute daily standup and couple of set hour-long meetings every week, this can lead to very productive working days.
* The office zone starts right behind a reception and only separated from a receptionist by a thin glass wall, slightly wider than receptionist's desk. When I arrived, reception wasn't manned, so after hearing me ringing the doorbell several times, some developer interrupted his pair coding session and walked down with an irritated face to open a door for me. I can only imagine how many breaks in coding do FedEx delivery people ensure.
* The open plan office itseld is slightly prolonged and has long "corridor" areas cutting through it. I can only guess why they want to maximize the number of developers whose backs and monitors are turned towards everyone who passes by.
* The desk density is super high (it may even beat Facebook's, but my perception may be wrong here).
(update) Also, during a pair coding session I took part in, two men and me were enthusiastically discussing the code we wrote. 40cm away, at another desk someone was trying to get on with their work and was visibly irritated. So it might be that open plan is not so great for pair coding after all.
I remember watching a video about Pivotal's offices and work routine. The distinct impression I got is that Pivotal is a very regimented sweatshop with rigid working hours - everyone is expected to show up at 8am for breakfast, and pair-programming and a "panopticon" style open office layout are there mostly to prevent procrastination and force people to at least try to code. The good part is that the developers there have a set 8 hour workday and leave earlier in the afternoon. It obviously works for them because they can just churn out sort-of working apps and let some other suckers deal with maintenance/rewrites later.
You use the term sweatshop, and then say everyone goes home early. Really?
" rigid working hours"
Business hours are not for everyone, but they are for a lot of people, and they help foster collaboration.
"everyone is expected to show up at 8am for breakfast"
Not mandatory (it's an incentive to come in on time), but it is free.. As is lunch. Not dissimilar from most SV companies.
"mostly to prevent procrastination and force people to at least try to code"
So, it's a sweatshop because people are encouraged to work, and not browse Facebook behind a closed door?
There are lots of opportunities to take a break, from Xbox to ping-pong.
"It obviously works for them because they can just churn out sort-of working apps and let some other suckers deal with maintenance/rewrites later."
This is quite a conclusion to draw from a video.
You do realize that outside of R&D, most Labs teams are balanced customer/Pivotal pairs? There is no belief in handing over to a maintenance team, let alone doing the development by ourselves. You build it, you run it, is the mantra.
The whole business model is to build products while teaching companies a culture (open, Devops, collaborative but high discipline) and process (XP, CD) and tools (PaaS, open source) of how to build software productively.
It is a sweatshop because management is trying to impose a rigid pace of work and a surveillance scheme on employees.
The word "sweatshop" is traditionally (AFAIK, don't have access to OED right now to confirm) associated with garment cut-and-sew workshops, which are organized exactly like an open plan programming office: https://duckduckgo.com/?q=sewing+factory&t=ffsb&iax=1&ia=ima...
The false dichotomy you present (you are either working exactly like we tell you to work when and how we tell you to work, or you must be slacking off) is exactly the kind of rationalizing used by sweatshop managers who are trying to break unions or deskill workers. I recommend reading David Noble's _Forces of Production: A Social History of Industrial Automation_ and Ellen Rose's _User Error: Resisting Computer Culture_ to learn more about how and why these efforts are used, why they are counterproductive, and to learn how to recognize when management is trying to apply them to your work as a computer programmer.
Sorry, that's nonsense. Instead of "rigid" and "surveillance", I'd say "disciplined" and "actually managed". As opposed to "do whatever you'd like" and "unmanaged".
What's the difference of a disciplined culture and a rigid culture, or surveillance vs. actual management? I'd say it's whether the employees actually WANT and VALUE these things.
In my experience, everyone here WANTS a strong discipline of TDD, pairing, CI/CD, 8 hour work day, etc. And everyone WANTS a strong product manager and product owner that knows what's going on with the latest stories, bugs, and velocity. It makes for a better product, team, and morale.
Now try walking normally for an hour.
Which makes you the most tired?
I'd posit it is a much more fulfilling experience to put a full 8 hours x 5 days sustainably, than the industry's usual "crap we need to work evenings and weekends, we're late"
I could see this being argued for the traditional game development industry, which was plagued by long hours, harassment, and shit pay.
I think you've already recognised the work hours aren't for everyone in your previous comment, so it sounds like Pivotal's hiring policy is pretty solid on this point. And in fact, it's not even an unreasonable expectation for everyone to come in on time, but probably a less popular one on HN judging from the downvotes you are getting.
To be honest, it's a model I prefer. In my previous workplace I worked ridiculous hours due to understaffing and a few other issues and had to resign from burn-out. I'd much prefer to work for a Pivotal than I would a company like the last one I worked for :-)
Heck, if Pivotal can get all their work done without a final crunch time, that's actually pretty amazing! I'd go so far as to say that I've never heard of a company who got this working before, so if that is the case then Pivotal are clearly doing something right.
If only you were hiring in Australia, I'd seriously consider applying :P
I hadn't really seen it before either, TBH. It is not perfect - sometimes we ship late. But that's part of the culture - Pivotal Tracker (www.pivotaltracker.com) tells you the date you're expected to ship given the work you have left, you don't tell it when to ship ;)
Management won't break people over a deadline, they'll generally slip the date. Sustainability is more important.
We do have a small/growing office in Sydney with a few openings: http://pivotal.io/locations/sydney
Sorry you had a disappointing experience.
Sounds extremely stressful
It's not for everyone, and there are some "consulting" individual contributors here and there, but the point is to have a sustainable pace that's always "busy" and everyone is "checked in" rather than have a few weeks of "crunch time" to meet a deadline. Some need to "check out" for a while, that's also fine.
Most product cycles last 3-4 months, and it's up to you if you want to switch teams. some don't.
Does any company give new software developers offices?
Software developers grow up with more screen time than others. They need forced interaction in order to communicate enough in person. Otherwise it's all by text and can easily degrade to passive aggression.
Offended? Cool.
When software engineers demonstrate they will come out of the office to speak in the open when needed, then they deserve the office.
But, I imagine if you gave everyone one, many would hide in there and only exit for the bathroom and food.
An A/B test of workplace environments might be a cool experiment. Targeting the same product with equally skilled developers, which is more successful?
As an extremely vocal individual, being vocal actually is a loss in productivity. When I am trying to communicate what I am doing to my co-workers - it leads the project from slowing down - and me unable to meet my deadlines.
This is why I do not like to waste my time explaining others what I am doing. Its more productive for them to specify the Inputs and Outputs and me doing my thing.
You're talking about someone who is too noisy. This kind of person probably benefits from an open environment with instant feedback. Even though the group may suffer a bit short term, in the long term, that person will be a better team member when they learn when and how to speak.
People who are too quiet can also benefit from being among a respectful group. Safety in numbers, and you can learn from your peers.
These are not hard and fast rules. I'm just discussing times when open environments can help teams. The parent of this thread did not mention any of the benefits of open offices.
Yup it is a sweeping generalization. I'm comfortable making it. I am/was one. It's totally anecdotal, based on my 15 years experience in work and school environments around both engineers and sales-y type people. The engineers are, on the whole, way more comfortable with screens than people. There's absolutely nothing wrong with that.
I'm not aware of any published research but if I were going to design an office I'd try to research people's experiences by asking friends or Google [1]
All engineers are different and there are many who prefer people to screens. I think the rest of my first comment explained that people are not all the same and can change over time.
I would never create an office seating plan without getting to know each individual. I would also change it up over time. Sitting in the same place all the time for years is too boring.
[1] https://encrypted.google.com/search?safe=off&q=software+engi...
Sure, there are individuals at any point on the scale. We're talking about averages though.
I have no qualms about disagreeing over where the averages lie. In fact I would widen my generalization and say that younger people are, on average, more comfortable talking through screens than directly person to person. Young engineers are just a subset of that who I think are more likely to be screen focused.
I'm okay with embracing some elements of stereotypes. Denying them entirely seems like an equally useless generalization.
This sub-thread was started by someone who felt open office environments aren't effective. Yet, open offices can be a tool for getting people used to person to person interaction. Every person, group, and organization will decide whether they think that's important or not.
Open communication within any organisation is very important so a developer who sits in his own office all day is a concern I'm in agreement with you. I guess I'm just not convinced of the reasons for the behaviour. But I think your observations are interesting and valid, so I appreciate you taking the time to give me a solid answer!
> I guess I'm just not convinced of the reasons for the behaviour
Reasons for behavior, even for a single individual, are super tough if not impossible to nail down. But we can make some educated guesses based on correlations. If we prevent ourselves from forming such hypotheses, life might get pretty boring. In hindsight, my original statement could be more accurately prefaced by "in my experience, ..."
I like to answer questions, technical or not, and it's really nice to be able to exchange ideas with someone (who was lurking on slack, anyway), from times to times.
If not, I agree it makes no sense. I guess it can cut down on frivolous browsing.
I guess it sounds weird if you've never done it, but it works really well.
Now and then, someone will ask "Hey, does anyone know X?" or something else, and issues will be resolved quickly. One counter intuitive thing that makes this possible is that since you're already engaged in a conversation with your pair, this turns out to not be disruptive.
Concentrating deeply means you're keeping too much state in your head. Write more tests instead. If it's still a problem, bring a co-worker over, or better yet, pair program. It's not the 1980s anymore, this industry is not for solitary special-snowflake hackers. You're a part of a team -- like a node in a cluster -- and the team's productivity is what matters.
Wound not have guessed that!
Now I think that if you need to focus very hard to program, you code and/or design is way to complicated.
2) Promote into/within people management roles based on their skill as an individual contributor. E.g. the better the programmer, the better they will be at managing programmers.
3) Create a set of company values vague enough to be meaningless. Enforce them selectively and only when convenient.
4) In the name of inclusiveness, expand meeting invitations to anyone who could possibly be affected by anything talked about. Refer to them as stakeholders. Be sure to include anyone whose job is unrelated but may be interested or have an opinion.
5) All goals should be subjective. The subjective meaning of the goal should change based on timing, external factors, mood, or self-confidence. If you aren't happy, someone (else) is doing something wrong and you should immediately switch directions. This is especially important in hiring.
6) In all meetings (see 4), require consensus.
7) Set individual performance metrics based on effort. Strong indicators:
- Individual sends emails late at night
- You see individual in the office late at night/early in the morning
- Individual speaks frequently in meetings
- Individual always seems so busy
8) Hire based on pedigree, especially from names you know. If they did not attend the Tier 1 school (Stanford), they're probably not an A player.
Recruit from companies with entirely different problems from your own. For example, if you're a small startup, target executives at Google so they can make you into Google. If you're a large company, acquihire small startups to inject agility and hunger.
Some general commentary: companies don't get this way because people are stupid. They get this way because people hyper-optimize for their own self-interests. Everything on this list is a way to show off, suck up, or CYA, all of which occurs because people want to stay employed and get promoted, and they implicitly optimize for more immediate, local rewards like positive social feedback from the colleagues they see on a daily basis.
Abstract and macro-level concepts are difficult to grasp and people have soft, differing opinions on them. However, people who work with you daily will come to "know" that you're a super hard worker if you're sending out emails at 4am. Including the company's Controller in a database schema design meeting not only gives you a chance to demonstrate your know-how to someone else in the organization, but also wins points for being careful, considerate, and cautious.
When promotion time comes, the less-visible heads-down coder who's been working hard and churning out bugfixes gets a lot less credit than his more boisterous, gregarious counterpart, who's been more focused on grooming personal biases in his favor than actually plugging in commits.
In theory a good corporate leader is supposed to make sure this kind of stuff doesn't happen, but they're only human, so really 99% of people operate this way.
What it translates to is that if you want to be a successful employee, remember ABC: Always Be Campaigning. Your primary job duty is popularity.
That is a warning in Robert Townsend's book 'Up the Organization'. He mentioned small corporations didn't become large corporations by acting like them. Beware of hiring enterprise level managers.
Sometimes I think this is even true for larger companies, See Atari post acquisition,Apple post Jobs 1.0. And Microsoft Ballmer era.
Lots of people in the technology industry and corporate environments are too focused on performance metric dick measuring contests and moving up in the pecking order.
All I know about someone who went to a "Tier 1" school without talking to them is that they wasted their youth doing whatever nonsense you need to do to get into said school.
The funniest thing about this is that the people who are hired to prevent political ambition and malfeasance from affecting the company's output are often the heaviest polluters.
That said, I've worked in really large organizations with plenty of weird bureaucratic artifacts which nonetheless treated people with integrity and respect. Good leadership who embraces that idea and low tolerance for bad behavior is the "secret".
In my observation, the level of nastiness and bureaucratic battlefield bravery is inversely proportional to the stakes at hand. People will murder each other over a 2% raise, but not lift a finger while an obviously bad decision puts the entire company at risk.
My list would be: 1) overestimate small tasks 2) Corollary to #1, underestimate large tasks 3) Find reasons to take the overestimated tasks and perform them slowly 4) Encourage your colleagues to take the larger tasks 5) Encourage bike shedding. Frequently evaluate your code standards. 6) If you are in the position to do so, enforce a terrible naming standard. 7) Write slow tests 8) Write useless tests 9) If you notice a coverage gap, try to introduce a subtle bug
As a manager: 1) Discourage specialization in favor of "flexibility" 2) Assign tasks to those with the least domain knowledge, within reason 3) Avoid letting more than a single developer work on a particular system/increase the "bus factor" 4) If you are able, under promise and under deliver 5) When brought new ideas or are asked to use new tools, be very encouraging but say you need approval. Never ask for approval.
The difficult part is doing all of it right.*
Look, I appreciate the history here, but nothing in the article ties back to actual planned sabotage. Do companies actually do this? Are top managers paid by competitors to break the companies they run? I mean, nearly all items on this list require C-level executive powers to effectively implement.
In all honesty, it feels to me like this article is more about how happy Stross is about his career change than anything else. That's a perfectly good topic, but can we turn this around? What's good, actionable, advice for (aspiring) managers, founders and employees? What's the oppposite of active sabotage? And can we encourage active, constructive anti-sabotage without becoming a creepy cult?
*) HN used to have lots of submissions about how to run companies right. Is it just me, or have those disappeared somewhat?
Isn't this exactly what an article like this is attempting to ask in the first place, albeit through irony and story-telling? I agree it's hardly ground-breaking, I guess it's just trying to make readers feel clever because (clearly) we'd never be stupid enough to do something like that. (Although it's worth far more to me, at least, when you get those articles saying "I did something stupid when I thought I was being clever," because if we're honest we all do things like that.) But I think OA is trying to discuss "how to run companies right."
I interpreted this as being one of them.
For example, if you are the first employee, do not expect to lead your team just because you were there first.
Here is the positive advice version:
1) Do not promote based on tenure. Talent is not 100% correlated with age or (especially) time at the company. Oftentimes the employees who thrive at early companies are generalists or love diverse responsibilities. These may not be the problems you're trying to solve later.
2) Do not promote into people management roles based on individual contribution. To be sure, knowing the problem domain is important, but, especially in engineering, people management skills are orthogonal to programming ability.
If your HR structure caps salaries for individual contributors to the point where ICs are forced to move into management, either change that or (if you determine there is a maximum value of an IC) stick to it.
3) Choose values that are specific to your company and can be reasonably disagreed with.[2] Stick to them, especially when it is hard. Values don't matter when it is the easy choice; they are defined by what you do when shit gets hard.
4) Narrow meetings to only those who provide knowledge which is Mutually Exclusive and Collectively Exhaustive. If someone does not add something that no one else in the meeting does, remove them. If others need to be updated, send them a summary.
Having an opinion does not qualify it as useful. This is also the first rule of being a CEO and the first rule of hiring product managers out of MBA programs.
5) Define success first, as objectively as possible. If you have to change the definition of success, it should be because what you're building will be fundamentally flawed without pivoting. If you are changing metrics to optimize results, your metrics for success are too in the weeds. Success is defined by what gets done, not how it gets done.
6) Have one clear decision maker. Do not appoint decision makers who are unwilling to make the right decision if it upsets everyone. Of course, they should be able to explain their reasoning enough that it shouldn't upset everyone, but the first objective is not that everyone feels like they got everything they wanted. Different people have different goals at cross purposes.
7) Effort can correlate with success, but certainly does not predict it. Writing code at 2am is not a priori more valuable than at 2pm (in fact, the opposite is likely true.) People who pride themselves as being busy will naturally resist automation.
As with most things, quantity is not the same as quality.
8) Know what pedigree tells you. Getting into Stanford likely means they thrived in high school. That may correlate with success, but certainly does not predict it. Similarly, thriving at a large organization does not predict the same skill set as thriving in a start-up. Because someone works at Google doesn't mean they have any idea how to build Google; because someone is at a startup does not mean they can turn your company into a startup.
Hope this helps.
[1]: https://news.ycombinator.com/item?id=11702549 [2]: I wrote a few sentences here: http://seneca.systems/values
> Do not promote based on tenure
Maybe not solely on tenure ala the government, but the people most likely to understand your company's particular problems and history are those who have been around for quite awhile.
Having someone who can say "We tried A last time and it didn't work because of reasons B,C, and D so what's changed?" in a position of (relative) power is invaluable to avoid repeating mistakes.
> Do not promote into people management roles based on individual contribution
Agreed that someone who doesn't want to be a manager shouldn't be one, but experienced ICs can make pretty ideal managers: They've been on enough projects to make (more) reasonable estimates, they know some of the potential blocks and complications, and they can likely stay a couple steps ahead of their team.
Sure, just because you're hung doesn't mean you have to do porn, but it's easy to see why companies would be eager and even pressure experienced ICs to become managers.
> Choose values that are specific to your company... Stick to them
Why? Shouldn't we re-evaluate our values as time goes on and we gain new information?
It's hard to imagine a contentious set of values (i.e. if your company values are "Don't be evil," then fine) that shouldn't be constantly re-evaluated as time goes on.
> If someone does not add something that no one else in the meeting does, remove them.
Ouch, this sounds like an insidious one that you could abuse heavily to do the committee thing that the OP rails against.
If you want something to go through: Invite only people who agree. If someone calls you on it and asks why you didn't invite more opposition voices, reply "I didn't think Alice had anything to add that Marie didn't, so I didn't invite her." or even just feign ignorance in the name of small meetings.
If you want something to get stuck in committee hell: Invite lots of people with different opinions that will never reach anything close to consensus. Don't invite any two people who agree, because "the other person isn't adding anything."
> Define success first, as objectively as possible. If you have to change the definition of success, it should be because what you're building will be fundamentally flawed without pivoting
That's suuuuper hard to do with anything that's even remotely considered a moonshot.
It also sounds like a good way to waste a shitload of time not actually doing any work. If the project is "upgrade our codebase from Ruby 1.9 to Ruby 2.3.1" then I can spend months dreaming up all sorts of useless bullshit metrics that define "success".
> Have one clear decision maker
Sounds like a formula for a shitty dictatorship. Even the CEO isn't the one clear decision maker.
> Effort can correlate with success
It often does.
> but certainly does not predict it
It often does.
> Writing code at 2am is not a priori more valuable than at 2pm
This kinda sounds like you're shaming people who have different circadian rhythms. I know plenty of night owls who do their best work at 2am and take it easy after lunch.
> Getting into Stanford likely means they thrived in high school. That may correlate with success, but certainly does not predict it.
It also might mean that they:
* Know how to manage their time effectively
* Are fairly mature and forward-thinking
* Are good with delayed gratification
* Are generally intelligent and capable of picking things up quickly
because certainly people who meet those criteria often find themselves at places like Stanford (with luck thrown in, certainly).
That works, if what you need is someone with substantial institutional knowledge. This isn't often the case, or the domain knowledge is not the most difficult part.
Would I rather have an incredible engineer with no local government knowledge, an engineer that knows government inside and out but has never worked for a tech company, or someone who has worked with me for years?
Depends on the role, needs of the team, etc. My point is that, too often, tenure is used because that's what's always been used. This is especially tough in startups, when someone has dedicated significant time and energy in the early days but just hasn't grown at the rate of the startup. It's a very emotional human decision that fights against our nature.
> experienced ICs can make pretty ideal managers: They've been on enough projects to make (more) reasonable estimates, they know some of the potential blocks and complications, and they can likely stay a couple steps ahead of their team.
I agree that they would be great at the technical aspects. That's oftentimes the least difficult part of running a team. People are hard.
> Shouldn't we re-evaluate our values
Yes! But either live up to the values you have or change your values. My comment was against having a set of values and ignoring them when they are inconvenient.
> It also sounds like a good way to waste a shitload of time not actually doing any work. If the project is "upgrade our codebase from Ruby 1.9 to Ruby 2.3.1" then I can spend months dreaming up all sorts of useless bullshit metrics that define "success".
You've proven my point. Upgrading Ruby is not an end in itself, it should solve some actual goal. There are many (performance, security, library compatibility, tech debt, etc.) but you should be able to list why we are prioritizing that versus other things.
>> Have one clear decision maker > Sounds like a formula for a shitty dictatorship. Even the CEO isn't the one clear decision maker.
This does not mean one person who does whatever they want. It means one person who, at the end of the day, owns the decision. By that definition the CEO is absolutely the one clear decision maker.
As CEO, if our company fucks up it is my fault. If I didn't know about it, it is my fault for not knowing about it. If it was some hire 4 levels down, it is my fault for creating a culture where a) that person could be hired and b) there weren't adequate checks in place.
To be clear, we will absolutely make mistakes. I'm not saying, "someone shipped a bug so that is my fault."
>> Effort can correlate with success > It often does. >> but certainly does not predict it > It often does.
We may just agree to disagree. I believe that effort is necessary but not sufficient for success. I have meant plenty of nice, smart, well-meaning, and hardworking people who were vastly unqualified for their roles.
I love them as human beings, but, especially in strategy or people management/leadership, results flat out matter. You can get better, but you won't train a 2 into a 10. It's about recognizing your strengths and weaknesses, then working in a role which emphasizes your strengths.
> This kinda sounds like you're shaming people who have different circadian rhythms.
My comment came off wrong. As a night owl, I'm definitely not shaming people for when they work. I'm shaming people who purposefully try to look hardworking by making it known they are working at irregular times.
Here are a few of my favourites in no particular order:
* Stand ups are bad - Let's be frank, I'm belting out code so quickly that staying on the same page as everyone else is just not worth the time anyway (at the speed I'm going it'll be done tomorrow anyway).
* Pair programming is bad - when was the last time I caused a bug, right? Or for that matter hit a problem I couldn't solve, and wasted time having to research the solution. Never, right? Right...ohhhh look at the cute picture of my niece on Facebook.
* Open plan offices are bad - I'm super important to the company, the company would break if I went away. I'm so much of a star that I should have the best office. Not to mention, I need somewhere to put all my trophies.
* Meetings - don't get me started on meetings. BAN THEM ALL. There must be a better way to communicate? Email? Ummm, yeah Email, wait, no, I'll come back to email. I know, lets just have someone decide on the direction we're going to go and write it on a stone tablet, that'll save some meetings (I'll get started on the tablet right after I finish here). I mean lets think about it, why do we need to coordinate anything? I'm the rockstar and if you just leave me to belt out the code it'll all come together...what do you mean other parts of the business need to do things to get ready?
* Emails - I get too many of them. For stupid things too. Ops alerts, customers asking questions, internal announcements, travel itineraries. Being included on email chain discussions about direction? Who needs that. What do you mean you made a decision without consulting me? Now we have to start over with the direction I want to go in.
And I'm out of time. Off I go to my lean, agile, open plan job.
Could you elaborate on this? I find standups most useful when we're working on small widgets of feature work precisely because we move so fast. Standups keep the business side in sync with the code we're putting out (e.g. features x, y ready to release, expecting z next week). It gives them a tighter feedback loop in case they need to manage expectations or coordinate with other groups.
If we're working on meatier chunks that take longer then we back off to a pull model. When someone wants to know they ask, but daily standups aren't very helpful when updates sound like "Working on <huge_feature> for the forseeable future"
Sure I made up the reasons above, but people are genuinely hating on the things I've mentioned with no real alternatives offered.
Lunch breaks are good - Dude, I love to eat, and if I can't stop working when I have my cheeseburger then nothing is getting getting done here even though I'm smelly and 500 pounds.
Paychecks are necessary - I'm such a loser that I work for money instead of just loving cranking out sick code that disrupts the world. I grew up poor so I whine about people who don't need the money.
Not eating arsenic - Oooh, I'm such a picky wimp that I can't take a little arsenic in my food...
And I'm done. Off I go to my volunteer sweatshop that's slowly poisoning me to death.
Don't you think it does a disservice to the actual underprivileged sweatshop workers of the world to compare cushy software coding jobs to sweatshops? Is your software development gig so bad that it's "slowly poisoning you to death" instead of putting food on your table and cash in your 401k? If so, why are you bothering?
2) Have a small room for tea breaks. Split the workforce into two groups. Schedule one to end at the same time as the next one starts. (Teabreak for group A ends at 10:00 am; teabreak for group B starts at 10:00am;) This causes disruption and disgruntlement between people trying to wash up their cups and people trying to make their tea.
3) Allow some people to have cigarette breaks. Do not allow anyone else to have anything similar.
4) Occasionally drop in to the small room during teabreaks and have an important conversation, then allow that group an extra 5 minutes for their break but make sure the next teabreak group does not have that extra 5 minutes.
5) Observe what side of the desk people prefer to have their telephone. Tell them it's the wrong side, and that they must have it on the other side. Switch it for them. A surprising number of people don't just walk out here. The ones that stay? YOU HAVE BROKEN THEM AND VICTORY IS SURELY YOURS. CONTINUE TO CRUSH THEIR SPIRIT UNDER YOUR BOOTHEEL.
6) Tell someone that you're going to give them a payrise if they meet some vague but easily achievable criteria. Then, when they've achieved that, tell them that you hadn't promised the pay rise, and that their 360 feedback is disappointing this month. Especially because they keep moaning about the generous pay.
There's probably plenty of good material in "Processed World" https://en.wikipedia.org/wiki/Processed_World_(magazine)
Thanks for that link.
Q: "How can we sabotage stuff?"
A: "Here's a bunch of stuff I think is messed up. Leave your own complaints in the comments."
I am disappoint. No creative sabotage ideas here, only observations of stuff already going on that we think is "wrong." Now granted, when looking for tips on how to fuck shit up, you can look at actual fucked-up shit and get ideas. But I guess I was hoping for something more creative. And yeah not the supposedly hilarious hahajoke that "Golly things are so messed up we can't even tell if they're inept or saboteurs," and not more complaints about "If only the world listened to my brilliant ideas about how to do things the 'right' way (my way)." If I had a dollar for every asshole with an opinion...
There's no reason, in their healthy minds, why someone would want to sabotage their IT company.
For me, the real interesting question is why would someone want to sabotage my workplace.
It is also the job of Human Resources to ensure that the company scores as highly as possible in the local business journal's annual edition of the Best Places to Work. Here's a link to an "anonymous" survey with a unique ID embedded in the URL. We strongly encourage you to fill it out.
This!
Air gap developer workstations, have a formal procedure including a detailed approval form which must include a justification and must be reviewed and signed off by C-level for moving information/software between the outside network and the inside network.
- Byzantine hiring practices. Create engineering teams that are 95% new college grads. They're the only ones who'll suffer your BS, while having no experience to call upon in challenging decisions.
A basic analysis of a selection of the NSA/GCQH leaks showed a significant number of citations to various marketing textbooks and public research papers.
Maybe this is the point, but to me all the comments and even article itself read more like a commertary on common issues than an subversive insider attack.
Instead, a good sabotage will make the company extremely unproductive but still alive - which leads them to suck a lot more money in than they'd otherwise need, waste most of it, and then turn out subpar products being sold by the power of marketing itself, and otherwise a waste of energy, fuel, materials and man-hours...
... oh wait, we're talking about sabotage, and here I am describing most of the consumer electronics.
Instead that person is a hero, and the costs associated with the decision are initially small and don't show up until that person is long gone.
Repeated a few times the small hits to productivity/quality/etc will result significant lost ground. This is probably even more important long term in the technology industry than it is to a war effort. The sides would have to be close to evenly matched and the war would have to go on a long time for all the little bits of sabotage to add up.
This one bothers me. It's brought up all the time. And I completely agree that adding a new tool or feature adds risk and technical debt. But if there's no other way to do it... I work in a corporate VBA shop. 90 percent of our work in the last year was in VBA. But next year is looking like python, R and JS. How? Requirements changed. We got handed some projects in machine learning and we delivered, crudely but still. While in the technical sense we 'could' have coded it all in VBA it's not practical in the slightest to do so.
"Teams are better than individuals and everyone has to be aware of the valuable contributions of employees in other roles. So let's team every programmer with a sales person—preferably working the phones at the same desk—and stack-rank them on the basis of each pair's combined quarterly contribution to the corporate bottom line."
That is gooood.
I would quit, yet be so traumatized that my productivity would still suffer, even at my next job. A double win for the enemy.
Edit: typo
Oh, dont' we all wish. In practice, unfortunately, what's calculated is the average office worker's workstation requirements. Then the developer gets that, too, like everyone else.
Even if you need two instances of Visual Studio on a VM.
For instance, in my old workplace at Small Company™ I had two 24-inch monitors. In my current (but only for another two days) workplace at Big Corp™ we're only allowed a single 19-inch monitor. Try running two instances of VS on that. I have to constantly Alt-tab between browser and IDE, or stack windows side-by-side, which is not optimal. Obviously, because we're not allowed to keep anything on our desks, we can't bring our own monitor from home. So.
>> 8GB of RAM ought to be enough for everybody.
And even that is not a given. Frex, in the last two years at Big Corp™ I had to run a lot of machine learning algorithms - those were for my MSc course, sponsored by my employer so it was OK to run during office hours. Now, my work laptop has 12 GBs of RAM and it's noticeably faster than my home laptop, with 8 GBs and a similar processor.
And the fact that my office laptop has 12 GBs is a happy accident. Normally you only get 4 GBs, 8 if you ask nicely. So I was going to ask for 8, but let's just say I got lucky and the person who managed my request for the new laptop didn't know much about RAM and suggested the 12-GB stick spontaneously (and obviously I didn't turn it down).
But that's just a silly way to handle this sort of thing. Big Corp™ can afford to give devs much more if it wants to. It just doesn't value them as highly as other staff, who get the goodies they value highly.
In my experience, people who might be called "minority" or "diversity" hires tend to kick ass, possibly because they have put up with so much cognitive bias about how they supposedly don't belong.
11) Ping ping tables and other noisy shit.
The idea of promoting incompetent people still works. That's a gem.
For the small hammer/big hammer, simply choose technologies that are less suited and make them work. Sorry, our CRM is also our mapreduce framework. Make security an afterthought, and the world will do your sabotage for you.
The frightening incompetence of that guy is maddening. Incidentally, I don't think he was put in place to sabotage the company. Just a case of well-meaning nepotism.
I wish the author had addressed worker sabotage too. More on that here: http://thenewinquiry.com/essays/manual-override/
You might think I joking, but I'm not.
- Spend a couple months researching existing solutions for a complex product - Pick the "perfect" one - Ask for a quote - Recoil in horror at the price (about 1 weeks pay for that decision maker, in a 100+ people company) - Steal the damn JS library from their demo page - Use it on the product - ... - Profit? Once they can sell this turd
Given you have backups and ensure they can't fiddle with the authentication system: Go for it. It's like BYOD but with provided hardware.
Giving local admin to the non-technical staff who want to download 'free' software (not FLOSS, free as in beer) because they think (at best) that they are saving the company money, but instead infest their computer malware. Most people are totally disinterested in their computing environment, let alone managing it. We standardise on certain packages because there is utility in having common programs from support, training, and administration points of view, but ultimately if there is a good reason to get/use something else, we will do that.
Furthermore, any user with a local admin access can use a Kerberos 'Golden Ticket' leverage attack to gain full domain access across the entire realm.
Are you seriously telling me that you want the teller at your bank to have local admin access to his workstation?
How about the person at the IRS/CRA/HMRC/<you government tax office> that you just called?
Local admin has its place, and certainly the first test is that will the person endanger their system by running dubious programs. The next question is if that person does infect their system, can they clean up the mess themselves?
We went from a situation where we had local admin across our estate where we had at least one virus problem a week to one where I can not remember the last time we had one. Finally, can you really trust a Windows workstation after it has had an infection?
It applies to the kitchen policy, to the bathroom policy ("Keep the toilets clean"), to the password policy. Initiate a company discussion to get feedback, the exclude the black sheep.
2) Spread rumours about how the dept/company/sector is cutting jobs. It is very important that employees feel they're in surplus so they'll work more. Keep them upset about things, so they'll focus on that instead of programming.
3) Promote women. Don't help men to succeed or learn things.