I have been thinking a lot about company-building lately.

Before starting Justworks, most of my experience was centered around building things on my own as an engineer, or as part of a single cohesive product team with 2-10 people.

Often, people build organizations as a “big team”. Much of the decision-making is centralized at the top. During my internship at Yahoo in 2006, I was part of a cross-functional team where the only person that we all reported to in common was the CEO! That’s crazy, because it means that any contentious decision can only be resolved at senior levels, and in practice it means that contentious decisions are not made. Only safe and obvious decisions are made and everything else ends in gridlock. That is a lost opportunity.

During my career, I have worked in two organizations that really focused on decentralizing decision-making. Both are exceptional organizations.

One is Amazon. It is a hybrid model, and Jeff still has his hand in a lot of things, but there are many small teams that operate with relative autonomy. Because of their architecture, teams spend a lot of time negotiating with other teams (establishing APIs and SLAs, for example) but many decisions can be made within a single team. It’s not perfect but Amazon has enjoyed outsized returns over the past few decades and this is an important part of it.

The other is the army. While it evokes images of drill sergeants and generals and “command and control”, the reality is that the army is a highly decentralized organization. Small units operate within an established framework but have latitude in how they accomplish their missions. This is necessary for survival because the battlefield is too big and changes too quickly for any one person to make all the decisions. (McNamara choosing bombing targets himself in Vietnam is a classic example of military dysfunction.)

Amazon and the army have many things in common. Here are a few:

  1. They have strong values and cultures. In both of these organizations you can ask anyone about values and they will respond with some specific answers. They invest heavily in developing and maintaining culture.
  2. They select leaders carefully and ensure that these leaders are aligned with the organization’s culture and values. In the case of the military, they grow these leaders from scratch, often starting with recent high school graduates (West Point or ROTC.)
  3. They have robust communication systems that allow small units to operate autonomously without losing visibility into what each unit is doing. Information can move quickly up and down the organization.
  4. They have strong support systems that allow each unit to focus on its mission. This means certain systems are highly centralized (personnel and logistics systems, for example) in order to support decentralization around organizational objectives.

There are lots of other things and these organizations are far from perfect. But I believe these are the key components of how they have been able to achieve massive scale while continuing to be highly effective.

So, if team-building is orchestrating a small group of people to accomplish a single mission, then company-building is creating an environment where many teams can thrive together and move towards a common goal with relative autonomy and latitude.

Here is an excerpt of a recent all-hands meeting that includes more (though some of the diagrams are a bit esoteric without a voice-over, but you’ll get the gist)

Evolving your battle rhythm

In the military, there is a concept of “battle rhythm.” This is essentially the cycle that military leadership operates on, though the cycle is different at each level. For example, your TOC (tactical operations center) might run on 12-hour shifts, with a briefing during each shift transition where everyone is updated on what’s going on. Police departments do something similar.

What I love about this concept is that it acknowledges that sheer and utter chaos is happening around you, yet it is possible to maintain a certain tranquility; to create certainty in the face of the unknown.

Each company, and team within a company, has its own battle rhythm. At Etsy, my team had a “milestones meeting” at 1pm every Friday. This meeting acted as a metronome, letting the team synchronize their efforts to it. What part of this project can we get done in time for milestones so we can demo it? It’s Friday morning, is everything in JIRA updated for milestones at 1?

Creating this structure creates alignment between people and also helps people break seemingly herculean tasks into manageable chunks. It creates certainty.

I have been thinking a lot about how we do this at my company, Justworks. For about six months each team lead has been putting together a metrics sheet, and every Tuesday at 11 each lead updates the others on their metrics.

When we started the meeting, it was an invaluable tool for gaining alignment between teams and pushing each lead to gather the information that we needed to understand the business. It forced us to better understand our business, together. The meeting was never fun, but it was a huge step forward.

But six months have passed, and the company has evolved. The conversation has changed. Instead of talking about the actual numbers, the conversation consistently drifts towards big, important topics–because we’ve been able to develop better numeric fluency over this period of time. (We’re nowhere near done, though.)

So, I think it is time to change the format and cadence of our meetings, so that we can get the best thinking out of our leaders. It is time to evolve our battle rhythm.

Improving the quality of your company’s thinking

I worked at Amazon from 2002-2009, with a break in the middle for business school. People often ask me what it was like to work there, and why they’ve been so successful.

I argue that their success, as they’ve pursued myriad business and product lines across many verticals and markets, is driven almost entirely by the quality of their thinking.

Here’s what I mean: When you go to a meeting with Jeff Bezos at Amazon, you spend time preparing a document. It could be called a narrative, a 1-pager, or something else–the name doesn’t really matter. The document is an articulation of what you are trying to accomplish and your understanding of what it will take to get there. The document is long, thorough, and written in prose.

When you present to Jeff for an hour, you spend the first 20 minutes while he reads your narrative, making notes in the margins. Everyone else waits. It sounds like a waste of time, except that the following 40 minutes is pure gold. For 40 minutes, you have a strategic discussion where everyone in the room is on the same page, has the same context and access to detail.

I believe that those meetings, along with Jeff’s intellect, are Amazon’s true competitive advantage. They think better than their competition. Great decision-making and execution follow.

While most meetings at Amazon don’t involve Jeff, the pattern is similar. Engaged, thoughtful discussion where the meeting owner has spent time preparing so that you can get everyone’s best thinking.

In stark contrast is a product management internship that I had at Yahoo in 2006. At each meeting, people would barely prepare and would instead bring their laptops. They’d leave the laptops open so they could check email and even send each other IMs — in the meeting! The quality of the thinking was poor and Yahoo’s operating results followed. I couldn’t wait to get back to Amazon.

To this day, I avoid laptops in meetings and encourage presenters to participate as best they can. It’s tough. There’s a lot of pressure to be online and available all the time, much more so even than in 2009. I’m hopeful that by creating a place where distractions like email, social media and Google can be avoided, I can get my team’s best thinking.

Putting together chairs

Something really cool happened the other day.

We moved into a new office recently. The place came with desks but no chairs, so we had to buy a few dozen chairs which, of course, come in a box unassembled.

There were still a bunch of chairs that hadn’t been put together yet, so after our all-hands meeting I was sitting on the floor with some of my colleagues putting together the remaining chairs. It was fun, a nice change from normal work and a chance to shoot the breeze with some of my favorite people.

Then a candidate for a software engineering job came into the office for an interview. At first he was a little surprised to walk in on a bunch of people putting together furniture; but I offered him a glass of water and got him settled in a little bit.

He commented that “it feels really good in here” and “I feel calmer already”. “There’s something about people sitting on the floor that’s incredibly disarming.”

What he really got was a sneak peak at what we’re actually about at Justworks. Not the day-to-day, per se… there are only so many chairs to assemble. But more about the fact that there was work to be done and we sat down as a team and did it, smiling.

Of all our candidates I think he might have gotten the single best feel for what it’s like to be on our team. And I think if we get to a point where there is a fit on both sides he will probably take the job.

Kanye says AGAIN

We’re working on a big, important tech project at Justworks. While I’m excited about what we’re delivering, I’ve never been a huge fan of big projects. They’re fraught with risk, and even worse, the world changes more quickly than the project requirements. Which means that in many cases the work is already out-of-date by the time you launch it. That sucks.

I recently read a post by Fred Wilson about how “development is cheap, production is not” and that reminded me of how we’re tackling our current project.

One of our PMs, Chris, was in charge of defining the requirements for the project. Key use cases and flows, components, that sort of thing. Chris took a shot at a first draft of the document and then we reviewed it together as a team. There were lots of changes that needed to happen in order to make the requirements workable.

Chris was inspired by a recent Kanye West concert where Kanye performed “Niggas in Paris” not once or twice but three times in a row. After the first and second performance Kanye simply yelled “AGAIN” and started over again.

So, Chris scheduled a review meeting “AGAIN”. (That was in the title of the invite.) And AGAIN. We met a total of 6-7 times to continue refining the requirements until everyone in the room was confident that the definition was as good as we could get it.

Meeting 6-7 times about the same topic and reviewing the same document is tough. But what’s tougher is getting halfway into the project and realizing that there are major definitional gaps where no one bothered to flesh the spec out. Unknown unknowns. That can have catastrophic consequences on the project and on morale.

We haven’t finished this project–though we hope to in the next 30-45 days–and it will be with its own hiccups, but I think that meeting AGAIN really helped. I would encourage you to do the same the next time you’re specing out a big project.

Suite 451

When I started at Etsy in December 2009, buyers were unable to make purchases on the site using a credit card. The vast majority of transactions went through PayPal. This was problematic for us as a marketplace because the buyer checkout experience lacked cohesion and we had a hard time delivering great customer service if things went sideways with a purchase. There were other problems too but these were the big ones.

I made it my personal mission to “fix” payments at Etsy, mainly because of my payments experience at Amazon. It seemed like you should be able to check out with a credit card just like on other big e-commerce sites, and I felt like it was my responsibility to deal with it. It was nominally a company priority but various efforts had already been stalling before I even came on board.

One of the reasons that payments had been stalling for so long at Etsy was because no one had successfully taken a multi-functional approach before. Business people had taken a run at it a few times, but without support from engineering they couldn’t actually deliver anything. Product people had taken a run at it, but without the vendor partnerships, technology know-how and support from finance they couldn’t pull it together. Payments is fundamentally a multi-discipline problem that requires intense collaboration between a variety of business, product and engineering disciplines.

There had been lots of cross-functional teams at the company already, but cross-functional is not the same as multi-functional. In our cross-functional teams, loyalty went back to the function rather than the project. The mindset was “I am a PM on the product team, and I happen to be working on the ___________ project right now.” This probably sounds familiar. It’s common in many organizations because lines of decision-making authority and career progression often go back to the function rather than the product or business line.

About a year after I started, I got the payments project resourced and backed by the company’s leadership, but the project was still moving slowly. Then, I stumbled upon suite 451, a roughly 1000 square-foot room on a different floor from the main office.

I had been re-reading Peopleware and focusing particularly on chapters 7-9 which discuss things like the effect of ambient noise and open floor plans on software developer productivity. In an effort to reduce ambient noise, we decided to try an experiment and have the team move to 451.

Moving to a separate part of the facility was a big deal. My desk had moved at least five times in the previous 24 months–so had everyone else’s–but this was different. The level of anxiety about the move was very high, particularly amongst functional leaders. The concern was that separating the team physically would result in organizational isolation. (This was true,  but I thought it was worth it to ship the product.) Then there were basic logistical concerns, such as difficulty accessing shared resources like printers and pantries. The members of the team were worried about being isolated, too.

So we moved in. We bought couches, tables and rugs, brought in whiteboards, procured a projector and old computers for dashboards. We did all this on a very modest budget but it was ours. The team started to think about itself as its own unit, separate from the rest of the company and charged with a critical and challenging mission.

The process of moving into our own space radically changed the mentality of the team. We all thought of ourselves as “payments”, regardless of what function each person was coming from. Business, product, design and engineering people sat together. We tracked the same milestones and metrics and had a single weekly meeting, the agenda of which included not just product development but also product marketing, risk management and customer support. We had a handful of crystal clear goals and the entire team was focused on them no matter what their title or function was. These are things that we had done before, but claiming our own space took it to a new level. We became truly multi-functional.

I am including a picture of the room. Basically it was a long L-shaped room with a little nook that we used as a conference area. The echo was terrible and it didn’t get direct sunlight. We didn’t take time to decorate the walls. It was real estate that no one wanted, but we made it ours. (After the team moved out, 451 became a storage area.)

Suite 451

For the people that were on the team while we were in 451, I think that this time will always be special. For me it defined my time at Etsy and was my biggest professional accomplishment. This was when the team became a high-performance team. We weren’t there for long, about five months total before we moved back into the main open floor plan. Many of the predictions that functional leaders had made were true. The team was becoming organizationally isolated and once the product was launched it became important to re-integrate the team, its members and its institutional knowledge back into the rest of the company. Once we’d launched, the advantages of being isolated quickly diminished relative to the costs.

While the team has re-joined the rest of the company, the multi-functional and high-performance nature of the payments team has remained. They have continued to build and launch important and impressive products and I am proud of what they have accomplished. Etsy itself has come a long way since the payments launch (about 18 months ago) and new multi-functional teams have formed that are delivering great results.

I have many takeaways from my time in suite 451 but the three most important are that (1) multi-functional teams can accomplish more than cross-functional or single-function teams, (2) crystal-clear objectives help focus across functions, and (3) strong camaraderie is critical for high-performance teams. These are lessons that I will carry with me throughout my career.


Further reading: Tracy Kidder’s The Soul of a New Machine describes a similar situation at Data General in the late 1970s where a team moved offsite to build an important new product. Drastic times call for drastic measures.

Transparency as a value

I’ve heard many people talk about transparency as a value. “At our company, we’re transparent,” people say. But values don’t really take on meaning until you begin living them, and this is where transparency can quickly become a myth.

I think of transparency as operating with a default mode of “share”. It consists of a few things:

  1. Using sound and consistent judgement (i.e., your other values) to decide what information should be shared and what information is private
  2. Sharing information proactively even when (a) the other party would benefit from knowing something but wouldn’t know to ask, or (b) it’s uncomfortable
  3. Sharing the reason why information is private if you choose not to share something

Deciding what information is private

Every organization and person makes decisions about to share and what not to share. This requires the highest judgement and integrity because only the person or people with the information can make the decision. Of course, having other values is a useful lens for deciding. Here are a couple of interesting examples:

  • The U.S. government classifies documents based on whether “the material would cause [damage] to the national security.” That’s a broad definition, and it is applied variably.
  • The U.S. defense department publishes pay tables. Whole Foods and Norway publish salaries of all their employees and citizens, respectively. These organizations have made a clear statement that compensation information is not private.
  • Though not about information sharing exactly, the 9th step of AA’s 12 steps says “Made direct amends to [persons we had harmed] wherever possible, except when to do so would injure them or others.” The person following the 12 steps is responsible for figuring out whether their actions would cause injury.

