If you’ve worked in the tech industry for any length of time then you probably know that the software development life cycle goes something like this: Planning, Requirements Definition, Design and Prototype, Development, Testing, Deployment, Maintenance, and Operations.
I often write articles for decision-makers and product owners and how they relate to this life cycle. This is not one of those articles. Today we’re going to turn the tables, and I want to explain how we can create a successful work environment by treating work culture as a software development project.
For once, managers and decision-makers in the company will be the developer and the software engineers will take the role of product owners, working together to shape their culture and create a healthier and more productive business.
Why? As research has found, positive work environments foster productivity, and the most successful culture are those based on strong leadership. We’re talking about managers and leaders who take active measures in guiding their team as well as enhancing their culture. Think of it as real-life UX.
What is Culture?
Culture is a blanket term that encompasses most social behavior. While we could give an academic definition of the concept, for our purpose, it’s better if we define it in broad terms. Culture is both what people do in a social context, and how they’re shaped by that social context in tandem.
We’re the byproduct of our culture, and at the same time, we reinforce that culture by enacting what we’ve learned and by sharing it with others. What we value, how we walk, what behaviors we deem acceptable, even how we feel about the world, are all aspects that are shaped by our surroundings.
This isn’t to say that culture is immutable, quite the opposite actually. Cultures are living organisms evolving with each generation and surviving by adapting to changes. Some of these changes are the consequence of the environment, like the fast adoption of remote work during the pandemic. Others are guided by human action, such as enacting policies to shape your company’s culture, for example.
Every culture is different, and its susceptibility to change depends on the size of the culture as well as its age. Like a tree, the bigger and older it is, the more difficult it is to transplant or trim.
Culture as a Project
Since culture is behavior, you have to change people to change a culture. We cannot directly reprogram brains, so instead, we have to create the condition for a new behavior to emerge and a reward cycle that reinforces said behavior.
Culture is not software, you can’t just open a file, change a few lines of code and immediately see the results. It takes time, effort, and more importantly, persistence. Having said that, the aforementioned software life cycle is a great model to follow to implement changes to our culture.
Planning
Just like in software development, the first stage is to create a plan. Begin by envisioning a goal, what is your end state? And how can you measure cultural changes within the organization?
Speak with your team, begin by explaining to them what culture is and then ask them what they like to see changed. It doesn’t have to be anything specific (that comes later). Right now we want to have a big picture of where we’re headed.
As for measurement, use KPIs like work environment measurements, stress levels, emotional disposition, work engagement, and so forth. The specifics of which KPI to focus on will depend on the requirement set by your product owner (your team).
Qualitative measurements like an in-depth interview with team members and focus groups are a welcome addition that can bring key insights about their subjective experience.
Define Requirements
Once you have a vision, it’s time to give it shape, with the help of your product owner (once again, your team) define in clear terms what you want to achieve. Remember that a clear goal has four conditions:
– We’re aware of where we currently are
– We have a measurable end goal
– We have defined a set of actions that get us closer to that goal
– We have a way to measure if we have moved in the right direction.
Just like in software development, we listen and provide input, but in the end, it’s the product owner that decides what they want (within the limits of our possibility of course). At this point, we take all ideas regardless of feasibility.
Design, Prototype, Develop
This is where the fun begins. By now we have a goal and the requirements from the product owner. Let’s say for example that we have established as a goal that we want a fun work environment and one of the requirements is that the group members want to know each other better.
At this point we could come up with any number of ideas: for example, if your team is comprised of gamers you could have weekly board game tournaments, if they’re partygoers, then casual Fridays with soft drinks would get a warm reception.
The point is that at this stage you have enough information to “build a prototype” of what you want. Just like a software prototype, you can have a beta test period, or you can show it to your team to gather feedback.
Let’s say for instance that you’re creating a set of guidelines for handling communication amongst team members. You can introduce a new guideline, gather data for a couple of weeks, make changes as needed and then add a new guideline.
What you’re doing is incremental design. Take a small part of the project, test it, perfect it, and then add to it. Little by little you end up building towards your goal.
The incremental design has another benefit, it makes change more palatable. One of the biggest risks when working with a company’s culture is meeting resistance from team members. Even if they were the ones to ask for those changes in the first place.
People are more willing to make smaller changes and compromises than big sweeping revolutions. It may take longer to reach the goal, but the benefits of taking it one step at a time outstrip the risk of changing too much too soon.
That extra time can help you assess if your new culture is having unintended consequences and why. It will also give you plenty of time to assess the feasibility of keeping these changes in the long term.
Maintenance and Operations
Changing a behavior once it’s easier, but committing to a long-term change, especially when making changes to an established culture, is a challenge in itself.
Just like video games, find ways to reward the key behaviors that create real change in your culture, design a sustainable reward cycle based on income, social reputation, or point accumulation that motivates people towards the behaviors you want to see.
Just like software, new cultures gain a lot from documentation, and in this case, creating a simple document with the whys and hows of your project can help people understand the perks of their new behaviors.
Finally, just like software, developing a new culture is a job that never ends. Keep your eyes open, keep gathering feedback and keep adapting and making changes to create a work environment where everyone feels safe and is motivated to become the best professional they can be.
