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.

A standup in progress

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.

Chickens & pigs

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?

What Would Christopher Alexander Think of Remote Work?

I was intrigued by a comment someone from Hacker News wrote in response to my post about office plans:

People tend to enjoy private alcoves with a view on the action, which is kinda best of both worlds. Christopher Alexander describes that pattern in _A Pattern Language_.

I felt an immediate connection between this idea and the feeling I get when working remotely. I think this "private alcove with a view of the action" applies in a non-physical sense as well. I wanted to see if I could make a more direct connection with Christopher Alexander's writing, and track down this pattern the HN commenter mentioned in the literature, and see if it jibed with remote work.

A Pattern Language

I bought a copy of Christopher Alexander's classic architecture book, A Pattern Language, and started hunting. And then...since the physical book ended up being ~1,200 pages in a format resembling an English dictionary in dimensions and typeface, I quickly found a nice, searchable electronic copy at the Internet Archive.

A Pattern Language

Alexander mentions workplace design in several of his patterns, and alcoves are sort of an ongoing theme throughout the book, but he never really ties them together in a way that captures the feeling I mentioned above. In fact, one of the interesting things I learned reading through dozens of patterns in the book, is that it's clearly a book that was conceived and written before remote work as we know it today was even on the horizon. In one section, he speaks of how Xerox and IBM typewriters have played a vital role in how he and his co-authors produced the book. This is an age before the Internet, when remote work meant having a personal typewriter in your home.

1970s IBM typewriter

It's frustrating to think about how the accumulated knowledge about human work activity pre-Internet is so tied to physical constraints and the built environment. A great deal of a masterpiece like A Pattern Language seems out of place, for example, when you can no longer take for granted that a company must have a central office where people gather to work together. Many of the foundational assumptions of a work published in 1977 would not exist in a work published in 2015.

The modern concept of remote work / telecommuting is so new, that the masterpieces that will describe this new world have not been conceived yet. Christopher Alexander is still alive, at 78 years old, but I couldn't find anything online about his views on modern remote work. I'm dying to know what he'd have to say about people working 100% remote for companies like 37signals Basecamp or Automattic.

So I didn’t find anything in A Pattern Language that seemed analogous to the modern remote work experience, but let me take another stab at it…

Evolutionary Aesthetics

Below is a landscape that people universally find pleasing to the eye. Why?

Gran Sabana, Venezuela

Several years ago I learned about the field of evolutionary aesthetics, which provides some fascinating insight into people’s preferences for certain landscapes over others. Here’s a quote from The Routledge Companion to Landscape Studies in a section on evolutionarily driven landscape preference:

A landscape form that affords somewhere to hide and look out from is the kind of landscape in which we feel safe.

How do you feel about the workspace pictured below? Quite a view!

Desk with city view

And here’s a picture of someone’s home office setup. Not quite the same view.

Home office setup

But, in a team that has a lively remote work culture, this setup can feel very similar to that wonderful city view. This is where you go to view the human activity of your team. To me it feels like I'm in a "private alcove with a view of the action."

Remote work tools

Going back to A Pattern Language for a moment, in the pattern called "Hierarchy of Open Space", Alexander says this:

Outdoors, people always try to find a spot where they can have their backs protected, looking out toward some larger opening, beyond the space immediately in front of them.
Simple as this observation is, there is almost no more basic statement to make about the way people place themselves in space. And this observation has enormous implications for the spaces in which people can feel comfortable. Essentially, it means that any place where people can feel comfortable has: 1) A back. 2) A view into a larger space.

I think remote work has psychological parallels to pleasing physical space. I know this is sort of a weird connection, but I feel like there's something there. If you've ever worked remote on a team of people that were also remote, maybe you'll know what I'm talking about. I think a person in their home office, working in a lively remote culture has the psychological equivalent of their back protected with a view into a larger space.

Am I crazy? What would Christopher Alexander think?

The Open Plan Office and the Extrovert Ideal

When I wrote my last post about open plan offices, I did not imagine the reaction it would get. It became the #1 post on both Hacker News and Proggit. In the hundreds and hundreds of comments people wrote in reaction to the post, there was an overwhelming feeling of negativity toward open plan offices.

Many people weighed in with their theories about why the much-despised open plan persists, and why companies continue to lay their offices out in such a way. Low up-front cost was the reason most people put forward, and I agree this is a major factor in why companies choose the open plan. There’s another strong reason that I think causes the open plan to persist, and since it’s one that I didn’t see many commenters hint on, I wanted to call it out here.

The Extrovert Ideal

Susan Cain’s New York Times bestselling book, Quiet, has sparked a kind of resurgence in interest around the concepts of introversion and extroversion and the deep ways in which they impact the working world.

Let’s start out with a simple refresher on these terms. Cain is clear that the terms are hard to pin down with objective definitions that everyone agrees on, but here’s a starting point. Quoting from her book:

Introverts are drawn to the inner world of thought and feeling, said Jung, extroverts to the external life of people and activities. Introverts focus on the meaning they make of the events swirling around them; extroverts plunge into the events themselves. Introverts recharge their batteries by being alone; extroverts need to recharge when they don’t socialize enough. If you’ve ever taken a Myers-Briggs personality test, which is based on Jung’s thinking and used by the majority of universities and Fortune 100 companies, then you may already be familiar with these ideas.

Cain goes on to describe what she calls the Extrovert Ideal:

We live with a value system that I call the Extrovert Ideal—the omnipresent belief that the ideal self is gregarious, alpha, and comfortable in the spotlight.

Introversion—along with its cousins sensitivity, seriousness, and shyness—is now a second-class personality trait, somewhere between a disappointment and a pathology. Introverts living under the Extrovert Ideal are like women in a man’s world, discounted because of a trait that goes to the core of who they are. Extroversion is an enormously appealing personality style, but we’ve turned it into an oppressive standard to which most of us feel we must conform.

After going on to reveal that one third to one half of people are introverts, Cain leaves us with this thought regarding office space:

In you’re a manager, remember that one third to one half of your workforce is probably introverted, whether they appear that way or not. Think twice about how you design your organization’s office space. Don’t expect introverts to get jazzed up about open office plans… Make the most of introverts’ strengths—these are the people who can help you think deeply, strategize, solve complex problems, and spot canaries in your coal mine.

Collaboration, Extrovert Style

When you read those beaming descriptions that company presidents and architects give when talking up their open plan office, there’s one magic word that comes off their lips like a reflex: Collaboration! Look how collaborative our space is! It’s one big room, man. No walls! You can’t stop these people from collaborating!

Open plan office in-private-office
Look at all this collaboration! What’s this lazy motherf*cker doing?

Looking out over the vista of their magnificent bullpen, teeming with activity. I can almost hear the ping pong balls!

This is how extroverts like to collaborate. What about the folks you invariably see in these open plans who are wearing noise-cancelling headphones most of the day. Let’s say maybe, one third to one half of them. Is it because they love music so bloody much that they just can’t stop listening? Nope. They’re trying desperately to keep people from poking and prodding their brains from every angle at random times.

By forcing your whole team into an open plan, you are effectively telling your introverts, act like an extrovert! All the time! If you don’t like this, there’s something wrong with you!

Some introverts collaborating

Introverts tend to be quiet people. When you keep shoving the extrovert ideal in their faces, they’re not likely to stand up and yell, “I’m as mad as hell, and I’m not going to take this anymore!” But read the comments on a post about open plan offices, and watch out! These people work with you!

Below are some of the comments people shared about their experiences in open plan offices on Hacker News and on my blog post itself. As an introvert myself, they ring true with my experiences in open plans.

I sometimes put headphones on but incessantly bombarding my ears with noise just to cancel out other noise is like spraying deodorant on excrement - pointless. It also means I'll suffer gradual hearing loss.
I sometimes wonder if people don't understand that we need time to solve problems and problem solving is best done in quiet! The other guys in this office do not write software so I sometimes wonder if people don't "get" it. – 72deluxe

I've done the headphone thing, they are noise cancelling, I listen to SimplyRain on them, and that helps, but I just can't take all that input. I want quiet. I need quiet. I don't want distraction that is slightly less annoying than the current distraction, at the risk of my health besides. – RogerL

I currently work in a 'creative' and 'collaborative' open office and I just don't enjoy it. It's loud, distracting, frustrating and worst of all, it makes me a hypocrite. I hate the noise, but I am just as much a part of the problem as everyone else. I talk to teammates and make jokes when other people are working, just as they do when I'm working. I can't keep count of how many times per day I'm deep in thought and then get startlingly pulled out of it when I notice my line-of-sight goes right through someone and they're looking at me. – benihana

I work in an open office, and everyone wears headphones for hours when they need to concentrate.
The thing is, these people are doing irreversible damage to their hearing. Listening to headphones at a volume that will drown out conversation is not a good thing.
Furthermore, I've never experienced as many migraines as I have before switching to an open office. I have to keep pills at my desk. Never had to do that before. – anon13839

The fact that you have to wear noise-canceling headphones (bought on your own dime, no less) to get work done is an indication that the space has failed in its primary purpose, which is to enable you to get your work done. A good office layout (or any good architecture, really) does not force the people who live in it to fight against the environment it creates. – smacktoward

We have people doing speaker phone calls with bad connections where they are yelling, endless joking and cackling, people walking by and saying 'hi' to you when you are deep in code. It's utterly impossible. – RogerL

Don't you feel self-conscious that everybody can see your every movement, for the entire day?
To me it reminds me of one of those Victorian prisons where every inch can be viewed from the central platform. Now that I think about it, even prisoners get a lot more privacy than this. – alextgordon

I am in a room full of people, none of whom are working on anything related to what I'm doing. The idea that my seating will help "foster collaboration" is ludicrous. It's all about maximizing the number of warm bodies per square foot. – OneMoreGoogler

In open offices there always seems to be at least one person (maybe several) who insist on having frequent personal conversations at full volume, completely oblivious to how many people around them are trying to work. Every open office I've been in had at least one and if they're that loud and inconsiderate to begin with, you can bet that nicely asking them to keep it done will not go well. Don't ask me how I know this. My kingdom for a door. – Anonymous

I'm just leaving one of the most unproductive places I've ever worked -- with an open floor plan with 5+ people per "pod" and pod walls only extending 2 feet over the desk area. It is noisy and awful!

I tried using empty conference rooms to concentrate on my work, but apparently an executive administrator noticed this after a week and had a talk with my boss -- I was banned from this practice and criticized as not being a team player.

I could not be productive in this environment, so I'm leaving. – Anonymous

None of them have a ping-pong table in the middle of the bullpen like mine does. The incessant banging of ping-pong balls really drowns out the noise of the loud conversations that keep me from thinking. – Anonymous

The worst thing I've ever had was on an open floor plan, when I was basically in an alley and people would pass right behind me all the time. Absolutely awful and extremely stressful. – Anonymous

(Notice how the topic of headphones keeps coming up. The classic refrain from many open office supporters—“Just wear headphones”—probably deserves its own post.)

The Results-Only Work Environment

I think, as an industry, we eventually need to get away from physical presence as an indicator of work happening. The question of “Did Jim work today?” cannot be accurately determined by assessing, “Was Jim’s chair warm from 8AM to 5PM?”


I can understand the appeal of looking out over an open plan office and seeing all the worker bees busily tapping away at their keyboards. Unfortunately, when it comes to knowledge work, that vision has essentially no correlation to actual work getting done.

The concept of the results-only work environment (ROWE) acknowledges this fact and embraces it. When you start focusing on the results of people’s work, and not the process by which they create those results, then showy displays of collaboration are no longer necessary. If getting a desired product of work requires collaboration, then people will collaborate. There’s no need to put them physically cheek-to-jowl all day every day to ensure that they’re collaborating. Dictating people’s physical proximity becomes as superfluous as dictating the text editor they use to write code. They will arrive at the result as they see fit.

No Size Fits All

Just as you can’t assume that everyone works best in a loud and open way, you can’t assume that everyone works best in a quiet, low-key way. Introversion and extroversion exist on a continuum. There are people at both ends and all the way in between. An office like, I don’t know, say the world’s largest open plan, goes pedal-to-the-metal all the way to the extrovert end. A building filled with individual privates offices and no common areas would go all the way to the introvert end. And even a very introverted person has some need for interaction, just like a very extroverted person has some need for solitude. There is no silver bullet.

Reading through the comments on my last blog post, there were several developers who wrote to say that they love their open plan and wouldn’t want to work any other way. Some mentioned that they had private offices in the past and found the open plan to be superior. I don’t doubt them! I believe they’re genuine. But I also believe that many people on the more extroverted end of the continuum don’t understand that not everyone is like them.

I want to make it clear that I’m not trying to make a blanket statement that every knowledge worker should have their own individual private office, and that’s that. What I’m trying to do is combat the assertion I see over and over from open plan office advocates that they’ve somehow cracked the nut on the future of collaboration. Guys, just take down all the walls! Duh. It’s lazy and irresponsible.

The inconvenient fact of life is that the best workplace is not going to be infinitely replicable. Vital work-conducive space for one person is not exactly the same as that for someone else. If you let them, your people will make their space into whatever they need it to be and the result is that it won’t be uniform. Each person’s space and each team’s space will have a definite character of its own.

Management, at its best, should make sure there is enough space, enough quiet, and enough ways to ensure privacy so that people can create their own sensible work space. Uniformity has no place in this view. You have to grin and bear it when people put up odd pictures or clutter their desks or move the furniture around or merge their offices. When they’ve got it just the way they want it, they’ll be able to put it out of their minds entirely and get on with the work.

Peopleware, “Breaking the Corporate Mold”

Going Beyond Productivity

I’d like to go beyond productivity for a brief moment, and talk about quality of life. One of the most striking comments my last post received was by a Redditor:

A few years ago, I was working at a company where they had just purchased an old shoe making factory and were renovating it into office space so they could have room to grow. In each spot where a person had sat for 8-12 hours hunched over in front of a sewing machine, I was told to install a workstation and run network and electric cable down from the ceiling where the sewing machines had been hooked up.

At the end of the project, a co-worker of mine that had the foresight to take a picture of the old setup took one of our finished work and compared the results. The room looked a lot cleaner, and didn't have the smell of oil and leather anymore, but in the photo, it looked like a factory that you'd see in the early part of the 20th century by its layout. The lone difference being instead of looking like it would make shoes, it looked like it'd make code. They both looked like you'd have the same amount of privacy (aka none), and unless you bought headphones, the same amount of silence for concentrating on your task(s).

So to get to the point, every time I see articles like this one that's linked, I don't see a fancy office, or a stylish work environment, or a hip new way to collaborate and be all super productive. I see a cleaner, digital sweatshop, a modern version of an age that many thought we had left decades ago. It hasn't really left, it's just had the cleaning crew in and been given a few runs through the marketing machine to make what was once undesirable "suave and sexy!" – canadiancreed

Is this a true story? I don’t know. Is it a bit overly dramatic to compare an open plan office to a sweatshop? Perhaps. But I think there’s a valid point in there: quality of life matters.

If you’re unsure if real suffering is going on in open plan offices, read through the 1,300+ comments on Reddit. Your more introverted employees and colleagues are stressed out, on edge, annoyed, disrespected, and in a constant state of not-quite-bad-enough-to-quit. If you see your company as a “big family”, look at how you’re treating some of your family members. This is no way for a person to spend 8+ hours a day for years of their life.

Finally, I want to address a point that several commenters made about the well-known tech companies I highlighted in my last post. Here’s a representative comment:

These seem to be successful companies. Does that make you question your assumptions about open spaces? – Anonymous

It’s a fair question. Facebook, Twitter, Dropbox and so many other wildly successful companies have open plan offices. Obviously their software developers are productive! Beside the question of how much more productive they could be in a different layout, I’ll ask again for you to look beyond the issue of productivity. If many of your employees and colleagues could work day in and day out in a space that was not at odds with who they are as people, what would that do to turnover? What would that do for their personal lives? What would that do for their stress and sense of well-being?

But Where Do People Work in This Office?

In one study after another, workers failed to give much weight to decor in choosing, for instance, among variously colored panels and fixtures. The feeling seemed to be that depressing surroundings would be counterproductive, but as long as the office wasn’t depressing, then you could happily ignore it and get down to work.
So we see the paradoxical phenomenon that totally unworkable space is gussied up expensively and pointlessly with plush carpets, black and chrome furniture, corn plants that get more space than workers, and elaborate panels. The next time someone proudly shows you around a newly designed office, think hard about whether it’s the functionality of the space that is being touted or its appearance. All too often, it’s the appearance.

Peopleware, “The Issue of Glitz”
I’ve become fascinated by the concept of office space design for knowledge workers, in particular software developers. There’s a fantastic site called Office Snapshots that gathers information and photos about the offices of hundreds of companies, including many well-known software companies.

