devopsy.kinsta.cloud

Tag: employee burnout

  • How to Build Healthy Engineering Teams

    How to Build Healthy Engineering Teams

    A common challenge today for engineering teams is the increasing complexity of their jobs and figuring out how to make it both productive and enjoyable without burning out.

    Over the last 10 years, the role of a software engineer has evolved drastically. Software continues to reach unprecedented scale, it is becoming more complex and customer expectations are higher than ever. Organizations from all industries are now becoming software companies and, with the pandemic, everyone is feeling the effects of burnout.

    There are close to a million unfilled IT jobs in the United States. To ensure organizations are able to continue innovating, the industry needs the tools, state of mind and reliable practices to make this career sustainable.

    Creating an industry with healthy productivity is paramount. But too much of a focus on going faster without addressing burnout is a recipe for disaster. Engineering managers need to constantly balance both. Here are some things they should keep in mind:

    Invest in Engineering Productivity

    Companies are increasingly hiring for roles focused on engineering productivity—there are currently hundreds of open job postings from organizations looking for these skills. These jobs are aimed at making developers and engineers’ lives and work easier by focusing on streamlining how things are done within the engineering organization—including improving developer workflow processes, execution efficiency and product quality. They are often responsible for building internal tools that support cross-functional and developer workflows. Even with a relatively small engineering team, organizations can start thinking about bringing on a team member dedicated to making engineers’ roles within the company easier.

    Focusing on Healthy Productivity

    Productivity is, and will always be, extremely important, but potential burnout should also be seriously considered in the process. Remote work during the quarantine and the pandemic has brought this front and center. When people don’t have enough deep work time, they often work longer hours which can eventually lead to burnout. An average employee has 11 minutes to focus between distractions at work and then, after an interruption, it can take around 23 minutes to return to the original task. In addition, the average worker attends 15 meetings per week.

    There are many questions about how workers’ productivity has been impacted since early 2020, and research has found that developer productivity isn’t a problem—but burnout is. From March to December 2020 the study found:

    • Deep work time—a two-hour period of uninterrupted work—decreased by 22% between March and December 2020.
    • Average time in meetings went up by 67% from March to December 2020.
    • Pre-pandemic, 10% of developers were showing “always-on” behaviors at work, but that percentage went up to 15% and then to 20% by the end of the year.

    Focusing on driving healthy productivity—where developers are productive but not overworked—is key to keeping your employees.

    Strengthening Engineering Managers

    Managers play a key role in keeping engineering burnout in check. Ensuring that managers ‘manage well’ is not a new idea, but today there are particular complexities that make the engineering manager role both uniquely challenging and especially important.

    It is now widely acknowledged that culture is a considerable part of what gets employees to stick around. But culture isn’t only employee benefits like trendy offices, great snacks and other relatively superficial—though still important—benefits. What really matters is identifying and building teams that really care about one another on a personal level and making sure that incoming employees feel the same.

    With engineering teams, there is a tendency to focus primarily on the technology being created rather than the people who are creating it. While this approach can absolutely result in successful products, it is often the default management style for managers who don’t have the tools to do otherwise. Moving from software engineer to manager requires a whole new skill set that involves different communication styles, time management, organization, tools and software, scoping work, learning how to effectively delegate and identifying the right people to complete the team.

    As challenges continue to evolve, organizations need to ensure that engineering managers are able to support each individual on their team. It is so important to make sure that people feel aligned with a mission they care about and that their career interests and goals are being met. Not all of those can be measured with data, so managers have an all-important role in keeping up with the pulse of the team.

    Building Helpful Tools and Growing Developer Communities

    In the last decade, the speed of innovation in enterprise technology has skyrocketed and the amount of code and tools developers need to master has increased. At the same time, the number of unfilled job openings continues to grow. There are a lot of great trends that are helping to close this gap including low-code and no-code tools as well as a massive increase in community resources.

    No-code/low-code tools: As both technical and non-technical organizations hire an increasing number of developers, low-code and no-code have become more prevalent. With frameworks that allow even those without a technical background to deploy software, no-code tools open development capabilities to an increasingly diverse subset of people. While these tools will not replace developers, they will make it possible for more people to enter the field of software development and help companies continue to innovate.

    Developer community: The amount of resources available to new and existing developers has also skyrocketed in the last several years from open source communities to Stack Overflow to the ability to simply Google how to do something in code. The Linux Foundation’s extensive training catalog is one example; even Medium has a wealth of basic technical info, how-tos and deep dives available. If you’re looking to adopt a new tool, one of your main priorities should be to look at the size of the community so that you can easily troubleshoot problems if they arise. Having access to resources from community members that have gone through the exact same problems you encounter is priceless.

    The above are all just a start. Teams can go even further by finding and adopting analytics tools to dive deeper into specific productivity metrics. These can give managers and executive teams the hard data they need to make educated decisions that will help them keep their teams and drive innovation. It is worth investing the time and the tools to maintain your engineering resources. By doing these things, organizations can reach and maintain healthy productivity.

  • COVID-19, Digital Transformation and Teams: Q&A With Red Hat’s Kevin Behr

    COVID-19, Digital Transformation and Teams: Q&A With Red Hat’s Kevin Behr

    Even prior to the novel coronavirus pandemic, enterprise teams found themselves strained as they pressed to move digital transformation goals from whiteboard to reality. Then along came the big push to work from home and many transformations that were planned to occur years from now were put into action. So how are enterprise teams faring in their mission? There are a lot of claims of success, yet surveys continue to show many, if not most, enterprises fall short.

    To get a sense of the impact this is having on staff, and gain insights into what they could be doing better, we reached out to Kevin Behr, global senior director, global transformation office at Red Hat. Kevin is also the chief scientific officer at PraxisFlow and the founder of the Information Technology Process Institute (ITPI), and a co-author of “The Phoenix Project” and “The Visible Ops Handbook.”

    DevOps.com: Has the push this year, largely driven in response to the novel coronavirus, for organizations to rapidly “digitally transform” themselves had a substantial impact on staff and teams?

    Kevin Behr: Yes, and one of the things that can be depressing is that management does not always understand how to manage during times of change and adapt their ways of working within the new economy. They are behind. Way behind.

    Kevin Behr

    And they think they can cost cut their way to success. During many transformations, they will try to cut the cost of their infrastructure to pay for the transformation. And they basically gaslight everybody in the organization that has to operate. It means management essentially just gave operations teams more things to do, more quickly, while deferring many of their priorities that, in all likelihood, contribute to reliability. And then management tells them that they’re going to have to cut costs in operations because there will be more things they have to do and manage.

    Makes perfect sense, right? Of course not. Anyone who understands change theory understands that there is always a hump to get over when one changes behaviors. And that’s the other problem: When a transformation does not result in behavior change it burns people out.

    Finally, many times people are saying one thing about the success of the digital transformation in public while they know the automation is just a series of Mechanical Turks and scripts executed between swivel chairs.

    DevOps.com: How do such organizations allow themselves to grow so dysfunctional?

    Behr: A lot of that has been by leadership not framing their efforts correctly. I think that really burns people up because they get put into efforts, especially in operations, efforts that they know have no chance of succeeding—but they can’t ever say that because the organization only embraces happy talk. But it’s toxic happy talk and “toxic positivity” everywhere. And I think toxic positivity endlessly burns people out, especially when it reaches the point where one can’t actually say anything against it because they’re just viewed as being inherently negative.

    People get disillusioned and competent people just sink. And then there are organizations with so-called meritocracies. Meritocracies can be unfair because it’s the privileged who decide what has merit. The key is who decides where merit resides. I think sometimes in a meritocracy, there can be a continual skewing of merit to the same people or to the same ideas and others begin to believe that they don’t fit and feel marginalized. And, when combined with toxic positivity, the organization becomes something people just can’t crack through. It is impenetrable.

    This also happens at places that are, in theory, top-down. When you watch who decides has merit, it doesn’t have to be a hierarchical top, sometimes it’s influencers.

    That just becomes impossible for people to manage their way through. They have to plan to influence a ton of people in the organization just so they have a shot at making something sane happen. They conclude it’d be easier to get another job.

    I think it’s that combination of such organizational stupidity and the opportunities in the job market that give people more choices. I’ve just been blown away by how many smart companies are picking up talent during COVID right now and watching all the career changes happen with great people in our industry. People getting better lives.

    So, when you’re an organization that doesn’t allow you to improve your own value, let alone improve anything in your organization, that’s a no-no. It’s a lose-lose, and people leave.

    DevOps.com: What impact do you think this has on enterprise transformations?

    Behr: I think company actions speak louder than words. And I think a lot of these actions are very hurtful to people in technology, especially those who work in infrastructure operations. Operations is just under the scalpel’s blade all the time. And I think it’s blown up most of our transformations.

    There are a lot of problems with transformations, generally. One of the areas is how we love to talk about all the happy talk about the future and serverless and all of the pizza box teams and product line orientation versus project orientation, and all of this stuff that they’re actually just distracting themselves with.

    Yet, the failures come down to the fact that organizations just don’t do what they say they do and people get hurt. And reality catches up to them: that teams actually need to support all of this transformation so that they can literally run the applications and resources. Eventually, organizations have to literally deal with the fact that all they have to operate the infrastructure that actually runs all of the business and systems of record. And they realize that, despite all of the happy talk, much of the transformation was really playing around the periphery.

    I think organizations may get this right over the long term. But they have to learn the lessons from what they are experiencing now. I don’t think employers understand it well enough, yet. I think they have an understanding regarding the talent problems they have. But they don’t get that the way they solve their talent problems isn’t through hiring. Long term they have to invest in their people, and they need to learn this lesson.