As a software leader, you compete in this market for in-demand developer talent. You understand the pain that was caused the last time one of your key developers resigned their position for another opportunity. If you tracked the resultant onboarding time and time to become similarly effective, then you understand the cost better than most. If you don’t remember this pain, learn from others and start planning for this eventuality so that it doesn’t represent an unmitigated risk for your organization.
Expect and plan for turnover
While past generations might have worked for the same employer for thirty years, don’t expect that from your workforce, especially since you probably don’t offer the lure of a guaranteed pension to get them through a lengthy retirement. Along with this general change in the workforce, the technology and software development fields are so new that the workforce is experiencing exponential growth. Stack Overflow’s developer survey[1] surfaces that over half of current developers have been in the field less than eight years, and while we don’t have data on the average length a developer stays at one job, the younger the developer, the shorter the average tenure will be, especially when starting out.
When you organize your team, don’t expect the roles to be static. Don’t assume that none of your team will leave for another opportunity. Plan for retention and work on your team culture but understand that there will be turnover. Make sure you’ve planned for it. One way to plan for it is to continue reading.
Build a software factory, not a craftsman’s shop
In the last decade of the software industry, many have created the analogy of the software craftsman[2]. This is a very positive an aspirational ideal, whereby an individual takes great pride in forming the software into a beautiful and useful product. To consider oneself a software craftsman, you apply discipline to your work and adopt certain practices rather than work in a careless and hasty manner. Who could object to that? And what developer doesn’t want to be a software craftsman?
But from a leaders’ perspective, you don’t want some of the other attributes the craftsman analogy conjures. For example, a craftsman curates a workshop specific to the individual. And while the craftsman may have an apprentice or two, the model doesn’t support many. In addition, while the work produced by the craftsman is beautiful and of high quality, when the craftsman goes away, others cannot immediately walk into the same shop and produce product of the same quality. The capability was imbued in the person of the craftsman, rather that the environment.
As a software leader, you want to create an asset for the company. You recognize that the software itself is not the asset. The asset is the software capability of your team. Assets hold their value and appreciate over time. You know from experience that the actual software produce requires ongoing expense to support and maintain it, and it depreciates over time and is eventually replaced. The data the software manages is the real software asset. Data will live on long after the current software is replaced. That is an aside for another day, but your organizational asset is the team’s capability to develop and change software. If that capability can walk out the door in the brain of a single person, then your organization doesn’t have a durable asset.
Our model for DevOps-Centered Software Engineering is a model for a digital software factory – a true organization asset that represents a complete capability to develop, grow, and change mission-critical custom software. By building not only an automated DevOps pipeline but a full software capability around it, described by the layers in the model, you can ensure that your process, environment, and methods are what give you your software capability, rather than any one individual. Keep in mind that even with a very well-run factory (picture the factory for custom fire trucks, each hand-crafted from custom orders), each of your team members must be highly skills and professional in all their work. But the organization’s capability should not decrease when one goes on vacation or regrettably leaves the company.
Make all work visible
In the “Team Workflow” of our model, and in The First Way of DevOps, as outlined in The Phoenix Project book[3], if any work is invisible, you won’t be able to manage it or control it. Many teams have a project Kanban board, but then they also must monitor email, chat, and support queues in order to accept and perform additional tasks. Inevitably, some team members will show great strength in performing a certain type of task. Without guidance, that team member will become the “go-to” person for that work, and the work queue will become that person’s inbox. This is evident when this person is out of the office. Then, if this person leaves the company, the ability to perform that work walks out the door.
To combat this, make sure that all work goes into a queue for the whole team or at least groups. Ensure that the same person doesn’t perform all the work. Force the work to be spread around so that the team is cross-trained. Use knowledge base software in order to capture solutions to issues that have happened previously.
Maintain architectural blueprints
As software systems grow, it can become harder and harder to understand all the components and how they work together as one. This is true with a single large application or one that has been factored into many independent services. Without architectural blueprints, only a few people with the history of the system will have the full picture in their brain. And when this brain walks, that knowledge walks as well.
Instead, keep an up-to-date 4+1 architecture on hand and versioned with the system. The Philippe Kruchten model[4] for architectural blueprints is a good model to adopt, as it specifies four common layers of software architecture, the physical, logical, process, and development layers – with the +1 being the listing of current software capabilities. By maintaining this shared view of the system, others will be able to see how each component relates to the next. Given that a picture is worth 1000 words imagine how much textual documentation would otherwise be needed to maintain the same level of understanding.
Automate the building, verification, deployment, and monitoring of the software
In short, make sure your team is equipped with a complete automated DevOps pipeline. If you rely on one or two people to build and deploy your software, you have siloed knowledge that will walk out the door one day. This siloed knowledge usually doesn’t stop here. If deployments are manual, then environment creation is probably also manual. Some companies are still trying to move their software system off Windows Server 2003 and paying Microsoft extended support fees until they do. In these cases, those who installed the software configured these servers, and understand the configuration have long left the company. Those that are there know still struggle to understand these large systems enough to recreate a new modern server environment and perform the migration.
When you equip your team with an automated DevOps pipeline, you organize them in your digital software factory where ideas enter on one side and working software exits on the other. You build the foundation for a complete software capability that is manifested in the process and the team rather than one or two individuals.
Bake learning into the system
Things go wrong. You probably have someone who is better than others at debugging issues in production and resolving hard support tickets. They are learning every day how to resolve tough problems with your system. Make sure that your team is learning. Make sure that your organization is learning. If that individual is where the learning resides, you haven’t bake learning into your organizational system. Journaling is a proven but sadly less common method in the software world. Developers don’t like to create documentation, and journaling is the act of creating documentation of what is happening while troubleshooting and resolving an issue with a software system. Then, once an issue is resolved, the final act of journaling is creating a knowledge base article about the symptoms, the root cause, and the resolution. This practice creates a growing searchable database for other team members to use when working production issues. This practice bakes learning into your organization and makes sure that this learning doesn’t walk out the door with your developer.
If you don’t have a knowledge base for your software applications, set one up today and make sure your people are journaling in it with every issue they work.
Bibliography
Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. Retrieved 2 19, 2019, from https://amazon.com/phoenix-project-devops-helping-business/dp/0988262592
Kruchten, P. (n.d.). Retrieved from Architectural Blueprints—The “4+1” View: https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
Mancuso, S. (2014). The Software Craftsman: Professionalism, Pragmatism, Pride. Prentice Hall. Retrieved 2 19, 2019
Overflow, S. (n.d.). Retrieved from Developer Survey Results: https://insights.stackoverflow.com/survey/2018/
