Are you ever impressed by the software of a handful of companies? A game studio that keeps releasing hit after hit, or a productivity suite that integrates neatly with the ecosystem. Or maybe it’s that team of crack developers in your company that is simply unstoppable: fixing outages, releasing ahead of schedule, and always keeping tech debt at bay. Do you ever wonder what makes them so consistent? How about companies that keep spitting out crap despite millions of dollars in investments? Or have you ever considered why a change of CEO has rarely benefited struggling companies? For many decades companies have embarked on countless quests to find a crystal ball that can help them predict the outcome of software projects. Will a project be on time? Will it be reliable? Will it collapse in flames when the user provides a string instead of an int? Will it bring more revenue? Yet in their quest for this Holy Grail that may bring maximum shareholder value they have forgotten to look closer to home: their Culture.

Cultures can encompass a small group of individuals, such a group of 4 coworkers, or entire organizations. It also exists at different levels, which are usually but not always hierarchical. It is the operating system running in the background, that which you cannot see but can feel. It defines what an individual can or cannot do, almost regardless of individual skill level, seniority or intent. You are probably thinking “Duh! This is obvious, why are you telling me this?”, because it sounds exactly like Eat more vegetables to be healthy and sleep more to live longer. Behind these simple statements lie hard truths that people don’t want to hear: you are likely not eating enough vegetables, you are probably losing valuable sleep thanks to late night doom scrolling, and that your team culture says much more about you than your own skillset and individual belief systems. Hard pills to swallow, but important nonetheless.

Belief Systems

You can narrow down what you would call your personal belief system into simple sentences. In my case:

  • Programming Languages and frameworks should not do magic behind your back, everything is explicit.
  • Programming Languages should be opinionated to reduce pointless developer discussions (i.e. Golang’s in-built formatting)
  • Programs should strive to economise their resources and should be optimized heavily.
  • Projects should aim for quality and robustness over delivery speed.
  • Projects should be thoroughly documented as part of the development process.

I can now give myself a pat on the back and say “This is me, this is who I am, this is my free will speaking”, but it would be a lie. Whether you are aware of it or not, you belong to one or more cultures that define your belief system. My personality is risk-averse, and my first professional programming job was at a regulated BioTech company. My personality integrated perfectly with their need for caution, and they took me into their fold. I am also meticulous, which suits the need for documentation. I subconsciously joined the “Test First” culture that values rigorous testing over delivery speed. This meticulousness and need for “caution” may also explain why I dislike languages that seem magical and abstract away concepts in exchange for a loss of control1. And just like that, I can rationalize my belief system and gauge where I stand. Instead of searching for a crystal ball that can tell the future, I can simply look inwards and assess myself: I will highly likely take longer than the average developer to deliver a project, I am unlikely to trade rigor for development speed, I would not be a good fit for a disruptive or cutting edge team, I would thrive in companies that require rigor (BioTech, MedTech, Critical Systems) and I would be better suited for keeping the lights on (production stability, observability, platform) than the early development phase.

When externalizing your belief system you can also find information in what you didn’t say. If you read between the lines of my personal belief system you can notice that none of them relate to leadership nor interpersonal skills. That is not to say that I am an anti-social introvert (you could make the assumption that I am not fun at parties), but that I currently do not have aspirations for leadership. An assessment of my future growth would probably concur that I would prefer a technical path rather than a leadership path. Keen minds would have noticed that I framed all of these assumptions as likelihoods, because they are only assumptions. In reality, I am very social and extroverted (but still not always fun at parties). A culture gives you an estimate, not a bull’s eye.

Again, keen minds will detect a chicken and egg problem. To claim that your culture fully overrides your personality would be foolish and shallow. It would be equally foolish to claim that your personality fully overrides your cultural influences. It is more like a waltz, where each dancer can nudge the duo to different parts of the dance floor but only if the other dancer is in agreement. Which one comes first? That is a question for Developmental Psychologists and Early Childhood Development professionals. Lucky for us, software developers are usually adults or late teenagers with a robust personal belief system. Your personality and personal beliefs will predispose you and nudge you towards a culture. Using myself as an example, my natural risk-aversion predisposed me to being accepted into regulated fields like BioTech. A risk-seeking personality would have increased my chances of being rejected by my new employer’s culture. Note that I said chances of being rejected, because it does not guarantee an outright rejection. Cultures are seldom uniform in their beliefs, you instead would belong within a spectrum of the culture. A culture is an aggregate of many beliefs that converges on specific points. I will call these converging beliefs core beliefs. As long as you share the same core beliefs, you have a high chance of being accepted. It is not always easy to discern core beliefs from culture: do you write lots of tests because you are risk averse? Or are you risk averse after learning the benefits of heavy testing? This is why challenges to the beliefs of your culture can feel like challenges to your core beliefs. Your identity and your culture can seem and feel like one.

