Learn to improve, and improve by learning—constantly
The topic of mental health has been bubbling up in the tech sector for years now. Psychological safety is one of the big buzz words, and leaders have been eager for tips on preventing burnout and reducing work anxiety. These things matter both at the individual developer level and for the continuity and health of organizations as a whole. According to a survey by TELUS International, 80% of employees would consider quitting their current position for one that prioritized employees’ mental health.
Remote teams make the same considerations about individual well-being even more challenging. Work-from-home is inherently low-touch, which means leaders have fewer cues from which to assess their teams’ health. Remote employees are literally living in their office. Leaders need to be mindful of each engineer’s needs and be flexible in ways alien to a co-located environment.Here are some strategies for leaders who want to improve or create a digital environment that benefits their team members’—and thus the team’s—health and well-being.
SECTION Three
Transparency can take on different connotations, so let’s define it right here: Transparency in an engineering organization means that everyone on the team has access to all the same data, workflows, goals and context; that no relevant information is siloed or hidden; that mistakes made by developers and executives alike are public learning opportunities; and that everyone in a company has access to its strategic plan.
SECTION 3.1
Increase visibility
and understanding
Benefits of transparency in a WFH environment:
Plus, everyone can understand the reasons behind those decisions, particularly when they are tough or contentious ones. Asking teams to “disagree and commit” works much more smoothly when dissenters can see the reasons and the thinking behind a decision, rather than it being proclaimed from atop Mount Olympus. Particularly with remote and asynchronous communication, having all the relevant information openly available means no one is feeling left out of the decision-making process.
Teams can make better-informed decisions
Want to avoid scheduling yet another Zoom meeting around everyone’s flexible schedule? Transparent contextual information provides a guiding light to development teams. They can plow through work without having to bog themselves down in meetings to align themselves.
Working from home becomes more efficient
Developer disengagement is one of the common fears with remote teams; working from home, there is little to no physical connection with any company. A culture of transparency builds that sense of trust and connection. Hiding so-called negative information does the opposite. Mathilde Collin, CEO and cofounder of Front, recalls a previous employer that lacked transparency. “Instead of me being engaged with the good news, I was disengaged with the lack of trust,” she tells Fast Company. Employees, she says, engage more with the company when they understand why they’re doing the work they’re doing—and where the team and the company are headed.
Teams develop stronger engagement
Transparency sounds great in theory. If implementing it feels at all daunting or unclear, here are some actionable steps to integrate and boost it in a remote team’s dev process.
Building transparency into the development process
Transitioning to remote work requires teams to tackle varying amounts of upskilling and reskilling, depending on how an organization functioned before making the shift. As an example, if a team already worked in the cloud—great, that infrastructure is in place. If not, it’s time to add cloud migration tools and skills to the work-from-home kit.
Maintaining and upgrading the toolkit is always an essential component of effective development teams (as well as effective leadership). Continuous learning keeps developers engaged with new challenges, as well as deepening the knowledge and abilities of an engineering organization. Routine and constant education is just as essential for remote teams as any co-located one, and shifting to a work-from-home model may even necessitate specific additions and alterations.
SECTION 3.2
Keep the toolkit sharp
Signing up one of your engineers to some conference others are going to, or signing up the whole department for a class you enjoyed may be beneficial to a degree, but you could be missing opportunities if there’s no strategy to what career development you’re sanctioning. Technologists report wanting individualized skill development experiences that will move their careers forward in ways that are personally meaningful to them.Making upskilling personal is easier than you might think, and it pays off big time.
Developers want personalized opportunities for growth and learning.
Developers appear most interested in improving their skills in cloud computing, AI, IoT, machine learning and data analytics. Odds are, several of these would boost any engineering team’s capabilities, especially when fashioning new work-from-home processes.
Not every technology or skill will work for every team. That said, gauging employee interests is a great opportunity to evaluate how the technologies they want to learn could achieve the team’s goals in creative ways. Could upskilling on this new technology help the company achieve its goals more quickly? Could it open up new revenue opportunities or improve existing customer channels? Could it ease the transition to remote work? Giving employees the freedom to solve tough challenges in unexpected and innovative ways will pay ongoing dividends for the team—and their personal growth.
The things technologists want to learn are likely the same things that will boost the bottom line.
“As an organization, you have to agree on some fundamental principles that everybody buys into,” says Paul DePodesta, chief strategy officer for the Cleveland Browns. “This then helps you make your decisions, because it’s a shared vision for success that everyone, no matter their role, knows that if they execute on it, the team is ultimately going to be successful.”
Concrete goals build a shared vision
Trello’s Evan LePage offers a great strategy for reducing unintentional information silos. Team members and leaders alike can walk through their most important workflows and log each step in the chain. “Make note of every time work travels from one person to another, every time a tool is used and every feedback cycle,” Evan says. Then identify each link that is impacted by shifting to remote work, particularly those that used to rely on in-person communication or anywhere else information can slip through the cracks. Those are the highest-priority spots for conscientiously altering the team’s processes.
Audit workflows for links where data can get lost
Because the team doesn’t share a physical space, all communication needs to become more intentional—and available to everyone who needs it. Public communication channels are the gold standard here—public within the team, and in some cases within the whole company. Here are some recommendations:
• Store documents in a storage tool like
Drive or Dropbox, with public share settings.
• Communicate in writing whenever reasonable,
so anyone can refer back to it.
• Have conversations in public channels instead of
private chats—e.g., use a public Slack channel instead
of personal email or DMs.
• Store documents in a storage tool like Drive or
Dropbox, with public share settings.
• Communicate in writing whenever reasonable,
so anyone can refer back to it.
• Summarize voice and video chats in writing. It’s a great
chance to recap and clear up any miscommunications,
as well as chronicling the information for the entire
team. (An additional option: Record important voice
and video conversations and save them, with tags or at
least clear file names, in public folders.)
Use public channels to make everything accessible to everyone on the team
Doerr, the man who brought OKRs to Intel and Google, believes that an individual’s and a team’s OKRs should be open knowledge. “Companies should make this part of their DNA, their everyday culture and language,” he says. “OKRs, whether at the corporate level or the individual contributor level, should be visible throughout the company. New employees should receive formal training on the OKR system. That’s how we make the system successful and sustainable.” Seeing what an individual contributor and a team are working toward, updated in real time, supports remote workers’ autonomy and self-alignment with company goals.
Put OKRs in the public domain
Transparency sounds great in theory. If implementing it feels at all daunting or unclear, here are some actionable steps to integrate and boost it in a remote team’s dev process.
Building transparency into the development process
Transparency sounds great in theory. If implementing it feels at all daunting or unclear, here are some actionable steps to integrate and boost it in a remote team’s dev process.
Building transparency into the development process
Sharing data with a team—both performance metrics and outcome metrics—extends transparency from a team’s intentions and actions to its outcomes and results. Like all statistics, how the data is received matters as much as what the data shows, so here are actionable ways to incorporate live data transparency into a remote team environment.
Building transparency with meaningful data
Although developers are a data-savvy bunch, implementing performance metrics can feel to them like Big Brother is watching. Using data primarily to inspect or track a team leads to mistrust—the inverse of transparency. Instead, metrics used well are more like footprints than electrified guardrails; they show where a team has recently gone and offer a chance to learn more about a team’s strengths and support needs, rather than keeping the team in line.
Remember that data-driven coaching, particularly when first implemented, can be uncomfortable for team members. Piping up about that discomfort can be even more challenging for remote workers. As a leader, you can establish explicit parameters around how to use (and not use) metrics. Team members need to know how their leadership will act as stewards, rather than overlords, of their data. One-on-ones and team meetings are moments to see how the approach is resonating, so it can be tweaked as needed
Use metrics for learning, not for judgment.
Paul calls out the core trait of successful data professionals: humility. “A lot of experts in the field—when they’ve been around awhile—can start to think they know success when they see it, or automatically assume they know what’s happening. It’s hard to admit to ourselves as decision-makers that maybe we don’t actually know.”
Getting as many people as possible involved in data-driven decisions builds a collaborative atmosphere, where the entire team experiences the process of deriving conclusions from the available metrics in real-time. Since a remote team lacks in-person camaraderie-building moments, this creates a collective experience for them. Plus, this diversity of thought drives insights that one leader’s personal assumptions and biases will miss.
Test assumptions and biases with a diversity of thought
In other words: show the team the whole game instead of giving them just the final score. This way, they can derive collective conclusions about what the metrics say, empowering and involving them in the learning process. To that end, leaders can be one of the last ones on the team to offer their insights. Sharing the data also builds transparency in and of itself.
Make the data itself public—not just the conclusions from it.
Particularly in organizations where upper leadership is inexperienced with or leery about work-from-home teams, data provides a particularly powerful communication tool. Presenting the right data-driven conclusions offers a company’s leaders both context and clear language to understand a team’s progress and needs. Tech leaders are uniquely suited to translate metrics into stories that non-technical people can digest and appreciate, thereby allowing them to advocate and protect their remote development teams.
Manage up by telling the team’s story with data.
Considering that leaders of remote tech teams already have to dedicate extra diligence to employee engagement, this result from our State of upskilling report stands out: although 94% of technologists report that their companies provide some opportunities to develop their technology skills, about 45% say they’re leaving their job because they were concerned about a lack of opportunities for advancement and 36% left because they wanted more challenging work.
Developers want the challenge of learning, yet there’s a disconnect between what employees want to learn and the opportunities their employers offer them. As a result, companies and their technologists are missing out on big possibilities for growth.
There is no one-size-fits-all approach to training and upskilling your team, but there are practical ways to make a real difference for the individuals on your team:
Upskilling and continuous learning
Skills development is no longer limited to traditional methods. With online course libraries led by subject-matter experts, developers can take charge of their own skill development experience at a pace and method that works best for them. That kind of ownership is hard to duplicate in a classroom or a conference setting without bogging down the experience for everyone. Plus, it offers precisely the kind of flexibility and autonomy that leaders and developers alike want to cultivate in the work-from-home environment.
Effective learning opportunities come in versatile forms.
It’s the most efficient way to both raise the collective value of a workforce and keep individual employees satisfied with their career trajectory within the company so they don’t start looking elsewhere. Tech skill development platforms also come in the format employees want: the overwhelming majority of technologists report that their preferred learning method involves online self-paced and instructor-led courses.
Find a tech skills development platform that offers built-in assessments. Technologists want a platform that can be personalized to what they need and that’s taught by experts, and leaders want the upskilling investment to make an impact on the business as soon as possible. That’s where skill- and role-based assessments come in. They’ll provide insight into your organization’s collective knowledge base and give engineers insight into what they don’t yet know. From there, it’ll connect developers to specific classes taught by leading experts, continuing to evaluate their knowledge gaps as they progress. When assessments like these are built into technology skill development platforms, they provide the fastest route to upskilling, saving you and your engineers from wasting resources on the wrong material.
Seeking out online technology skill development platforms that offer these capabilities will save an organization time and money.
While some developers can learn well from YouTube videos or Reddit threads, content-specific certifications matter. This is particularly true in a remote-work environment where team members may be expected to operate with heightened levels of autonomy, and where help requests may be asynchronous. In short: If developers are touching data or apps, they need validated skills.
Get the team certified in what they do (or want to do)
Common types of certifications from major providers tend to expect and promote similar skill sets, such as problem-solving within a certain application or domain. Solutions architects, for example, are all tested on best practices when designing and migrating applications and data to the cloud, estimating costs and using cost control mechanisms, and selecting the right cloud solutions for different scenarios.
When team members achieve that certification, the organization understands their knowledge base and their role can embrace that area. And if an engineering org is hiring to augment or scale its teams, that certification verifies where potential hires can hit the ground running.
Certified skills bring clarity to remote work roles and confidence in hiring
Pure self-guided learning is valuable and has its place. But certifications provide a standardized way for a team to ensure that it’s acquiring the range and precision of skills it needs.
The skills measured in certification exams are tied to real-world risks and challenges. The exams are generally designed with input from product managers, support staff, architects, technical content developers and veteran trainers. And the courses are modified and improved constantly based on feedback and results from course participants. Certification thus helps ensure that developers are skilled on the right things at the right time.
Industry-set standards enable teams to validate and improve skills
Certification can be proactive just as easily as reactive. Of course, a gap in current skills requires education, and certification programs can fill those knowledge gaps. But leaders especially need to have a vision of the team’s roadmap in relation to company strategy, foreseeing such needs as reinforcing certain skills or adapting new technologies for the transition to remote work.
Teams can certify skills needed in the moment, or prepare for impending change.
Here’s why certification matters:
Remote work is a process, not a conclusion.
The COVID-19 pandemic forced many organizations into a WFH model for the first time. The ones with existing remote components had to put everyone in that same boat, and even fully remote teams had to contend with new stresses in their daily operations. One way or another, most all of us had to scramble.
But what you did after that—and what you do now—defines success within your new reality. You can either continue reacting to global circumstances, itching to get back to the way things were, or make the decision to fold remote work into our best practices in a way that enhances our individual organizations. Whether your new reality is a permanent transition to WFH, integrating WFH into our co-located environment or building versatility for the next time global circumstances require us to pivot: when we become active players in the choice to adapt, we position ourselves to triumph.
This section is for those leaders looking to build WFH into their long-term strategies. Remote work is always in flux, and teams looking to strengthen themselves in that direction need to improve continuously. It’s time to revise the approach to amplify your successes. And you can do that by leveling up the cumulative and interwoven ideas in this guide directly within the development process.
SECTION 3.3
Audit and edit the approach to WFH
Transparency sounds great in theory. If implementing it feels at all daunting or unclear, here are some actionable steps to integrate and boost it in a remote team’s dev process.
Building transparency into the development process
This guide, of course, focuses on developing a sound process and culture for working from home. But the progressive nature of software development doesn’t go into stasis mode while a team learns how to work remotely. Teams need to keep improving the dev process in order to make any WFH model truly successful.
The inclination with too many WFH transitions is to add layers to development—as if working remotely is itself an extra step in the dev process. Or to add extra safeguards—as if WFH is a liability that needs to be protected against. Those are simply not the case.
It is true, though, that remote work stresses certain considerations in the dev process.
These are examples of common points of inefficiency or drag in any development process—ones that are easily magnified by working remotely—and steps to remediate them.For more information about auditing the team’s workflow for transparency and assessing the links where information could get lost, check out Section 3.1, on increasing visibility
Keep the dev process flowing to keep WFH working
We’ve all heard about maker time vs. manager time. Creative professionals need large, uninterrupted blocks of time to hit their flow state, where many leaders operate in 30- or 60-minute blocks, switching tasks according to the clock. Yet we still buy into the myth that humans, including software developers, can multitask.
They can’t.
Too many of us, engineers and leaders alike, fall into the trap that WFH means “always available.” This attitude short-circuits flow efficiency, which is what the dev process should be optimized for. Yet leaders too often optimize remote teams for resource efficiency instead.Here’s why that difference matters: Flow efficiency is the ratio between active time and total time on a task. If developers have four days to build a feature, their workload according to resource efficiency could suggest they’re tapped out. But, if they need only one day of focused work to complete it, that equates to flow efficiency of 25%.Resource efficiency puts more focus on doing more things at once. But in development, the goal should be to optimize the speed of the task. Focusing on flow efficiency still keeps a team busy, but they’re able to focus on completing one task at a time at a natural cadence.
Optimize new tickets for flow efficiency
The ability to achieve this results from smart upskilling, as explored in Section 3.2: Keeping the toolkit sharp. When one team member has a backlog of work, exacerbated by other team members pointing more work their way, this may be due to that person’s domain expertise. Not only is the workflow stagnating (through no fault of that one developer), the team will not be ready if that team member wins the lottery and makes a rapid exit.
Knowledge silos may occur more easily with remote work because physical isolation may result in expertise isolation as well. Cross-training other team members and manually assigning this critical work to multiple hands eases bottlenecks and makes the team more resilient. The domain experts on the team may even be able to train their peers, multiplying the impact of their expertise.
Cross-train the team to distribute the work as needed
Here’s how to avoid a work-from-home trap: Flexible schedules—a perk and, really, a necessity for remote work—do not equate to flexible contribution schedules.
Large pull requests, particularly at the end of sprints, rush the team’s review process. Furthermore, the code is likely to contain more errors that would have been spotted and fixed earlier if the pull request had come in smaller, more frequent commits.
Whatever each individual developer’s schedule looks like, the team culture will thrive when it encourages incremental progress and delivering continuous improvements via pull requests at regular, short intervals—think multiple times a day, multiple days a week, however each developer builds those days.
You can encourage this environment by setting explicit expectations, and also by working individually with engineers who tend to hoard code (intentionally or not) for days at a time before dropping larger, more infrequent batches. They may not realize the benefits of receiving regular reviews from their teammates.
Establish a cadence of frequent, small commits.
Solution disconnect will waste a development team’s time and efforts, creating answers that don’t quite match the problem. It happens when an initial ticket is vague or unspecific, and teams will experience high churn, lots of jitter and excessive back-and-forth between the developers and the original ticket submitter. The lack of coffee-break conversation in remote work can exacerbate this problem, because remote workers can’t clarify requirements and expectations quite as casually as co-located teams can.
This is an arena where you can multiply value more than they ever, by digging into the code and PR tickets yourself. This will give you a sense for what’s being built and how your team is communicating, so you can be their sword or shield to help them get things done. For more information on being their sword and shield, check out Section 1.2 on psychological safety.
To be effective, development teams need clearly described outcomes. The more concrete the objective or user story, the less potential for churn. For example, a ticket that says, “Fix the button on the landing page” will result in more churn than a user story that says, “The landing page button does not change when hovered over. Please have it transition from blue to green.”
Developers working from home may not have the personal relationship with the requestor that would allow them to jump on a quick call and clarify the requirements. Nor is that a developer’s job—at most, they should need to ping unclear requests as part of a clear ticketing process so that leaders can tackle the communication needed to clarify them, saving their team untold time and productivity.
Clarify non-specific requirements
TL/DR: Iterate, iterate, iterate
To survive the transition to WFH, a team doesn’t have to get it right right away. It just has to keep getting better.
Iterations in transitioning a team or an organization to remote work is really a lot like deploying code: frequent small adjustments and efforts work better than massive infrequent changes.
True, a tech team leader may not deploy dozens of changes a week. But humans resist big change. Iterative adjustments as you go will help the entire team adapt to this new realm—and your own leadership style will adjust the same way.
We all know that the companies with the biggest teams or the biggest budgets aren’t necessarily the ones most likely to succeed. The ones that will thrive during a global pandemic and survive whatever other forces necessitate the next big pivot are the ones who establish an ability to iterate quickly, a strength of resiliency, and an endurance to tolerate short-term growing pains for long-term creative gains.
Change is constant. We all tell our teams, one way or another, that the speed of execution is more important to product and organizational growth than perfect execution. The same attitude will distinguish the most successful remote work teams, as well.
Talk to us about starting a pilot.
sales@pluralsight.com
1.888.368.1240 | 1.801.784.9007
Introduction
section One
section two
section Three
Introduction
section One
section two
section Three