Creating A Culture

This is part of a series of posts about early-stage startups. If you have anything you want me to dig into in future posts, let me know in the comments. You shouldn’t treat these posts as gospel. They’re just some insights about what has worked for me during a decade in startups. I hope I’ve made enough mistakes with this kind of thing so that you don’t have to.

This question came from my friend Jane who is the COO of a software startup.

How do you get developers to buy into creating a team culture?

Company culture is a hard thing to get right as a so-called “good culture” is entirely subjective. Software culture is even harder as you often have to manage very different personality types on top of the usual things, such as understanding people’s motivations and career goals. In early-stage startups, culture is an evolving organism. The founders guide it, but everybody who works at the company has a part in defining it. It is the sum of every employee with the founders acting as a multiplier. There is no Netflix-style 100+ slide culture deck to guide you.

While this post is about engineering teams, it’s broadly applicable across any group in an early-stage startup.

Let’s dig into the question.

Build ownership

The essential thing you can do to engage developers in building team culture is to establish ownership. A team member who has an investment in the decision-making process is often happier than one who doesn’t. Involvement is usually a lesser issue in other disciplines such as design or product where you may be working closely with other parts of the business or the customers.

Developers, sometimes by organisational design, and sometimes of their choosing, can often feel removed from the decision making process. The key to building a robust team culture with developers is to make sure they involve themselves at the beginning of projects. You want developers in the room when questions like “Should we even build this?” or “Is this going allow us to hit our company KPIs effectively?” are asked. Avoid top-down management where possible and don’t become a feature factory where senior leaders dictate the product.

That’s not to say that your product shouldn’t be founder driven. You often need a vision and the motivation to realise this vision. Usually, only a founder can provide this. The trick is to balance that energy and focus without descending into micro-management.

Sometimes this can be a bit of a slog. There is a certain developer mentality that doesn’t care about this kind of thing. I didn’t particularly care about the business impact of my work earlier in my career. I just wanted to write code and get paid. But early-stage startups are different. The work that the team delivers day-to-day has a measurable, visible impact on the success of the company and creating individual investments in that work leads to a better product and a happier team.

Set OKRs

OKRs, or Objectives and Key Results are a great way to get everybody aligned with the direction the company takes and to visualise the impact of individuals day-to-day work at the company level.

One of the things I like the most about OKRs is that they set goals but don’t specify how you should achieve those goals. Having clear goals allows for a lot of freedom regarding problem-solving, something developers love to do.

I’m not going to dig into OKRs too much as there are a lot of fantastic resources already out there about how to set them up and manage them.

Instead, let’s look at an example:

Traditional product request

Imagine you are a startup that manufactures widgets. You take orders by phone as you haven’t had the resources to build out an online platform yet. Management has decided to move online and invest in developers.

We need you to build an online store where the company can sell its widgets. We need a search engine, product pages, payment solutions, emails, etc.

This request has several issues. The first is it puts blind trust in management that they know precisely the right thing to build. And they may. But it removes any ownership in the product and puts the responsibility for success and failure purely on management.

A team OKR

Objective

  • We want to be the number 1 seller of widgets in Australia.

Key Results

  • Make 500 online sales.
  • 10% of sales are from returning customers.

In a company that uses OKRs, there is no specification about how to build the product. There is a goal to achieve, usually quarterly, and it is the team who decide how to get there. They may decide building an online store is a bad idea. Why not sell via a social media platform? Or use a marketplace that has a lot of this functionality already built? The outcome may be the same, but there are plenty of options on how to get there.

This method builds ownership into the team. The team have made a decision, have measured the success of that decision and can see the impact it has on the business. The developers have also learned significantly more during this process than if they were working from a build specification. One of your jobs in an early-stage startup is to grow leaders, and you can only do this by empowering people and relinquishing control.

Provide structure

Team empowerment comes with some caveats though. If a team has the responsibility to make decisions, they also need a structure to work within so that they can fail safely. Handing over the power to decide on the product is just as bad as top-down management if there is no framework.

It’s your job as a manager to build communication patterns and feedback loops, so that team members and the rest of the business has confidence and clarity on what is delivered.

Having the ability to fail quickly in a blame-free environment is one of the most powerful techniques you can use to improve on anything you do quickly. The fail-fast philosophy is so ingrained in the startup world at this point that it can often seem like a stereotype, but there is no other way of learning at speed.

Action your team’s feedback

One reason team members find it hard to buy into the team culture is that they can feel as if they don’t have a say, or if they do, their ideas are not as valid as someone else’s. These feelings can stem from a lack of confidence, quieter personality types or experience in previous companies. It’s seldom the fact their ideas aren’t valid.

Make sure you write these concerns down. They usually surface during one-on-ones and not in public forums. Once you have a list of issues that your team are concerned about you can start actioning them.

Now some issues don’t need to be actioned. Some people use their one-on-one time to have a private rant, and that’s fine. You shouldn’t view everything as a problem to solve. Picking apart what is actionable information and what is letting off steam is a valuable skill to master.

The best way to action issues is to reframe the conversation. Ask the person who has surfaced the problem if there’s anything they can do to resolve it? Can they talk to another team? Can they build a process and get buy-in from other team members about how to move forward with it? Can they change their approach to a difficult colleague? Whatever you do, don’t try and wade-in and fix it for them. By all means, support them, open up communication channels and back them up publicly but don’t take away their agency.

Build product teams

I’ve been lucky in my career that I’ve had the freedom to build product development teams with engineering, product, design and data all within the same structure and every discipline on equal footing. Creating these kinds of groups is a lot easier at early-stage startups than it is at more established companies.

If you focus on building an engineering culture and ignore building a product culture, you will end up focusing on engineering problems. While these are fun problems to solve for engineers, there is a finite number of them in early-stage startups. A talented engineer will fix everything they can and then see their job as done. An engineer invested in the product will always be looking for new things to solve on behalf of the business and will rarely get bored.

Make sure your teams are integrated and have a range of skillsets outside of development.

Celebrate success

Celebrating success is something I’m especially bad at doing. I often forget about significant milestones as my mind has already wandered onto the next piece of work. Luckily my team are very much on top of this. Take people out for dinner and drinks, say thank you publicly for a job well done and always celebrate as a team.

Having these celebrations is especially vital in startups where you ship incrementally. Sometimes it can feel as if you are not making much progress until you look back at what you have covered in six or twelve months. You’ll often be surprised how much ground you’ve covered if you take the time to look back.

Treat people like adults

I don’t even know why I felt like I had to add this point in 2020, but there are still a lot of companies out there that require bums on seats, 9-to-5. People have busy, complicated lives and allowing them the flexibility to work in a way that suits them is an investment in people that will buy you a lot of goodwill. Just create some ground rules such as honour your calendar, let your colleagues know if you’re going to be away for an extended period on the school-run or if your brain is maxed out for the day, so you’re going to sign-off and go for a cocktail at 4 pm. Remember doing that in pre-covid19 times?

Conclusion

I hope these points have been useful and thanks for reading. If you have any feedback or anything you want me to dig deeper on in future posts, leave a comment.

Further reading