8 mins
You have 0 further articles remaining this month. Join LeadDev.com for free to read unlimited articles.

What can your organization collectively do to reach its goals?

October 19 – December 14 Leadership course
graphic element

Change doesn't happen alone – inspire your team today

Join the new five-part course on engineering leadership’s most fundamental challenges

The story of most startups is largely the same: a few friends – usually software engineers – come together over a shared brilliant idea, an innovative solution. They code and cobble together something that gains attention. They get funding, hire a few more engineers, and focus on building something people really want to use and pay money for. Once that product-market fit box is ticked and customers are steadily ‘coming through the door’, the company starts hiring more and more people outside of engineering: marketers, administrative people, recruiters, finance people, sales, and customer care folks (like me). And somewhere along the way, someone pipes up and says the company really needs to define its culture and values.

The need for this defined culture is driven as much by a need for new, more structured processes as it is by the need to better define the brand and attract people to work there. While, traditionally, that process of inscribing culture has seemed a rather top-down and corporate affair signaling – to some – the end of the ‘good old days’. These days, the project can be collaborative, including a wide variety of team members and other stakeholders. When this cross-company culture creation is done well, it can increase individual autonomy, unlock creativity, and enable a company to go from good to great.

Scoping for an actionable culture

In the Merriam Webster Dictionary, the second entry on the word ‘culture’ gives the definition: ‘the set of shared attitudes, values, goals, and practices that characterizes an institution or organization’. In startup after startup, whether they realized it or not, those early team members of the sort that we met in the first paragraph were defining the culture as they went about building a viable product and business. While some teams are fortunate enough to launch with a prescription for culture and developed practice for how to realize it; for the vast majority of companies, culture is an afterthought. Once culture becomes a problem, it can be rather difficult to refactor that early code, but it is by no means impossible.

Unfortunately, the mistake too many companies make is trying to pack far too much into the culture-setting exercise. Every hope and dream for planet earth and the universe must get its pride of place in the new culture code. Rather than the nimble tactics that drove the early days of development, the project of defining culture becomes a silver bullet for all that ails the world.

Expansive scopes and unrealistic aspirations can cause people to become disillusioned with the effort and dubious as to its value. With a shift in scope and more specificity, you can create a more intentional culture that drives cooperation and promotes cross-functional harmony while setting sights on tangible outcomes.

Asking for a problem-solver culture

As a customer experience leader, I think all day every day about problems: our customers’ problems, our company problems that affect our customers or make it harder to solve problems for them, and also the things that hamper my team from more effectively solving customer problems. On any given day, I can be found trying to unblock a release, getting clarity on a legal matter, or watching a customers’ screen as they show me something that looks suspiciously like a bug. While the work that I do is laser-focused on what customer care guru Jeanne Bliss calls driving high-level alignment for a ‘one company experience’, the day-to-day work of the people on my team is not so different than many of the others in the company. There are challenges in front of them and they need time, resources, space, and support to resolve them. If we could all see each other as problem-solvers and approach situations with the question ‘What are we trying to solve here?’ perhaps we could get what we need more easily, and tackle the challenges on our plates.

For example, the main complaint I’ve heard time and again from engineers is that they are tired of so many meetings. What I often hear from them boils down to this: there are things that they need to do (write, edit, compile, and ship code) that require long uninterrupted hours to accomplish. This work cannot be done effectively because all the other people in the company have some compulsive need to keep creating calendar invites, adding Zoom links to them, and sending them out to everyone including the beleaguered engineers. The truth is that many of us across many departments dislike meetings (especially pointless ones without agendas!) and would love to forgo them. However, getting the information and alignment we need from engineering often proves impossible without the meetings. If, instead of making the assumption that other people are adversaries hell-bent on chomping into valuable coding time, devs got curious about what problems were trying to be solved with meetings, we might be able to develop some creative solutions.

Another time when digging into the actual problem has helped was when engineers have pushed back about a question or request they keep getting over and over from success or support. When we are able to communicate around the question that is ultimately trying to be achieved or alleviated, the customer teams are able to move away from being pesky question-askers in the eyes of developers to partners in problem-solving. When we dig into the actual problem, we can create extensible and transparent systems rather than churning out mere band-aid fixes.

Nurturing the written culture

Asynchronous communication is invaluable within distributed workplaces. The teams that I currently oversee – support, success, training, and documentation – are there to empower customers and protect our product and engineering teams from their sometimes voracious demands. When engineers write things down, they also protect themselves from the customer team’s demands.

If we know where to look for information about patches and new features, we don’t have to come to the engineers. If your commit messages are verbose and your release notes are thorough, then we can trust that information and convey it to customers and users without initiating lengthy Slack threads.

The best way to cultivate this culture of written, asynchronous communication is to hire and nurture people who are not just great coders but also good writers. When someone has mastery of written communication with an understanding that they are creating a lasting record for those that come behind them to glean valuable and actionable information, rather than just typing in words to satisfy a prompt, it nurtures a culture of asynchronous proactive enablement.

Caring for the maintenance culture

The tech industry is famous for the reification of the new and shiny. Companies boast of how their software, app, or device will change the world for the better. They speak of recklessly and speedily blazing new trails and throwing caution to the wind. However, if the last year has taught us anything at all, it is that the most crucial work – the work that undergirds any attempt to innovate – is that of care and maintenance. Without the day-to-day maintenance of our built environment, processing and delivery of food, and care of human bodies, nothing else is possible.

When we care for the relationships and products we build at work, it reaffirms what is important to us and sets the intention for what is most important to do next. It also forces us to turn back and look at places where we worked too hastily or carelessly in the past. How could I have forgotten to put a closing bracket there? Why didn’t I take a moment to thank my colleague for their help on this?

Too many companies keep engineers in silos and away from the rest of the company and pressing company concerns because they want to keep them pumping out ‘innovative’ new features. Taking time to focus on the bug backlog or understand how the rest of the business is working and how they might help seems like needless overhead for the engineering ‘cost center’. Meeting-free days become meeting-free weeks because the new widget or add-on needs to be delivered by a certain date. However, a fact of growth that most customer care pros know is that, over time, a greater portion of revenue is expected to come from existing customers. So, while new features might attract new customers, the unglamorous work of fixing bugs and ensuring performance and reliability is what will keep the lion’s share of your customers around and support the overall success of the business and its people.

Conclusion

Though many companies approach it that way, the project of defining team culture doesn’t have to be a public-facing marketing event. Culture is not set by pressing ‘post’ on a webpage or after one All Hands presentation. Culture is about the things we do together to reach goals that we have mutually agreed upon. Culture is social, and can shift and change over time. However, it is that very element of time that can make our culture richer as we go on. When we can scope efforts iteratively, ask questions with immediacy, document our decisions and discussions in a way that nods to the future, and maintain our systems in a way that turns fresh eyes to our past, then we are working in a mature and intentional culture where people and projects can flourish.