Find out how engineering data can help you remove blockers, encourage professional growth, and empower excellence on your team.
High-quality code is critical to creating functional error and bug-free software that is easy to edit and understand. Let's look at how to measure code quality.
According to a McKinsey study of over 400 large enterprises across 12 industries, companies with high-performance engineering teams best their competition in all areas, including revenue growth, customer satisfaction, and brand perception. The evidence is so clear that the study itself is called, “How software excellence fuels business performance,” and it concludes that software development is integral to business success in all industries — retail, financial services, manufacturing, and of course, software companies, all require a strong engineering department to succeed.
Yet, many executives view their engineering departments as a “black box.” While other departments report on their success with metrics like revenue, customer retention rate, or cost of new customer acquisition, engineering metrics don’t often make it into the board deck. But engineering metrics are essential to understanding how your company is doing. They convey critical information about your company’s ability to deliver value to your customers, and your company’s potential for future success.
Plus, engineering is expensive — it’s important to know whether that’s money well-spent.
For a holistic picture of how your engineering department — and your business — is doing, you need to start tracking engineering metrics.
Our concepts of Lead Time and Cycle Time came from the field of Operations Management and Production Engineering. As such, I think it’s beneficial to all of us to maintain coherent with them and use the same semantics in Software Engineering Management as well.
Software quality metrics are essential tools in ensuring a product provides the best experience to its users. Here are some tips for (not only) data scientists.
One critical engineering metric can help you innovate faster, outrun your competition, and retain top talent: Cycle Time. It’s your team’s speedometer, and it’s the key to everything from developer satisfaction to predictable sprints. And Cycle Time has implications beyond engineering — it’s also an important indicator of business success.
That’s why we’re excited to announce the release of our new book, The Engineering Leader’s Guide to Cycle Time. For those looking to boost their team’s efficiency and productivity, we offer a data-driven approach, backed by research, case studies, and our own experience as an industry-leading Engineering Intelligence platform.
Having too much Work in Process, also known as Work in Progress (WIP), is a remarkably common issue. In my experience, management often encourages this behavior. I don’t know if it is the notion that we will get more done if we work on more things simultaneously. Or perhaps there is a fear we won’t get enough things done unless we work on several of them at once.
Ever wondered what key metrics other engineering teams are tracking? The short answer: it varies completely. Even within the same organization, different teams
I have read multiple definitions for Lead Time and Cycle Time over the last years. Recently, I shared why I prefer using the first over the later.
Engineering managers often rely on subjective clues to assess how their team is doing. But decisions made based on gut feel and imperfect measurements are less than ideal — sometimes they result in team success; other times they result in disappointment.
The secret sauce to an engineering team's success is an effective tech lead guiding the team to be on the right track.
How do you measure how well your engineering team is doing and how do you find the bottlenecks where you can improve things the most?
Processes are essential for effective management. They keep people in sync, making it possible for team members to come together and achieve a shared goal. But they’re also dangerous. Processes can create the illusion that things are running smoothly because they’re moving along according to the shared understanding of how they’re “supposed to” run.
This is the Fallacy of Process — the idea that by adding consistency and predictability to a shared workflow, a given process is inherently valuable.
Too often, process becomes canon. A team develops an effective way of doing something, then returns to that framework indefinitely, long past its expiration date.
Technical Debt is one thing, but when let to fester for too long, it can become Technical Fraud. A much more dangerous and much more insidious predator.
That technology is here to stay is an obvious duh. If and how well-prepared companies are to deal with the constant need to increase investments in technology, that’s not as simple. Another obvious axiom is that software engineers and developers are highly valuable resources. Weather having more or putting the ones you have to better use is the best approach, that is less obvious.
Software engineering metrics help daily stand-up meetings to be more productive for the team. They can become tedious or irrelevant for many developers when they frequently exceed the fifteen minutes time box or even sound like a work report.
Becoming a Tech Leader implies in more responsibilities. Your toolkit must include new skills. Besides designing, writing, and reviewing code, tech leaders must care about the team members and the overall code quality and architecture.
The four key DevOps metrics are an exciting set of measurements. They’re getting more and more relevant since the book Accelerate has been published. I firmly believe they’re essential for engineering teams seeking effectiveness and efficiency.
The software development lifecycle methodologies (SDLC) or the Systems Development Life Cycle method aids in planning the design process of the software
Becoming a manager is usually one of the biggest challenges of an engineer’s career. We are usually used to algorithms and state machines, which are predictable and have specific outputs depending on the input.
Proactive (software) engineering leadership means you’re not a firefighter all the livelong day.
As you prepare for your board meetings, you might be struggling to find some good news to share with the board. Sure, it’s a mistake to go into a board meeting pretending everything is going well — board meetings are a valuable opportunity to share your startup’s challenges and get guidance from a panel of trusted advisors.
OKRs vs. KPIs, what are the differences? That’s a common question I hear from managers of Engineering Teams. KPIs are more straightforward to explain than OKRs, which can be tricky and more complex. They don’t mean the same, although they are connected.
The performance of verification and configuration management is essential to the ARP4754A document and other avionics development documents. ARP4754A, officially titled Guidelines for Development of Civil Aircraft And Systems, is concerned with “the development of aircraft systems taking into account the overall aircraft operating environment and functions.”
In this guide, you’ll learn all about refactoring source code: the benefits, challenges, tools, and best practices, and what is the difference between refactoring and technical debt.
Most agile teams do sprint retrospectives at least once a month, to iterate and improve on their software development process and workflow. However, a lot of those same teams rely only on their feelings to “know” if they have actually improved. But you need an unbiased reference system if you want to compare how two sprints went.
Between January 29th and March 5th, we conducted a survey to get a technology landscape of the Brazilian startups and companies. We released the full report with the results of the study.
Tech lead, team lead, software architects, and engineering managers — as any developer already knows, naming is hard. Throughout the industry, those roles are as fuzzy as their responsibilities.
We need to start building the best practices across the ecosystem to maximize the value of data observability.
When I started writing a small but real growing project, I noticed that the app shouldn’t only work well but also should be well organized.
Many Engineering Managers promote Pull Requests as part of the development workflow. It’s a consolidated practice that brings lots of benefits. It consists of comparing the changes of a branch with the repository’s base branch (conventionally called master).
We have entered a critical time in the life cycle of many companies around the world. The world has shifted away from a period of immense growth, and as many struggle to meet revenue expectations, companies and their leaders face a ton of pressure both internally and externally.
If you can’t answer it, don’t worry, you’re not alone. Many engineering leaders couldn’t tell you without some significant number-crunching. Gaining visibility into performance is only half the battle though. Knowing how to interpret metrics and how to apply them to improving performance is where the magic happens. Many CEOs do not know how to align engineering metrics to business KPIs (revenue, customer retention, etc.). Bringing metrics to your board or non-technical CEO for the first time may be challenging if you are unable to help them bridge the gap.
This article is devoted to the consideration of Software Requirements Specifications, their importance in the software development process, and how they could be written. Within this article, I will pay more attention to the effective SRS template and its description.
It has become a constant temptation to praise engineering leaders and undervalue engineering managers, but maybe we shouldn’t be focusing on their differences but on correctly understanding their roles.
We’re right on the precipice of a reality that’s more agile than Agile — as we move from Agile development and a DevOps culture to autonomous development
How to Use - and NOT Abuse - Software Engineering Metrics
The most popular goal-setting frameworks — FAST goals, SMART goals, OKRs — break when it comes to the engineering department.
The cornerstone of every framework is specificity, but most engineering departments run on benchmarks and estimations that are vague, subjective, or constantly in flux. Common project measurements, like story points or t-shirt sizes, lack objectivity. And while lists of completed features are definite cause for celebration, they’re too broad to provide insight into the actual work being done by the engineering department.
To get specific, you need data. With information from your VCS, it’s possible to gain visibility into your development workflow and spot opportunities for advancement.
Subjective measurements, like t-shirt sizes and story points, can be replaced with objective metrics that are comparable across projects and teams. For example:
How do you measure quality in software engineering? I guess this is the question there will always be a debate on. There are so many approaches to this question that finding only one answer is just impossible. In this article, we will be listing the quality-related metrics that the top engineering teams have been keeping track of, and see when and how you should use them.
Engineering managers are in charge of tech teams. It means there are tens or maybe hundreds of people supporting them. Generally, they need to ensure the best practices around software development, hire and train engineering staff, align and motivate the team towards the company’s goal, manage the team’s performance, and be accountable for all technical decisions.
Every conversation I have with CTOs, Engineering Managers, and Tech Leaders eventually gets to the “Which Metrics Should We Measure?” discussion.
What’s the overall performance of your engineering team? Let’s look at how we can improve your team’s performance.
Lead Photo by Max Duzij on Unsplash
In the Atlassian playbook, it states that Sprint Retrospective’s goal is to identify how to improve teamwork by reflecting on what worked, what didn’t, and why. Usually, the meeting consists of brainstorming what the team did well and what the team needs to do better.
Recently, I read a blog post titled "VPE and CTO — The first 90 days". It’s a brief article in which James Turnbull shows a mind map with four areas that “every new technical leader needs to, at least, think about and explore when starting at a new organization.”
Technical debt metrics help you to monitor deficiencies in your current codebase. We decided to look at how they work, and pick out the best tracking tools.
This is one of the hardest lessons to learn in the Software Engineering business. It doesn't matter how good you were at doing something, or how much you accomplished, there will always be something that didn't go right.
There was that feature you hacked to meet a deadline, or that bug that took 4 days to diagnose, or that weird edge-case that flaked out, or ... And even when you didn't have any of those issues, there are the things you didn't do - the features you didn't put in, or the customer types that you didn't support, or whatever.
On average, a software development team reworks about 26% of its code prior to release. Even after accounting for necessary changes, those wasted hours can cost a medium-sized business upwards of $4.7M a year.
Still, when engineering leaders look to cut costs, they often look at departmental spending. Software licenses, discretionary expenses, and even salaries may come under scrutiny.
But not all costs come with such a clear price tag — inefficiencies in the software development process are harder to quantify, but much more expensive.
According to a 2017 DORA white paper, Forecasting the Value of DevOps Transformations, the cost of Rework in software development is staggering, setting businesses of all sizes back millions of dollars a year.
Software Engineering KPIs (Key Performance Indicators) are measurable values that indicate the progress of engineering teams’ performance towards business objectives. Therefore, they need to be consistent, broad enough to consider everyone’s effort, and, most importantly, measurable.
Take a look at some of the most interesting findings of the 2022 State of Engineering Management report, and become a better engineering manager today!
Code churn is a measure or indication of how often a file changes. It typically refers to how often a developer throws out code
Below is an excerpt from our conversation with Alex Roetter, former SVP of Engineering at Twitter, Managing Director and General Partner at Moxxie Ventures, and featured in the Netflix documentary, The Social Dilemma.
What is tech debt? How to manage it effectively? In this Engineer's Complete Guide to Technical Debt, you will learn metrics, statistics, and tools that help engineering teams accelerate the software development process.
Visit the /Learn Repo to find the most read stories about any technology.