Sometimes people horde information to consolidate power within organizations. Or they do it to protect a decision they’ve made from scrutiny, or just because secrecy is a habit.

The best thing a leader can do is be the example of what information should be shared and what is private. The rest of the organization will follow.

Sharing information proactively (“Own your own news”)

If you decide that a given piece of information can be shared, then:

  1. Share the information proactively with people who you believe will benefit from knowing the information. Don’t wait for them to ask.
  2. Share the information, even if it makes you uncomfortable or has mixed consequences. These are often the things that are most important to share. Make sure you have your facts in order, plan your conversation and be respectful.

Keeping information private is okay

Sometimes you decide that information should be kept private (even when “transparency” is a value!)  That’s okay. If the topic comes up, you should be prepared to explain why you have decided that certain information is private:

Q: How much does Joe make? A: That’s private. We don’t share compensation information because it involves a number of factors that are specific and personal to Joe.

Q: Do you think BigCo will buy us? A: That’s private. Sharing information about potential corporate transactions distracts people from their goals and could potentially violate a merger agreement.

Q: How much cash do we have in the bank? A: That’s private. Cash in the bank doesn’t reflect upcoming revenue/expenses/investment capital and sharing the number without appropriate context could cause anxiety within the organization.

Explaining why you have decided that something is private is, in itself, transparency. It gives you an opportunity to teach the people that you work with and it shows that you have seriously considered why something is private. In other words, it demonstrates that you default to sharing. That is transparency.

Don’t forget the denominator

Product people love to talk about features and functionality. “Wouldn’t it be cool if it could do this?” “Yeah, that’d be awesome.”

To be clear, I’m one of these people. When I’m outside walking the dog, I’m often crunching through what the next feature set looks like. What will the data model be? How will you interact with it? What are the key flows? Who will use it? Will they like using it?

This stuff gets me excited. But when I come back to the real world and have to figure out how it fits in with all of our other priorities, it’s a different conversation. When I prioritize different options, one of the main factors that I consider is ROI. (Depending on how you define ‘R’, you could say that it’s the only factor; but there are often factors extrinsic to the activity itself.)

What I’ve come to appreciate is that often the highest ROI aren’t the projects that have the most features or do the coolest stuff. The highest ROI activities are usually the ones that require the lowest investment. They’re usually not as interesting, and their utility may be limited; but compared to the investment required, which may be very little, they have a good overall ROI.

This isn’t just a math formula, either. Because each project or activity almost always enables some learning, it turns out that you can learn a lot from a low-investment project that can help you make better decisions later. You might find out that one of the big projects you were considering isn’t relevant after all, or you might discover a customer need that you didn’t know about.

Our team experienced this recently at Justworks. We were creating a new flow that connected a handful of subsystems together and realized we needed a new screen to complete the flow. We talked it over for a couple of minutes and decided to do a patch job: We literally built and shipped the screen within an hour, which was enough to link all the parts together.

It’s turned out that the screen is totally sufficient to pull the flow together. Will we replace it soon? Sure. But in the meantime, we proved our own hypothesis that it was needed and useful, and we’ve had opportunities since to watch how our customers interact with it so that we can make the next version even better. I’m really glad we didn’t spend days on it, though. It’s the fact that we invested so little that has made it such a win.

Start with values

Earlier this year, our team had an off-site at my apartment in Brooklyn. There were four of us on board full-time: My co-founder Iris and I, as well as the first two developers to join our team: Chris and Chang. In addition, we asked a freelance writer, Allison, to join us and help facilitate.

The overarching objective of the day was to come up with a tagline that summarized what our company (then called Clockwork) did. We would spend the morning articulating our values and the afternoon brainstorming a tagline.

My private hypothesis was that given our team composition–it felt like we all shared the same values–we’d be fairly consistent right off the bat. I was relieved to find out that I was right. We asked each person to write down the values that they saw and respected in other people (either famous or important, like mom or dad.) After everyone was finished writing, we went around the table and each person read what they came up with. There was lots of duplication (great!) and some very obvious themes. This was the final, deduped output:

Honesty, integrity
Results, simplicity, real value
Fun, warmth, camaraderie
Grit, determination
Diversity, complementarity
Doing right by the world around us

Once we were finished with that, we went to lunch and never really got around to the tagline. That’s okay–we’re still figuring that out months later–but what really matters here are the values. As we’ve brought on new team members we have used these as a guidepost for understanding whether a candidate would be right for the team.

For me, personally, the most fascinating thing is how closely these values reflect my own personal values. It means that I found a co-founder who shares my values, and it means that we together started to build a team that shared our values. It does not mean that everyone on the team is the same–quite the opposite–but we all have a common thread.

In a fundamental way, it relieves me of worry about “how” something will happen at our company because I know that it will happen in a way that is congruent with our shared values. I am very proud of that.