If you want to have a successful technology startup, you need more than just a great company culture, you specifically need a great engineering culture. A great culture gives you a tremendous advantage in recruiting top people, retaining those people, and subtly guiding their behavior to drive the business.
Contrary to the hype, culture is not about ping pong tables, softball leagues, and free lunches. Instead, culture is the set of implicit rules, guidelines, and values that a group of people guide themselves by. It’s the peer pressure that shapes behavior in powerful ways. And simply putting a bunch of core values on a wall somewhere isn’t enough. Culture is a living thing that requires ongoing care and feeding.
And while every culture should be different based on the team’s strategy, for engineering there are some common elements found in the very best teams.
“It’s important to me that I’m encouraged to have an opinion and that I’m being listened to” – Jose @ Stormpath
Tech startups are hard. Most of the time you’re building something no one has ever built or pioneering a new approach or a new market. The path is never clear and no one person has all the answers. Yet, your engineering team is a collection of very smart people who are committed enough to the vision to join the company and stick around for the roller coaster.
Their value goes beyond the ability to sling lines of code; they can contribute greatly to technical design, processes, architecture, features, etc. And in some cases, they might even have great ideas for sales and marketing. By encouraging people to speak up, you not only benefit from their insight, but you also make them feel impactful and valued. That’s powerful. It drives better technical decisions. It helps identify hidden risks. It helps with knowledge sharing. It drives loyalty.
However, not everyone on the team will naturally speak up during a heated debate or contradict a senior manager on their own. It’s incumbent on your team leadership to make “room” for more reserved people. Watch for body language that indicates they have an opinion on a subject. Or maybe pause a debate and ask the people who aren’t vocal if they have anything to add. Perhaps, you ask for input before or after the meeting so everyone has time to stop and put together their ideas in an email. Try it all, because well a functioning culture of debate includes everyone, not just the loud extroverts.
“Once a decision is made, we move — together. No looking back.” – Mario @ Stormpath
The culture of debate has a singular purpose — to make better decisions. And yet, it’s very hard to make good decisions via consensus. A strong team with a strong engineering culture has a bit of a dictatorial bent to it. One person gets the final say after the debate. CEO, CTO, Architect, Manager, Guru, whatever — this leader in the team not only needs the confidence and skill to open and manage a true debate, but they also need the authority and confidence to stop the debate at the right point and make a firm decision. Even if it’s an unpopular decision. Harder still is driving a sense of commitment to whatever decision is made because nothing is worse for a team than “I told you so” after a decision.
Achieving that level of commitment is hard. It’s first born out of trust in the leadership. To build that trust, make sure you’re listening and make a point to understand all the information and opinions offered. An easy test is whether you can replay the arguments back convincingly. After you’ve made your decision, don’t just announce the decision, explain why you took that path. You may be right, you may be wrong but if the team can understand “why”, then they can commit.
“Everyone here is really nice. The team has a good vibe and people are open to new ideas”- Jeff @ Stormpath
In order for open debate to really work in team, you need humble people. Humble people are more focused on finding the right answer than winning an argument. Humble people have ideas and opinions but know they aren’t always right. Humble people make room for others to disagree with them and still respectfully engage. Humble people will commit to a decision counter to their opinion, so long as they feel their voice was heard. Humble people are easy to teach. Humble people are easy to work with — they’re inclusive, share credit, and tend to be open to new ideas.
Hiring for humility is more art form than science. Look out for how they talk about their former teams, how they describe their own strengths and weaknesses, and how they treat you and your team during the interview process. Do they share credit? blame? Do they make room for other people in the conversation? How do they react to a dumb question? to being contradicted?
“We aren’t fooling around here. This is a team of professionals” – Tom @ Stormpath
If you’re a tech startup, you’re not just on a budget, you’re very limited on time. So, you need people who are worth every penny and will move fast — smart people who get things done. To quote Joel Spolsky, “People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical.” And “people who get things done but are not smart, will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, they also soak up good people’s time.”
If you think hiring for humility is hard, this is harder. Your tools are interview questions, programming tests, and reference checking.
The right interview questions are a great way to assess smarts. Steer clear of questions with right or wrong answers. Even the smartest candidate might forget some obscure theorem in the heat of an interview. Instead, ask questions that will expose how people tackle complex questions with no clear answer. You can take a pragmatic technical approach (like us), “How would you build a photo sharing application” or a more fanciful approach (like Microsoft) “How much tea is there in China?” Ask them to think out loud. Can they wrap their heads around the question? Find an angle of approach? Ask the right questions back to you? Are their solutions practical and based in reality? Is their path to an answer clear and internally consistent?
To determine if they can get stuff done, give them a take home programming exercise. One that’s just a little challenging, has a dozen or so requirements, and mimics your general environment. Were they able to complete it? Did they meet all the requirements? Did they take it seriously? Those are the easy checks. More importantly though, how did they organize their project? Did they document and test their code? Can you follow what they did? Did they apply an appropriate design pattern? Was the design any good?
“I know who’s going to use our product, and what they’re trying to achieve with it. Knowing someone is going to use my code, I feel pressure to make it great.” – Robert @ Stormpath
If your engineers understand your customer and what they’re trying to achieve, they become a team of product developers. When User Experience (UX) becomes a deeper debate than just button colors, it becomes culture and leads to better product development with less meetings and management.
So how do you get there? It’s a big investment and the method depends on your business. At Stormpath, we put our engineers on support shifts so they have 1-on-1 interactions with customers to see how people are using the product, what they’re trying to do, and where they’re having issues. We encourage them to connect to the API as an end-user. It takes away from their development time but it’s an investment we feel pays for itself. What makes sense for you?
“A artist that only sees the world in sixteen colors can only create art in sixteen colors” – Les @ Stormpath
Engineers solve problems. To do so, the very best engineers are always on the lookout for new skills and technologies to add to their toolbox. Embrace it and promote it. By letting new tech and methods into your organization you not only excite them with new challenges but you also force them to think in new ways. Consider NoSQL, a radically different and powerful way of thinking about data structures. Your particular project may not ultimately use it but by simply being exposed to it, your team’s skill has grown and may come up with a new novel solution to your next problem.
There’s a fine line between encouraging exploration and adopting new tech for the sake of new tech — which can cause a lot of problems. The way to stay on the right side of that line is to encourage your team to bring new technology to the table when they think it can have a meaningful impact to your work. Let the members share new tech in lunch and learns. And if it looks like there’s potential value, make time for the team to get their hands dirty and test the tech— perhaps through spikes, proof of concepts, or even internal hackathons.
“I love the freedom we have to always improve our techniques, process, and technology whenever we need to” – Elder @ Stormpath
Have a process, any process. Make it strong and clear. Heavy or light, iterate on it so that it fits your strategy and your team. It’ll ensure that your team has clear direction on what to do and how to do it. That’s just good engineering management, but to build a great engineering culture, the process should be owned and managed by the engineering team itself, not the management team.
The engineers are the ones working with the process day in and day out. They know, better than anyone, where it’s working and where it’s not. If your culture already fosters open debate and has clear goals, this ownership can work wonders.
Every two weeks or so have everyone meet with their ideas on how to improve your process. No idea is a bad idea. No matter how crazy, give it a shot for two weeks and reassess. You process will ebb and flow but always towards stronger alignment with what matters most to your company. This style of management is ultimately the backbone of Toyota manufacturing and has worked well for us at Stormpath too. If you’d like to read more on it you can check out our post on Agile Kanban process.
“I feel like you respect my time as a professional” – Pablo @ Stormpath
People want to be respected. If you give them that respect, you’ll be rewarded with respect, as well as loyalty and low friction in the office. Respecting your engineers is easy: respect their expertise and, more importantly, respect their time.
You can institutionalize respect incredibly fast in two ways. Start with these two and you’ll see respect spread quickly.
- Force your daily stand up meeting to start on-time, every time. Scheduled for 10am? Start at 10:00am and not a minute later, no matter who is late, as a sign of respect for the other people who showed up on time. Even if the manager or chief architect is late, force them to start on time to make it clear that no one is exempt.
On that next big engineering deadline where everyone needs to work crazy hours, ask them, don’t tell them, to stay late and explain why it matters to the company. Set a clear and realistic expectation of what you need so that they can plan their personal lives during the push. Make sure they’re as comfortable as possible. And once its done, do everything in your power to minimize the frequency of those pushes so that you don’t lose their trust.
“Feedback, the breakfast of champions” – Alex @ Stormpath
The best engineers want to grow by improving their skills and areas where they struggle. To do so, they need clear, honest, and constructive feedback. The more often you provide that feedback the more data points they will have and the quicker they can make changes. In turn, gather feedback from them so you can improve yourself, your management skills, and the company. By building strong two-way feedback channel you’ll get better, stronger engineers and their trust and loyalty.
Setting up for regular feedback takes time and discipline. Once a quarter works well for us — often enough to be actionable and yet not repetitive. For each engineer, dedicate at least an hour of prep time to think through the feedback you think would be valuable and actionable. And ask them to spend as much time prepping to give you feedback, and reflecting on their own performance. Then schedule a one hour meeting to give and receive. Justifying this kind of time investment can be difficult for teams who’ve never done it before, especially when all of engineering feels under-resourced with short deadlines. But it’s an investment thats comes with huge long term payouts to you and your team. Preparation is key if this is new for you (and if not!).
These nine steps are powerful ways to build a great engineering culture, but they’re just the baseline. To build a truly exceptional culture, evaluate your organization’s core strategy and find ways to align your culture to that strategy in a way that’s authentic and actionable by your engineering team. If you invest the time and effort, your culture will blossom eventually help you attract, retain, and guide the best people with a lot less management.