Software Development Tribal Culture

Often overlooked and underappreciated, among the most important factors in determining the success of every software development tribe is its culture.  I'm using the word 'tribe' rather than the more traditional word 'team' to reference the anthropological roots of culture, because I think the elements of culture that make modern software development teams successful can trace their origins to primitive tribal societies.

There's a difference between your tribe's culture and its processes.  Processes are usually documented in some form and represent the ideal of what you're supposed to do.  You can most likely read about your "development process" somewhere, and you might read words about Agile development or waterfall methodology.  At a more detailed level, you might also find the documentation for your check-in process, or the bug fixing process.  These are all processes.

In contrast to processes which might represent a sort of ideal of what you're supposed to do, culture represents the reality of what you're actually doing, and consists of memes that are communicated amongst tribal members.  Do you remember your first day, when you joined your software development tribe?  Remember that "drinking from the fire hose" feeling where your brain was in overload mode because it was taking in so much new information?  You were integrating and melding with your new tribe, drinking in its culture and grokking its memes.  It doesn't matter if your new tribe works in a bank and wears suits every day, or if they dress in kilts and boots and have a dog named Blue who likes to hang out in the kitchen, or if they wear leaves around their genitals and carry spears and hunt big game (or dogs named Blue).  You have to do more than form relationships with the key people in your tribe and find out where the rest rooms and gazelle are: you have to meld with your new tribe's culture.

On the other hand, if you are the person starting a new tribe as opposed to joining an existing one, you should be very conscious of the kind of culture you want to create.  The first people in a tribe usually play the greatest role in creating its culture.  Cultures are a fluid thing and are usually not under the direct control of any individual even though all individuals may contribute to the culture.  Past experience can be especially useful when forming new cultures.

Culture exists at multiple levels within larger organizations.  You may have a divisional culture that is broader than your development tribe's culture, and a company-wide culture as well.  In larger organizations, you sometimes see cultural wars between competing tribes, even as they cooperate on some levels as well.

For purposes of understanding software development tribal culture, I'm going to break down culture into these elements:

• Symbols and language, which often take the form of neologisms and new meanings for existing words, but they also appear in visual and auditory form as well
• Rules that govern interactions among tribal members and with the world at large
• Values - what you spend time and money on
• Knowledge that allows you to control various elements of the world, cyber and physical
• Wisdom and vision that encourages you to pursue the "right" goals

These elements of tribal culture are not just limited to software development tribes, but can be found in all sorts of teams such as sports teams, schools, companies, and indeed at any level of social organization up to nation states and beyond.  These elements of culture are often only partly documented in online or printed forms, and to a large extent must be learned via personal interactions, whether in the flesh or virtual.  That takes time.

I find it fascinating to ponder where this magical culture actually exists.  If all the electricity went out and there was no Internet, your culture would still survive.  It also survives the departure of any individual of the tribe as it is spread amongst all the tribal members.  I once wondered whether culture can survive the death of all of the members of the underlying society.

Let's take a look at how these things manifest in your software development tribe.

Symbols.  You know those acronyms you throw around now?  You had to learn each of those.  At the high end, cultures like Microsoft create thousands of acronyms.  Here's one public list of 451.  Then there are all the software module names, machine names, names for conference rooms, product names - the list goes on and on.  You have a corporate brand identity, product logos, and maybe even a sonic brand.  Your brain needs to understand the meaning of all these new symbols.

If your tribe uses a lot of symbols, or at least if you find yourself feeling like you're listening to a foreign language more often than you'd like, you may want to start your own dictionary.

Rules. Rules can be expressed in many different ways.  As software developers, we're familiar with the pattern for a rule consisting of a condition and an action.  While your tribe's rules could be expressed in that format, since these rules are executed by wetware and not software, I find it more convenient to express these as questions.  Rules can answer these sorts of questions which are found in most software development tribes:

• When you sit down in front of your computer to work, how do you know what to do?
• To what extent can you integrate your personal (family & friends) life with your business life?
• If you would like someone else to do something, how do you do that?
• When is it really OK to work from home?
• How much time off do you get?
• If someone comes to you and asks you to make a change to your code, is it OK to make that change?
• What kind of testing should you do before you check in your code?

Values.  Values are what you spend time and money on.  Here are some examples of values:

• Does your tribe maintain thorough unit tests and automated functional tests?  If so, then it values long term quality.  Some times you don't need long term quality because the code will have a short life time, and in that case, it could be entirely appropriate not to value such testing.
• Do developers have multiple monitors and screaming-fast development machines?  If so then the art of software development is most likely valued by your employer (i.e., you have a higher salary).
• How much time and money do you invest in your build, test, and release process?
• Do you get paid to invest time in staying current in the art of programming by getting to attend trade shows or classes to learn new things?

Knowledge.  Knowledge bases capture some of your tribe's cultural knowledge in a written form, while the remainder exists as tribal knowledge.  For example, you need to know your tribe's system architecture in order to extend its code base in a good way.  So you might start by reviewing system architecture documents.  Most likely the actual architecture is different from the documented architecture and you may well have questions about the architecture that you can best answer by asking someone and drinking in some tribal knowledge.

Knowledge can also be thought of as answering these sorts of questions:

• How do I set up my development machine?
• How do I check in my code?
• How do I log a bug?

Wisdom.  Sometimes ordinary knowledge is insufficient to make the big decisions.   I once recounted the story of when I was once part of a massive development team with many dozens of staff-years of effort invested in a very large product, and the CEO of the company decided to kill the project.  How did he know that this project was a dead end and that he needed to pull the plug?  It was wisdom.

Dakota tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount.  This is one of the most beautiful metaphors I've heard.  How do you just "discover" that you are riding a dead horse?  And how can the simple act of dismounting a horse turn into a strategy?  It turns out this metaphor shows itself all the time in various parts of our lives.  How do you discover when it's time to leave a job, a relationship, or change a habit that's no longer working?  And then how do you form a strategy to address your new discovery?  It's a bit of a magical process, usually accompanied by insight, inspiration, some trepidation, and a feeling of reaching a turning point.

Wisdom also guides our software development.  How do you know when your code design isn't working out and you need to redo it?  What about if you're just stuck on a bug and your existing approaches at fixing it aren't working?  How do you know whether to build or buy some technology?  Should you re-write your server code from Java to Kotlin?  And when you're interviewing, how do you decide which person to invite to join your team?  Even harder, how do you know when it's time to let a team member go?

Putting it all together.  Frank Addante starts off his article Start-up Step 1: A Culture Plan for Inc. by saying "Great culture doesn't just happen - you need to make it happen."  I hope that by breaking out culture into these individual elements and giving examples of how they manifest in software development teams, you can be more aware of the role that culture plays in modern software development teams.  With such awareness, team founders and team members can more consciously and carefully choose or at least guide the culture that best suites them, rather than letting it evolve more haphazardly.