devopsy.kinsta.cloud

Tag: engagement

  • The Metrics Disconnect Between Developers and IT Leaders

    The Metrics Disconnect Between Developers and IT Leaders

    A survey of 350 software developers found a majority (91%) of respondents are unhappy with the actual metrics leadership teams are measuring.

    The survey, conducted by Atomik Research on behalf of Uplevel, an enterprise intelligence platform provider, found the top metrics developers say should be tracked include hours worked (52%), work allocation (49%) and the amount of time they have to focus on writing code (46%).

    Unfortunately, the survey also revealed more than half of respondents (56%) reported that the CTOs that lead software development efforts make significant strategic decisions without realizing the negative impact on their team. They also often move people around on projects or tasks without knowing the full implications (51%) and overwork developers (44%).

    Just under a third (30%) noted their engineering leaders rely solely on gut feelings to measure the effectiveness of their teams, while a third of respondents observed most engineering roadblocks go unnoticed by leadership.

    Additionally, 96% noted that not knowing what their own leadership team is working on is detrimental to the larger team.

    Christina Forney, vice president of product management for Uplevel, said many CTOs clearly need to be more engaged. Developers don’t mind being measured, but they clearly want to be evaluated based on metrics that matter, she added.

    Managing software development teams has become a lot more challenging in an era where many developers are working remotely. IT leaders can no longer manage by walking around as easily as they once did, said Forney. Aligning workflows across a highly distributed team of developers is a challenge no matter how many communications platforms are used.

    Surprisingly, the Uplevel survey found more than half of respondents (54%) said they feel more productive in the office. More than a third (35%) also said they preferred some form of synchronous communication to engage with other members of their team versus 27% that preferred some form of asynchronous communication. A total of 38% said they preferred a mix.

    It’s no secret that despite long-standing commitments to automation, there are still a lot of manual processes in DevOps workflows that create bottlenecks. In an uncertain economy, however, there’s a lot more focus on developer productivity, so eliminating DevOps bottlenecks has become a major priority. The challenge is those bottlenecks are not as apparent to senior IT leaders, many of whom may have simply become inured to them over time.

    Regardless of how bottlenecks occurred, DevOps teams would be well-advised to reevaluate the metrics they track. Mean-time-to-recovery (MTTR), for example, is not as important a metric to the business as the amount of quality code that finds its way into a production environment.

    In theory, all the data required to track more meaningful metrics that could improve productivity already exists in the tools and platforms DevOps teams use to build and deploy an application. The challenge has been finding a way to automatically surface that data without adding yet another bottleneck to a DevOps workflow.

  • Are you Being ‘Nice’ to Your Developers? Think Again

    Are you Being ‘Nice’ to Your Developers? Think Again

    As a developer, you’ve learned your craft. From your fingers comes the magic that builds the applications that run the world. You can literally create something from nothing! And not just software programs. You can create value that means revenue for your company. You’re a revenue machine — no, you’re a god, creating anything that’s needed! That is, you could be if you could spend all of your time writing that magical code. But this dream is not so simple. If you’re like most developers, you’re spending way too much time on other things, such as:
    ● Meetings
    ● Dealing with interruptions
    ● Security hassles
    ● Operations
    ● Debugging
    ● Fighting with infrastructure
    ● Burnout

    Every minute you’re dealing with any of those, you’re not making magic. Because you’re human, that is going to make you unhappy.

    If you really are a developer and not just imagining you are, you already know all of this. Now let’s turn our attention to those of you who are responsible for developers. Because it’s your job to make them happy.

    Yes, it is, if you want them to keep working productively for you and add value. Luckily, it’s within your reach to do so. It will benefit you, add value to the organization and, most importantly of all, the employees themselves.

    Simply put: If you want to get value from your developers, you have to be nice to them. If you expect them to pour themselves into you and into the company, you must first prioritize them and invest in them. Success can only be realized and achieved by a happy balance of developers who are motivated to create.

    Do you know who feels more motivated than anyone else? Who will always go above and beyond?

    Those who are appreciated.

    So let’s get started.

    Increased Productivity and Value

    The most obvious issue is productivity. The reality is that software development can be an arduous mental task, and when developers are unhappy, it will inevitably affect their productivity—especially when they spend mental cycles on things that are not directly related to the task at hand.

    Even if they’re not spending work time searching for another job (or quiet quitting), they’re probably thinking about what could be different and mentally grumbling about it every time something comes up that irritates them.

    By treating developers well and eliminating those annoyances as much as possible, you prevent that problem and get 100% of their attention.

    And there are other productivity benefits, as well. When developers trust their company and their co-workers, it fosters greater collaboration between those developers and business stakeholders. It also engenders greater creativity, which can lead to innovation and value above and beyond what you are expecting them to deliver.

    Retention

    The most obvious issue when it comes to developer happiness is, of course, retention. After all, if you’re not nice to your developers, you should expect them to leave for other jobs. If the Great Resignation taught us anything, it’s that it is human nature to move along if dissatisfied.

    That may not seem like a big deal to you, but think about the implications if your developers are leaving in droves. Never mind the turnover costs, what about the inevitable delays as you bring new developers up to speed? Hiring and training are arduous, time-consuming endeavors. And if turnover is bad enough, you may never be able to actually complete anything because nobody ever gets a chance to build up a good head of steam.

    Compare this to a company with a dedicated team of happy developers who are motivated to grow and innovate for themselves, their team and your organization.

    Which organization do you think is going to come out on top? Yes—the organization with the happier team of developers is probably going to have a competitive advantage—and a big one!

    When developers are happy, they are likely to be loyal to your company. That loyalty means they stay long enough to become experts in what you do, making them more likely to create the kinds of innovations that move the company forward for added value.

    But most of all, can you really afford to have your best employees leave and take all of the knowledge they’ve gained with them, potentially to a competitor? Probably not.

    Maintaining a Good Reputation

    All of this adds up to reputation; get a bad reputation in the developer world and it is going to be hard for you to attract top talent. In a world where technology changes so fast, it’s already difficult to find developers who have stayed with one technology long enough to become experts. You need to take advantage of every tool you can to make it easier. Your reputation can be one of them—if you treat your developers right.

    But there’s another reason to protect your reputation among developers: It could easily bleed over to your reputation among your customers. If you’re a big company, word of your treatment of developers may spread. If you’re not so big, and you have enough developer turnover, some of your former employees may work for prospective customers or know someone who does.

    Today, customers are trying to be socially responsible by buying from companies that ‘do the right thing.’

    Without much effort, you can be one of those companies by trying to foster developer happiness. Ultimately, it’s not that difficult.

    How to be Nice to Your Developers

    Fostering developer happiness doesn’t have to be a hugely expensive proposition. It’s not always about huge paychecks (though they do help smooth out some rough edges). Some things you can do to be nice to your developers include the following.

    1. Provide what they need: Developers should be able to spend as much of their time as possible actually coding; make sure they have the tools that they need so that they’re not having to improvise or struggle with creating infrastructure. For example, engaging a ZeroOps partner can take some of this off their plates.

    2. Eliminate distractions: Even in ideal situations, it can take as long as 20 minutes for a developer to get back into their train of thought every time they’re interrupted. Try to provide an environment with as few distractions as possible.

    3. Foster a training-centric culture: Developers need to feel as though you have their best interests at heart, and one way to do that is to help them learn new skills. And there are multiple benefits for you: For one, it’s much easier to train your existing people in an in-demand technology (such as Kubernetes) than it is to hire someone who already has those skills. For another, training your entire team in these new technologies can unlock creative ways of solving problems.

    4. Help developers understand how their work relates to the customer: While it can be tempting to expect developers to simply do what you ask them to, when they understand why they’re doing it, they’re much more likely to feel invested in the work.

    5. Listen to ideas: Your developers are at the heart of what you’re trying to do. It’s very possible that they have a new way of doing something or an idea for something that could help your company. Even if you don’t end up going forward with the idea, your developers need to know that you respect them enough to listen.

    6. Respect work-life balance: Developers have a reputation for working long hours and many even take pride in it. But it’s not always the most efficient way to get things done. A tired developer works more slowly and makes more mistakes. Be flexible and make sure that you’re not overloading your people with more than they can reasonably accomplish. If your developers have to work 70, 80 or 100 hours a week to meet deadlines, you either need to hire more people (if you can find them) or find a way to partner with other organizations to take things off their plate. (See number one).

    All of these things make for a positive work environment that enables your developers to work their magic for you, day in and day out, making something from nothing and moving you forward the way nobody else can.

  • How To Keep Engineers Happy and Reduce Burnout

    How To Keep Engineers Happy and Reduce Burnout

    Software development can be a mentally taxing profession. It requires intense mental focus, often under heavy workloads, with unclear job expectations and a lack of control. And with recent labor shortages due to layoffs and resignations, teams may also be understaffed, making matters more complicated. These issues can compound and lead to prolonged excessive stress—that’s when burnout hits.

    In fact, one report found that 82% of developers surveyed indicated that they had experienced burnout in the last six to eight months. Some top causes of burnout include increased workload, a poor work culture and personal reasons. But whatever the cause, for 73% of these developers, burnout is negatively impacting their productivity or personal life. So, what can leaders do about it?

    I recently talked with Randall Degges, head of developer relations at developer security company Snyk, to learn how to address ever-present burnout issues in software development teams at scale. Snyk, which provides popular automated vulnerability detection tools, recently closed a staggering $196.5 million series G funding at a $7.4 billion valuation. With that kind of momentum, they must be doing something right. According to Degges, there are a handful of tactics to consider to prevent burnout, like ensuring developers are heard, not assigning tasks without context and making improvements to the DevOps workflow.

    Understanding Burnout

    Burnout is an ever-present issue, explained Degges. It’s common within any high-stress job where you’re on the hook for constantly delivering new features to support the business. Specifically, in software development, burnout can quickly arise when developers don’t feel they have a voice. Or worse, when they’re tirelessly producing software they know won’t ever see the light of day.

    A paper entitled Burnout in software engineering: A systematic mapping study took an interesting systematic approach and analyzed decades of research into burnout in software engineering. It found the following qualitative work-related factors to be most correlated with burnout. (Interestingly, the paper suggested machine learning might soon help produce more quantitative indicators of burnout.)

    causes of burnout diagram
    Causal-relationship of burnout, taken from ‘Burnout in software engineering: A systematic mapping study.’ (Deciphering this diagram gives me burnout!)

    7 Ways to Fight Burnout

    Since we know burnout is a pervasive problem, how can engineering leaders minimize the issue? Below, we’ll outline some specific strategies to consider and how they might help.

    1. Give Developers a Voice

    First, Degges encouraged leaders to ensure developers have a say in what they’re building. He recalled working within a large enterprise, sitting in a cubicle and having absolutely no say in the features his team was working on. This often included code they all knew would never make it into production.

    Slaving away on irrelevant work is never motivating. Instead, a good internal culture provides a comfortable atmosphere where developers can raise issues early on, said Degges, hopefully before leadership puts targets destined to fail on the roadmap.

    2. Provide More Context

    On that note, when decisions are made, don’t throw orders over the wall in a vacuum. Instead, Degges recommended providing more context into what you’re all creating. Giving visibility into the reason behind decisions will align everyone on project roadmaps and create a shared purpose. This helps foster a culture of empathy and listening to others, said Degges. (David Shackelford affectionally calls this attitude HugOps.)

    3. Optimize Communication Patterns

    Optimizing communication patterns for your working environment is also vital to encourage a healthy culture, said Degges. For example, this could equate to optimizing for the physical reality of distributed teams—no one should have to clock into daily standup at 4:00 a.m. If you are working under timezone constraints, Degges recommended adopting more asynchronous communication.

    For instance, his team relies heavily on Slack and provides dedicated channels for sharing ideas. They’ve also incorporated automation to summarize verbose Slack communications with a recap of conversations. In general, removing unnecessary meetings and optimizing communication patterns could greatly reduce the baggage an engineer might carry in their day-to-day work.

    4. Practice Internal Developer Relations

    As they say, practice what you preach. Many tech-driven companies have adopted a developer relations (DevRel) division to build a community with external developer consumers. But are you practicing DevRel internally? According to Degges, DevRel teams should act as a bridge between external and internal teams.

    “Our goal is to not only to think and empathize with customers but also to encourage internal people to be authentic community members themselves,” said Degges. This can equate to empowering internal employees with resources like mentoring, blog writing or speaking opportunities, he said.

    Additionally, other groups are emerging to help increase internal developer satisfaction. For example, platform engineering and developer productivity engineering (DPE) are being applied by many organizations to improve developer experience around internal tools and processes. Naturally, this will require working closely with internal developers to source feedback and make quality improvements.

    Another method to upkeep engineering morale is through automating away toil. And security vulnerability discovery is one area full of painstaking manual tasks. Half of applications have high-risk vulnerabilities, and new exploits in open source libraries are being discovered almost daily.

    As more software supply chain risks emerge, it’s challenging to keep up with the pace of vulnerability discovery and necessary software patching. Therefore, implementing real-time automated vulnerability detection, said Degges, can help remove many manual processes and free up energy to devote to other areas.

    6. Hire Based on the Work, Not the Interview

    Before developers even get the job, they can be put through high-stress on-the-spot tests during the interview process. Experiences here can set the tone for the entire engagement with the company. But activities like white-boarding algorithms are pretty disconnected from day-to-day work, said Degges. In his opinion, engineers should instead be hired based on the quality of their past performances and the work they’ve produced. This could be artifacts like their personal blog or contributions to open source projects.

    7. Apply Artificial Intelligence (AI)

    Lastly, what’s a tech blog post in 2023 without a mention of AI? Generative AI like ChatGPT has rocked the programming world and is being integrated into more development environments and engineering workflows. The future of AI looks very bright and is poised to help developers produce more with less time and resources.

    Of course, automated code generation will require sanity checks, but these tools can certainly help many ancillary functions. For example, Degges’ team is using ChatGPT to spin up content outlines and automate keyword research, helping support their educational content production.

    Soothing the Burnout

    Even with new tools emerging and a newfound emphasis on developer experience, burnout is still prevalent. A full 58% of developers and security professionals said they are currently experiencing burnout, according to a 2022 Cobalt study. This is, perhaps, due to the rapid release cadences of today’s software delivery.

    “In the past, it took months or years for new software updates to roll out. Now, developers only have a matter of weeks,” wrote Bill Mann, CEO of Styra, on Forbes. “Suffice it to say the stakes are high for today’s software teams.”

    Burnout is psychologically taxing and can negatively affect employee happiness and retention. Therefore, it’s an excellent idea for engineering leaders to take it seriously and consider what positive cultural changes they can make.

  • 8 Reasons Why DevOps Needs Competent Writing Skills

    8 Reasons Why DevOps Needs Competent Writing Skills

    It’s a fact: DevOps practitioners need to have competent writing skills to help them in their career. It may seem a little antithetic—after all, software engineers and programmers are well-known to be the kind of people whose brains are wired toward math, not English. Written communication may not be an area of strength for people who spend their days looking at code; however, it could set someone on the path to success.

    Here are eight reasons that highlight exactly why DevOps practitioners should work on their writing skills to advance in your career.

    There Are Similarities Between Writing and Code

    This may not be immediately apparent, as most English students would pale at the thought of writing code and most computer science students would cringe at the thought of producing an essay. However, writing and coding are very similar in the sense that they both require a clear mind, have a set beginning, middle and end, and normally address a problem. Plus, as writing is essential in finding and landing a job, you can boost your skills by practicing writing for CVs, resumes or cover letters.

    Learn from Each Other

    Software engineering is becoming an increasingly collaborative area of study; however, for people to get involved with your project, they need to know what it is and understand it. Being able to write well helps people understand and follow simple instructions and communicate clearly on what they want to achieve or add to a project. If you’re unsure how to write a proposal, you can find great advice in the writing forums or from online editors and writers.

    Become a Proponent of Literate Programming

    Codes are fundamentally written for a computer; however, literate programming supporters state that it should be written for humans, too. The code can have a longer shelf life and be a lot clearer and high-functioning if the people who write it have the interests of a human at the other end in mind, and if the code has a purpose that can serve human needs.

    The Role of Writing is Increasing

    Programmers do have to work with others at times, and even programmers who work on individual projects have to communicate progress and setbacks to their employers, universities or the people who provide funding. If you want to be able to keep all of these people happy so you can carry on with your work, then you need to be able to write quality emails and progress reports. You can find plenty of email and written communications help by using online proofreading free tools on the web.

    Improve Your Professionalism and Reputation

    If you can sell and market yourself well, then you’ll be better-received within your own specific field and within the organization that you work for. Poor writing, littered with spelling and grammar mistakes that leads to miscommunications, just makes you look bad and can make people doubt your ability.

    Make Sure You’re In Line for Promotion

    Programming is a competitive field, even if many of the people who work in it work independently. This means you need to stand out from other programmers when you want the best projects to work on, and getting advice from a professionals is the best way to present your ideas and goals can go a long way.

    Show Your Authority

    A lot of people you work for will not understand code, so you’ll need to employ other means to convince them that you know what you’re talking about. This could include using sources and references to describe why you’ve taken certain courses of action.

    Develop Better Relationships

    It’s always good, and sometimes useful, to maintain good relationships with colleagues, so you can make sure you aren’t being too curt by checking your emails with word count tools, to make sure you’re engaging and approachable.

    Writing and DevOps may not seem to go together; however as the list above shows, they are actually compatible and both necessary for anyone to really succeed in the workplace.

    About the Author / Gloria Kopp

    Gloria Kopp is a digital marketer and an elearning consultant from Manville, Wyoming. She is a regular contributor to such websites as Engadget, Ukwritings and Huffington Post. Connect with her on LinkedIn.

     

  • Why Your Organization Needs DevOps

    Why Your Organization Needs DevOps

    The recently released fifth annual “State of DevOps Report” by Puppet has once again brought with it fresh insights into what drives high-performance teams. The report, which comes at a time when DevOps has ceased to be a buzzword, provides proof of why more and more businesses across the world are adopting DevOps to improve their organization’s performance, revenues and profitability. DevOps has truly come of age and this year’s “State of DevOps Report” clears any doubts fence-sitters may have about the effectiveness of the DevOps approach.

    The 2016 report reasserts that unparalleled IT and organizational performance is a result of a team effort spanning development and operations. The report also highlights the importance of improving the entire product life cycle—from initial product planning, to quality and security assurance, to customer feedback—to speed up delivery while improving quality, security and business outcomes. You can read the full report here.

    In today’s competitive business environment, DevOps has emerged as a vital solution that helps organizations meet ever-growing industry demands. The “2016 State of DevOps Report” helps us understand how the practices associated with DevOps affect IT performance and organizational performance. Let us examine the findings of the report to ascertain how DevOps can benefit your organization.

    Why Does Your Organization Need DevOps?

    The “2016 State of DevOps Report” makes it plain and simple that companies that incorporate DevOps practices get more done. According to the report, high-performing IT organizations deploy 200 times more frequently than low performers, with 2,555 times faster lead times. They have 24 times faster recovery times and three times lower change failure rates. High-performing IT teams spend 50 percent less time remediating security issues and they spend 22 percent less time on unplanned work and rework, the report states.

    Performance

    If we boil down the report findings into actual benefits of adopting DevOps, we could say that DevOps enables continuous software delivery with less complex problems to fix and faster resolution of problems. This essentially means that you can deploy faster and more effectively in more stable operating environments and add value rather than just fixing or maintaining.

    DevOps can revolutionize the performance levels of organizations and allow them to deploy at a rate never seen before. It has certainly enabled organizations such as Etsy, Netflix, Facebook, Amazon, Twitter and Google deploy hundreds and thousands of code per day while delivering world-class stability, reliability and security. You can find out how different organizations have implemented DevOps to their benefit in this YouTube video.

    Security

    Higher performance is not the only payoff in the DevOps culture. Organizations that adopt DevOps practices are known to have better information security. The “2016 State of DevOps Report” clearly states that organizations that integrate information security objectives into daily work spend 50 percent less time remediating security issues than low performers. This has a positive impact on IT performance and security outcomes.

    Any organization, irrespective of size, can employ DevOps to achieve high performance levels and meet business goals while cutting down on costs related to fixes and remediation security issues.

    How DevOps Transforms Teams

    Consider this scenario: In an organization that does not apply the DevOps methodology, the development team writes code and develops a product, which is then sent to the testing team that verifies if the code meets the requirements. The operations team steps in to run the product only after this process is complete. The DevOps philosophy was created to break the silos that teams operate in and effect better collaboration and performance.

    The culture shift DevOps brings about in organizations is substantial, and since culture is a key factor responsible for a company’s performance, application of the DevOps philosophy provides measurable and non-measurable results. A few of them are:

    Employee Engagement

    DevOps is neither a method nor a tool, it’s a culture! In organizations that observe the DevOps culture, the development and operations teams work outside silos, releasing products faster, thereby increasing operational efficiency. This is made possible by the operations team giving the developers constant feedback about the code and troubleshooting problems with the user experience in mind. This continuous learning and delivery practice allows cross-functional teams collaborate as one team with one goal, thus facilitating higher performance levels. The improved organizational culture and enhanced employee engagement can help organizations not only in retaining great talent but also in recruitment.

    Organizational Success

    The “2016 State of DevOps Report” effectively explores the relationship between employee engagement and organizational success and goes on to show that there is a strong correlation between these two factors. The report states that employees in high-performing organizations are more than twice as likely to recommend their organization to a friend as a great place to work.

    Organizations can greatly benefit from adopting the DevOps culture. The “2016 State of DevOps Report” shows that high-performing organizations are widening their lead against lower-performing organizations. This can be attributed to the increased productivity and creativity of highly engaged employees that helps them provide better experiences to customers.

    Organizations can achieve great business results by reinvesting the human time, creativity and energy saved by reducing rework and downtime through DevOps. Herein lies the ROI of DevOps—the competitive advantage that organizations get by investing in a philosophy that positively affects bottom-line results!

    About the Author/ Pallavi Poojary

    Pallavi Poojary1Pallavi Poojaryis a writer with Edureka, an online learning company with more than 250,000 learners spread across the globe. She writes on hot technologies and skills that are in demand today, including DevOps, Big Data and Project Management, to name a few. She is a believer in transformation of careers through learning