devopsy.kinsta.cloud

Tag: visibility

  • Speeding Up Software Delivery Is Changing How We Debug Performance

    Speeding Up Software Delivery Is Changing How We Debug Performance

    Deployment frequency has become one of the clearest markers of a mature engineering organization. Teams that once shipped monthly now ship daily, and teams that shipped daily now ship several times a day. This shift has largely delivered on its promise. Smaller changes are easier to reason about, rollbacks are faster, and feedback loops are shorter.

    What has received less attention is the effect this same shift has had on the practice of debugging performance issues. Several assumptions that previously held, a stable release to compare against, a known change set behind a given incident, sufficient time between deployments to observe a system before the next one lands, no longer apply in the same way.

    A Moving Baseline

    Performance debugging has traditionally depended on comparison. An engineer examines current behavior against a known good state, typically the previous release, and narrows down what changed. This approach works well when releases are infrequent enough that the previous release remains a stable, well understood reference point.

    When deployments occur several times a day, that reference point moves continuously. A regression noticed in production may trace back to any one of a dozen deployments merged since the last time someone reviewed that code path closely. The regression itself is genuine, but the comparison method that once made it straightforward to isolate no longer has a single fixed point of reference.

    This does not indicate that frequent deployment introduces more performance issues. It indicates that the traditional method of identifying them, comparison against a known baseline, becomes more difficult to apply as the baseline itself becomes a moving target.

    Smaller Changes, More Difficult Attribution

    A related effect occurs at the level of individual changes. Smaller, more frequent deployments are generally easier to review and easier to roll back. However, when a performance issue surfaces days after a change was merged, rather than immediately following it, attributing the issue to a specific change becomes a process of elimination across many small deployments rather than an inspection of one larger one.

    A single large release makes attribution simpler in one way, since there are fewer candidates to consider, but harder in another, since each candidate is larger and more complex to inspect. Frequent small releases invert that trade off. Each individual change is simple to review, but the number of candidates behind a delayed symptom grows quickly, and a minor dependency update or an altered query parameter buried in a routine pull request is just as capable of causing a regression as a larger architectural change.

    Neither approach removes the underlying difficulty. It appears in a different form depending on how a given team ships.

    Where Transaction Level Visibility Applies

    This is where visibility at the transaction and code level becomes relevant, not as a substitute for deployment history, but as a means of observing what actually occurred at runtime, independent of which release introduced it. A trace showing precisely which method, query, or downstream call consumed the time for a specific slow request does not require prior knowledge of which deployment caused the issue. It identifies the issue directly, within the transaction in which it occurred, whether that turns out to be an unindexed query, a retry loop against a failing dependency, or a serialization step that grew more expensive as payload sizes increased.

    This changes the starting point of an investigation. Rather than beginning with an assessment of which among several recent deployments caused a given issue, an engineer can begin with a direct account of where a specific request spent its time, and work backward toward the change that introduced it, informed by observed behavior rather than elimination alone.

    Dependency mapping serves a similar function at a structural level. As services are deployed and redeployed independently of one another, understanding which services actually call which, based on current behavior rather than the architecture as documented at the last major review, becomes part of maintaining visibility that keeps pace with the system itself.

    Delivery Speed and Diagnostic Speed Are Separate Measures

    It is worth being precise about what deployment frequency actually measures. It measures how quickly a team can move a change into production, a genuinely useful indicator of process maturity. It does not measure how quickly that same team can diagnose a performance issue once one appears in production.

    These two measures can move independently of one another. An organization may improve deployment frequency substantially while diagnostic time remains unchanged, or even increases, if the practices used to investigate performance issues have not kept pace with how frequently the system now changes. Improving one without corresponding attention to the other tends to produce a team that ships quickly and then spends a disproportionate share of that gained time identifying what went wrong afterward, which is a cost that rarely shows up in delivery metrics themselves.

    Keeping both measures aligned generally requires treating runtime visibility as something that keeps pace with deployment frequency itself, present for every service from the point of deployment, rather than something introduced after a service has already accumulated a performance issue worth investigating.

    Where This Leads

    The practices that enable faster software delivery and the practices that make performance issues easier to diagnose are not inherently aligned. The two require deliberate coordination. This typically involves treating transaction level tracing as part of how a service is deployed, rather than as a separate concern addressed later, so that the same velocity built into shipping code remains available when investigating what that code actually does once it is running. OpManager Nexus provides a 30-day free trial for teams that want to see this kind of transaction level visibility applied to their own environment.

  • How AI Helps Teams Track Dependencies and Reduce Delivery Risk

    How AI Helps Teams Track Dependencies and Reduce Delivery Risk

    AI is showing up everywhere in software delivery, but project management is where a lot of the real friction lives. Newly appointed Planview CEO Matt Zilli talks through why planning and delivery still break down inside modern organizations, even when teams have more data and more tools than ever.

    Zilli’s point is simple: the problem is not visibility in the abstract. It is that work is scattered across different teams that make decisions in different ways, using different systems, with different operating models. That fragmentation makes it hard to see what is actually happening, where dependencies are forming, and what needs attention before a small delay turns into a wider miss.

    He argues that AI can help by turning that messy, cross tool picture into something teams can act on. Instead of people spending time chasing updates, filling out status fields, or maintaining sprawling dependency maps, AI can pull signals from the systems teams already use and surface where work is drifting off track, where risk is accumulating, and what tradeoffs matter for the next decision.

    Zilli also lays out a practical view of agentic AI. The technology is moving fast, but most organizations are not going to hand over full autonomy overnight. For 2026, he expects more proofs of concept and guided deployments where teams build confidence in specific use cases. In lower risk scenarios, that can extend beyond spotting issues to taking action, like adjusting resource allocations or sequencing work differently.

    For project managers, agile coaches, and delivery leaders, the goal is less low value coordination work and more time spent on the decisions that actually move outcomes. Zilli thinks that shift can reduce surprises, lower stress, and improve forecasting, not because planning becomes perfect, but because teams get earlier, clearer signals about what is really happening in the work.

  • The Hidden Threat of API Sprawl Beyond the Gateway

    The Hidden Threat of API Sprawl Beyond the Gateway

    APIs power everything beyond just carrying data, from allowing higher-order software applications and improving customer experiences to engineering efforts and internal operations. But beneath this surface of innovation lies a growing, often unacknowledged challenge—API sprawl.

    This phenomenon describes an ever-expanding collection of APIs that outpaces an organization’s ability to effectively track, manage, and secure them, leading to a tangled digital infrastructure where visibility is lost and control becomes elusive.

    At the heart of API sprawl are shadow APIs and zombie APIs. Shadow APIs operate completely off the radar, often undocumented and unknown to security teams, meaning no security reviews or vetting ever take place. Zombie APIs are those that should have been decommissioned but remain active, often forgotten after a new version or service replaces them. In both scenarios, these endpoints exist outside normal oversight, making them prime targets for exploitation. But the implications of this sprawl extend far beyond mere operational untidiness, posing significant and often underestimated security risks.

    One common misunderstanding among tech leaders when talking about API sprawl is failing to grasp its deeper, strategic liability. It’s more than just a “messy” IT landscape; it’s a fundamental obstacle that can block critical strategic initiatives like AI transformation. Leaders might overlook that their extensive API investments could be effectively invisible to AI systems due to inconsistent documentation, inaccessible specifications, and incompatible implementation patterns—a phenomenon some call the “AI accessibility paradox.”

    And this reliance on tribal knowledge rather than clear visibility can also lead to skyrocketing infrastructure costs and an unknown security posture that keeps leadership awake at night.

    The Limits of Traditional Visibility (Gateways & Catalogs)

    Many organizations believe they have a handle on their API landscape by relying on API gateways and manually maintained spec catalogs. While these tools are undoubtedly valuable and serve crucial functions, they often present an incomplete picture, missing a substantial portion of an organization’s actual API estate. These traditional methods typically only capture APIs that are actively managed, documented, and exposed through the gateway, leaving significant blind spots.

    The reality is that a considerable percentage of an organization’s API landscape—including internal, legacy, and in-development APIs—is typically missed if visibility relies solely on conventional tools. Because these overlooked APIs often reside in code repositories, operating completely off the radar, unseen by security teams, and often undocumented.

    And this gap means that even well-intentioned efforts to secure and manage APIs fall short, as a significant portion of the attack surface remains unknown and unmonitored. For instance, nearly a third of API publishers today use multiple gateways, which further fragments visibility and makes comprehensive API discovery and observability even harder. Effective API security, therefore, transcends mere management; it begins with deep discovery, moving beyond the superficial view offered by standard gateways and catalogs.

    Danger Lurking in the Code

    A significant portion of an organization’s API landscape often lives hidden within code repositories, never seeing the light of formal management or security review. These are the APIs that developers may spin up for internal use and then forget, or older APIs that are never properly decommissioned. These endpoints, including shadow APIs and duplicated internal services, pose critical risks.

    One of the most significant dangers is the creation of security vulnerabilities. APIs lurking in code repositories are often completely off the radar, meaning they are never tested, monitored, or patched. Because this leads to wildly inconsistent security postures, where critical controls like proper authentication, authorization, and input validation are easily missed.

    An unvalidated input, for instance, can lead directly to severe vulnerabilities like SQL injection. These hidden APIs can become conduits for exposing sensitive data, even if not explicitly “vulnerable” in the traditional sense, simply by virtue of being accessible and unmonitored. They can be exploited using stolen credentials, leading to data leakage or injection attacks, or may bypass newer security measures implemented elsewhere.

    Without a complete and up-to-date API inventory, security teams operate with blind spots, undermining threat modeling, weakening incident response preparedness, and leading to ineffective controls.

    Beyond security, these hidden APIs contribute to operational instability and wasted resources. Developers spend a surprising amount of time simply trying to figure out what APIs exist, which ones are safe to use, and whether the documentation is up to date – if it even exists. And this lack of clarity leads directly to duplicated work, brittle integrations, and excessive firefighting, killing momentum and slowing development velocity. Teams might spend half their time just discovering and understanding existing APIs before beginning new development.

    The frustration is palpable, turning regular development into “detective work.” For example, building a seemingly simple third-party integration can mean bouncing between multiple code repositories and numerous outdated or undocumented API files, just to start writing tests. This overhead pushes feature delivery late and drags hotfixes into future sprints.

    This environment also fuels “dependency hell,” where unchecked API sprawl creates a cascade of interrelated challenges like circular and nested dependencies, versioning inconsistencies, and authentication conflicts. Such complications have a quantifiable impact on development cycles, resulting in absurd local environment setup times, crushing machine resource requirements, and agonizing build and testing times.

    A single build issue can lead to hours or days of troubleshooting, sometimes even a complete rollback, which then requires starting from scratch. This severely damages project timelines and morale, creating an unproductive environment. The “if it works, don’t touch it” mentality often prevails, making it easier to implement new functionality than to modify existing, tangled APIs. This continuous toiling over sprawl creates an unseen cost that drags down an organization’s ability to innovate.

    The True Cost of Ignorance

    The technical friction and security vulnerabilities flaring up from API sprawl don’t remain confined to development teams; they swiftly translate into significant business consequences that impact the bottom line, reputation, and long-term innovation capabilities.

    Financially, the hidden costs are substantial. Organizations face skyrocketing infrastructure costs and hundreds of thousands of dollars in maintenance for unmanaged APIs. Developer inefficiency, due to wasted time on discovery and rework, directly impacts the bottom line, as slower development teams negatively affect output. Furthermore, excessive services running on developer machines or in remote development environments can bloat infrastructure costs. But beyond these ongoing drains, a single security breach stemming from an unknown or forgotten API can result in millions in losses and significant reputational damage.

    The inability to manage API sprawl hampers innovation speed and market responsiveness. Lack of visibility means leaders are constantly guessing about existing systems, dependencies, or stability, delaying everything from capacity planning to delivery forecasts. What might appear to be a two-week feature can easily turn into a month-long delay because an underlying API is undocumented, broken, or lacks clear ownership. This friction directly translates into slower time-to-market for new features and products, and a diminished capacity to respond quickly to evolving business needs. The overall impact on efficiency ultimately slows down innovation and prevents teams from delivering true business value.

    Moreover, the lack of API visibility creates significant compliance challenges. If an API is not properly documented or secured, fundamental principles of accountability, often enshrined in regulations like GDPR, are violated. Without knowing what APIs exist and what data they handle, companies cannot secure or comply with what they don’t know exists, leading to severe compliance breaches, especially if shadow or zombie APIs handle sensitive data without oversight.

    When a security incident does occur, perhaps exploiting one of these hidden APIs, the response is often doomed from the start. Lack of proper documentation means understanding what APIs have access to critical databases becomes a frantic, time-consuming effort. This drastically increases the time to mitigation, allowing attackers to continue causing damage and exacerbating the business impact. The inability to quickly respond to a high-impact API risk directly impairs an organization’s ability to deliver and maintain code in production.

    This confluence of API sprawl and the urgent pressure to leverage AI capabilities has revealed a critical bottleneck, escalating from a technical debt issue to an existential business challenge. Organizations that cannot consolidate and structure their APIs risk falling behind, as AI systems demand precision, discoverability, and composability to operate effectively. Without control over their API surface, businesses will struggle to enable automation, build copilots, or participate in AI-native ecosystems, putting both innovation and competitiveness at stake.

    Seeing is Believing

    The grim picture of hidden API sprawl—with its attendant security vulnerabilities, productivity drains, and escalating costs—underscores a fundamental truth: you cannot manage or secure what you cannot see. While traditional tools like API gateways and manually maintained catalogs offer a partial view, they inherently miss a significant portion of an organization’s true API landscape. A comprehensive understanding requires going deeper, directly into the source code repositories where APIs often live, undiscovered by conventional methods.

    For organizations looking to get a true handle on API sprawl, discovering APIs directly from source code repositories offers transformative benefits compared to relying solely on runtime observation or declared specifications. This deeper discovery enables the creation of a living, centralized inventory that combines documentation, real-time discovery, and regular validation, allowing teams to see what exists, what’s being used, and what’s safe to build on. This clarity immediately translates into improved efficiency and productivity. It frees developers from the endless cycles of rediscovery and reinvention, accelerating time-to-market by as much as four to ten times when APIs are properly cataloged and discoverable. Engineers can feel more confident and make faster decisions, no longer wasting valuable time hunting down information or rebuilding existing functionality.

    Beyond efficiency, this comprehensive visibility significantly enhances an organization’s security posture and helps enforce compliance by reducing the attack surface. It allows for the enforcement of security policies and API design best practices across the organization. When you know exactly which APIs are exposed, what data they handle, and who owns them, you’re not scrambling when a security or regulatory question arises. This transparency can even unlock the budget needed to tackle API sprawl effectively, as security becomes a key driver.

    Perhaps most pressingly, addressing API sprawl by achieving this deep visibility creates the foundational layer for successful AI integration by making business capabilities programmatically available. Developers can immediately use existing assets for new AI initiatives, eliminating the need to build integrations from scratch and significantly accelerating the development and deployment of AI agents. This builds up an environment where innovative technologies can be seamlessly integrated and scaled, giving organizations the precision, discoverability, and composability that AI systems truly require. This approach also leads to improved ownership and accountability, naturally reducing “shadow IT” by making APIs centrally tracked and accessible.

    From Hidden Threat to Managed Asset

    The journey to reclaiming control over your API landscape, transforming hidden threats into managed assets, begins with a fundamental commitment to comprehensive visibility. Understanding the “hidden” sprawl—those APIs living unseen in code repositories, beyond the reach of traditional gateways—is the indispensable first step to mitigating risks and significantly improving efficiency.

    For a CTO or Head of Engineering who suspects their organization is grappling with a significant, hidden API sprawl problem but isn’t sure where to begin, the advice is clear: start with discovery. An API’s security issue is fundamentally a discovery issue; once identified, it can be addressed. Begin by striving to document all APIs, gathering as much information as possible about every available API. A simple litmus test can reveal initial insights: how many APIs do you have, and how many are truly “well-documented” with up-to-date specifications in a usable developer catalog?

    To delve deeper, a thorough assessment of development operations, broken down by production, output, and infrastructure, can be highly revealing. Metrics like overall cycle time (including coding, review, build, and deploy phases) offer a window into efficiency and the likelihood of a sprawl problem. Furthermore, observing a team’s ability to rapidly scope, plan, and deliver new features, along with consistently hitting timelines for low-point agile stories, can clearly indicate the presence or absence of API sprawl.

    Beyond initial assessment, it’s crucial to “stop the bleeding.” This means pausing the creation of new APIs until clear policies are defined and consistently enforced. Each new API should be rigorously questioned: Is it truly necessary? Are there no existing APIs that can serve the same use case? By adopting this strategic pause and proactive questioning, organizations can begin to stabilize their API ecosystem before embarking on further growth. Ultimately, transforming hidden liabilities into strategic assets requires this commitment to seeing, understanding, and then managing every API.

    Consolidating Your AI Strategy

    The chaotic, unmanaged tangle of unknown and forgotten APIs creates a fertile ground for attackers, complicates compliance efforts, and can paralyze an organization’s response when security incidents do occur. This challenge, though significant, is not insurmountable.

    The path to reclaiming control hinges on a fundamental commitment to comprehensive visibility into your entire API landscape. This means moving beyond reactive measures to a strategic, proactive approach that identifies and manages every API, whether it’s exposed through a gateway or lurking unseen in a code repository. The organizations that successfully address API sprawl will gain a decisive competitive advantage in their AI transformation efforts, while those that do not will find themselves struggling with increasingly expensive and ineffective technology investments.

    By embracing the principles of deep discovery, strong governance, and embedding security proactively throughout the entire API lifecycle, organizations can begin to transform these essential connectors. APIs that were once hidden liabilities can become secure, strategic assets crucial for driving innovation, achieving operational efficiency, and fueling your company’s AI-powered future.

  • CodeSee Extends Reach of Code Visualization Platform

    CodeSee Extends Reach of Code Visualization Platform

    CodeSee updated its code visibility platform to enable instant mapping of application services, directories, file dependencies and code changes.

    CodeSee CEO Shanea Leven said CodeSee Enterprise 2.0 should extend the appeal of the platform beyond developers to include software engineers managing DevOps workflows.

    CodeSee Enterprise 2.0 provides real-time visibility across multiple repositories regardless of whether the application is a monolith or based on a microservices architecture, she noted.

    In addition, a Code Automations module enables developers to set granular conditions and actions down to the function level, requiring checklists to be complete before allowing developers to move on.

    CodeSee Maps now includes the ability to click to view code directly, while a streamlined Review Maps module has decreased code review time by 30%. Developers can easily share maps to discuss proposed changes or keep necessary code changes as automatic permanent artifacts.

    Additional languages including C#, VB.NET, ASP.NET, Blazor, Java, JavaScript, Go, Python and TypeScript are now supported.

    Finally, CodeSee is making available a dedicated solutions engineering team that provides guidance to connect an organization’s Datadog or OpenTelemetry trace data to CodeSee in less than an hour without storing code or having to first dive deep into traces, noted Leven.

    The core open source CodeSee tool was created because it takes too long today for most developers to pore over a codebase to understand where they might contribute. The larger a codebase becomes, the longer it takes for a developer or software engineer to be onboarded to a new project.

    The overall goal is to improve developer productivity, noted Leven. That’s become a critical issue because many organizations are hesitant to hire additional developers during uncertain economic times; they first want to ensure they maximize the utilization of the teams they already have.

    Application development, of course, is now a team sport. The days when a lone developer cared for an entire application are long over. The issue is finding a way for teams of developers to collaborate more easily in an era where many of them may never have met in person.

    In the longer term, Leven said she also expects that generative artificial intelligence (AI) platforms such as ChatGPT will supplement code visualization tools. Many developers are already starting to use these tools to help generate code faster. That code should, in theory, have fewer errors because it has essentially been copied from other previously validated sources. CodeSee provides a means to visualize that code before deploying it to ensure it will function as promised in increasingly complex application environments.

    One way or another, the tools being provided to developers to boost productivity are advancing. It’s not clear what metrics should be employed to track developer productivity, but the amount of code simultaneously moving through DevOps workflows is going to increase. The challenge DevOps teams face now is keeping track of all the dependencies that exist in that code as application environments are continuously updated.

  • Connections Matter: Gaining Visibility Into APIs

    Connections Matter: Gaining Visibility Into APIs

    Digital transformation is at the center of modern enterprise. Yet, as cloud initiatives take shape and the complexity of connecting systems and applications multiplies, the need to tie everything together and automate processes grows. APIs, otherwise known as application programming interfaces, fuel this automation. These small pieces of code—which connect and interconnect clouds, containers, microservices and applications—help organizations compress what used to be years of project development into months or weeks.

    As businesses connect functionality—often across companies and service providers—APIs lead to an enhanced user experience. Simply put, they make it possible for much of the magic of the internet to take place, including seamless authentication, data sharing, payments and collaboration.

    Today, it’s next to impossible to find an enterprise application that doesn’t rely on APIs. Yet, despite all the gains, APIs can cause plenty of pain. The slow performance or complete failure of an API can lead to an array of problems. These include customers who can’t complete transactions, employees who can’t collaborate through critical apps, and incomplete or incorrect supply chain data.

    Today, a typical organization relies on more than 1,200 cloud-based applications and hundreds or even thousands of APIs. For many businesses, 50% to 90% of revenues are linked to APIs. If a system underperforms or breaks, there’s often no way to identify the root cause and fix it promptly. Reputational damage and lost sales often ensue.

    When Good APIs Go Bad

    It’s important to recognize that the monolithic applications of the past are a vanishing breed. Today’s highly-distributed software and services environment taps a universe of more than 24,000 APIs. It isn’t unusual for a transaction to pass through several cloud containers and across numerous companies en route to the desired outcome. Along the way, these APIs encounter different hardware, code and conditions.

    When APIs work well, a process or transaction typically finalizes within milliseconds—and the digital experience usually excels. However, if a page loads slowly, a promotional code doesn’t work or payment doesn’t go through, the odds are high that somewhere along the line something went astray with an API.

    For many organizations, there’s no simple and fast way to identify the source of the problem, understand the current impact, and take steps to fix the failure post haste. In fact, it isn’t unusual for several thousand or more failed transactions to pile up before the issue hits IT’s radar and anyone begins to notice a problem. By then, shoppers have likely abandoned shopping carts and sales have evaporated.

    Adding to the challenge is the fact that APIs can fail in several ways. Not surprisingly, the number one problem is availability. If the API doesn’t function, the interaction or transaction cannot take place. In addition, an API might perform slowly or erratically, thus delivering highly inconsistent and frustrating experiences for users along with a problem that is difficult to diagnose and fix. Yet another problem is misconfigured or poorly functioning APIs that return incomplete data or the wrong data.

    The real-world fallout can be significant. In practical terms, a customer shopping at a clothing retailer’s website may find it impossible to add socks to a shoe order or use one or more payment services. It may be impossible to cash in points from a loyalty program or view delivery information. Broken APIs can disrupt or break shopping carts, customer accounts, supply chain data, collaboration links, security tools, and much more.

    Of course, when things go haywire, finger-pointing and conflicts with vendors, business partners and customers often ensue.

    Deep Visibility

    In today’s API-centric world, detecting problems early and often is critical. What makes the task so difficult is that API transactions do not unfold in a linear way. They bounce across servers and companies—often a couple dozen of them—scattered all over the world. Further complicating things: This routing can change at any given instant.

    Identifying specific issues that trigger a problem—traffic bottlenecks, bandwidth issues, code problems and more—requires the right tools. It’s vital to understand how an API-based transaction behaves across a dozen or even two dozen hops and touchpoints that extend through clouds, containers and microservices.

    Passive visibility tools, while useful for getting closer to the end-user, do not offer a comprehensive and granular view of events and processes. Today, businesses require broader and deeper observability capabilities that extend across an ecosystem of APIs and into the entire IT landscape—from network to device. It’s vital to understand how customers use websites, apps and other services.

    Making Integrations Matter

    As organizations delve deeper into clouds and digital interconnectivity, a more nuanced approach that incorporates both passive and active observability is in order. This approach makes it possible to emulate a user journey and quickly identify problem points. A business can detect problems as they pop up—after only a handful of failed transactions—rather than thousands or even tens of thousands of transactions later.

    With a best-practice observability and remediation framework in place, an enterprise can establish baselines and triggers for alerts and notifications. It can assemble a complete picture within a single pane of glass and troubleshoot across the delivery chain. Whether the API involves a collaborative task within the organization or a financial transaction that stretches across several companies, it’s possible to view the entire transaction—and experience.

    With both passive and active monitoring in place, a business can evolve beyond constant fire-fighting mode. Armed with the information and insight required to make vendors more accountable, businesses ensure they are getting the level of service (SLA) they are paying for. Make no mistake, as digital transformation initiatives accelerate and cloud complexity grows, it’s critical to ensure that APIs, microservices and other digital components are up to speed.

  • How Visibility Helps Devs Focus on Innovation

    How Visibility Helps Devs Focus on Innovation

    As software engineering leaders adjust to a future defined by remote and hybrid work models, they are shifting priorities in the organization of work to compensate for the lack of in-person collaboration. According to a recent study conducted by Jellyfish, the top priority for engineering leaders is ensuring that each member of their team is focused on the highest-priority work for as much time as possible. To achieve this goal, these leaders are using real-time visibility and data-driven decision-making to guide more effective management.

    Earlier this year, Jellyfish analyzed the work of more than 23,000 engineers and surveyed hundreds of leaders to better understand the current state of engineering management. The research revealed that engineering leaders are shifting resources away from reactive work—such as responding to customer-reported bugs—to the type of work that directly impacts top-line revenue. Additionally, engineering teams are emphasizing growth and innovation, developing the type of infrastructure that will enable their teams and their software to scale long-term.

    Prioritizing Visibility

    To shift from reactive to proactive work, engineering leaders must first have visibility into what their teams are doing. How can you allocate your time and resources more effectively if you don’t know how they’re being allocated today? Before work can be prioritized effectively, leaders must understand how much bandwidth their teams have to take on new projects. Additionally, they need data-backed insights in order to align the priorities of the engineering team with those of the company at large.

    Visibility is also key to avoiding work that wasn’t part of the plan. According to the study, teams spent 22% of their time on unplanned work in 2021, a 15% increase year-over-year. This trend indicates that engineering leaders may not realize when certain types of work are taking attention away from mission-critical initiatives. When asked to name their biggest challenge heading into 2022, 45% of leaders (by far the largest group) selected “making sure everyone is focused on the highest priority work.”

    To gain visibility into their operations, some engineering teams are doubling down on data aggregation and analysis. According to the report, while all organizations tend to devote similar amounts of time to “keeping the lights on” and customer support activities, those that invest in a more robust data organization are able to spend 29% more time on innovation and 48% less time on unplanned work.

    Building Through Data and Metrics

    The report also found that engineering leaders who’ve embraced data-driven decision-making are seeing more productive, healthy and focused teams. These organizations tend to release code more quickly and foster higher collaboration than their peers. Conversely, organizations that don’t prioritize data-driven decision-making are more likely to experience burnout, decreased productivity and less focus on innovative work.

     

    Here again, the difference between embracing data and ignoring data comes down to technology. Aggregating data and metrics manually can be tedious and challenging. However, emerging tools are able to automatically collect, measure and analyze data to offer insights on what teams are prioritizing. As a result, leaders can more easily align engineering work with business priorities, ensure more predictable development cycles, increase financial responsibility and continuously improve operations.

    For every engineering leader, nailing this approach to data will be essential for maintaining efficiency as teams expand. More than 79% of engineering leaders expect to grow the size of their teams in 2022, and respondents named employee onboarding ramp time, virtual onboarding and hiring among the most significant challenges they face.

    Despite the numerous challenges engineering teams have endured in the past two years, the industry has adapted and become more collaborative as remote and hybrid work models multiply. For leaders who seek to increase data-driven decision-making, new tools and approaches will result in more intentional engineering work and improved visibility and operations.