The pandemic and recent market volatility have highlighted the necessity of resilient engineering teams. More than even before, engineering organizations need to be agile and resilient to survive through natural disasters, market movements and shifts in business strategies. The role of engineering leadership in building resiliency is to perform change management with a focus on consistency of knowledge, culture, strategy, mission, and emotional well-being of the team.
Throughout my career, I’ve been through the Great Recession of 2007-2009, have experienced layoffs and changes in leadership and business strategies of my work units, and have led a startup through pandemic. I have also first-hand experienced successful fund-raising rounds, IPOs, and acquisitions. In this post, I share some of the lessons I’ve learned through these experiences.
1. Build a strong knowledge base
2. Establish engineering best practices at the organization level
3. Be transparent about planning and strategy information
4. Cultivate a shared sense of purpose, mission, and vision
5. Foster psychological safety and mental well-being with specific actions
1. Build a strong knowledge base
The communication load of engineering teams increases exponentially with the increase in team size. In addition to that, as the team grows, engineering teams normally become more siloed by either product or technical functions. As a result, it is inevitable that certain engineering information will be highly localized, only known by a small number of team members. That leaves organizations open to a single-point-of-failure risk: if one or more members of a team leave the organization, the remaining members may not have all the information they need to continue the tasks of the departing members.
Engineering teams can use a few different tools to create a knowledge base. An effective tool for creating and sharing knowledge base has the following criteria:
- It is complete.
- It is accurate and up-to-date.
- It is easy to find, search, and query.
- It is clear and easy to follow.
In this post, we look at 3 common tools for preserving knowledge: documentation, automation, and tests.
Documentation
The main challenge with documentation is to make sure it is kept up-to-date. The closer the documentation lives to the code, the easier it is to remember to update it when the code changes. Some common ways to produce documentation are:
- Wiki: Most engineering teams use wiki tools or cloud-based documents to create documentation. This format is usually the hardest to keep in sync with the code, but it is the most flexible format, and is the easiest to index and search.
- In-code: Different programming languages usually have automation tools to generate documentation based on the comments in the code (some examples for python). The main drawback of this format is its limited format (text-only), as well as low coverage (only documents the code, and does not cover a lot of context).
- Multimedia: In the hybrid work era, other formats such as recording videos of team meetings or demos have become more common, although videos have the disadvantage of being very difficult to search for specific pieces of information.
- Architectural Decision Record: In larger teams or organizations who have been around for more than a few years, architectural decisions are commonly made within a larger context of business and technology constraints. In such teams, documenting the thought process that led to an architectural decision is critical for the ongoing stability of the application. This is done using an Architectural Decision Record.
Automation
Automation can be thought of as a form of building a knowledge base. Instead of explaining to the users how they are expected to perform a task, automation codifies the process in a way that is still accessible to the user.
Since automation is task-oriented, it can only cover a portion of the documentation that is required to create a knowledge base. Also, automation generally requires more upfront effort than documentation to build. However, once established, automation has a wider reach: more people can use it faster and it requires less effort from the end user.
Testing
A test can also be thought of as a tool to document and enforce how a certain feature or service should behave. Tests are primarily written for machine consumption, and they often leave out the process that results in the end goal. So, be careful with relying too much on them to convey information to other humans.
2. Establish engineering best practices at the organization level
The main utility of these conventions are:
- Reduce the decision time and fatigue, since the team no longer has to debate certain items for every new task.
- Shorten the time it takes for the new team members to onboard and be productive, by creating consistency (and reducing confusion) across the board.
- Increase overall productivity and development velocity. Consistent code is easier to read and understand, making it faster to ship new features.
- Improve system resiliency by reducing its reliance on its individual members.
The question that software teams need to ask themselves is:
do you know what you are doing as a team? Or do you just have a collection of individuals, each of whom knows some fraction of the problem space?
Most teams start at the initial phase of “individuals knowing some fraction of the problem”, trying to solve a problem. This often results in chaotic efforts, and inconsistent results. As they learn the problem space more, they start to have more repeatable results, but the process is still not documented, and so it is prone to collapse if an external shock is exerted to the system (e.g., an individual leaving the team). As the team moves on this journey and document its learnings into defined processes and workflows, the system starts to show consistency across multiple environments and conditions. Once the processes are defined, the outcomes can be managed closely and across a range of different conditions without loss of service or quality. The team shows it is capable of delivering the expected quality even if there are unexpected changes to the environment. Lastly, on this journey, the team starts to optimize its processes and workflows to achieve higher throughout and better quality across a range of environments. This journey is well documented in the Capability Maturity Model.
Whether or not explicitly set, each team eventually will converge on a set of conventions for engineering processes and software development. If not set at the organization level, these conventions and “best practices” are set on a team-by-team basis, normally influenced by the personal views and experiences of a few senior people on the team. This creates a risk of disruption when those senior members leave the org. To mitigate this risk, the leadership should depersonalize decision making by instituting a set of engineering best practices and enforce them across the organization. There should still be room for updating these best practices as the team grows and accumulates experience; however, such changes are no longer dependent on the personal opinions of a certain team member.
Here are a few engineering practices that can be standardized:
Style guides
A style guide is a set of standards that outline how code should be written and organized. The “best” style guide is the one that actually gets implemented and enforced. Being consistent and reasonable is more important than being “right”. There are tons of good style guides out there to get you started. If you are just getting started, it is best to adopt one of the existing style guides from a company or developer community that you respect, and tweak that as needed over time to fit your team’s specific goals. I’ve included links to a few style guides at the end of this post.
Engineering processes and workflows
This is an area where you want to make sure you move deliberately and build momentum. Especially in smaller teams that are used to operating less formally, you may get some initial resistance from the team for introducing processes.
The best argument for processes and workflows I have read is that structure and process help us bring growth, transparency, and resiliency into the organization. So, when introducing new processes, instead of focusing on redtapes and structure, talk about learning and transparency. Structure and processes help us learn from our failures in a transparent way. This learning and sharing will make our organization more stable and scalable over time.
The best experiences I’ve had with developing engineering guidelines have followed an iterative and collaborative approach:
Meetings and collaboration norms
Meetings are a necessary part of collaboration, but they can be disruptive and time consuming. Mitigate that risk by establishing a set of guidelines for meetings and interactions. This can be done by a mix of different methods of influence:
- Lead by example. Be very aware of the fact that, as a leader, how you organize and run meetings may become the new “norm”, so model the right behavior.
- Provide mentorship and feedback to other organizational leaders, in a discreet and constructive way.
- Publish a set of guidelines to get everyone on the same page about when to call for a meeting and how to run meetings. One great example of such guidelines is “10 rules of a successful meeting in a tech company”.
3. Be transparent about planning and strategy information
Change fatigue is a real thing in engineering organizations. Constant changes in product priorities and project planning causes burnout, reduced motivation, and disengagement from the engineers. Creating a sense of trust and continuity in planning is a big component of building resiliency. One way engineering teams can achieve this is by creating product and engineering roadmaps, and making them easily accessible to the team.
Designate a single source of truth for the roadmap document.
Make your planning and roadmap docs easy to reference. Make sure it lives somewhere accessible to everyone, such as in a company wiki.
Communicate often and align tasks to the roadmap
Communicate the roadmap often, and keep referring to it to remind the team members that their day-to-day work is contributing to the success of the entire team and company. This could be in 1:1 meetings, team meetings, planning meetings, all-hands, etc.
Communicate changes in advance
When making significant changes to the roadmap, make sure to communicate that to the team, along with a reasonable explanation for why the change was made. You don’t need to have all the answers, but it is important to acknowledge that the change was necessary, and that it came as a result of a deliberate decision. In the absence of an explanation, team members will make assumptions to explain the change that could cause further stress and anxiety on the team.
4. Cultivate a shared sense of purpose, mission, and vision
Most engineers spend a considerable amount of their time working on a small piece of the application. Going through product direction changes can be demoralizing. If a vision exists, it may get lost in leadership transitions. During the transition, the team may default to inaction, assuming that the vision may not carry over to the new leadership. Especially during hard times, a shared sense of purpose can help the team carry on.
Creating a shared sense of purpose starts all the way at the end user.
Define the end user and the problem statement
Start by documenting the answers to the following questions:
- Who is the user?
- What problem does the product solve for the user?
- What is our approach to solving those problems?
- What are the core features of the product?
Create a sense of purpose and mission
Use real user stories to show engineers how the outcome of their work is changing lives or helping other businesses grow and contribute to society in meaningful ways.
Build a community
One of the most effective emotion management tools is relationships.
- Get to know team members as persons and not just coworkers.
- Create opportunities for engineers to learn about what other teams do, and even work on different parts of the code.
- Make sure to create opportunities for those who don’t like small talk and are more task-focused. For instance, team events that are focused on a shared task (cooking classes, games, etc.) can be a great opportunity for everyone to feel included.
5. Foster psychological safety and mental well-being with specific actions
Engineering teams are a collection of individuals who collaboratively work on achieving a shared outcome. Having a sense of belonging and emotional safety can improve team morale and productivity. Some tips to improve the team’s psychological safety:
Practice empathy
- Listen and try to understand before being understood.
- Never brush off a concern, even if it seems unimportant to you.
- Show empathy and care for those who are affected by the layoffs and RIFs. Remember that during layoffs and RIFs, oftentimes it is not the technical capability of individuals that determines who gets to stay and who leaves the team. But, the decision is often made at the business level to stop investing in a feature or a customer base or market segment, and that decision usually trickles down to letting go of one or more engineering teams. Remember that your remaining employees are watching how you deal with the impacted employees, and will draw conclusions about how you generally value the people who work for you.
Acknowledge and address uncertainty and doubt
- Lean into criticism and resistance, rather than just shutting it down. Acknowledge perceived concern, anger, or loss of team members, even if you can’t do anything about it at the moment.
- Acknowledge and address the sense of uncertainty and doubt. People are inevitably worried and anxious. Try to have as many team meetings as needed to address their concerns.
- The core of resilience is mindset, so anything you can do to help the team to foster a more solution-oriented thinking is beneficial.
- Help the team reframe the situation. In difficult situations, listen with empathy to the team’s concerns, and summarize to make sure you’ve understood. Then, ask the team how they could be thinking about the situation differently – in ways that are more hopeful and action-oriented yet still feel believable.
- Lastly, resilience may be misunderstood as the ability to bounce back instantly from difficulties or to ignore real issues. Defining or encouraging mindless acceptance of workplace stressors is a recipe for burnout.
Offer professional help and support system
There are lots of studies that tie resilience to mind games only. However, in the context of organizations, it takes more than just talking to build a sense of psychological safety in the team. Invest in tools and professional services that improve the mental well-being of the employees. There are several mental well-being apps, professional counseling services, and other tools that can help team members feel less anxious and instead feel emotionally safer.
Offer Flexible working arrangement
A major stressor during the pandemic was the competing demands of work, personal, and family life. Workers who had more flexible working arrangements showed less mental fatigue, and increased productivity. Your teams may be struggling with childcare, stress, family support, and health anxiety. Be mindful of these challenges and offer help or flexibility so your team can deal with them.
Lastly, remember that during times of uncertainty and hardship, the team will look up to you as the leader. Model the behavior that you want the team to adopt. Be positive yet realistic. Plan strategically yet execute consistently. Communicate and be transparent but filter out the noise. Planning, communication and transparency are the bedrock of resilience.
Code style guides
Google Style Guides
Airbnb JavaScript Style Guide
Microsoft API Guidelines
GoLang’s official style (Effective Go)
JavaScript Standard Guide
Github’s Ruby Style Guide
Python Foundation’s Style Guide (PEP8)
Angular Style Guide
And many more that can be found in a curated list of style guides: