A year and a season ago, I took a new job, working at a small start-up in Boulder that aims to help people reduce home energy use. Last week was my last day there (I’m moving on to work with a team doing face recognition), and so I thought I’d write up some of what I learned.

This all comes from the point of view of someone who has mostly lived in a freelance mode, beginning with controlling my own schedule while I was high school age. So I’m unaccustomed to showing up at the same place regularly on someone else’s schedule. I’m unaccustomed to a lot of components of office life. And that’s exactly why I took the job in the first place.

Here are the big two things I took away: how you structure your organization in terms of status and communication will be reflected in what you manage to achieve as an organization, and how you structure your organization to develop the people in it is critical to your survival. Let’s talk about them.

First, communication and status structure. You’ve heard of Conway’s Law, right? I hadn’t. The gist is that a system-designing organization’s communicative structure will get reflected in the systems it designs. As a matter of personal bias, I strongly suspect that hierarchical systems discourage honest communication, and the more you can eradicate status as a component of your interactions, the more you can achieve honest communication. And I think honest communication is a prerequisite for making software that is simultaneously well-designed and meets business needs.

As I hear Marty Cagan said at Mind the Product San Francisco 2015, “if you only use your engineers to code, you are only getting about half their value”. This goes for all your employees, not just engineers—we humans are good at thinking about many kinds of things, and I hope that the humans you’re hiring are more than just cogs to spin in particular parts of your machine. Honest communication can be hard, but it’s how you avoid the cognitive waste of reducing your employees to one role.

(While we’re at it, I’ll plug Siderea’s piece on coordinative communication again. It’s not free, don’t ever think it is, or you’re committing a kind of accounting fraud, pretending that things that cost do not.)

So, smash your hierarchies. I think Valve is a cool model here, but not the only one. Actual collective ownership is another route, for example. But I also don’t see any great ways around the requirement that flat organizations be small. That may just be my bias, though: I don’t have much desire for large organizations, so.

Next, let’s talk about development. I think that everyone should be both a teacher and a student. Everyone in your organization has something they can teach, be it design sense, business understanding, how to play ʻukulele, or something else. This enriches everyone, but also, what a surprise, helps you smash hierarchy: if you have learned something from someone, it helps you remember that you are not “on top”, whatever that means, and mutual teaching encourages peer relationships.

Ben has said that the first part of any skill tree is just to recognize that there are skills in that area, that the labor isn’t free. I think that this kind of mutual education encourages this, and helps people understand the constraints and context of the labor that their coworkers are doing. Software development is notorious for being obscure in this respect, so there’s a lot of virtue in helping people understand what sorts of constraints do exist in software. You don’t have to get into a lecture on NP-hard problems, but helping people understand that, while it’s almost always possible to do a thing, it constrains the difficulty of future choices is really important.

Now, some personal notes: I think offices and office schedules are an antipattern. They are awkward proxies for a couple things we do want: evidence of productivity, context for camaraderie, context for coordinative communication.

I think that if you cannot more accurately and empirically measure someone’s productivity than with the bias-prone mechanism of “does someone look like they’re working”, then you have problems. Using that bias-prone mechanism can actually mask those problems, and ultimately cost more. (Also, while we’re at it, if someone’s not evincing the productivity you want, then you should also have mechanisms for helping them get there—see “development” above.)

Camaraderie is not something I value much. (I am more of a cat than a dog, if you will, and deep connections and mutual respect are much more meaningful to me.) However it is something many people find valuable—but I think that it can best be fostered outside of a work context. Have social events, get together and see each other as more than people-who-work-together.

Coordinative communication is certainly important, but we have this amazing worldwide network for communication now. If you need the bandwidth of in-person communication, organize it, but if you don’t, then you get lots of ancillary benefits to using written communication, primarily a record of the conversation and practice developing clear writing skills. Further, in my ideal situation, reducing the need for coordinative communication should be a goal: you need it early in a project’s life, and intermittently thereafter, but if you need more than 15 minutes of it a day in the body of the project, I think something’s wrong. It means you’re not giving people the necessary context to understand what they’re supposed to do. Again, an office can actually mask this problem, allowing apparently low-cost frequent communication to conceal that someone is maintaining power by strategic control of information.

Wow, got harsh there. So it goes. I may revisit this topic as I continue to digest it.

Addendum: nothing here is targeted. I think that everyone I worked with worked in good faith, but pathologies can emerge regardless, and pathologies can be visible even if you’re not directly experiencing them.