Last month the engineering department of Ibotta participated in a first of its kind event in the organization’s six years of history. For five hours (including breaks) we actively engaged in the process of building the future culture of our department by teaching and talking about a variety of topics including psychological safety, understanding communication via text, and how to have a productive code review. The event, appropriately enough, was called CultureCon.
So why did 100 smart and skilled engineers spend 5 hours in a conference hall last month talking about communication skills? Part of it had to do with increasing communication failures and frustrations across the department. Part of it had to do with a survey that went out at the beginning of the summer about how folks felt about talking to other teams in the department that came back with phrases like “afraid to speak up” and “Culture feels a bit unintentionally cliquey based around groups/teams.”
But the root cause of the event was that, compared to last year, we had twice as many engineers as before. Even last year there were twice as many engineers as there had been the year before that. In the beginning there were only a few engineers to cover the needs of mobile and backend development, with new hires slowly being folded into the team and culture. In the early days communication norms and workplace connections could grow organically and be taught out informally as new engineers trickled into the org. With the department growth chart turning exponential, that was no longer a solution that scaled. Ibotta was in the midst of an Eternal September. Hence, CultureCon!
CultureCon 2018 hopes to improve the psychological safety of all our engineers and builders, empower our collaboration, and enhance our communication skills.
There were four stated objectives going into the afternoon:
- Contribute to the collective discovery of what is working well and what can be improved in each topic area
- Inspire everyone to think about the topic in a new way and/or from a different perspective
- Establish a forward momentum for change
- Find a baseline for what the organization’s thinking is on these topics
This was accomplished by six half-hour sessions (plus discussion and breaks) for a total of four and a half hours of culture building and fun!
The first session of the afternoon, Organeering Documizing Enginents (Organizing Engineering Documents) was all about how to better leverage Jira and declutter Confluence. The presenters helped the audience understand that a Jira ticket defines a contract and we should make sure to level set on inter-/intra-squad expectations before issues arise. The presenters provided great advice about how to think about Confluence document placement, style, and ownership. All this was done without imposing company-wide mandates to allow individual groups to organize in the manner that works best for them.
The next session, Cross Squad and Cross Group Information Dissemination was an expanded object lesson (using cats!) on common internal and external communication breakdowns with specific and general conflict resolution suggestions. We learned valuable techniques on how to avoid unnecessary friction and how to resolve conflict after the fact.
Slack Best Practices followed, covering the art and science of instantaneous digital communications. Starting with some simple tips and tricks to help cut down on the chatter that comes with using Slack as the main form of communication in the office (for example, muting channels that are not important to your day to day workflow) it then went on to discuss the follies that come with having a large, public forum be the center of office life. Human communication is over 90% non-verbal and people have a higher tendency to read written correspondence negatively, especially if they have not met face to face. Additionally, some can be intimidated or scared of looking stupid by posting questions out in the open. It is up to all of us to help reduce intimidation and encourage others to post their comments and questions. This helps everyone — those who might also have been too afraid to speak up, as well as those searching for an answer to the same or similar question down the line.
Code Review Culture covered how to have the most effective code review that leaves both reviewers and reviewees feeling satisfied with their work. The goal of a code review at Ibotta is not necessarily to find bugs or dress down another programmer’s code, but rather to get as many eyes aware of the changes and context related to the code, and to make sure it fulfills best practices and sets future programmers up for success. As a reviewer, being mindful of tone can go a long way towards making people responsive to your comments. Using hedging words like “I think” can turn what might be interpreted as a demand into a friendly suggestion. As a reviewee, making sure your code is clean and in as close to a production-ready state as possible will make sure that the most time is spent on relevant parts of code.
Bonding over legacy code horror stories is a rite of passage for software engineers. During Handling Legacy Systems, the presenters flipped the script, helping us acknowledge that in order for code to become legacy it is often both functional and profitable. We learned to empathize with the people (sometimes ourselves!) and context behind legacy code. As an Agile shop, we felt this perspective aligned perfectly with the Retrospective Prime Directive. At Ibotta we are transitioning to microservices from a legacy, monolithic Ruby on Rails codebase. We’ll know we’ve “made it” when we can call this greenfield microservices work “legacy”.
The last talk of the day, Can You Hear Me, was all about emotional awareness and how we as a tech community can learn from our previous shortcomings (for example, years of tolerance for Linus Torvald’s bad behavior) and do better. This was a perfect bookend for the themes of the day. Some of the tools introduced were “Engaged Listening” (actually hearing and trying to understanding what someone is saying instead of just waiting for your turn to talk), “Step Up, Step Back” (speaking up if you haven’t engaged much/recently and stepping back to create space for others to contribute if you have), and “Situational Awareness” (knowing when to say something can be just as important as knowing what to say). In addition to communication styles, the discussion focused on common assumptions (of prior knowledge, history and agreement) to keep an eye out for.
A Job Well Begun
In the lead up to CultureCon, there was some skepticism and confusion about what it was and why an entire afternoon of engineers’ time would be occupied by it. By the end it was obvious why we were doing it. It wasn’t just about discussing Ibotta’s culture (although there was plenty of that) but rather showing what an active culture looks like. An active culture is engineers getting to know each other as people first. In an active culture we come together to talk about those sometimes difficult topics that can get ignored in more “technical” fields. Most importantly, in an active culture we take time to self reflect on where we have been, where we are, and where we want to go as a group.
CultureCon 2018 was such a success that plans for a yearly CultureCon are in motion. In the short-term, the effects are already noticeable. Pull Request comments are taking on a more “what if” tone than “thou must.” One squad came up with the idea of “#conclusion” for long Slack threads — a signal used to sum up discussions and dump the end decision back into the main channel. A Diversity & Inclusion working group is ramping up. And, of course, the coolest engineers are co-authoring talks and blogs.
If any of this sounds useful to you, start taking action in your own organization. Talk to those around you, you might find you’re not the only one interested in building a better office culture. Or, you could come help us build Ibotta’s. We’re hiring!