Early startup employee lessons learned, part 3: building culture
Published:
A core function of being an early employee at a rapidly growing startup is helping it grow! At my current job, I’ve helped the data science team grow from being just one person doing a little bit of everything (me!) to a team of over 15 people working in three focused sub-teams. Growing the data science team has been one of the best parts of my hyper-growth experience, and I’ve learned a lot of really useful lessons from it.
As I mentioned in Part 1, building an open and collaborative team culture on my team is one of my proudest achievements. Because I care a lot about organizational culture, a lot of this culture came about organically through my hiring decisions, early management role, and general positioning as an influential teammate. But as I reflect on the past two years, I can identify some specific things we did that contributed to our positive outcome.
Communicating about how we communicate
Talking about how we communicate and then adapting our communication behaviors, processes, and norms as the team grew has helped us maintain a functional working culture despite our rapid growth. I think this is also especially important given that we’re primarily remote: communication doesn’t come for free, it has to be an active effort. These efforts can be grouped into three categories: talking about communication, hiring for it, and implementing processes that encourage the meta-conversations.
Talk about it!
First and foremost, our teams talks about how we talk to and work with each other. When someone posts a message and also asks “is this the right channel to post this in?”, folks on my team actually answer their question. It’s been interesting to notice this, because we’re one of the only teams at our company that I’ve seen actually engage with the meta-question, which I think stems from the norm we have of talking about how we talk to each other.
We also encourage holding each other accountable to the shared communication norms we’ve set - for example, a core value of our team is that we share unfinished work early and often. That means that when someone posts an unfinished analysis in one of our private channels, we encourage that person to re-post in a public channel where more of our team can engage with their work.
My favorite way that our team talks about how we communicate is by giving cute names to specific communication strategies we see others use effectively. So far, my favorites are:
- “pulling a Claire” which means “asking someone to surface a private message in a public channel.”
- “pulling a Scott” which means “bring up an issue by making statements that nobody can disagree with and naively asking questions with the hopes of sparking the change you’d like to see.”
- “pulling a Nadia” which means “addressing a vague request by calmly asking for more details and links to documentation if it exists.”
As we see our colleagues find ways to effectively communicate with us and others, we talk about what it is that makes them effective and learn from them.
Hire for communication
We also explicitly center communication in our hiring processes. One of my favorite things we ask our data science candidates is about sharing unfinished work. For example, we ask “how comfortable would you be sharing an analysis that isn’t fully polished to the CEO?” or “how do you know when your work is ready to share internally vs. externally?” With these questions, we’re gauging candidates’ approach toward sharing unfinished work and trying to understand their ability to make decisions on partial information, which are both critical parts of our culture and key to being successful data scientists at our company.
Also, our technical interviews usually consist of some sort of pairing exercise or hypothetical scenarios - when we walk candidates through these, we emphasize over and over that we’re less interested in their answers and more in hearing their questions and thought processes. If candidates jump straight to answers, we’ll explicitly reorient them to questions, asking them point-blank what sorts of questions they’d need to ask their users or stakeholders. At the end of day, candidates who don’t ask us any questions never get hired by our panels, and I find that we get much better signal on their technical ability from the questions they ask than the answers they give.
Implement processes to encourage meta-conversations
Finally, our team has explicit processes that encourage the conversations about communication. Some of my favorite examples of these are:
Sprint retros: we started using a baby version of agile when had zero project management expertise at the company, and we basically just made it up as we went along. One thing that sticks out to me from those early agile days was the retros: it was the first time we’d had a structured place to talk not just about the work that we did, but also how we did the work that we did. Importantly, because it was a semi-formal environment, it was all intentionally constructive: when we talked about what went well and not so well, we brainstormed together about how to improve the way that we do work. I think this really set the stage for our team’s culture of interrogating and then collaborating on solving our organizational problems.
Intentional slack channels: for a long time, we basically had two channels: one called #data for all public data-related things, and one #data-team-internal private channel for internal banter and existential “omg is all of our data wrong” conversations. We also had legacy product-specific #data-XX channels that nobody really knew how to use. As we grew, that wasn’t working for us anymore - the #data channel was cluttered with inbound requests from non-data science team members, and our posts with results and analyses weren’t getting enough engagement because the channel was just too busy. We were also worried about posting jargon-heavy or unpolished analyses in #data because we knew there were so many non-technical eyes on it, and so a lot of our work had started going to our private channel, which ran counter to our values of transparency and collaboration.
At that point, three sub-teams within the data science team had started to form, and so we decided to create intentional public channels for each team. We talked about it extensively within the data science team, and then made an announcement to the company: what channels we were deprecating, what channels we were creating, and - importantly - what each channel was for. We were very clear: our team-specific channels would be just for us, with unpolished and sometimes incorrect work or analyses - lurk at your own risk! This re-organization and intention-setting freed us from the paralysis of not knowing where to post, improved our ability to collaborate by removing our fear of unintended consequences, and also helped the broader organization learn how to engage with us more effectively.
Intention-setting disclaimers on documents: this one is the brainchild of a former colleague, but the majority of our team has since adopted it. Whenever we shared a document in a public channel, we add a disclaimer to the top indicating where this document is in its lifecycle (WIP, draft, ready for review, etc), what we want from folks who look at the doc (hold your comments, comments welcome), and whether we are comfortable with others circulating the document (circulation OK, do not circulate). These disclaimers are especially helpful when you’re working on something that you know a lot of people will have feelings about, but you don’t want to keep it a secret until it’s finished. It helps us act in the transparent way that we value while minimizing potential negative consequences from other teams who aren’t necessarily used to working this way. As a consumer of documents, I also find it extremely helpful to know what the author wants from me: should I hold my tongue, or are they ready for feedback? Can I share this broadly, or are they not ready for this to be disseminated yet?
Intentional onboarding
Another easy way to build a positive and collaborative culture is to bake your team’s values into standard onboarding tasks. Preparing a plan for new hires’ first 30, 60, and 90 days of their job is great, but realistically you only need a plan for the first 2-4 weeks. After that, things will have probably changed enough either with the company or with the new hire figuring out where they fit in their new role that a new path will have become clear. Instead, putting in effort to create standardized and intentional onboarding tasks that immediately ask new hires to put your team’s core values into practice is a great use of energy that may have more impact than individualized long-term planning.
On our team, onboarding involves two core activities: meeting a lot of people and making a plot. When we set up intro meetings for new hires, we intentionally go for a broader circle than the individuals they’ll be working with directly. As a team, we value collaboration and compassion, which means that we want our data scientists to understand how their work fits into the broader company and how they can help support others beyond the data science team. So during onboarding, we make sure to encourage meetings with not just close colleagues, but also nearby teams and individuals from unrelated teams who they would benefit from having met at least once.
The other part of onboarding, which I love, is to make a plot. We give every new hire the same ticket their first sprint: make a plot, any plot! Just get access to our data somehow, make a plot that shows anything at all, and post it in our public team channel. This activity emphasizes our values of transparency and collaboration. If folks post it in our private channel, we remind them that the task was to post it publicly; if they take a long time to post it because they haven’t found anything “interesting,” we remind them that the task is to make literally any plot at all and post it. By emphasizing the public channel and the literally any plot at all, we get new hires comfortable with sharing unfinished work publicly, which is core to how we want to work together. Importantly, we ask everybody to do this task - even our head of data science! By doing so, we encourage new hires to put our values immediately into practice, and show that the values are team-wide and that we’re serious about them.
Be the broken record
Finally, something I didn’t realize I was doing at the time but which I think has been very helpful in shaping our culture is to constantly give my team the rationale behind what I’m doing and what I see our company doing. I think that explaining the “why” behind decisions that we’re making helps build an engaged team. For example, helping individual contributors understand why the company is making certain decisions or prioritizing certain projects can help provide additional motivation and context for the work they’re being asked to do. And as an early employee and leader, explaining my thought processes behind my decisions can teach and empower others to learn how to make those decisions themselves in the future, thus scaling my influence without stretching me thinner.
For example, I was originally responsible for the team QC’ing our data. Part of that was to work with our QC analysts and customer success teams to decide how to approach tricky situations, for example if a customer’s results seemed a little wonky and we didn’t know whether to just release the results or also send along a pre-emptive explanatory note. Rather than just telling my team of junior analysts what I thought the right thing to do was, I would walk them through my thought process. After a few months of this, instead of tagging me in to make the decisions, they started applying the same thought process themselves and tagging me in to just confirm the answer they’d gotten to themselves. There’s nothing better than messages like that, I can tell you!
Because I repeated myself to the point of being the voice in their heads, I’ve been able to step away from these day-to-day decisions with basically no impact to the quality of their work. Of course, explicit training and documentation would probably be a better way to scale my knowledge, but at rapidly growing startups there sometimes isn’t time for that - and simply being a broken record is often a good substitute.
When in doubt, I’ve found that clearly spelling out the “why” behind what we’re doing can be a great substitute for process and documentation, and is a good way to help others connect the dots themselves and understand the bigger picture behind what they’re being asked to do.
If you liked this post, check out the rest of the series on being an early startup employee: