Tag: software engineers

  • For Engineers, Meetings Waste Time and Money

    For Engineers, Meetings Waste Time and Money

    Meetings can be the lifeblood of any organization, allowing coworkers to check in with one another, exchange ideas and solve problems. But, for engineers moving up the career ladder, the mounting number of meetings expected of engineering managers can end up being a distraction that does more harm than good.

    Research from Clockwise recently examined data from more than 1.5 million meetings over the course of a year involving more than 80,000 software engineers at more than 5,000 companies around the world. Our analysis, which aggregated and anonymized the information, found that large and growing companies in particular are putting themselves at a competitive disadvantage by distracting some of their most valuable talent from doing important work.

    Engineers Spending More Time in Meetings

    The 2022 Engineering Meeting Benchmarks report showed that as software engineers move into management and spend significantly more time in meetings, they lose more than nine hours a week of what the report referred to as focus time—uninterrupted blocks of at least two hours to focus on deep work.

    That loss comes at a cost that can erode an organization’s bottom line. Engineering managers overwhelmingly say that focus time makes them and their teams faster and more productive, according to a related global survey of about 150 of them. Perhaps even more importantly, 76% traced a direct path from more focus time to more revenue.

    And as companies grow in size, so does the meeting “coordination tax.” In the hotly competitive tech world, that can put larger companies at a disadvantage compared to their smaller, nimbler rivals. Engineers at smaller companies have significantly more focus time—nearly six more hours per week–and spend three fewer hours in meetings than their counterparts at large companies.

    The Pressure of Meetings

    We all have our complaints about the seemingly endless proliferation of meetings in modern business life, and many other kinds of professionals certainly need uninterrupted time to be creative. But these pressures are especially acute and costly for engineers. They are often the most expensive part of a team’s budget, and the consequences of diminished time for deep work can be dire. A single misplaced character in a line of code, for instance, can result in a massive bug affecting an entire organization. In 2012, for example, a programming oversight caused Knight Capital Group to execute a series of erroneous automatic trades, resulting in a loss of $440 million in 45 minutes—and a $12 million fine from the Securities and Exchange Commission (SEC). More recently, a few missing characters in a programming update shut down Skyscanner, a travel search engine and booking platform, for more than four hours.

    Leaders need to be aware of the burden that they put on their teams with well-meaning but less-than-useful meetings. The engineers in the Clockwise analysis averaged 19.6 focus hours each week compared with 10.9 hours in meetings and 6.3 hours between them, something we call “fragmented time.” As they move into management, their meeting time soars to 17.9 hours while their weekly focus time plummets to 10.4 hours.

    And those averages don’t tell the whole story–there’s a very wide distribution depending on the organization. At some distracted businesses, engineers are clocking in with fewer than 10 focus hours a week, while elsewhere the most productive teams get 20 or more.

    Meeting Culture

    It’s easy for leaders to become convinced that they need to have a slew of meetings each week–one-on-ones, daily standups, planning sessions, scrums to coordinate across teams–but the cumulative impact can turn a calendar into something resembling Swiss cheese. Traditional meetings are obviously important–we need to talk to one another and work things out–but there’s also a big opportunity for businesses to try a new approach.

    It can be as simple as eliminating those annoying, unproductive 15- to 60-minute gaps in your schedule by holding meetings back-to-back. Other experiments in meeting culture could include instituting no-meeting days. Or deleting every other occurrence of a regularly scheduled meeting. Or try asynchronous working practices through apps like Loom or Slack Audio that allow participants to respond to presentations or messages on their own schedules, rather than as a group in real-time.

    In 2020, for instance, the company Loom—using its own remedy internally—switched its regular all-hands meeting to an asynchronous format on the theory that real-time meetings should be reserved for conversation rather than simple information sharing from a small group of people. Staffers watch short, prerecorded videos of updates from presenters when it’s convenient for them, and then participate in a company-wide Q&A in real-time. This approach allows the company to take advantage of everyone being together to engage in discussions and exchange ideas, Graham Gawthorne, then a member of Loom’s business operations team, wrote in a company blog post.

    It’s a practice that starts at the top. When scheduling, leaders need to take a good, hard look at their team’s calendars and, rather than just grabbing any empty space that shows up, consider how to leave individual contributors the blocks of time they need to actually do their work. Keep in mind that studies have shown that it takes roughly 25 minutes to refocus and get back on track after an interruption, and that task switching can take up 40% of a team’s productive time.

    And leaders need to preserve enough focus time for themselves, too—rather than trying to be perpetually available to their team members. If they’re not creating space in their own calendars to solve the larger problems, they’re probably not doing what managers should: Helping their teams to thrive.

    I don’t know a single engineering leader whose boss isn’t asking, “How do we go faster? How do we do more with what we have?” with even greater urgency in these economically challenging times. The Clockwise analysis suggested that the answer, for many of us, is to stop ping-ponging from one meeting to the next and give your teams what they need most: Time to focus on their work.

  • Report Finds Software Engineering Productivity Gains

    Report Finds Software Engineering Productivity Gains

    An analysis of the time 23,000 software engineers spent working in 2021 that was published this week by Jellyfish, a provider of an engineering management platform (EMP), finds cycle times on average were down to 12.6 days, representing a 12.3% decline over 2020. The report, however, also finds commits were down 4% year-over-year, while the number of issues resolved was up 5% year over year.

    Jellyfish CEO Andrew Lau said the data suggests that software engineers are opting to commit less code in favor of resolving issues faster. Overall, coding days per engineer were down 8% to less than 1.6 days per week in 2021, the report found.

    Engineering teams on average in 2021 allocated 35% of their time to growth and innovation, while 19% was allocated to infrastructure work, up nearly 6% from 2020. Time spent on support work (24%), meanwhile, was down nearly 5% year over year. On average, unplanned work accounted for 22% of the time software engineers spent working in 2021, a 3% increase over the prior year. In general, Lau said the report suggests that engineering teams need to factor more time into schedules for unplanned work as application environments become more complex.

    The report also finds engineering organizations using EMPs tend to allocate similar time to “keeping the lights on” and customer support activities as other organizations but spend 29% more time on innovation work and 48% less time on unplanned work. In addition, the report notes teams that devote 50% or more resources to growth and innovation work deliver software at least three times faster than those who commit 25% or less.

    Virtual collaboration in the last year has also increased more than 20% as teams continue to embrace remote and hybrid work models, according to the report. Overall, organizations that allow software engineers to work from home remain productive but it’s not quite clear if managers have completely adjusted to the realities of hybrid work, noted Lau. The report also noted that pull request reviews per engineer are up 30% on average to 1.7 reviews per week. Pull review comments per engineer were up 23% year over year.

    In addition to the report, Jellyfish conducted a survey of 128 engineering leaders that finds more than 79% expect to grow their teams in 2022, with 57% expecting more than 10% headcount growth. Improving operations, tooling and processes (36%) is their highest priority in 2022, followed by hiring and retaining talent (18%), improving infrastructure (17%) and managing technical debt (10%). The biggest overall challenge is making sure everyone is focused on the highest priority work (45%), the survey finds.

    However, only 27% of the leaders currently track productivity metrics, despite more than two-thirds (67%) describing them as being very important or critical to track. Among teams that do track metrics, more than half (53%) do so manually, the survey finds.

    While the productivity of software engineers will naturally vary by organization, it’s apparent the weight of application environments is starting to impact how much time can be devoted to building and deploying new applications. The challenge, of course, is demand for new applications in the age of digital transformation has never been higher, which in part explains why so many organizations are struggling to find and retain software engineers.

  • Bridging the Gap Between ITSM and Software Engineering

    Bridging the Gap Between ITSM and Software Engineering

    Considering the individual roles of IT service management (ITSM) and software engineers, it seems obvious they should work closely together. ITSM tracks internal and external customer issues and engineering fixes code-related issues (such as defects) that IT cannot fix on its own.

    However, more often than not, coordination between these two departments is poor, which—critically—undermines customer response times and damages application satisfaction. It’s important to remember that the quality of customer response isn’t just about speed, it’s about giving customers insight into the state of the issue.

    The disconnect between ITSM and engineers, often caused by individual priorities and semantic differences, makes this real-time insight difficult. Both teams have individual and shared concerns, and separating these while simultaneously improving collaboration is a big challenge.

    Addressing this relationship is an important step in optimizing ITSM and DevOps integrations, alongside focusing on IT help desk enhancement requests to product management, and tracking code from build to release and back.

    The Flow of Information on Things that Matter

    Most of the tickets generated by the IT help desk can be handled internally with no help from engineering, but it’s the tickets that do need help which require consideration. For these issues, there needs to be an open flow of information on the things that matter between these two teams.

    IT help desk must give engineering enough information to understand the defect and its impact on the customer. Meanwhile, engineering needs to be able to give the help desk a sense of when to expect the fix, when the fix is done and be able to request more information when required.

    Information that should be shared from the help desk to engineering includes the following:

    • Severity – Engineering needs a sense of the importance of the defect. If everything comes in as “High Priority,” nothing is high priority. The help desk must understand that engineering already has its own internally generated set of defects, as well as defects found by QA and other sources. For these customer defects to be prioritized and fixed in a timely manner, engineering needs to know how impactful they are to the customer.
    • Description – This is perhaps the most important piece of information the help desk can pass along. The more contextual information that can be shared, the better. It’s immensely important to provide engineering with the necessary steps to reproduce the specific defect, which version of your tool the customer is using, the general environment, etc. Sometimes this is best in structured fields, while other times it’s important to simply write out everything.
    • Screenshots and other visual information – Along with the written description of the problem, engineering often requires logs and/or screenshots. As the saying goes, “A picture is worth a thousand words.”

    Now that engineering has the vital information it needs to fix the defect, it has a responsibility to provide useful information back to the help desk:

    • Planned release – This should not be a firm commitment, but rather an estimate to give the help desk general timing. While the actual date of the fix may vary, it’s still useful to be able to tell a customer,”This is coming soon,” rather than, “We realize this is a problem and it’s on our backlog to fix.”
    • Engineering status – While this is a single defect to your customer and to them only has one status, there are really two statuses your organization will care about:
      • Status of the ticket in your ITSM tool
      • Status of the defect in your defect tracking/agile planning tool

    It’s very important that the ITSM tool contains both statuses to provide more information and context to the help desk. Imagine the benefit of knowing that the defect is “In Triage,” “In Progress,” or “In Verification” and being able to provide that information to a customer.

    • Actual release/released – As opposed to the planned release information, this lets the help desk know that the customer’s issue has been resolved. Imagine running a report from your ITSM tool indicating the defects fixed in your most recent release. Your IT help desk can proactively reach out to customers to let them know to upgrade, enabling you to offer more proactive customer communications.

    Finally, and perhaps most important, you allow your teams to talk about the “same thing” even when it exists in different tools and they speak a different language. There are four core ways to do this: 

    • Cross-tool tracking – Each artifact in each system should have the ID (and ideally URL) of its twin artifact in the other system. If a help desk representative needs to talk to an engineer about a defect, the rep needs to let engineering know which defect it is in the engineering tool, not just in the ITSM tool.
    • Routing – IT help desks often support multiple products, each of which have multiple components that may belong to a different engineering team. The help desk needs some indication which component and/or team should work on the defect. This information will help the IT help desk know which team to reach out to for help.
    • Filtering – Not every ticket in the ITSM tool needs engineering help (that’s a good thing). However, there should be some indication on the IT ticket if it has been sent to engineering. You do not want to send the same defect to engineering twice (confusing) or to assume it’s been sent when it hasn’t (poor time to resolution or issue overlooked).
    • Communication – IT and engineering need a shared way to talk about a specific defect that they both care about. The closer this communication can be to the native commenting that already occurs, the better. Ideally this is not via email as that communication vehicle does not stay attached to the artifacts in question, meaning information can be hard to find or get lost.

    The Benefits

    Customers will love it – Improved communication means happier customers. Customers can plan their upgrades with more certainty, and their trust grows since your organization is able to deliver on its promises. No longer will they feel like their issues are being thrown into a black hole.

    Better engineering focus – Engineering gets pulled in a variety of directions, contending with feature work as well as internally generated defects. The more information it has, the easier it is to prioritize and deliver more value to customer. Without the ability to share the severity of a defect, you risk two undesirable outcomes:

    • The defect is fixed instead of more important work, which hurts all your other customers.
    • Other, less-important work is prioritized, which can threaten your relationship with this customer.

    Better trust across your organization – Open communication fosters trust and understanding. Providing insight into prioritization and status let’s your help desk feel part of the development process. No longer will staff feel like their requests are being ignored with no idea when they will be fixed. Enhanced cross-team communication also helps engineering to avoid feeling like work is simply being thrown over the fence. Obtaining more context around a defect is invaluable.

    Next Steps for Total DevOps Integration

    To fully integrate your ITSM and engineering teams, there are still (at least) two other processes to implement:

    • A method for the IT help desk to provide enhancement requests to your product team: These enhancement requests are similar, but distinctly different from the defects described above. Consequently, they need to be prioritized and triaged by a different team.
    • The other process to implement is the traceability from task to code to build and back again. To properly inform customers that their problem is fixed in this version of your product, it’s important to correlate features, stories and bug fixes with the actual version of your product that includes them for the first time.

    Bridging the gap between ITSM and engineering teams brings your company closer to customers. While making your organization work as a unified whole is an incredibly complex problem, addressing this relatively small, but vital, piece of the puzzle helps you on your journey to integrating your whole software value stream. This change of mindset, combined with connecting all teams, tools, disciplines and processes in an enterprise’s software value stream, optimizes collaboration, productivity, efficiency and most importantly, value delivered to the customer.

    About the Author / Trevor Bruner, Product Manager, Tasktop

    Trevor Bruner is Product Manager at Tasktop Technologies. His background includes experience in financial services, oil and gas and as a Navy submarine officer. Connect with him on LinkedIn and Twitter.

     

  • Reasons Why DevOps May Not Work for You

    Reasons Why DevOps May Not Work for You

    DevOps is a great way for many organizations to optimize software design and delivery. Yet, like every other technological innovation in history, DevOps is not perfect. Here are some examples of drawbacks associated with DevOps.

    By no means do I think DevOps is a bad idea in general. I want to be very clear about that.

    However, organizations considering making the move to DevOps—and those that are already doin’ DevOps, as we say here on devopsy.kinsta.cloud—can gain useful perspective by recognizing the difficulties that DevOps can present. Those include …

    Narrower Team Member Roles

    Traditionally, software engineers were expected to bring “full-stack” skills to the table. That meant they should understand the ins and outs of all layers of an application stack.

    Under the DevOps model, each member of the software delivery team has a more rigidly defined role. Coders code, QA engineers test, IT Ops admins administer and so on. These people all talk to each other, but they do not share in the same tasks.

    In many cases, this approach is better because it allows each professional to focus on what he or she does best. But this can be a drawback for full-stack developers. Their broad skill sets are no longer valuable. This is why people such as Jeff Knupp complain that DevOps is “killing” developers.

    There’s a potential downside here for organizations, too. Under DevOps, they have to hire and manage more personnel to make sure there is a specialist who can cover each stage of the software delivery pipeline, rather than investing in a smaller number of full-stack developers.

    Software Feature Bloat

    One of the key advantages of DevOps is that it promotes continuous software delivery. That means new features can be rolled out faster.

    But the ability to add features more easily also raises the risk that software delivery teams will add functionality to software just because they can, not because it’s needed. More features are not always better, even if they can be implemented efficiently.

    Infrastructure Changes

    To make the most of DevOps, most organizations will have to upgrade at least part of their infrastructure to optimize software delivery. Many will need to migrate apps running on virtual servers to containers, for example.

    There is nothing inherently wrong with such infrastructure upgrades. But they are potentially expensive and complicated endeavors, and if you don’t complete them properly, you might not actually get very much out of the other DevOps processes that you implement. Organizations considering DevOps should keep this in mind.

    Half-Baked DevOps

    The final major risk of a DevOps migration is not actually a downside of DevOps, per se. It’s a risk that results from the chance that organizations will implement DevOps imperfectly.

    This can be easy to do, because organizations can mistakenly believe that doing DevOps means simply running a continuous integration (CI) server or changing job titles. In practice, DevOps also requires significant cultural changes and new methods of communication. If you implement a half-baked DevOps environment that includes the tools but not the culture, you’ll likely be worse off than you would without having attempted DevOps at all.

    Conclusion

    Again, I want to be clear that there are lots of good reasons to do DevOps. I’m not trying to go on record as the guy who hates DevOps, because I absolutely don’t. Almost all organizations have much more to gain than to lose by adopting DevOps, if they have not already.

    Still, being aware of the imperfections and risks associated with DevOps is important. DevOps is not a magic pill that will solve all of your software delivery problems with no side effects. If you want to avoid mistakes or unrealistic expectations when doing DevOps, you need to appreciate the drawbacks you may face.

    — Chris Tozzi