Why our engineering team of four has a culture manifesto

We’re constantly learning from other start-ups and businesses that share our values. As Crowdcast grows, we hope to pay it forward with posts of our own as we discover learnings and create tools that work.

One area we’re particularly mindful about is culture and operations. Cy and I have focused on our mission and values from the start. We’ve been lucky to have like-minded people join us this past year, but now that our team is rapidly expanding, we are especially aware of how dynamics change as a company grows. It’s easy for a start-up’s early culture and values to get lost in the waves of hires and product development. We want to keep those values authentically shared with everyone we bring on board.

Engineers are no exception — in fact, because we rely on them to maintain our high product standards, I need them to be fully aligned with our values. So last May, I wrote a manifesto on Crowdcast’s engineering culture. That wasn’t a radical act, but it was significant for our team for a couple reasons: we like to keep things lean (meaning our company policies are few and infrequent) and, most importantly, our engineering team has only four people.

But I believe the time when a team is small is precisely the stage to create a culture statement — not after a growth surge. I would even write a statement for two employees. Here’s why:

• Standards and expectations are already developing. There’s a big difference between working on a team of two engineers and a team of four. Hierarchy dynamics and patterns start to form about what is acceptable in the codebase. To maintain a high standard for product and code, expectations for how the team works together and discipline for the details need to be established early on.
• This is the time to create consistency. Engineers currently make up half our team and most are remote. As our team grows, we want to make sure engineers know what is expected.
• We want to build-in our values with rapid growth. We have a good vibe at Crowdcast. We want to keep that with us as we double or triple in size, not tackle retroactively.

The results were pretty immediate: This culture statement has been really helpful in digging a little further in our interviews with engineers to get a sense of a candidate’s values. It’s also helped to establish credibility with our engineering team. This culture statement means nothing if we don’t use it IRL — in fact, a few of our engineers admitted they didn’t take it too seriously until they came on board and saw our values in action. I’ve included a few examples below.

I share this document openly — feel free customize for your own team (or crib from it completely).

Engineering Culture & Values

Supportive. We are all here to learn and grow and to get better as a team. We are not here to attack or berate other team members.

Flat. There are no “senior” or “junior” engineers. We are all just engineersand we are all peers. We all bring different skill-sets and different levels of experience to work, but we don’t operate with hierarchy dynamics. When we succeed, we succeed together. When we fail, we fail together. We’re all here to do to what’s best for Crowdcast and what’s best for the team.

Our intern works hand-in-hand with other engineers and with myself. We’re also pretty open at Crowdcast — from growth campaigns to sales figures. We all take part in guiding Crowdcast’s journey (and its many Slack channels).

High standards. We hold ourselves to high standards. In order for Crowdcast to be successful the engineering team needs to do our part to deliver stability, reliability, speed, functionality and we have to make itbeautiful.

Product-oriented. Everyone is product. Everyone on the engineering team should be thinking about product. Features and enhancements won’t always be delivered to you with every detail precisely thought-out and considered. If you don’t know the answer to a detailed product question, then think it through, come up with the best solution you can think of and ask another teammate for their opinion.

We’re still at an awesome phase where the entire Crowdcast team enjoys a close relationship with our member community. Our engineers are very much a part of that on a daily basis, from support to growth conversations.

Embrace feedback. Since we hold ourselves to high engineering standards, we must be willing to both give and receive critical feedback with one another. Feedback should ALWAYS be delivered in a way that is considerate of your teammate on the other end. Teammates should debate and discussconcrete ideas and not make personal attacks on each other. Remember that we are all here to make Crowdcast better and to help each other learn and grow and continue to make this a supportive and inclusive place to work.

Weekly office hours is one channel I use to provide (and receive) that feedback. Even though we’re a team of four, I strongly believe in setting up structures early.

Don’t rush. When implementing features, fixing bugs and with all coding projects, don’t rush it. As an effective engineer, you should never feel rushed with your work. Work briskly and effectively, but maintain a cool composure and think critically. Most of the time, you should feel like you are doing your best work. Take the extra time to name classes and functions and variables in a way that makes the most sense. Take the extra time to keep your code organized and readable for the next person who comes along. Remember that building Crowdcast is a marathon, not a sprint. Let’s all maintain a good, steady pace without feeling that we need to make quality trade-offs because we are rushed.

When things break, chill. And learn. Inevitably, shit in production breaks sometimes. We have to do our best to minimize the frequency of when this happens but, when it does happen, we have to remember:

• Stay calm. First, take a breath and keep your cool.
• Don’t talk. Your first reaction should not be to start talking about the problem. Your impulse will be to start talking and rationalizing it. This is a trap. You will be much more effective if you can think before you talk. Take a moment to actually consider what is going on. Step back and start thinking about what facts you know and what facts you assume. It’s important that in this moment you think critically, not emotionally. Get a full assessment of the situation before you start acting on it.
• Don’t blame. Find the reason this happened, but don’t focus on the person who caused it. We all take ownership of Crowdcast together; if one person messed up, we all messed up. It is NEVER one person’s fault.
• Learn from it. Whatever happened, however big or however small, just remember this rule: If this doesn’t happen again, you win. What happened has happened, and it’s in the past. Be positive looking forward, and learn from it.

Follow through. When you have a task assigned to you, take responsibility to see it through. It is not “done” until it is running in production for all users. Don’t assume it’s done when you open a pull request. If it’s your task, it’s your responsibility to make sure it gets deployed and it’s your responsibility to speak up and ask for help if you are blocked.

Thoughts? Share your comments or questions for me on Twitter @dylanjha.