Humane Offices: SAS

Located outside Raleigh, North Carolina, analytics software maker SAS is the largest privately owned software company in the world.





SAS is consistently ranked as one of the best places to work in the United States and is well known for its workplace culture and world-class employee benefits. One particular aspect of its culture might stand out to readers of this blog.

One example of employee-centeredness can be found in the fact that each employee has his or her own office. There are no cubicles. While SAS Institute describes this as a way to maximize productivity, it also fits in with the operating principle for [CEO] Jim Goodnight: that’s how he would like it were he “just” an employee.  - The Wharton Work/Life Roundtable

Everyone gets a private office. We're not talking cube farm here, either. These are real offices with doors that can be shut. All of SAS' 13,700 employees are encouraged to be creative and make their work space fun. A SAS senior communication specialist has turned her office into a shrine to Elvis with a velvet Elvis painting and a life-size standup of the King.  - The Huffington Post

SAS has incredibly low employee turnover of 3-5% annually, when the software industry average is 20-25%. If you want to get in the door (and get your own door), apply here.

Humane Offices: Epic Systems

If you’re the kind of person who cares about humane office space, you’ve no doubt heard the vocal opinions of Joel Spolsky and his companies Fog Creek Software and Stack Overflow. But I wanted to shine a light on some of the companies that aren’t constantly mentioned when the topic comes up.

Epic Systems, a healthcare software provider, has bucked the open plan trend by giving a private office to every developer in their beautiful campus outside Madison, Wisconsin.

 

At its 385-acre campus, with 1.5 million square feet of space spread across five buildings, Epic Systems Corp. provides private offices for all staff—a choice that is designed to support the focused-work practices and needs of software developers. According to Epic’s own research, this design approach increases productivity by 40 percent.

- HQ

One feature that isn't farm related: A lack of open offices. Cuningham has worked with Epic for more than 19 years, and learned early on that "employees felt they were much more efficient when working in individual offices."

"At first they exclaim that they don’t feel individual offices are necessary. But they all go away saying, ‘Wow, I think they’re onto something.'"

- Fast Company

 

Even more beautiful than the architecture and carefully manicured landscape is this: hallways lined with individual offices and doors that close.

 

Epic Systems is hiring aggressively. If you like what you see, apply here.

Open Plan Alternatives: Gleaming the Cube

In my last post, I urged office planners to ask their people what kind of environment is best for them. One surprising thing they might hear is that people prefer—gasp!—cubicles. Yes, cubicles.

In the hundreds of comments people have written on my various blog posts about office design, a common theme was of people working in open plans who wished they could have their cubicle back.

In fact, I was surprised when an interview I did with Wired regarding my views on office design was boiled down to a statement I made to this regard:

I’ve heard from several people who were incredulous that anyone could prefer a cubicle to an open plan. I believe this attitude may be a kind of extreme reaction to the giant, soulless “cube farm” that some companies employed (and still employ).

But, an open plan can turn into a landscape just as depressing when applied uniformly to a large space.

We can compromise, right? The Library and the Bazaar can coexist. It’s not an all-or-nothing proposition. And please don’t assume that everyone hates cubicles. It’s no private office, but for many people it beats the hell out of the open plan.

Open Plan Alternatives: Ask Your People

I’ve heard from several people who have the power to make decisions about office space, but feel frustrated that they can’t find practical suggestions on what to do instead of an open plan.

Well, if you’re already open to the idea that open plan offices are not a panacea, but you don’t know what to do instead, here’s a surprisingly straight-forward suggestion: ask the people who work there.

If there’s one thing I’ve learned throughout my writings on office design, it’s that people who work in offices have strong opinions about how they’re designed. The only thing that holds them back from expressing their opinions is a sense of learned helplessness that comes from years and years of working in crappy offices and seeing that no one cares about improving the situation.

This point was buried in another post I wrote regarding open plans, but here it is again: No size fits all. I’m sorry, but you’re going to have to consider the people who work for you as individuals with different wants and needs, because, well, they are.

I’ll end on a quote from Peopleware, as I often do…

A common element that runs through all the patterns (both ours and Alexander’s) is reliance upon non-replicable formulas. No two people have to have exactly the same work space. … The texture and shape and organization of space are fascinating issues to the people who occupy that space. The space needs to be isomorphic to the work that goes on there. And people at all levels need to leave their mark on the workplace.

Integration Is Communication

Kent Beck wrote a tweet recently that had me nodding my head:

I feel like this is a lesson one only learns while working for a large corporation. At this scope, there’s so much work to be done, and so many groups of people involved, that the most acute pain is always felt at the integration points.

The obvious solution is “better communication.” More meetings, more emails, more documentation, more complicated forms one group fills out to communicate its needs to the others. The cure seems worse than the disease.

What’s the real solution? I’m not sure there is one.

Martin Fowler, Perks, and Remote Work

In my post, Remote Work Denial Is a Bad Look, I argued thusly:

You can think face-to-face, in-person communication is most efficient, and I won't argue with you, but it ultimately doesn't matter as the remote work trend will not be stopped.

Figure out how you're going to make remote work effective for your company and then shout it from the rooftops.

In a recent article, Remote versus Co-located Work, Martin Fowler presents a level-headed take on remote work in which he arrives at roughly the same conclusion:

Most groups of people will be more effective when working co-located due to the richer communications they have.

Despite the fact that I think most teams would be more productive working co-located, you will often get a more effective team by embracing some form of distributed model because it will widen the talent pool of people you can get.