Crystal Ball

Just like any other statistical problem, you will need data points. You cannot watch a team launch their first successful product and correlate it to their team culture. One hit wonders exist beyond music. Instead you need to look at teams or companies that can replicate their success many times. Some famous examples are Lockheed Martin’s Skunk Works, Google X Labs, Mozilla, Apache Foundation, Free Software Foundation and CNCF. Some of these examples create their own projects from scratch, while others adopt them and guide them through a rigorous process (like the Apache Incubator). If you heard that one of these Teams/Foundations is coming up with a new project, you would probably assume it will be useful. CNCF is not about to release an AI-coded blockchain Kubernetes side-car, and neither is Google X Labs about to release an alternative to Microsoft Access written in Ada. If you spent enough time dissecting the internal cultures of these entities, you may be able to create a rough sketch of what they represent. But you can never fully replicate it unless you have seen it first hand, or even better, taken part in it.

A work culture can give you the following pointers:

  • The project’s tech stack and development style: Covered in previous examples. PostgreSQL developers are not about to release a new database backed by blockchain.
  • Team Compatibility: Whether a new member would be accepted into the team’s culture and would thrive in it.
  • The likelihood of cost overruns: A thrifty or resourceful culture is less likely to overrun costs, while a team of crack engineers with delusions of grandeur are likely to need a line of credit.
  • The likelihood of schedule overruns: Is the team usually focused on delivery dates and is willing to cut corners? Or do they usually take longer to produce a product?
  • The quality of the project: See above.
  • The stability/safety of the project: Some teams are known for rigorous testing, others are known for their long term support, a rare few are known for both, and the remainder possess none of these qualities.

It is very important to note that you cannot always predict the popularity or success of a project. I am not confident that a work culture can help you predict this because too many variables come into play.

Building a Dream Team

Let us take an extreme example, Skunkworks. These were not average engineers who clocked in at 8 AM and left for home at 5 PM. They were highly skilled engineers, mostly (if not all) workaholics who would happily work late nights and weekends to complete projects. They were willing to push the very limits of knowledge and even physics. They were also known for delivering world-class projects, either on or ahead of schedule, and without overrunning their budget. Because they were in the aeronautic industry, they did not deliver half baked products that endangered their users2. You could easily guess that their development style prioritizes facts and experimentation over everything else. You could also infer (or properly grasp if you read about them) that they had a close team of people who supported and helped each other, but also maintained the highest of standards for everyone. A clock-watcher or slacker would have been neutralized by their culture, and so would have been charismatic people with little engineering background.

This is enough information for you, as either a team member or a Power That Be (i.e. Team Leader or CEO), to understand how this team’s culture can be fostered. You would know which types of people would be a great fit, increasing the size of the Team. If everything goes well, you may even be able to split the Team and grow multiple concurrent sub-cultures. You now have the ability to increase the reach of that team’s culture.

Skunkworks is an extreme example, but the rule of thumb can be applied anywhere. Just look around you, look at the company you work at, or even the different teams that inhabit it. Think of their past projects, think of their outcomes, connect the dots: The proof is in the pudding.

Corporate Culture

Enter one of the most dreaded words in many fields: corporate. Most of us are acquainted with company’s Our Culture, Mantras, Who We Are and other corporate propaganda. Most of us are also probably very weary of these and to a degree think it’s all rubbish. The truth is that a generic corporate culture full of buzzwords means nothing. But a corporate culture that is spelled out in full detail, leaving little to the imagination, it is useful both for the company and for its employees. A company is putting its cultural expectations out in the open, letting employees know: “This is the kind of behaviour that I expect of you.” A company claiming that “Collaboration, Respect, Teamwork” is their culture is the equivalent to a Tinder date stating that they like to “Eat, Sleep and watch TV”. Cultures and mantras must go beyond the minimum expectations of a team. Being able to work with people and not being a dick to your coworkers is an innate expectation of all jobs; it is worrying that a company has to state these to the public and their employees.

Take Google’s company philosophy. Mantras such as “You can be serious without a suit” and “The need for information crosses all borders” point to a more flexible and casual approach to work. “Fast is better than slow” and “Great just isn’t good enough” are letting you know that they want things done fast and properly. Use your crystal ball, look at their previous projects and their outcomes, and voila! You can find out how truthful their mantras are. Another valuable example is the Apache Way. They focus on Earned Authority, Community of Peers and Open Communications. These are noble qualities that are hard to apply in corporate environments (“Community of Peers? What about the shareholders?!”) but reduce bus factor and politicking while improving collaboration. This is Apache’s way of saying: “If you are going to send good code you better also be prepared for criticism and teamwork”.

When done properly, Corporate Culture exists to provide a general direction for everyone. It can be a slow but consistent wind that sways all ships towards a general area, or it can be a strong gust that destroys any ships that refuse to travel with it. Kelly Johnson’s famous 14 rules at Skunkworks were treated as gospel. 2 Anytime someone deviated from the corporate culture you could quote the rule being broken. This can be considered abrasive and controlling in some corporate cultures, but in others it is absolutely necessary to maintain cohesiveness.

If you don’t want employees or team members to roll their eyes whenever they hear your Mantras then do better. Live, Love, Laugh is not a culture to live by. You can either ask a stupid question or call one out, once per day is slightly aggressive, but gives people something to live by.

CEO Mandates Are Stupid

Storytime! Upper management in Corporate Software Co. are concerned about the quality of their software. Developers have been delivering software at record speeds, making customers very happy. But the number of support tickets has been on the rise and the triaging process is costing the company a lot of money. Corporate Software Co. has always prided itself on its delivery speed. Their developers are well known for their commitment and rarely hesitate to jump to their laptops during an emergency outside of work hours. After a long conversation in their expensive boardroom, Upper Management has decided that it is time for a change. The next morning all staff members are met with an e-mail from the CEO: “CEO Mandate - […] Our focus will slowly shift from delivery speed to quality of work. We must strive to reduce outage times for our customers and improve reliability […]”. Upper Management pats themselves on the back, and everyone lived happily ever after.

Except, they probably did not live happily ever after. If Corporate Software Co. was a company well known for its delivery speed, it was highly likely part of its culture. Culture and Identity are heavily intertwined. Attacks to someone’s culture are usually considered as attacks to their identity. More importantly, you haven’t attacked one person but a whole group of them. Cultures act like an immune system that automatically fights back. In the same way that an immune system can detect foreign entities and get rid of them (just like teams can reject new members that do not fit in), they can also resist badly against significant change. Developers of Corporate Software Co. are not being backwards, stupid, incompetent or disloyal; they are simply reacting to an attack on their identity. No matter who you are, you cannot change a culture through sheer force. This is not only true in corporations but also in societies. No matter which company you are, people more powerful than you have tried and failed (see Cultural Revolution and Idi Amin’s Africanization). Even if you are trying to fix real problems such as lack of accountability, attacking the issue head first may not always have the desired effect. Martin Luther’s 95 Thesis were meant to help the Catholic Church overcome issues, but instead it led to a 500+ year schism.

Cultures are not static, they ebb and flow like a river. And just like a river, cultures can be slowly redirected to other places. Slowly tweaking Mantras to fit the new strategy, rolling out the strategy over time or even introducing small and achievable KPIs/targets are probably more efficient. If you are a growing company, shifting your hiring requirements to align with your new strategy is a clever way of introducing foreign bodies to the culture’s immune system (and making sure they can be introduced safely). A shift in strategy requires buy-in from a big chunk of a company; without this support you are only lowering morale and attacking their identities. Corporate Software Co. could instead introduce a new Mantra that alludes to software quality. It then could introduce a new quarterly or half-yearly target: required testing. Something as simple as 25% code coverage of tests and a 15% reduction in outage tickets raised. Through this strategy: the company has not attacked anyone’s identity, it has not hurt anyone’s feeling, and has slowly nudged the culture towards the new direction. Most importantly, it has acknowledged that its culture is the biggest definer of its success.

Final Thoughts

It is as imperfect as other metrics, but a team’s culture can help you guess how things will end up. If you are a developer, vibing with your company culture is much more important than you think. The idea of being offered triple your salary in exchange for a drastic culture switch is tempting… until you do it. If you are a Team Leader or someone in middle management, watching how your team interacts can sometimes give you more insights than a JIRA board. I am not telling you to ditch the board, but to complement it. If you are in Upper Management or aspire to it, your culture will define where you end up. Don’t expect to run a profitable government consultancy company with engineers who love the cutting edge and advise you to deploy with Arch Linux. Also don’t expect to be the next Silicon Valley big shot with a team of people who need 126767 requirements before starting. Whatever you do, Live, Love, Laugh belongs on the wall of a beachside Bed & Breakfast and not in your company website.

Footnotes

  1. I hate ORMs with a passion. Their magical properties and loss of control over databases has led me to tools like sqlc ↩

  2. Rich, B. R., & Janos, L. (1996). Skunk Works: A personal memoir of my years at Lockheed. Little, Brown. OpenLibrary ↩ ↩2