Heads Up DevOps & Software Delivery Leaders, Here Comes EngOps

Nevo Alva
CEO

About Acumen

This article is brought by Acumen, helping dev leaders release software faster with engineering intelligence. Transform data from Jira and devop tools into insights. Learn More

Do you feel growing pains when scaling your engineering team(s)? 

Growing pains are a challenge that every team faces as the organization expands its operations and scales its employee-base. One thing I’ve noticed during my career is that even the smallest, most humble of operations always has to reorganize itself as it scales and grows. Otherwise, efficiency and productivity are lost as the company hires new teams without properly managing the scale. 

Software engineering can serve as a great example of how chaos starts when the team grows. The team leader struggles to cope with the amount of data that needs to be voluntarily inputted by each developer, is challenged to  understand who performs well and who doesn’t, and has very little visibility into how the sprint is run. Product requests for accurate delivery timelines aren’t met, and control is pretty much lost. 

Right, things continue to be delivered in most cases, but there’s little room to run continuous improvement, as no one has a clear line of sight regarding the right starting point. 

The pains only worsen in agile organizations, where there’s a demand to deliver fast without compromising on quality. 

I am totally emphatic to the frustration of VPs of engineering who continuously complain that: “I’ve increased my developer headcount by more than 20% and productivity didn’t scale. What on earth is going on?” 

Like I’ve written before, it basically boils down to the fact that when the team grows, the operational structure becomes undone and needs to be rebuilt. And it probably needs to be rebuilt with a lot more granularly-defined processes, more data to be fed and analyzed on different platforms, and more operational heavy lifting. 

Yes, growth is a double-edged sword; everytime we grow, we get a little bit less lean. Necessary evil if you ask me. 

We’re not the first to experience such challenges. Other teams and departments face the same challenges.   

Many of them confront these challenges by bringing in dedicated staff that exclusively handle the operational aspects of the organization’s varied teams. I’m talking about having a dedicated person--or team of dedicated people--in charge of the operational side of different teams. Organizations hire operations for sales, marketing and more as they mature and look for smart ways to boost productivity and efficiency.

You see as teams get down to the dirty business of reorganizing the way they work to support scale, operation teams take more and more ownership across the software cycle. I’ve seen great results take place when operations eliminate their silos and start collaborating with vertical teams in a way that helps them streamline their workflow processes. 

But before we jump into the subject of this article, Engineering Operations aka EngOps, let’s take a closer look at how the whole vertical ops ball got rolling. 

First, there was DevOps

Today, software has long since gone beyond the mere support of businesses, and now plays a central part in every aspect of business operation. From customer communication and logistics and all the way to supply chain management and operations, software has eaten the business world. And now that the mobile app and SaaS worlds have merged, software has eaten the consumer world as well. 

DevOps is a relatively new but already established discipline in the agile tech world, born out of a competitive need to develop and release software faster than otherwise possible using older methodologies and processes. DevOps is meant to eliminate the traditional silos between operations and dev teams so that engineers from both teams merge their complementary skill sets across the entire software lifecycle. This enables them to automate and scale what were previously slow, manual processes using advanced technologies and tools in a way that empowers faster software deliveries, greater reliability and more scale, alongside improved collaboration. 

DevOps emerged out of a need to mitigate between development and IT and build software that could be smoothly delivered through the CI/CD pipeline, until launched in production. It simply became too time-consuming for developers to manage all the operational stuff that came up with different cloud environments, server configurations and so forth. A need for an engineer that speaks IT emerged. And so, a new role was invented. 

A similar example of mergers between operations and other teams is found in SecOps. This collaboration, born out of an acute need to respond to the increasing cybersecurity challenges faced by many organizations, combines IT operations and security teams. This new, highly focused, niche team handles the monitoring and protection of a company’s digital assets while working from a Security Operation Center (SOC). By eliminating the silos between these two traditionally separate teams, organizations are better able to provide ongoing protection while responding faster, and more effectively, to breaches. This also reduces security risks and minimizes the costs associated with successful attacks while increasing compliance levels. 

#EngOps, The Newest Kid On The Block

Necessity is the mother of invention. This time, EngOps (engineering operations)  is about developing  an internal ability to streamline engineering operations, gain visibility and improve velocity, just like sales and marketing already have. 

EngOps introduces many advantages into the software workflow. Instead of developers bit%&ing about the need to update every step on Jira, run Github in an organized manner, and attend tiring sync meetings, EngOps handles it. Instead of having a frustrated team leader try to understand the reason behind all the delays, identify bottlenecks and figure out how to reduce risks, EngOps extends a dedicated, organized way of solving those issues.  

The point of EngOps is to better connect engineering to actual business outcomes in a way that aligns all stakeholders, improves visibility and efficiency and enhances improvement. 

So how does EngOps do that? Well, it focuses on helping managers and leaders gain more clarity into what the rest of the team is doing, improves the effectiveness of dev tools and eliminates anything that prevents engineering teams from doing what they were actually hired to do--engineer. By removing anything that slows teams down or keeps them from collaborating at top levels, EngOps does for engineering teams what DevOps does for IT teams and SecOps does for security teams--it helps them remain efficient in a scaled operation.  

EngOps was built to make the work--and lives--of the engineering leaders and the VPs at the heart of an organization’s development operations, more impactful and easier to do. By implementing advanced, new data tools that do away with all of the BS teams have to deal with on a constant basis, we’re able unlock insights that help us improve productivity and efficiency. 

At the end of the day, this translates into faster and accurate delivery, reduced risk, better software, higher competitiveness and, hopefully, happy developers. 

EngOps: A Passing Fad or the Real Deal? Here’s some evidence 

EngOps is no trendy buzzword. If you don’t believe me, a quick review of just a small sample of the current open positions for this new role reveals that many of the world’s leading companies are hot to trot for qualified individuals that can develop EngOps capabilities for them. 

Currently, as the EngOps role is still very new, job descriptions include terms such as “DevOps” or as “Software engineer”. But make no mistake; under roles and responsibilities it is clear that the position is meant to serve the purpose of continuous improvement in the development team, through automation of data collection and analysis of software delivery performance, velocity, and so forth. 

Will EngOps Live Up to the Vision? It Depends… 

EngOps is a particularly difficult position; imagine having multiple different teams that you need to support. How would you know who needs it most? 

Let's also imagine that you did decide on a place to start and there’s plenty of room for improvement (let's say that this team is constantly delayed in delivery and is always in need of more resources, while other teams seem to manage a lot more with a lot less), how would you identify the sources of those delays and bottlenecks? 

Where’s the data? 

EngOps are highly dependent on data for both examples above. Leveraging the insights it delivers can support the quick identification of the teams that need the most attention so that effort and resources are invested with them first. EngOps teams mine data from platforms such as Jira and Github in order to identify bottlenecks, project risks, net work time, misestimations, tasks with no activity for a long duration, unplanned work that entered the sprint, changes in scope, how much time was spent on commit work versus review work versus ops work, how much effort was put on bug fixes by each team of member, refactoring effort and so forth. 

Without proper data analytics at their disposal, EngOps team would be running blind and provide very little value, if at all. 

Full disclosure, we are Acumen (Hi there :).  Acumen integrates with your dev tools, automatically organizes the raw performance related data that lies in there, and then uses AI to quickly detect hidden patterns and risks from across engineering data sources that slow teams down, deteriorate efficiency and make engineers frustrated. With Acumen, VP engineering, dev teams leaders and EngOps can answer questions such as: 

  • What does the team spend its time on? Acumen highlights issues like the amount of   actual work the team invests in bug fixing vs. new features vs. refactoring, and so on.
  • Which team needs the most help? Acumen provides visibility by drilling l down into processes like the pull request review and pull request cycle time, easily while quickly identifying teams with potential inefficiencies and bottlenecks.
  • How long does it take our team to resolve high priority bugs? Acumen empowers MTTR (mean time to resolve) view which enables the teams to see the time to resolve issues by priority.
  • Why are we not meeting the sprint goals? Acumen runs  in depth analyses of the sprint presenting both a retrospective of WHAT happened while also drilling down into the root cause of WHY things happened.

Before you Go

In today’s competitive market, software based organizations are in a race to implement technology that helps them become more productive and efficient. Over the years, numerous new disciplines arose focused on removing the silos between operations so that teams can automate processes and streamline workflows that support faster deliveries of higher quality software products. DevOps, SecOps, MarkOps, SalesOps and DevSecOps are just a few examples.

EngOps is the latest discipline to emerge. As with the other new teams, EngOps is focused on merging skillsets between business operations and engineering teams so that engineering tasks are completed in a more efficient manner. With the world’s leading companies already hiring for this coveted position, it looks like that EngOps is quickly becoming a competitive advantage for forward-looking companies. 

Ready to build brilliant teams?

Get instant visibility and the actionable insights you need to maximize your dev team’s potential!

Get StartedAcumen Brand Characters

Sign up for a stream of tips and tricks for engineering Leadership