This is a document I started writing in May 2014. At the time, the Sosh engineering team was 4 people including myself. We had achieved a lot in a short time, but we needed to grow. I was having trouble articulating my vision for what our team should look like, and made some notes for myself. This is an expanded version of those notes, fleshed out when the engineering team is 15 people.

Uniformity & Diversity

As we build the team at Sosh, I spend a lot of time ensuring we have a great, productive engineering organization.

After talking with smart friends and thinking about some of the great companies I’ve worked at, I’ve come to the conclusion that the best software teams strike the correct balance between two opposing forces: Uniformity and Diversity.

Uniformity

The best teams have shared values. When everyone values the same things, trust is easier to earn and decisions are considerably faster to make. These are the things that everyone in the engineering team should share.

We are focussed on building the right thing

• The right thing is not necessarily “the perfect thing”. Shipped projects are more important than theoretical gains.
• The right thing is not necessarily “the spec you are handed”. We are smart people who use other products. As engineers, we should be ready to raise questions to the product and design teams when we don’t think things make sense, or think it can be done better.
• The best engineers work with others to balance the trade-offs of product, complexity, time & quality.

We are company focussed

• We want to work to make Sosh great. We are the company of today, and we want to make the best company of tomorrow.
• We teach others what we know. We share our knowledge freely regarding product, process, and technology. We don’t limit ourselves to thinking only about the immediate needs of product & engineering — We try to improve things company-wide.
• Everyone is involved in recruiting. From referrals to interviews to writing entries on our engineering blog that convince folks that we’re the team they want to work with.

We communicate well

• Poor communication dooms great engineering teams. One of the cornerstones of Brook’s Law is that as teams grow, communication overhead can swamp increases in productivity. We will continue to grow, so we are always mindful of our communication.
• We communicate well, whoever the audience. With other engineers, with the product team, or with anyone else in the company, we are able to explain ideas at the correct depth.
• We are proactive. We are always prepared to share status, ideas, questions, and frustrations.

We are self-organizing

• We get shit done without hand-holding. Through understanding our company and team goals, we can make decisions and unblock ourselves without excessive meetings.
• We know when to ask for help. Sometimes you’re only one Google search away from an answer, but sometimes taking five minutes to ask a co-worker something will save you hours of confusion. We learn how to differentiate between those states to avoid unnecessary interruptions and frustration!
• We know when to push back. By intrinsically understanding the goals of the company, we can use our deeper knowledge of the technology to influence product and business decisions.

We motivate ourselves

• Enthusiasm is infectious. We aim to match work projects with individual engineers’ intrinsic interests. This won’t always be possible, but when they overlap, the work quality will be greater and engineers will be happier.
• We grow. No-one is ever fully formed. As the world around us shifts, we investigate new technologies, new processes, new products and new ideas, and look for appropriate opportunities to apply them. We read, learn, experiment, grow and share.
• We teach. Every engineer has unique experience that they can share with their teammates. A recent grad has maybe used newer technology. A wizened senior engineer can wax lyrical about the mistakes in the first bubble. When we hire an engineer, we’re not just looking for one more pair of hands to type code, but someone who makes everyone around them better at their craft.

We are productive

• We always work on the highest priority tasks. We have limited resources, so should always be mindful that any time spent on lower-priority tasks is harmful. Everyone should be able to articulate the importance to the company of the task they’re working on, and ready to ask “Why?” if they’re not sure.
• We iterate our process. Just as we iterate on the product, it’s important that as we adapt as an organization we’re always careful to look at how we’re working. Retrospectives on our development, design and roadmap processes ensure we can identify the things slowing us down and start to work around them.

Diversity

The temptation is always “more of the same”. We have a team that’s working, so just keep finding more engineers who think, act and work the same way, and everything will be great.

The problem with that is you never uncover your weaknesses and blind spots. No-one is challenging themselves or others. And you miss out on great people who don’t look like the template of who you already have.

If we don’t gain diversity in the following areas as we grow, we will fail.

We will have differing skills

• We will build a lot of things. Already we have engineers working on web front-ends, iOS apps, server-side services, and data tools. This will only grow. We will need a variety of folks to do all these things well.
• We need both generalists and specialists. Generalists are great. You can point them at a new problem, and they’ll learn just enough to try and jam something together to make it work. However, when we’re ready to commit to adding a technology to our toolbox, we need to hire specialists: The folks who sweat the details in a particular area, know where the bugs are lurking in the frameworks, and can make sure we build things well for the long-term.

We will have differing experience levels

• We will grow junior engineers. Our technology stack is fairly common, but still only one of the many that people might experience elsewhere. There are far greater numbers of flexible junior engineers out there at the start of their career who understand the basics of software development, than there are senior engineers with specific expertise. We should use this to our advantage to grow our team.
• We will need the right senior engineers to lead that growth. Great leaders with focused experience and strong mentoring instincts are vital to help everyone grow and the engineering organization as a whole avoid common pitfalls.

We will be driven by different things

• We might be driven by product or by technology. Some engineers care deeply about the end product they’re working on, with the tools used an afterthought. Others care deeply about the technology; the code; the algorithm. We need both of these types of people. Our product goals & technologies will shift. As we evolve as a company, our previous technology or product decisions will become less important. It’s vital we have a team driven by diverse factors so we can continue to grow as things change beneath them.
• We will have different growth goals. In addition to questions of technology generalists vs specialists, some engineers will want to grow their skills in areas that aren’t technology-driven. Becoming engineering managers or product managers are goals that we should foster in our engineers, and give encouragement and opportunity to experiment with.
• We might be driven by quality or by speed. A team who are entirely focussed on shipping features no-matter-what might accrue technical debt at an unacceptable rate. A team obsessing over building a perfect architecture might be too slow to deliver and ever get the necessary user feedback. We want engineers from across this spectrum to ensure we ship regularly but are creating a quality structure to build upon.

We will have different backgrounds

• We will make better decision by being socially diverse. Across all frontiers: age, gender, gender identity, race, sexual preference, family status, financial background. The greater the diversity of viewpoints on our team, the more informed the decisions we will make in our product and our company.
• Being too narrow now makes recruiting harder in the future. Greater diversity opens up our candidate pool. If a candidate interviews with us, but can’t see example of “themself” already at the company, it will be considerably harder for us to hire them. This compounds with every hire we make, as candidates will start to look at the office as a whole to evaluate if they will fit in.
• Diverse professional experiences helps us find better ways of building. We’ll be able to synthesize the best techniques and architectures by drawing on team members with varied experiences at sizes and stages of companies; in consumer or enterprise fields; with continuous deployment or with lengthier release cycles.

About Sosh

There’s a whole wide world out there, full of things to do and amazing places to explore. Yet people so often do the same things over and over. We’re on a mission to put the city’s most memorable experiences at your fingertips.

Because life’s too short to be bored.

We’re hiring.