We’ve all heard about the lavish offices of Silicon Valley, where tech companies gather the best programmers in the world and spare no expense to provide for their every need. After looking through tons of cool office photos of many of the hottest companies in the Valley, I started to play a fun game I made up called “spot the desks”. I’ll show you what I mean.


Mark Zuckerberg recently engaged world-famous architect, Frank Gehry, to design “the largest open-plan office in the world.” Since that one’s still in the offing, I’ll share a few photos of Facebook’s existing campus in Menlo Park.

An all-you-can-drink coffee bar with free snacks!

A bright mural and custom-made propaganda posters (HACK! MOVE FAST & BREAK THINGS!)

I see a lot of awesome stuff, but where is the quiet area where your big brains go to make world-changing software? Oh, jeez. Were the geniuses that wrote Cassandra and HHVM sitting in a bullpen like this?


In the tech mecca of San Francisco, let’s check out Twitter’s headquarters.

There’s that coffee bar again. More free snacks!

It’s like a Dave & Buster’s up in here!

Ok…now where do the developers sit? Oh, I think I see them in the background of this conference room photo. Wow, that looks kinda noisy. Is that guy at card table #2 working on Bower?


We could go on all day, but let’s check out one more office. Who doesn’t love Dropbox?

It’s like they have their own Panera!

Just chillin’ in my treehouse / log cabin / conference room…

You know the drill by now. Let’s see where the desks are where the devs have their big monitors, keyboard, ergonomic Aeron chairs, and all their gear set up. You know, where they get in the zone and write that world-class code. Wait…what the f*ck!? I wonder how many MIT grads per square foot you can fit in here?

I could go on and on and on. The pattern keeps repeating. With everything we know about open plan offices, why are these mega-rich companies knocking themselves out to hire the very best and brightest minds from the world’s best universities, paying them huge salaries, tapping world-class architects to design artisanal office spaces in the most expensive place in the country, and then cramming desks together in noisy bullpens?

People Hire Clones of Themselves

Here’s a recent exchange I had in the comments of yet another post about the challenges of hiring software developers on Hacker News:

...a lot of companies that are selling pants online are searching for PhD-level engineering talent to run their shopping cart.

I've noticed this, too, and been baffled by it. My working explanation is that people tend to hire clones of themselves. If the people making the hiring decisions in that online pants company have PhDs, they'll believe they need PhDs to work on that shopping cart.

> people tend to hire clones of themselves
Winner winner, chicken dinner.
Ask a company that is hiring "is X important?", where X is one of {open-source coding, algorithm design, Ivy league degree, master's degree, MIT degree, Facebook alum, Google alum, presence in Silicon Valley, under 25 years old, over 25 years old, has a github, has a blog}, and you will get a "yes" for each X that the founder has.

This ended up being my highest rated comment on HN, so I thought it’d be worth expanding on with a blog post.

Hiring Is Hard

Hiring software developers is complicated and damn hard. Just hang around Hacker News, Twitter, or your favorite software blog aggregator and you’ll see people endlessly debating the best way to hire good software developers. It’s clear that as an industry, we’re not even close to reaching a consensus, much less even general best practices that most people agree on.

It’s not surprising then that the software industry generally sucks at making high-quality matches between organizations and potential hires. I won’t pretend that I have answers, but I just want to highlight one aspect of hiring that can be particularly baffling, especially if you’re a young software developer early in your career and trying to figure out where you fit in.

No One Thinks They Suck

In light of the bewildering difficulty of vetting software developers, an interviewer/evaluator often turns to the one exemplar of excellent software development he knows better than any: himself.

People tend to unconsciously assume, “If I hire someone like me, then I know they’ll be good, because I’m good.”

Psychologist Dr. Robert Cialdini explains in his classic book, Influence:

We like people who are similar to us. This fact seems to hold true whether the similarity is in the area of opinions, personality traits, background, or life-style.

Car salesmen, for example, are trained to look for evidence of [backgrounds and interests] while examining the customer's trade-in. If there is camping gear in the trunk, the salesman might mention, later on, how he loves to get away from the city whenever he can; if there are golf balls on the back seat, he might remark that he hopes the rain will hold off until he can play the eighteen holes he has scheduled for later in the day; if he notices that the car was purchased out of state, he might ask where the customer is from and report--with surprise--that he (or his wife) was born there, too.

Now, Cialdini was talking about a car salesman trying to move merchandise. But in a hiring situation, the candidate’s future work is the merchandise. The more that the candidate seems like the interviewer, the more likely the interviewer will want to hire that candidate.

That’s not to say that candidates do or should manufacture their interests and backstories. But if the interviewer puts a lot of effort into blogging, and the candidate has an active blog…or the interviewer has a side project in Haskell, and the candidate mentions that Haskell is their favorite programming language…or they both like to tinker with Linux in their free time…you get the idea.

I am not immune from this bias. I’ve found myself warming up to interviewees when I discovered they used ReSharper (one of my favorite development tools), were interested in the same bleeding-edge JavaScript framework I was, or something as utterly irrelevant as we both loved indie music. None of those things are direct evidence that they would make good software if they were to join my team.

There can also be a bias toward people who took the same path that you did to get where you are. If I earned a Computer Science degree before starting my career, and you didn’t…or software is my first career, and you transitioned to it from a different career…or I’ve worked for tech companies, and you’ve worked in a technical role for non-tech companies…again, you get the idea.

I’m not trying to point fingers here—we all have our biases and blind spots. I just want to make the point that objectively vetting software developers is hard as hell and many interviewers are not very good at teasing out the stuff that matters: will this person deliver high-quality software if they were to join my team? It’s super easy to fall back on: are they like me?

“Cultural Fit”

There’s a general catch-all term for the non-objective criteria by which companies decide go or no-go on candidates: “cultural fit”.

There are explicit laws against rejecting a candidate because they're not the same race as you, or the same sex, or the same religion. But some people will freely reject you for reasons that don’t necessarily seem relevant to the daily work they do, like they have a degree from a name-brand college and you don't, or because they attend hackathons and you don't, or they've memorized the merge sort algorithm and you haven't. People will sometimes jump to conclusions about your ability as a developer based on lifestyle choices you've made, what you do in your free time, or your preference for one programming language over another.

It can be frustrating that some teams get very micro-focused on the smallest aspects of software development, while being far from getting the most basic things right. There are about a million and one ways to effectively deliver software. At the end of the day, does it really matter if one team writes specs and the other writes unit tests? One hand-writes their SQL queries and another uses an ORM? One uses Gulp and another uses Grunt?

It’s Not You, It’s Me

Again, my aim with this post is not to condemn the way that people make hiring decisions, but just to help explain what can be the somewhat baffling way that groups of people choose who will join them.

Just be aware that simply being good at what you'd assume are the objective aspects of your job as a software developer (delivering high-quality software on time) are not always enough to land a job with a specific group of people. Much like dating, you can't take "rejection" personally. Just because you didn't fit one person (or one organization's) image, doesn't mean anything about your general worth. Sometimes it takes just finding a group of people whose preferences align with your own.

When new companies appear on your radar (and you’re open to a career move), you can save a lot of time and shut down unproductive avenues by paying close attention to the “cultural” aspects. If a culture clash is coming, it’s better to find out sooner rather than later, as those opportunities won’t work out in the long term.

How I Work Remotely

With the trend of remote work on a rocket ship to the moon, I thought I’d share some things I’ve learned working in a distributed organization where remote work is common.


Asynchronous Communication

As software people, we’re familiar with the concept of asynchronous communication. When my web app needs to kick off a long-running process on the server, it doesn’t freeze up until the server finishes the work and gets back to it. When I’m working as a member of a distributed team, adopting an asynchronous style of communication with my fellow humans becomes important.

I start by getting out of the synchronous mindset where I’m blocked until I get feedback from a specific person at a specific time. Remote team members are like long-running processes on a distant server. I assume that my communication with them is mainly asynchronous. I keep other tasks in mind that I can keep making progress on while that remote process is generating a response for me.

Effective Writing

When working with distributed team members, written communication takes a front seat. Getting input from people via writing is more effective when I keep a few points in mind.


Set the person up for success

Since email tends to be the dominant form of written communication in my distributed team, most of the important lessons I’ve learned relate to effective email. When I’m writing up an email to a team member, I try to set them up for success.

Since some of the folks I work with tend to have unpredictable schedules and receive a ton of email, I want to make it easy for the other person to provide a clear, unambiguous answer in one email that can unblock me.

I anticipate some of the reasonable possible responses they’re likely to give and include those in the email. It’s almost like preparing a menu of options they can pick from so they don’t have to start from scratch when they’re writing up a response for me. This becomes easier the more you work with certain people and learn how they tend to think.


Assuming as little as possible about the person’s mental context is another lesson I’ve learned. I avoid jumping in with a very specific question, assuming that the person will know exactly what I’m talking about. I’ll remind the person of the context of my question so they don’t have to rack their brain to rebuild the context. If we’ve written about the topic before, I’ll dig up our previous communications and quote them in the new one.

Include links! If I’m referencing something that has an online artifact, I link it up! Don’t make the person chase down things that I can pre-chase. For example, if we’re discussing the requirements for a particular backlog item, I grab the URL to the backlog item in TFS and include it in the email so the person doesn’t have to first dig up the backlog item before they can respond to me.

The sort of meta-point behind all these lessons is that people are more likely to respond effectively and in a timely fashion if you make it simple for them to do so. Set them up for success!

A picture is worth a thousand words

The old saying is true. When I’m discussing something that could be screenshot‘d, I include a screenshot! Windows has for several releases included the Snipping Tool, which is a simple screenshot tool I use a ton, as I work in a Microsoft shop. If you’re on OS X or Linux, I’m sure you can find similar tools for taking screenshots and marking them up.


Circle elements of the screenshot and draw arrows. When I visually draw attention to the most important aspects of a screenshot, it leaves no ambiguity as to what I’m talking about. I can’t count the number of times an email chain could have been shortened by a simple screenshot with red circles around the areas in question.

Mockups accomplish a similar purpose to screenshots, before something exists to be screenshot’d. When my team is in the stages where a new chuck of functionality for our application is coming into being, a simple mockup in a tool like Balsamiq can bring untold clarity to a design discussion and form a solid starting point for productive conversation to focus around. I’ll touch on Balsamiq again a little later.

Explain it to the duck first

Often I find that when I take care to thoroughly explain something in writing to someone, I end up not even needing to hit Send. Writing requires one to clarify one’s own understanding of a concept. Developers have a term for this process: rubber duck debugging.

Rubber ducks

State of the Project (Single Source of Truth)

When working in a distributed team, it’s important to have an online Single Source of Truth (SSOT) that people can go to to pull information from. You can’t rely on word of mouth to spread the status of work throughout the team.

State of the Union

There are about a million and one tools that will get the job done, whether it’s Pivotal Tracker, Asana, Trello, or something else. On my team, we use TFS for this purpose. Pick one and stick with it. Our whole team knows that TFS is the SSOT.

When I find some important piece of information missing from the SSOT, and I have to ask a team member for the information, I ask them kindly to answer the question by updating the SSOT. That way this new piece of information becomes available to the whole team the moment it becomes available to me.

If someone asks me for the status of something, I point them to the SSOT, because I’m always keeping the SSOT up to date with my status.

When the product owner dreams up a new requirement, right away we capture the requirement in the SSOT. Eventually you can weave into your team culture that if something doesn’t exist in the SSOT, then it doesn’t exist.

Build a Rough Version and Show It

There’s no doubt that it’s a bit more cumbersome to discuss highly visual concepts remotely. That new page in your web app that your product owner wants is tougher to design without a whiteboard in front of the two of you.

I encourage folks to get away from the idea that you have to perfectly define every aspect of some new thing before anything can be built.

I think this is a skill you develop with experience, especially if you’ve gotten used to working with a particular product owner. You can cultivate a part of your brain that can act as a sort of proxy for your product owner if they’re not immediately available to answer a question.

Taking care to understand the high-level motivation behind a feature allows me to rough in some of the details in the early stages with the confidence that they’ll only change slightly in the later stages when every little thing is being defined. For example, I won’t stop making progress on a new screen because I’m waiting for the product owner to tell me what color a button should be or the exact phrasing of a label. I use my best judgment, then keep on truckin’. Those things are easy to change later.

When finding myself in doubt about the general approach to take with some new feature, there’s no better way to get the conversation moving in a productive direction than to create a quick mockup. Again, a picture is worth a thousand words. Once you have some sort of visual artifact you can both look at independently, even if it’s wrong in many ways, then you’ve got a basis for productive conversation.

Balsamiq Mockups

Balsamiq is a fantastic tool for mockups. It’s very quick to produce a rough sketch of an idea and start getting opinions on it. Balsamiq has the awesome property that its shapes look rough and unfinished by design. The lines are a little squiggly, the font is almost Comic Sans-ish. It gets the message across that this is just an idea, it’s not intended to be a final product. Get the broad strokes of an idea across without people getting caught up in the fine details.

Once I have a mockup that shows my best understanding of the problem being solved, it’s time to send it over to the product owner (or whosever opinion I’m seeking) and get their comments on it. Once we’ve agreed on the general layout of a page, we can proceed confidently with development, knowing that we’re not wasting time and won’t have to bug each other for a while.

When You Just Have to Be Synchronous

Up to this point, all the tips I’ve discussed have been about how to work asynchronously as much as possible and how to be effective in that mode of communication. Well, there are times when I just need that real-time exchange with someone because the thing we need to discuss can’t wait. There are three main ways that I go synchronous with remote team members: screen sharing, conference calls, and instant messaging.

When we have some visual artifact that we both need to have our eyes on at the same time, screen sharing tools are the way to go. On my team we use WebEx, but there are a million other tools that can do this, including GoToMeeting, Microsoft Lync, and Google Hangouts.

Conference calls are old-school but they can be handy in some situations. For example, my team has a regularly scheduled stand-up every morning. There’s a standard con-call number everyone knows, and if you’re working remote that day, just call in and you can participate in the stand-up just like the folks at the office.


I have conflicted feelings about instant messaging. For one-on-one conversation, it beats a phone call as it’s less intrusive and people generally understand that an immediate response is not needed. But it has the same downside of ad-hoc in-person conversations in that the content of the conversation is not preserved for later reference. For anything beyond the most trivial of exchanges, I prefer to use email as it automatically creates a record that I can search through later when weeks (or months, or years) have gone by and I can’t remember why we decided to do thing X over thing Y. Somewhere in the middle are tools like Campfire that do group chat with automatic transcripts. I’ve used tools like this in past jobs, but they haven’t found wide use at my current company yet.

Writing is Searchable, Voice Isn’t

This is a sort of meta-point that I’ve touched on above, but I’ll call it out here as a separate thought. If a team can get used to written communication as their main form of communication, they get the awesome benefit of a searchable, historical record of their decision making process. Be honest, how many times have you wasted effort trying to remember why some feature of your software works the way it does? No one can remember because it was designed via ad-hoc conversations in the hallway or over the phone and no one thought to write down the salient points that led you to do whatever it was that you did. Or when you demo a completed feature to the product owner, and a moment of panic ensues because they remember telling you to do X, but you thought they said Y, and no one knows what’s correct because no one wrote it down.


Writing is recorded, voice isn’t. Writing is searchable, voice isn’t.

I ♥ Remote Work

Some of the most blissfully productive days I’ve had are when my whole team is working remote because a winter storm has left us snowbound. There’s nothing quite like the glorious zone of productivity sans soul-crushing interruptions. I’m extremely optimistic about the global trend toward remote work, and I’m confident that more people will keep making the jump to full-time remote work (me included).

There are undoubtedly unique challenges that come with working remote. The most helpful lessons I’ve learned are to communicate asynchronous-first, express myself clearly in writing, keep my team up to date, exercise careful independent judgment, and go synchronous when asynchronous just won’t do. When my distributed team does these things well, we can kick ass together.

Introducing Kenny

Kenny is my tool for webmasters who run sites secured with HTTP basic authentication. Kenny can track down and show these folks where logins for their site(s) have been leaked on the public Web.


Ride into the danger zone, y'all. - Kenny L.

I envisaged Kenny as a project in which I could explore several technologies:

And that's exactly what I did: Kenny is now a real thing, and all these technologies were crucial in its construction.

Kenny homepage

Webmasters can add the sites they want to track.

Add your sites

Kenny will search the public Web for logins and collect them in a list where the webmaster can test them for validity and review the source of each leak.

List of logins

I had a ball working on Kenny, and I learned a lot about some technologies I’d been itching to work with. I plan to follow up this blog post with another that goes into some details about the different tech I used, what I learned, and what was cool about them.

In the meantime, check out the source code and play with the demo on AppHarbor: