What has a hundred legs, sits in your office, occupies fifty computer screens, clicks on keyboards and trackpads all day, and gets nothing accomplished?
Answer: Your development team.
Wait, the CEO says. What is going on here? We hired a bunch of developers. We bought a very long party table and two very long benches. We put everyone together in a warehouse with a tin roof and a giant Steve Jobs motivational poster. We supply soda and pizza five days a week (and beer on Thursdays.) We made every Friday into Hawaiian shirt day. Why aren’t they producing great software?
Why, indeed. You see, dear reader, software is not necessarily linear in nature. It is an abstract, complex, creative endeavor. If one equates software development to shoveling rocks into wheelbarrows, the results will be bitterly disappointing.
Let us explore this together.
A Tale of Two Teams
Consider two development teams working within two companies of similar size.
The Blue Team
The Blue Team is led by a director having no development background. He does not spend much time thinking about best practices, but believes that competent developers should either produce 100% bug-free software, or be fired.
Blue Team is composed of the original technical co-founder and a band of developers brought on after the initial product version was built. The technical co-founder still plays the “hero programmer” role, and does not openly share his substantial domain expertise with his new colleagues – after all, if the information was difficult to obtain, then everyone should have to go through a hard indoctrination, right?
The Blue Team developers have learned to be very risk-averse because they don’t understand the software under development as well as the co-founder does, and they certainly don’t want to be accused of breaking the software through their own ignorance. Iterations are chaotic partly due to the lack of disciplined processes, and partly due to tribal knowledge that is lacking from developer to developer. When deadlines loom, the approach preferred by the director is to work harder and longer. When bugs arise, they end up at the feet of the original authors because nobody else knows what was done, or how it was done.
The Red Team
The Red Team is led by a director with a background in technology. This director is an expert at balancing engineering discipline with the realities of business prioritization.
Red Team developers pride themselves on being students of the art and craft of software. The team purposely uses modern tooling and takes accountability for their releases using a pragmatic test and deployment strategy. They choose tech stacks and languages based on technical, business and environmental conditions rather than religious dogma. They manage iterations with discipline and maturity.
The team keenly and openly shares code, ideas, and solutions with each other. Designs are challenged within the team in a supporting, professional, and positive manner. This cross-pollination of knowledge also means that when something breaks, the team can cover for each other. Every second Friday afternoon, the team takes time to improve their own skills by researching and exploring novel projects using the latest tech. These behaviors are openly espoused and promoted by the director, and some of the new ideas from developers even make it into the core product.
And Now, a Quiz
These teams represent two extreme examples, but they are based on very real scenarios. Time for a simple quiz.
- Which of these teams will produce a better product?
- Which team will produce software more quickly?
- Which team can scale faster in terms of people and technology?
- Which team has the lowest turnover?
If you answered “the Red Team” for most of these questions, you are probably correct. The Blue Team might actually produce an initial version of software more rapidly, but it would likely be sub-optimal over the longer term. This is Conway’s Law in effect.
There is a term for the difference between these two teams. That term is “development culture.”
What is Development Culture?
Yes, dear reader, development culture is a real thing with pronounced effects on the way knowledge work gets done. Here is my own definition:
Development culture is the way a development team works, and how they produce results.
This definition is purposely broad.
Development culture is about how developers build products; how developers relate to each other, their team, the surrounding business, the physical environment, the processes and tools, and the product itself. On an interpersonal level, it is about communication, teamwork, unit integrity, and how obstacles are handled, ranging from high level strategy to low-level tactics.
In my own travels, there has been no single universal standard for “good” or “bad” development culture. It is specific to the organization and the individuals involved. If a developer is working in a Red Team, it may not matter if the company supplies free meals, a laundry service, or beer parties – the developer is probably having great fun doing the work, surrounded by a vibrant team. Similarly, on a Blue Team, the free meals might have to be plentiful and delicious to keep a developer from leaving.
Is Your Development Culture Healthy?
You don’t always need a doctor to tell you that you are sick. Similarly, there are telltale signs that indicate whether your development culture is healthy without knowing all of the details at the ground level.
Diagnosis: Healthy
Revisiting our Red Team, their product and their practices would likely show the following:
- The product works for their customers, with relatively few bugs.
- Speed of building and releasing new functionality remains consistent or improves over time, even after initial product creation.
- There are very few bugs caused by deployments and change management issues, likely due to automation and disciplined development practices.
- Bugs are fixed rapidly and rarely cause more regression, due to the use of technical testing as an integral part of the development process.
- After each release, there are fewer and less severe bugs relative to an organization with an unhealthy culture, and these bugs are fixed rapidly.
- Low turnover of development staff.
Diagnosis: Unhealthy
How about the Blue Team?
- The product is unreliable, and customers are likely complaining about it.
- Bugs seem to take forever to fix, and when they are fixed, other things become broken in the process.
- Releases are often delayed because of high bug counts, and customers do not trust that releases will be bug-free. This erodes confidence in the product.
- High volume of support calls when new features or bug fixes are released.
- High developer turnover relative to an organization with a healthy culture.
- Difficulty hiring new developers.
Moving from Unhealthy to Healthy
Unfortunately, in my experience, unhealthy development cultures are by far the most common. I consider unhealthy cultures to be the automatic result of neglectful behavior. A healthy development culture takes work, intentional design, empathy, and – possibly the most difficult thing – the release of a certain amount of control. Hiring smart people often requires you to get out of the way in order for their best work to happen.
If your organization is like most, you probably have a combination of characteristics from the Red Team and the Blue Team. Here are some ways to reduce or eliminate those Blue Team tendencies:
- Solicit honest feedback from the team, without coloring it with your own bias. Take the feedback to heart and plan to take action. HR-sourced employee surveys typically do a lousy job of eliciting development feedback. You might need to hear feedback directly – especially when it is difficult to hear.
- Examine your product objectively. Listen to feedback from customers. Look at your support call volume, your release bug patterns, and so forth. How is the product perceived externally? How is it perceived internally? Product health will indicate the health of the development team.
- Together with your development team, review through your current technical debt load (and yes, you have a current technical debt load!) Try to understand how and why things got to be the way they are.
- Hire outside experts to work with your organization. Experts that have achieved similar goals can help you assess your current reality and plan a path toward your goals.
A Last Word
I have worked with highly engaged teams producing software in corporate environments that most would consider bland and depressing. On the other hand, I have worked with teams that are disillusioned and unproductive despite having all the accoutrements of a modern startup.
Development culture has many influencing factors, but its effects on developer engagement and productivity cannot be overstated. If you are a tech leader, I encourage you to engage with your teams and weave conscious intention into your own culture. While difficult, it will be well worth the effort.