The fact that you can get a better team by supporting a remote working pattern has become increasingly important during my time in the software business and I expect its importance to keep growing. I sense a growing reluctance amongst the best developers to accept the location and commuting disadvantages of single-site work. This is increasingly true as people get more experienced, and thus more valuable. You can either try to ignore this and accept the best people who will relocate for you, or you can explore how to make remote working patterns more effective. I think that organizations that are able to make remote working patterns effective will have a significant and growing competitive advantage.

Remote work is certainly not easy to get right, but it is nevertheless possible, and it represents a very desirable perk. Just as you could easily make the argument that it’s silly for employers to be responsible for the health insurance coverage of the people that work for them, try going out and hiring great people while telling them that you don’t offer health insurance (and good health insurance). How long will it be before companies have a similar difficulty hiring good knowledge workers because they don’t offer the perk of remote work?

The Yacht Metaphor for Software Organizations

I’m big on metaphors, and I’ve always loved Joel Spolsky’s software-organization-as-yacht metaphor:

Think of your development abstraction layer as a big, beautiful yacht with insanely powerful motors. It's impeccably maintained. Gourmet meals are served like clockwork. The staterooms have twice-daily maid service. The navigation maps are always up to date. The GPS and the radar always work and if they break there's a spare below deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether to have Tuna or Salmon for lunch. Meanwhile a large team of professionals in starched white uniforms tiptoes around quietly below deck, keeping everything running, filling the gas tanks, scraping off barnacles, ironing the napkins for lunch. The support staff knows what to do but they take their cues from a salty old fart who nods ever so slightly in certain directions to coordinate the whole symphony so that the programmers can abstract away everything about the yacht except speed, direction, and what they want for lunch.

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don't steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

“That’s Easy. You Just…”

On a recent Hacker News submission about the phenomenal success of WhatsApp, I clicked through to the comments thread, and read the top comment:

> Why WhatsApp Only Needs 50 Engineers for Its 900M Users

Answer: because sending short messages from A to B is basically a solved problem. There is even a programming language (Erlang) that was made with this application in mind. The prototypical "Hello World" example for Erlang is a messaging application.

There’s some kind of disease in the tech world about trivializing the accomplishments of others, and conversely about understating the effort one took to achieve one’s own accomplishment.

There’s a person I call the “That’s Easy. You Just…” Developer. He wants you to believe that software is easy and obvious.

My Weekend Project

If you’re a regular HN reader, you may recognize the common “Show HN” posts where someone seeks feedback on a project they’re doing. “My weekend project”. People like to suggest that it only took them a weekend to produce the thing they’re now showing off. When you build something in a weekend, it’s typically worth about a weekend’s worth of time. More impressive is, “Look what I built in 10 years.”

Boss, That’ll Take About Five Minutes

In an attempt to win technical arguments, a developer will sometimes trivialize the difficulty of the thing they want: “That’ll take about five minutes.”

As professional developers, we know that nothing takes five minutes to ship and recognize the exaggeration for what it is. The problem is, non-technical people hear this trivialization and occasionally take it to heart. “These guys keep talking about how that would take ‘about 5 minutes.’ Software is pretty easy, I guess.”

Cheating on the Definition of Done

A common hack is to cheat on your definition of done. Despite your overall feeling of Scrum as a methodology, I think one thing they nailed is the importance of getting precise about the definition of done.

Rule of thumb: a flurry of code at 2AM usually does not result in something that’s done.

Obviously…

It’s easy to pretend that something you know now was obvious. I’ve given in to the temptation to treat a momentary advantage in knowledge over someone as an opportunity to pretend that knowledge was obvious to me all along. In fact, I still feel like a jerk looking back at the times I’ve done this. “Oh you need to do X, just use Y. Duh.”

It’s okay to admit that things are hard, that maybe you felt dumb yourself when you were learning it. The secret is, we all actually know it’s hard, but we won’t admit it.

Backlog Prioritization Affects Developer Morale

If you read Scrum literature, you may get the idea that the Product Owner is a kind of dictator of the product backlog, in that he or she unilaterally decides the priority of work remaining on a product and passes this order down to the development team.

Author of All About Agile, Kelly Waters, has this to say:

Anyone can add anything to the Product Backlog. Anyone. The Scrum process, and agile development principles generally, are collaborative and inclusive.

But… very importantly – only the Product Owner can prioritize the Product Backlog.

As I mentioned in my last post, there is a ton of writing out there about Scrum and Agile methodologies, and it is definitely possible for someone to come to Scrum with preconceived ideas about how software should be made, and then find justifications in the writing.

I want to make the point here about the importance of development team input into backlog priority.

In particular it’s very easy for a Product Owner to dismiss technical debt or other concerns that typically only the developers grumble about as less “sexy” than delivering another feature to end users.

When the decision comes down to fitting one more new feature into a sprint or paying off some debt on code quality, the decision usually goes to the former. But as the authors of Peopleware discuss, managers need to keep in mind the importance of quality to makers, above and beyond just immediate market concerns:

We all tend to tie our self-esteem strongly to the quality of the product we produce—not the quantity of product, but the quality. (For some reason, there is little satisfaction in turning out huge amounts of mediocre stuff, although that may be just what’s required for a given situation.) Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.

The hard-nosed, real-world manager part of you has an answer to all this: “Some of my folks would tinker forever with a task, all in the name of ‘Quality.’ But the market doesn’t give a damn about that much quality—it’s screaming for the product to be delivered yesterday and will accept it even in a quick-and-dirty state.” In many cases, you may be right about the market, but the decision to pressure people into delivering a product that doesn’t measure up to their own quality standards is almost always a mistake.

Scrum expert, Mike Cohn, also discusses times when developers should be given leeway to decide their own priorities, including when they just need a break from the same old same old:

On some projects, teams occasionally hit a streak of product backlog items that are, shall we say, less than exciting. Letting the team slide slightly ahead sometimes just to have some variety in what they’re doing can be good for the morale of the team. And that will be good for product owners.

Product owners, please remember to incorporate the feedback of your development team into prioritization, as it has real effects on their morale. And unhappy developers will tend to leave your project for greener pastures.

If You Don’t Buy the Philosophy, Don’t Bother with the Practices

I used to roll my eyes when proponents of a certain methodology, when confronted with failures of projects using that methodology, would say things like, “You’re doing it wrong! If you would just perfectly execute every suggestion in this book I’m selling, you wouldn’t be failing.” After a while you start to wonder if it’s so hard to do it The Right Way then maybe there’s a problem with the methodology itself.

Lately, I’m come across several posts from writers I respect criticizing Scrum and “Agile” methodologies as micromanagement and as ways for authoritarian managers to assert themselves over development teams

Scrum's standups are designed to counteract an old tradition of overly long, onerous, dull meetings. However, at both these companies, they replaced that ancient tradition with a new tradition of overly long, onerous, dull meetings where management got to sit down, and everybody else had to stand. Scrum's attempt at creating a more egalitarian process backfired, twice, in each case creating something more authoritarian instead.

- Giles Bowkett

My personal experiences with “Agile” teams have generally been good. By the time I entered the industry in 2005, Agile ideas had spread considerably and I can’t say that I’ve ever been in a software organization that was doing Waterfall.

But, I have seen dedicated micro-managers when required to “do Scrum” turn that daily standup right back into their familiar morning status meeting where the team one by one turns to the highest ranking person in the room and reports their status directly to that person. What I won’t do though is ascribe this phenomenon as a failure of Scrum as a methodology.

Just like any large body of literature, one can essentially read anything they want into it. As I said in a previous post, I believe that Agile is a philosophy akin to egalitarianism. And at its core it’s about self-organization.

In Succeeding with Agile, there’s a good quote from Jean Tabaka:

I work primarily with Scrum teams, and those that struggle the most typically have a command-and-control project manager or a decision-oriented technical lead as ScrumMaster. Without a facilitative, servant-leader mode of team guidance, the agile adoption will be only a thin veneer over non-empowered, demoralized teams.

One of the saddest things to see is a software organization where people at the top have convinced themselves that what matters about the methodology du jour they have cast upon their people is the list of practices associated with the methodology. “If I see my people doing these practices, then I’ll know they’re embracing the methodology.”

But the practices mean nothing without the philosophy. A team can do planning poker sessions until they’re blue in the face, but if they’re working under a manager that believes he knows better than the developers how long their work will take, the whole exercise is pointless. Any practice can be letter-of-the-lawed and still give you no benefit.

Author of the popular book The Art of Agile Development, James Shore, explains in a post from his blog:

Agile development isn't just about good engineering practices. It's also about acknowledging the importance of people in software development, forming cross-functional teams, obtaining high-bandwidth communication, constantly reflecting and improving, delivering value, and changing plans to take advantage of opportunities.

Scrum includes these other points. It says that the team should be cross-functional and recommends collocating the team in a shared workspace. It says the team should deliver a valuable, shippable product at the end of every Sprint, and that the team should self-organize, discover impediments, and remove them.

Oh, and it also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That's right--Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.

If you want to benefit from a particular methodology, whatever it may be, people must buy into the philosophy first, or don’t bother.

The Library and the Bazaar

In Christopher Alexander’s discussion of his Workspace Enclosure pattern, he mentions this interesting concept:

You should not be able to hear noises very different from the kind of noise you make, from your workplace. (Your workplace should be sufficiently enclosed to cut out noises which are of a different kind from the ones you make. There is some evidence that one can concentrate on a task better if people around him are doing the same thing, not something else.)

This is an idea that seems simple, perhaps common sense, but as I’ve come to realize through my investigations into office design, common sense is not so common.

Here’s a paraphrasing of the idea, as simply as I can state it:

Put things that sound similar together, and isolate them from things that sound different.

This idea (should) affect every aspect of office layout.

Here are some examples:

• Don’t put people who talk on the phone often within earshot of people who don’t. Put the “phone people” together, away from the non-phone people.
• Don’t put a copy machine and/or printer within earshot of desks. Machines and people make different sounds.
• Team rooms: people who work day in and day out on a certain project should be sound-isolated from those who don’t. Overhearing someone’s conversation is a lot less annoying if it’s highly relevant to you.
• Group non-work things together and sound-isolate them from work things. It’s cool if the microwave and the air hockey table can hear each other, but put a wall between them and any desk.

Nope	Yep

There’s a fantastic white paper written by the GSA called Sound Matters, which is free and a quick read. Within, they explain the concept of the Library and the Bazaar:

The contrasting needs of the modern workplace can be seen as “The Bazaar” and “The Library,” with different acoustic needs and responses appropriate for each.

“The Library” is an analogy for a workplace environment where both quiet and speech privacy are expected to optimize the ability to concentrate.

“The Bazaar” is an analogy for the expectation that the area is not private, where sharing is the norm… Noise is far more acceptable to workers in the bazaar and a high level of intermittent background noise is expected.

The workplace needs libraries and bazaars, with sufficient noise isolation between them. The problem with many trendy open-plan offices is how they place everyone’s workspace into a bazaar.

In staged glamour shots like this, no one has to work at these desks.

There’s a certain fantasy promoted by open plan enthusiasts about how surrounding your people with a sea of random conversations and noises all day will lead to serendipitous collaboration / synergy / magic. What I’d suggest is that the bazaar is the place for these conversations, not the library.

Even if you don’t believe in a private office for every individual, don’t force everyone into a bazaar.

Technicians Get No Respect

I believe one of the fastest ways we developers can lose the respect of so-called “business people” is to behave like technicians.

What do I mean by technician? Here are some things a technician might do:

• Become visibly angry when a business reality compromises their carefully planned inheritance chain
• Declare that they are blocked on implementing the automated notification system the business requested until someone tells them what the subject line of the emails should be
• After hearing the description of a report the business would like to see, their response is, “Can I use D3?”

The technician thinks primarily in terms of technology and expects the non-technical person to adapt to this way of thinking when the two interface. As Chad Fowler explains in My Job Went to India:

You might be “just a programmer,” but being able to speak to your business clients in the language of their business domain is a critical skill. Imagine how much easier life would be if everyone you had to work with really understood how software development works. You wouldn’t have to explain to them why it’s a bad idea to return 30,000 records in a single page on a web application or why they shouldn’t pass out links to your development server. This is how your business clients feel about you: Imagine how much easier it would be to work with these programmers if they just understood what I was asking them for without me having to dumb everything down and be so ridiculously specific!

The technician believes that careful choice of technology is primarily what makes a software project successful. Peopleware tells us otherwise:

The main reason we tend to focus on the technical rather than the human side of the work is not because it's more crucial, but because it's easier to do. […] Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work.

If you find yourself concentrating on the technology rather than the sociology, you're like the vaudeville character who loses his keys on a dark street and looks for them on the adjacent street because, as he explains, "The light is better there."

Imagine that you were feeling depressed and decided to see a psychotherapist. After an emotional retelling of your troubles and the pain you’re feeling, the therapist responded with, “Would you like me to treat you with Gestalt therapy, ACT, or psychoanalysis?”

Avoid being labeled a technician:

• Exercise independent judgment regarding non-technical decisions. You’re not a code monkey!
• Also, don’t foist technical decisions on non-technical people.
• Care about the high-level objectives of the software you make. Show a holistic concern for the success of the project.
• Ask stakeholders about the why behind the features they want.
• Use the language of the business when talking to non-technical people (and as much as possible with technical people).

As you move from technician to solution provider, people treat you differently.

Further Reading

• My Job Went to India / The Passionate Programmer
• Don't Call Yourself a Programmer, and Other Career Advice
• Soft Skills: The software developer's life manual

Are Software Developers Respected by “Business People”?

In the Hacker News thread for my last blog post, there were a couple of comments that really got me thinking about the role respect plays in bad office design.

Is it time to get depressed yet? This has been a topic for such a long time. It was in Peopleware in 1987. I thought I discovered the topic when Joel (On Software) wrote about it in 2000. While a few people seem to enjoy open offices, the overwhelming majority of developers I know, or who chime in on HN, value a quiet place to work and dislike open offices.

And yet, not only has nothing changed, it seems to be getting worse. It couldn't be more clear to me that developers, at least on this issue, simply have no clout as a profession. There may be a few individuals who can make demands, but on the balance, these are decisions imposed on us, as a group, and we are apparently unable to do anything about it.

-- geebee

In a response to the above comment:

30 years ago programmers were highly respected. We were mysterious to others and we were able to influence things like office layouts and the like.

…

At some point over that time period, things shifted. Programmers became seen as "geeks" who didn't really understand business and "business guys" took over.

…

They have no concept that we might know what we're talking about because "office space is the realm of business."

…

We're not capable of decision making and we have no understanding beyond our weird obsession with those stupid computers. -- that's how they see us. They'll lie and say otherwise, but deep down and a fundamental level, that's how non-technical people see us.

-- MCRed

Is this true? Are software developers “geeks” that lack clout and respect with the “business people”?

If so, why is that? Have we earned our lack of clout/respect? I have some thoughts on this that I’ll explore in a future post.

In the meantime, let me leave you with this question: If you believed that an employee of yours did extraordinarily challenging mental work, which required extreme concentration, would you put them here to do that work?

Just Wear Headphones

In the comments people have written in response to my posts about open plan offices, a common theme was that of headphones (or earbuds) and how they are oversold as a solution to office noise.

In this post, I want to elaborate on a few issues with headphone use that hold them back from being a silver bullet.

Physical Hearing Damage

There are permanent physical consequences from prolonged headphone use. The effects accrue gradually, and as such people don’t notice that it’s happening.

From the American Osteopathic Association, Dr. James Foy explains:

I stress to my patients and the parents of my patients that if you can’t hear anything going on around you when listening to headphones, the decibel level is too high.

As a rule of thumb, you should only use [personal audio] devices at levels up to 60% of maximum volume for a total of 60 minutes a day. The louder the volume, the shorter your duration should be. At maximum volume, you should listen for only about five minutes a day.

ENT physician, Dr. Michael Seidman, continues in an article from the New York Times:

If you listen to music with earbuds or headphones at levels that block out normal discourse, you are in effect dealing lethal blows to the hair cells in your ears.

When you’re working in an environment so noisy that you have to pump music (or white noise) into your ear canal so loudly that it blocks out the other noise, you are doing permanent damage to your hearing.

Music Is Distracting

This is one of the trickier issues to discuss, as people love music and have a hard time separating the pleasure they get from listening to music from their effectiveness while listening to music.

If you ask software developers about what they blast out of those ubiquitous headphones, you’ll get answers like this:

"It's not just something in the background to help me concentrate; it's a source of inspiration, a door to free my mind from our day-to-day routines, and, at the same time, it's a way to memorize an experience," says Ortali. "I play tracks in a loop, sometimes the exact same track all day long. It's a way to connect with the lyrics, and move the tempo beneath my skin."

Scientific minds get very un-scientific when it comes to their favorite music.

In a terrific article from The Atlantic, “How Headphones Changed the World”:

In survey after survey, we report with confidence that music makes us happier, better at concentrating, and more productive.

Science says we're full of it. Listening to music hurts our ability to recall other stimuli, and any pop song -- loud or soft -- reduces overall performance for both extraverts and introverts. A Taiwanese study linked music with lyrics to lower scores on concentration tests for college students, and other research have shown music with words scrambles our brains' verbal-processing skills. "As silence had the best overall performance it would still be advisable that people work in silence," one report dryly concluded.

If headphones are so bad for productivity, why do so many people at work have headphones?

That brings us to a psychological answer: There is evidence that music relaxes our muscles, improves our mood, and can even moderately reduce blood pressure, heart rate, and anxiety. What music steals in acute concentration, it returns to us in the form of good vibes.

Headphones give us absolute control over our audio-environment, allowing us to privatize our public spaces.

People conflate the positive psychological effects of creating a cocoon of their favorite sounds in an environment of noise they can’t control with positive effects on their productivity.

Feeling of Vulnerability

As I touched on in a previous post, seating people with their backs to a high-traffic area leads to a constant sense of unease and vulnerability.

People in this position have lost their sense of sight to detect when someone is approaching them. When you add headphones to the equation, they’ve now also lost their sense of hearing.

Headphone use in a noisy open plan environment can be a catch-22. The noise is so oppressive that you want to block it out, but then you have to deal with the feeling of vulnerability and frequent startles of people approaching you from behind without hearing them.

So What to Do?

Headphones are not the new walls. Give people a quiet place to work or let them work from their own.

 

Side Note: Noise-Cancelling Headphones

I want to quickly address “noise-cancelling” headphones in particular, as they are mentioned often as a quick fix for the problem of office noise. The technology at use was designed to cancel the low, constant rumble of aircraft engines. So while it may work to cancel the noise of your office air conditioner, it’s powerless against the voices of your co-workers (the real noise you’d want to cancel in an office environment). Read some of the reviews for the popular Bose QuietComfort noise-cancelling headphones, and you’ll get the picture.

The "Phone Room"

Here’s another office design 101 thing that I want to get out of the way: the importance of temporary private space for people stuck in open plans.

These private spaces sometimes get labeled as “phone rooms” or something similar, implying that they exist for a person to take their loud conversation away from the rest of the workers. Well, the exact opposite situation is at least as important if not more: for a person to get some quiet away from the loudness of the general office environment.

We already know that some people need more quiet time than others. And headphones are not a substitute for quiet.

Let’s stop calling these “phone rooms” and ensure there is no judgment from anyone who matters about people using these rooms simply for quiet time.

How to Make Your Open Plan Office Suck Less

Open plan offices suck, but there are some easy ways to make them suck less. Here are three ways that simple desk positioning can make a big difference in the suckiness of your open plan.

1. Lower Density

Lower density means less noise. Put more space between desks.  

Sucks:

Sucks less:

2. Face Space

Don’t seat people where their line of sight goes through a nearby face. If you haven’t felt the awkward tension of having someone’s visible face right behind your monitor while working all day, then congrats, your open plan sucks a bit less.

Sucks:

Sucks:

Sucks less:

3. Watch Your Back

Don’t seat people with their back to a high-traffic area. People in this position feel constantly vulnerable and cannot have one moment of screen privacy. Ask these folks to wear headphones, and they’ll feel even more vulnerable.

Sucks:

Sucks less:

 

If you’re committed to an open plan office (shame on you), then at least get these things right.

Remote Work Denial Is a Bad Look

When out-of-state recruiters email me about their awesome tech company, my first response is always something along the lines of, “You support remote work, right? I live in Grand Rapids, Michigan.” When the response comes back as a flat denial of the possibility, suddenly that hot tech company seems very old-fashioned. And old-fashioned is not a good look in the tech industry. I always think to myself, “Really, you’re one of those? Well, that’s embarrassing.”

If “Agile” could be said to have traditional values, one of them might be colocation. I’ve come to view this emphasis as a bit naïve or idealistic in the present day.

As Keith Richards says in an article for InfoQ about distributed Agile:

Most of the agile body of knowledge that has been written is based on the utopian situation of one team, one ‘product owner’ and one location. Although this is still often the case, is it the exception or is it the rule? Having worked for well over a decade now on implementations of agile I find that multi-team, multi-location, multiple business area and even multi-time zone agile is more the norm.

If agile is to thrive over the next 10 years then it not only has to work in a distributed environment (i.e. an environment where we do not all work in the same place), but it has to work well in order to deliver the most value to an organization.

Mike Cohn, in his book Succeeding with Agile, expresses a similar thought:

A few years ago, collocated teams were the norm, and it was unusual for a team to be geographically distributed. By now, the reverse must be true. Personally, I’m now surprised when someone tells me that everyone on the team works in the same building.

You can think face-to-face, in-person communication is most efficient, and I won't argue with you, but it ultimately doesn't matter as the remote work trend will not be stopped.

When I see tech companies taking a hard-line stance against remote work, I can't help but think, “Imagine how dumb you're going to look in a few years.” I truly do not mean to offend anyone’s sensibilities with what I’m about to say and hope my point gets across regardless of your particular political beliefs, but remote work denial feels very much to me like people vehemently opposing the legalization of marijuana or same-sex marriage at this point--do you really think you're going to stem this tide? With all due respect to your beliefs, this is happening anyway.

Get on the boat now before your company has been too badly embarrassed in front of the people it wants to hire. Remote work is still a differentiator in this moment of time. What are you waiting for...your competitors to do it first? You want to clean up in the talent wars? Figure out how you're going to make remote work effective for your company and then shout it from the rooftops.

From the closing sentiments of Remote:

Life on the other side of the traditional office paradigm is simply too good for too many people. Progress on fundamental freedoms, like where to work, is largely cumulative. There might be setbacks here and there from poorly designed programs or misguided attempts at nostalgia, but they’ll be mere blips in the long run.

Between now and the remote work–dominated future, the debate is likely to get more intense and the battle lines more sharply drawn. Remote work has already progressed through the first two stages of Gandhi’s model for change: “First they ignore you, then they laugh at you, then they fight you, then you win.” We are squarely in the fighting stage—the toughest one—but it’s also the last one before you win.

Remote work is here, and it’s here to stay. The only question is whether you’ll be part of the early adopters, the early majority, the late majority, or the laggards. The ship carrying the innovators has already sailed, but there are still plenty of vessels for the early adopters.

Continuous Delivery and Management Pathologies

I believe continuous delivery is a foundational practice. In fact, it’s mentioned right at the top in the “Principles” section of the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

There’s a lack of trust that develops amongst stakeholders when the gap between “developer done” and “I can see that it’s done” is too great. In a perfect world, everyone trusts everyone, but that’s just not the case on real projects a great deal of the time.

You want to know how to cultivate trust? Deliver consistently. Perhaps, continuously.

I believe one of the greatest causes of managers behaving badly is a fear that the things that need to get done are not getting done. This is one of the great causes of micromanagement, which technical folks tend to hate (I know I do).

By reducing this fear, you can head off several management pathologies. You can prevent a hundred status meetings by sending a URL to someone and saying “see for yourself.”

I’ve come to believe that on most software projects, the speed of progress is not particularly important as much as steady progress. Optimize for steady, externally-visible progress.

CD is the ultimate progress indicator of your project. As Jenifer Tidwell says in Designing Interfaces:

Experiments show that if users see an indication that something is going on, they’re much more patient, even if they have to wait longer than they would without a Progress Indicator. Maybe it’s because they know that “the system is thinking,” and it isn’t just hung or waiting for them to do something.

Note that this is the same lack of trust that makes otherwise intelligent software organizations hesitant to embrace remote work. What if my daily work produced artifacts of working software that you can look at every day whenever you wanted? Would that assuage your concern that I’m sitting in my pajamas and watching cartoons all day?

I see CD as a sort of great equalizer. Working software in front of the people who paid for it levels all arguments.

Your Problem Is Not Unique

As I approach my 10th year as a software professional, one of the things that frustrates me the most about our industry is the way in which people chronically overestimate the uniqueness of the problems they’re facing, and the frequency with which wheels are reinvented.

Designers, developers, and managers all have a habit of approaching common problems as if they’re the first one to do so. There’s an expression about “standing on the shoulders of giants.” We’re not all giants, and not all of our problems require herculean efforts.

Begin rant…

Your UI problem is not unique

I think the most common and ultimately harmful way this manifests is in user interface design.

Reinvention at the UI level is particularly insidious, as it doesn’t just waste the time and money of the team developing the software, but it confuses users (and we’re ultimately doing this for them, right? Right?)

I’ve witnessed bored designers coming up with the most elaborate one-off UI components to show a list of items or tabular data as if that’s a unique thing to do. Your typical line-of-business web app is not going to succeed or fail based upon the clever, innovative concept you’ve invented for showing a list of items to a user.

The thing is for the 99%, familiarity trumps cleverness. Every UI element that has to be explained-- especially when you could have swapped in one that people already know and accomplishes the same purpose—is one check against you and your product.

For example, I can’t tell you how many hours I’ve spent on teams debating the look and feel of the primary navigation for a web app. Grab a copy of Don’t Make Me Think, read the chapter on navigation, do what it says, and then move onto more pressing issues. You’re doing a big disservice to your users if you don’t copy the familiar style of navigation that your users have gotten used to on popular websites for the last decade.

One more example: your web app is not the first one to need to notify users of events that have happened in the system. Roughly 1.4 billion people--including the people who use your web app--use Facebook and are desperately familiar with the way that Facebook handles notifications. Rip their design off as closely as you can, and move on to something that can differentiate you from your competitors.

There are good catalogs of established UI patterns out there, such as the book Designing Interfaces. Before you have a long, long, like cruelly long series of meetings and email chains, whiteboard sessions, and the like, identify the pattern that relates to your requirement, find some well-known examples of the pattern, and copy them as closely as you can. If by some fluke your unique problem has not already been solved in a nice, familiar, recognizable, warm-fuzzy to your grandma kind of way, then by all means proceed to your brainstorming session(s).

Your development problem is not unique

For developers (and this includes me), I know that working day in and day out on that accounting app is not always particularly exciting, but avoid the temptation to write your own object-relational mapper from scratch to shove ledgers in and out of your SQL database. If you want to break out of the mold and roll your own thing from scratch, choose an area where you can really make a difference.

If you really want to differentiate yourself, be the person that knows the lessons of 40 years ago rather than a person who’s obsessively implementing TodoMVC over and over in this afternoon’s hottest JavaScript framework. The former is much rarer than the latter.

I know a lot of devs are entranced by the technology for its own sake. And there’s nothing wrong with nerding out over programming languages (my personal favorite), or JavaScript frameworks, or NoSQL databases or whatever floats your boat, but it’s easy to lose sight of the bigger picture.

“Barb, I know this thing is a pain in the ass to use, because the navigation makes no sense, no thought was put into the information architecture, and we didn’t consult with one actual user before developing it, but you’ll be happy to know that we’re using Riak on the back end. You’re welcome.”

There’s an episode of The Changelog podcast that came out recently in which they interviewed DHH about the decade long history of Ruby on Rails. With his trademark bluntness, he lets loose on “unique snowflakes” in a quote that I would guess was inspired by Tyler Durden’s speech from Fight Club:

They want to believe that every single application is a unique snowflake. That they're so brilliantly unique, too. That their value comes from their careful selection of which template language, which data mapper, which whatever the hell it is...

There are lots of applications out there trying to be needlessly novel to satisfy the egos of programmers who do not want to feel like they're working in cookie-cutter domains. That they somehow attach their self-worth to how novel their application is.

That’s a little harsh—what would you expect from DHH?—but I think the point is valid. It’s all too easy to focus on the minutiae of technology when in reality, we’re in a people business. And now I quote from Peopleware, as I often do:

…the High-Tech Illusion: the widely held conviction among people who deal with any aspect of new technology (as who of us does not?) that they are in an intrinsically high-tech business. They are indulging in the illusion whenever they find themselves explaining at a cocktail party, say, that they are “in computers,” or “in telecommunications,” or “in electronic funds transfer.” The implication is that they are part of the high-tech world. Just between us, they usually aren’t. The researchers who made fundamental breakthroughs in those areas are in a high-tech business. The rest of us are appliers of their work. We use computers and other new technology components to develop our products or to organize our affairs. Because we go about this work in teams and projects and other tightly knit working groups, we are mostly in the human communication business.

Managers, you’re not helping

Project managers, stakeholders, and other people who manage software efforts are not off the hook here. You also need to be honest about the product you’re making and accept that sometimes your unique take on logo placement is not what’s going to sell your software. You folks hold the keys to the backlog and how work gets prioritized. Spend those precious developer-hours on things that matter, not reinventing the same basic features and conventions that nearly every application has in common.

What’s worth spending time on?

The way that your bread is truly buttered in 99% of applications is through insights into the business domain that come from years of domain expertise accumulating slowly.

If you want to futz with some new technology and try something new, that’s great. But be honest about what you’re doing. Most of the time you’re doing it for you, not for your users.

I wish a standard role on every software team was the “That Thing’s Already Been Invented” Czar. Or “Code Historian” or “User Experience Historian”. Now that person would be worth their weight in gold.

Instead of Not Invented Here (NIH), how about Proudly Found Elsewhere (PFE)?

But what about innovation?

Innovation is a necessary thing and I would never suggest that people should never try anything new. If you never try anything new, the industry can never move forward.

The question of when to innovate is so context-specific. If you’re writing an early iPhone app during the wild west of that platform, by all means, try some new form of navigation. If you’re Facebook and having the (good) problem of 1 billion users hammering your database every day, by all means, invent your own database.

I think “20% time” or something similar may be a good solution. Spike some crazy idea you had or some bleeding edge tech on a pet project one day a week. If it happens to have practical implications for a product, then awesome. But it’s ok to just have some fun and learn something new. Scratch your itch--we know that’s important for its own sake.

---

Postscript: Why make Ruby on Rails?

It’s funny—when I started writing an outline for this post, I couldn’t stop thinking about DHH and Ruby on Rails, which I think is one of the few true game-changing innovations in the field of web development since I joined the industry. I kept thinking back to the early days of Rails’ creation and how difficult it would have been to justify such a project. It seems like such a strange case of yak shaving. Really? You need to take this weird Japanese programming language no one has heard of and write the umpteenth web framework in order to write yet another project management tool? How can you possibly justify that? What did your business partner, Jason Fried, think? You guys are the “do less” guys. What the hell?

In an interview from 2005, Fried says:

I had some natural hesitation about using Ruby at first ("What the #@!* is Ruby?" "Why don't we just use PHP--it served us well before?"), but David Heinemeier Hansson, the first engineer on the Basecamp project, cogently made the case and I bought it.

In the podcast episode I mentioned earlier, DHH also discusses his motivation while writing the code that would become Rails. It turns out that a major motivation for DHH was to remove all the wheel-reinvention that happens with each new web project. He wanted to make a “batteries included” full-stack framework that gave you sensible defaults and convention over configuration. Because it’s not necessary, for example, to invent your own naming conventions for every class and every property and how they map to the naming conventions of your database tables and columns. Because what the hell does it matter? He’ll think carefully about the problem, pick one, make it the default, and then you can move on, because you have more important things to worry about.

Should Managers Share an Update in the Standup?

I've been a part of several agile teams in my career that did a daily standup as part of their process. I've come to view standups as a must-have for software development teams. The payoff is large for the minimal time commitment.

The idea is that the team gathers together every day for a brief meeting (typically 15 minutes or less) just to update each other quickly on what they worked on the prior day, what they plan to work on today, and if they’re hitting any roadblocks that the team may be able to help out with.

In some teams, I've noticed what seems like a strange phenomenon to me, which is where managers that attend the standup don't share an update with the team, but merely attend to hear the updates of everyone else. This has always bothered me a bit, as I view the Agile philosophy as an egalitarian approach to making software, where everyone on the team is an equal.

I can distinctly remember on one team, where one of the developers had recently been promoted to management, and almost immediately stopped sharing an update like every other member of the team in the daily standup. As we had worked together for some time, I good-naturedly asked him to share an update, which was greeted by nervous laughter from the rest of the team, as if this was an odd request. He obliged and shared an update, which turned out to be packed with helpful information for the team. But after doing this a few times, and each time feeling like I was violating a cultural taboo somehow, I relented to the idea that he was now in a different class from the rest of the team that did not need to share an update.

I saw this pattern repeat a few times, where managers who attended the standup would listen to everyone else, but rarely speak about their own work. I may find this strange, but what do the experts have to say?

Scrum—the most popular agile methodology—has its version of the standup called the “daily scrum.” According to the official Scrum guide:

…only Development Team members participate in the Daily Scrum.

According to the Scrum Alliance:

Though interested parties are welcome to come and listen to the Daily Scrum, only the Scrum team members, including the Scrum Master and product owner, speak during this meeting.

In my experience with Scrum, the Product Owner has always been someone in management. The quote above indicates that the Product Owner speaks during the meeting, but it’s not clear if this means answering the three questions development team members answer:

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

In James Shore’s highly-rated book, The Art of Agile Development, he has a fictional transcript of a well-run standup:

A programmer:

Yesterday, Bob and I refactored the database pooling logic. Check it out—we made some nice simplifications to the way you connect to the database. I'm open today and I'd enjoy doing something GUI-related.

The product manager:

As you know, I've been away at the trade show for the last week, getting some great feedback on the user interface and where we're going with the product. We need to make a few changes to the release plan; I'll be working with the other customers today to work out the details. I can give a lunch-and-learn in a day or two if you want to know more. [Several team members express enthusiasm.]

A domain expert:

After you guys [nodding to the programmers] asked us about that financial rule yesterday, I talked it over with Chris and there was more to it than we originally thought. I have some updates to our customer tests that I'd like to go over with somebody.

A programmer responds:

I've been working in that area; I can pair with you any time today.

In this hypothetical standup, not just programmers but the “product manager” and a “domain expert” are both chiming in with relevant updates for the team.

Scrum expert and author, Mike Cohn, has this to say in the comments of a blog post on daily scrums:

I have no idea why the Scrum Master and Product Owner would not give updates. That sets up a complete us-and-them division between the team: "You have to share what you did, but I don't." A Scrum Master and Product Owner could easily within a minute (total) update the team in a way that kept things brief but didn't create that division.

In another comment on the same post, Mike continues:

I view the Scrum Master as a committed participant. I coach Scrum Masters to give (brief) updates on what they did. For example, if a Scrum Master never reports on removing impediments he's told about, other team members may never mention them. They'll think, "Why mention my impediment? I've never heard our Scrum Master say he's resolved anyone else's?"

Finally, here’s a comment from Gunther Verheyen, author of Scrum - A Pocket Guide:

I tell that Scrum Master and Product Owner are allowed to join the meeting. This seems to have a positive effect on the team; it shows they are connected and committed as Scrum Team members. But if they join, behave as every other Scrum Team member. So, don't start leading the meeting. I ask them to answer the 3 questions from their perspective. It keeps the others informed, and it helps to keep the Product Owner to be accurately informed which is quite helpful for his/her stakeholder management.

Let’s consider the chickens and pigs analogy that Scrum practitioners are fond of. If a person is so invested in the success of a project that they are attending the standup every day, then in my mind, that makes them a “pig” and their input is needed just like every other member of the team.

If you're a committed member of the team, then you have important work to do to make the project successful. Tell the team what you're doing! In my mind, the standup is partially about keeping the team members accountable to one another, so that everyone is clear about the team's goals and that each person is contributing on a daily basis to make those goals a reality. If you're the Scrum Master, for example, tell the team what impediments you removed the day before and which ones you're removing today. If you're the Product Owner, tell the team about requirements that you're gathering or priorities that you've shifted. Tell the team about demos that you've given or discussions you've had with stakeholders that are relevant to the team. How are you helping the team meet its goals? What impediments are you facing?

When a manager attends the standup every day but doesn't feel the need to communicate what they've been working on that's relevant to the team, it indicates to me that the person thinks the standup is an old-fashioned "status meeting" where underlings account for what they've been doing while management listens and judges. I would argue that the best place to see the status of work the team is doing would be to look at the backlog in whatever tool the team is using to organize work (Pivotal Tracker, for example). There’s no need to be in a certain place at a certain time each day to find out the status of work. Pull that status any time you like.

What do you think?