00:00:10.719
Hello, welcome to 'Minimize Your Circus Factor: Building Resilient Teams.' My name is Mercedes Bernard, and I'm a principal engineer with Cloud City, a software consulting firm in the Bay Area.
00:00:16.400
If you are someone who likes to follow along with slides or if you want reference links for some of the stats that I'm going to mention in this talk, I've published my slides on my website. They have full speaker notes, so you can get all that extra info there.
00:00:30.400
You may have heard of the term 'bus factor,' which is a bit of a morbid metaphor illustrating the impact on your team if you were to leave suddenly. I prefer to think about it as your 'circus factor.' If you were to run away and join the circus, what impact would that have on your team? Are they set up to succeed?
00:00:54.719
I recently left the company I had been with for three and a half years, the last two of which I held a leadership role within the organization. I was planning to leave for about six months prior to my job search and wanted to do what I could to make the experience as unstressful as possible for my team. I had a wonderful group of humans that I still care about, so this was really important to me. Did I get it a hundred percent right? No. But I learned a lot, and I was able to ease the transition and find strategies that helped them continue to deliver high-quality work with as little disruption as possible.
00:01:34.720
I turned in my resignation in April, becoming part of the record 4 million people who quit their jobs in the U.S. that month. We are currently in the midst of what is being called the Great Resignation, and the tech industry, in particular, is seeing higher than normal turnover and unfilled jobs. According to a report released by Vizier, tech industry resignations are up four and a half percent in 2021. This adds to the fact that the tech industry has historically had the highest turnover rates of any sector, with stats over the last few years cited between 13 and 21 percent, depending on how specifically the report defined a tech worker.
00:02:26.400
For reference, the industry average turnover rate is around three and a half to four percent, depending on the month. It is currently projected that there will be about 700,000 unfilled tech jobs this year. Even during the height of the pandemic, when the economy looked bleakest, that number only shrunk to 500,000. Side note: there are also between 70,000 and 80,000 people entering the industry every year looking for their first software development job. A 10-year investment into early career folks could have helped prevent our current situation, but I won't get on that soapbox today.
00:03:00.239
In this talk, I will advocate definitely for hiring early career developers. High demand, high stress, and low satisfaction due to companies continuing to operate as normal during a global pandemic—while failing to recognize their employees as full humans—leads to high attrition. Other top-ranked reasons why workers are looking to switch jobs include burnout, organizational changes, a lack of flexibility, discrimination, and a lack of appreciation. Given that most knowledge workers prefer flexible, remote working arrangements, many folks are looking for remote-friendly jobs that will value their contributions.
00:03:51.680
Attrition is expensive and extremely stressful for those remaining on the team. With the current turnover and hiring trends, it will take a while for anyone to backfill a role, which means those who stay with a team may have to deal with the stress of being understaffed for a while. This is the unfortunate reality we face. Therefore, if we are a senior lead or a manager on our teams, it is our responsibility to enable and empower those who remain to do their best work, both while we are working with them and after we leave.
00:04:21.760
I want to make it clear that this talk is about individual interventions aimed at enabling and empowering your team members. At no point will I advocate for you to take on extra responsibilities for the good of the company or to bend over backward without additional compensation. Unfortunately, under capitalism, companies are not incentivized to care about you. Your role within a company is a business relationship. If you're doing what's outlined in your job description and no more, then you're fulfilling your job duties. My goal is to provide you with low-effort strategies to incorporate into your daily work that will empower those around you without adding more work for yourself. If these strategies succeed, they may help share responsibilities and create a better work-life balance for everyone on the team.
00:05:34.840
The perspective I hope you'll walk away with from this talk is that these strategies are about caring for the humans around you and reducing their stress levels without engaging in uncompensated or disproportionate labor for the company. Resilient teams are important because we work in an industry that is constantly changing and always presents new challenges. If we have a team that is highly cohesive and resilient, they'll be able to adapt to changes and respond to challenges without overwhelming stress. But what does that look like in practice?
00:06:01.680
Resilient teams are those with high levels of trust and psychological safety, capable of adapting to change while maintaining an enjoyable working culture. In such teams, no one member carries an outsized burden—everyone shares a vision and common goals and is committed to each other's individual success as well as the team's success. To build a resilient team, you need to create a culture where both the team and the individuals will thrive, where open and transparent communication is valued and modeled from the top down.
00:06:43.600
Approaching conflict with curiosity is essential, as is showing outward appreciation and gratitude towards all members of the team, sharing that recognition with others in the organization. Additionally, you need to allow your team to do what they do best by giving them control and autonomy over how they complete their work so they can be most successful.
00:07:02.120
So, how do you know if you're on your way to being part of a resilient team? How do you measure something like that? I can't provide you with anything quantitative; there is no such thing as a psychological safety unit. However, if you pay attention to how the team responds to challenges, you can start to gauge where there is high resilience and where we may need to invest in some of those attributes from a previous slide.
00:07:38.240
How often do you hear someone on the team admit that they don't know something? If they admit they don't know, is there shame or a genuine desire to learn? When they do admit it, how does the rest of the team react? What offers of support are provided by other team members? When priorities shift, how are they communicated to the team? Does the team feel well-informed after an announcement? Do they ask questions, and are those questions open-ended? Is the team included in the implementation planning for delivering on new priorities?
00:08:32.080
When a conflict or disagreement arises, how long does it fester? How well does the team navigate discussions? Are they open and do they seek help to resolve disagreements? Can everyone remain respectful and continue maintaining trusting working relationships after a conflict? How openly and freely are members recognized for their contributions? How often do team members give each other public shoutouts? Do they share credit with one another, and are contributions from early-career team members recognized as widely as those from senior members?
00:09:34.959
Finally, one of my personal most important measurements for team resilience is whether folks take Paid Time Off (PTO). Do they feel comfortable taking PTO? When they take PTO, how much planning and preparation is required before they can leave? How many meetings do they have to schedule on the calendar to ensure their time is not wasted while others learn how to transition knowledge before they go? How often is someone's PTO interrupted by emails or Slack messages?
00:10:01.680
Highly resilient teams can manage change and other sources of friction with little disruption and can give each team member the space they need to enjoy their time away. The best way to minimize your circus factor is to consistently support delivery, support people, and support processes. We'll talk about each of these and strategies you can use daily to make it as easy and low-stress as possible should you ever want to take extended PTO, unexpected leave, or pursue a new opportunity with a different company.
00:10:47.760
So, delivery resilience refers to the actual work product we produce. Does everyone on the team have the knowledge and tools to continue delivering quality, consistent work even with churn? Closely related to improving the team’s technical ability is investing in the people around you and their interpersonal skills. Invest in their careers and support them in the non-technical skills they need to succeed.
00:11:30.080
Finally, process resilience refers to simplifying and strengthening the processes we have that facilitate running our teams and our business. Strong, simple processes are not dependent on any one individual in order to be followed and keep things in good working order. A lot of the strategies we're going to discuss today for minimizing our circus factor don't fall cleanly into any one of these three categories. Often, the things that support our internal processes also support the people we work with.
00:12:24.240
As we go through some ways to reduce friction and create a sustainable environment for your team to continue to be successful, I will call out where in this Venn diagram the strategies fall and why.
00:12:54.919
The first strategy is automated testing. This is clearly a delivery strategy. I've seen teams that either don't test at all or enforce 100% test coverage. In both cases, the tests—or lack thereof—were not useful to current and future team members. Tests are a great tool for catching regressions, but more than that, they serve as a main source of developer documentation.
00:13:07.440
Tests communicate expected behavior, expected side effects, and how to use components within the code to other developers. If you don't have any tests, or if you require such extreme test coverage that your tests aren't valuable and become just copy-pasting for the sake of covering lines of code, then the documentation they provide isn't helpful. Support your team members by writing valuable tests. Ensure that the descriptions of the test cases are accurate, describe actual behavior or context, and not just the state of variables.
00:13:50.720
Write your tests so that someone could read the descriptions and assertions and understand the responsibilities of the tested code. Avoid writing brittle tests that focus excessively on implementation details, so your team doesn’t have to invest time in maintaining them. You want your team members to understand and enjoy working with your code even after you're gone.
00:14:57.919
Next, we have another form of developer documentation, but this one shifts a bit towards supporting people—not just delivery. We can provide a lot of extra information for our team to learn from. Lately, I've found myself in situations where I have to dig through code that's six months to a year old, but the authors have left the company, and commit messages are often just the Jira ticket number.
00:15:18.400
When I go looking for the pull request, I sometimes find that the description is pretty sparse, merely reiterating the Jira description or describing exactly what's in the code. These situations feel like an archaeological dig, where I'm searching for clues about why something was written or what its intent might be, and trying to determine which behaviors are intentional and which might be bugs or unintended side effects.
00:15:53.760
In these cases, a good commit message or pull request description could save so much time and provide helpful information for your future teams and developers. Write descriptive commit messages and helpful pull request descriptions that explain the context and need for the change, who asked for it, and why, rather than just describing the code change. Hopefully, your code is straightforward, but if not, all of that other information helps just as much as explaining the tricky parts of the code itself.
00:16:42.400
Also, include information on how to test it, information about preconditions, and various use cases and their outcomes. This information is valuable for future developers if they have to debug something and need to quickly familiarize themselves with expected behavior regarding tricky code. Links to relevant documentation are also a significant time-saver. If you encounter a bug in open-source code and need to implement a non-obvious workaround, include a link to the GitHub issue in your commit description.
00:17:50.080
Like automated tests, commit messages and pull request descriptions are often the first place we as developers look for answers, yet they are also the first place we ignore in the interest of time. Alright, so we have a theme: documentation is important! Who knew? But here, I'm referring to more traditional forms of documentation, which is why we're going to categorize this between delivery and process.
00:18:30.160
This is a straightforward strategy in this talk, but I see it consistently deprioritized, which leads to long-term consequences. If nothing is documented, organizational context lives in the heads of individuals rather than among teams, usually those with the longest tenure, and as such, they become the biggest attrition risk. If they leave, all their context is lost. Typically, documentation is only prioritized after someone has given notice or right before an extended vacation. No matter how hard anyone tries, some things are always forgotten or deemed unimportant when there are other, higher-priority things that need to be documented.
00:19:47.760
To combat this, get into the habit of documenting everything in a convenient place for your team. Technical documentation should live as close to the code as possible. It might not be in the repository, but please don't leave breadcrumbs all over random Jira comments, as very few people will be able to find that information and benefit from it. A recent example I encountered was at a client company that had a single sign-on (SSO) option set up for their users.
00:20:55.280
The engineers understood how it worked in production, but they never used it during local development or testing because they had multiple accounts set up with different feature flags, allowing them to test edge cases. So, they always logged in with email because that was the easiest way to manage their feature flags. This meant that when a bug was reported for the SSO feature, no one knew how to use it in the local environment for troubleshooting and fixing the bug. The engineers who had originally worked on the feature were long gone, requiring two weeks for myself and another engineer to figure out the local infrastructure and the correct configuration needed for testing.
00:21:55.760
If this had been documented, we could have spent an hour or two figuring out how to test it so that most of our time could be spent fixing the bug. Now, transitioning from delivery to supporting the people around us: I've discussed this in previous talks, but one area where many early-career folks don't receive enough mentorship is how to make decisions and evaluate trade-offs.
00:22:44.959
We often focus on becoming technically competent and writing good code, but we don't spend enough time learning how to make sound technical decisions. If you're a senior member of your team, one way you can support those around you is to coach them on how to make decisions and evaluate trade-offs so they feel confident doing so independently once you're gone. So how do you do that?
00:23:39.919
First, always explain the why behind each decision you make. This applies to any kind of decision; for example, when deciding on the team's upcoming pair rotation schedule, explain how you considered PTO or balanced skill levels and unique strengths for specific upcoming features. If you have an early-career team member who excels in styling but wants to become more full-stack, consider pairing them with a senior engineer who has more back-end experience.
00:24:26.719
If your decision is technical in nature, explain the trade-offs in performance or timeline you considered before making your choice. Ensure your team understands the context behind decisions so they can incorporate that into future choices they may have to make without you. In relation to decision making and sharing context, make sure to show your process when deciding between possible solution architectures.
00:25:17.760
Share diagrams and the strategies you didn’t choose, along with the reasons why they didn’t align with the team's goals and constraints. If you create an estimate for an upcoming project, show the different roadmap iterations and explain how the priorities of stakeholders overlap with engineering priorities.
00:26:10.720
Finally, if you set team or organizational strategies and goals, be open with the team about where these come from—whether they’re revenue-based, customer experience-based, or supporting your hiring strategy. Communicate how they fit into the long-term vision and what the plan is to achieve these goals. Paint a comprehensive picture of the future so that your teammates feel connected and engaged with the company’s direction. And if you choose to leave, they won’t feel lost, as they’ll know the purpose and plan.
00:27:06.559
A major aspect within the context of supporting people is building team credibility and stakeholder trust. It can be tempting to take credit for good work, and we all enjoy recognition from stakeholders for our contributions. However, this can create dependence on you as an individual. As a consultant, I've experienced clients valuing my individual work highly and feeling that I was essential for project success.
00:27:59.520
While this is flattering, if I'm doing my job right, I enable the client’s team to be successful with or without my presence. I provide them with tools they may not have and help them solve problems so they can continue succeeding after I leave. If you're a senior engineer or in any leadership role, you should have a similar goal. When engaging with stakeholders, make sure to recognize other individuals on the team for their vital contributions.
00:29:04.080
Identify and acknowledge their strengths, so stakeholders know what each person excels at. Share credit; your position on the team grants you a level of trust and credibility from stakeholders. The best thing you can do is lend that credibility to your team members and help build trust so that when you leave, stakeholders won't feel the rug has been pulled out from under them—instead, they will feel assured that they are in good hands and that the team will continue delivering.
00:29:55.760
By doing this, you set your team up to make decisions confidently without being challenged by stakeholders since they'll already have confidence in the team, leading to a better experience for everyone.
00:30:14.840
Now, let's look at individual interventions that you can take in day-to-day processes on your team. One simple strategy is to start giving more detailed stand-up updates. I don’t mean that you should dominate the entire meeting, but your updates should be concise yet aimed at increasing awareness among team members about what you’re working on.
00:30:49.280
Instead of merely stating the ticket you're working on, describe what you've implemented so far, what challenges you've encountered, and what you've learned. Share the kinds of problems you're solving. The goal is to increase team context as much as possible, because in two weeks, if there's a bug in your code, someone might recall something you mentioned in your stand-up update that could guide them to a solution.
00:31:43.520
Politics refers to activities linked to decision-making in groups or those related to power dynamics, including the distribution of resources or status. Calendars are a straightforward way to share political information with your team—who's making decisions, who’s being consulted, what's being decided, and so forth. I coach all my team members and direct reports that one of the best ways to know what’s happening within a company is to monitor calendars.
00:32:41.440
Being aware of how leadership spends their time reveals a lot about the company’s state and its goals. As a senior team member, I encourage you to open up your calendars as much as possible. Keep your personal appointments private but make the rest public, urging teammates to check your calendar for updates or ask questions if they'd like to know more. By being open, you're enhancing your team's political awareness and creating a psychologically safe environment where they can ask questions and become better informed—well-informed teams are resilient teams.
00:33:38.559
It's also beneficial to increase visibility around how you spend your day. The more folks are aware of what you're doing, the better prepared they'll be for any changes or shifts in responsibilities if you leave. Greater awareness also allows team members to express interest in projects and possibly step up if they are keen.
00:34:31.920
The next few strategies are straightforward, but they are often overlooked until it's too late. Make sure that you are not the sole owner of any company accounts or tools. Use a password manager, such as 1Password, liberally to share passwords, ensuring you always use company email addresses so that if you leave unexpectedly, the team is not locked out of vital tools needed for their workflow.
00:35:35.840
Additionally, ensure that critical environment variables are documented within your password manager. That way, there is a reliable backup accessible to the team. This is especially important if your CI tool obscures environment variables after they are added. Your NVars shouldn’t be checked into source control anyway, so even if there’s no turnover and everyone stays on your team forever, this is still a good practice—it provides a source of truth in case everyone’s laptops fail one night.
00:36:35.040
Similarly, clean out your personal document files. If you’re using Google Drive, Dropbox, or any other file-sharing tool, keep files out of your personal folders as much as possible and store them in shared spaces that the entire team can access. This could include technical documentation, architecture diagrams, project requirement docs, or even less formal materials like past presentations you've conducted or team-building activities you've organized.
00:37:38.160
Also, aim to hold as many discussions in public Slack channels as possible. Include your team members in all emails with stakeholders; this way, there will be a searchable record of your decisions and conversations that could assist others stepping into your role after you leave.
00:38:36.480
You can also support your team after your departure by keeping all your tools up to date. What needs upkeep will vary based on your role and responsibilities—this could include your applicant tracking system, job postings, onboarding materials for new team members, performance management tools, incident response systems, project management tools like Jira, etc. The less your team has to stress about learning how to use or configure tools when you leave, the more successful they will be in continuing to deliver and achieving their goals.
00:39:51.440
For instance, if you keep job postings updated during your tenure—and if that’s part of your role—then they won’t have to struggle with figuring out what position is needed, how to write a job posting, or where to publish it. They can simply click 'publish' and get back to their work.
00:40:12.080
In connection with keeping your administrative tools current, enhance visibility into your administrative tasks so that your team is aware of how to handle those responsibilities. If there are non-technical yet vital tasks to the team's functioning—like conducting initial candidate phone screens, sending out stakeholder project updates, or, as mentioned earlier, checking PTO calendars for upcoming pair rotations—find someone interested in pairing or ride-alongs to show them what those tasks entail. Senior engineers usually handle administrative responsibilities that the rest of the team may not see, which means the team may lack awareness of how much effort these tasks require.
00:41:48.400
When you leave, they may be caught off guard by the time these responsibilities take, or they might not even realize they need to be done. If they are informed about these tasks, they can prepare for them, potentially even distributing responsibility. Candidate phone screens, for instance, are an excellent opportunity to share the responsibility, allowing everyone to contribute their perspective on hiring discussions and team culture.
00:42:47.839
Lastly, consider the necessity of a transition plan, which encompasses delivery, people, and process. Incompetent leaders will often unload your workload onto someone else without adequate support. Therefore, you can help your team by thoughtfully contemplating what the next steps should be if and when you decide to leave. Who is poised to fill your position? Who has expressed interest or is ready for that opportunity? Having conversations with them and their manager early can demonstrate that they are ready for a promotion.
00:43:55.600
What roles or positions should be opened up to backfill your role? Keep those job postings up to date as that responsibility unfolds. Are there any internal initiatives that you lead that you should share or pass on to someone else? Do you know of anyone who might want to analyze those initiatives? How can you involve them before you leave to ensure an easier transition? Additionally, if there is any valuable feedback you want to provide for someone’s upcoming performance review, which could assist them in seeking a promotion, discuss this with their manager.
00:44:52.560
Try to give that feedback while it’s still fresh or see if you can be involved in peer reviews.
00:45:43.079
Unfortunately, it remains taboo in most companies and teams to talk about wanting to leave a job. There’s an unequal power dynamic that makes many people hesitant to express that they are job hunting for fear it will jeopardize their roles before securing another position.
00:46:44.080
This mentality is beginning to shift, especially in tech, but it's far from obsolete. While you may not feel comfortable being open with everyone you work with, there are many low-friction, non-obvious ways to ease your transition off a team and out of a company.
00:47:31.840
If you dream of flying trapeze or swallowing swords under a big top, you can minimize the stress on the humans you care about through small, individual interventions. If you're content in your current role, you can still invest in your team's culture and improve resilience because turnover is a fact of life in the tech industry, regardless if you're leaving or someone else is.
00:48:25.720
A resilient team is always pleasant to work on, and if you are planning to leave, I wish you all the best in your job search. Thanks so much, and have a great RubyConf!
