Category: Business Value

The Truth About “Ghost Engineers”: A Critical Analysis

The Truth About “Ghost Engineers”: A Critical Analysis

Disclaimer:
This article is not intended to discredit Boris Denisov, Stanford University, McKinsey, or any other entities referenced herein. I hold immense respect for their contributions to research and industry discourse. While findings like these may resonate with practices in FAANG companies, large organizations, and mature startups, this critique seeks to explore the broader implications of relying on narrow metrics to evaluate productivity in software engineering.

The “Ghost Engineer” Narrative

The term “ghost engineers,” popularized by a recent Stanford study, describes software engineers who allegedly contribute minimally to codebases. Analyzing data from over 50,000 engineers, the study concludes that 9.5% of engineers fall into this category, with the prevalence rising to 14% among remote workers​.

While the findings spark interesting discussions, they rely heavily on the flawed assumption that code commit frequency equates to productivity. As I argued in No, McKinsey, You Got It All Wrong About Developer Productivity, this narrow perspective risks undervaluing critical aspects of software engineering that don’t leave a visible footprint in version control systems​​.

Unintended Amplification: The Snowball Effect

One of the most significant risks of such conclusions—especially before peer review—is their unintended amplification. Articles on Yahoo, TechCrunch, and Newsday have already simplified these findings, creating narratives that could ripple through the industry:

  1. Unnecessary Layoffs: Misinterpreting data might lead organizations to hastily classify engineers as unproductive, ignoring less visible but valuable contributions.
  2. Remote Work Stigma: By associating remote work with reduced productivity, these claims risk undermining one of the most effective workforce models when well-managed.
  3. Toxic Metrics Culture: Over-reliance on activity metrics like commit counts can encourage engineers to game the system by prioritizing volume over meaningful work, as discussed in Business Value Delivery by Engineering Teams in Startups (Part 2)​.

History offers cautionary examples, such as McKinsey’s controversial reliance on lines of code as a productivity measure—a practice criticized in my earlier article for ignoring the multifaceted nature of modern software engineering​​.

Engineering Productivity: Beyond Output Metrics

As outlined in Is the Myth of a 10x Developer Real?, productivity in software engineering extends far beyond raw output. Effective engineers don’t just code—they align stakeholders, resolve ambiguity, and reduce future risks. These invisible contributions often lead to:

  • Improved Collaboration: Engineers who mentor, review code, or resolve cross-team dependencies amplify the impact of their teams.
  • Strategic Outcomes: Refactoring technical debt or implementing security frameworks might reduce visible code output while significantly improving system health​​.

Commit Frequency Misses Critical Context

  • Quality Over Quantity: A single commit that eliminates 1,000 lines of redundant code can be more impactful than 10 minor feature updates.
  • Diverse Roles: Roles like DevOps, QA, and security often contribute indirectly to engineering success but rarely generate frequent commits.

By focusing solely on visible metrics, we risk reinforcing flawed incentives, a point I emphasized in Business Value Delivery by Engineering Teams in Startups (Part 1)​​.

Analyzing the Stanford Study’s Claims

Claim 1: Engineers with Low Commit Activity Are Unproductive

Rebuttal: This assumption ignores the cognitive and collaborative aspects of engineering. As noted in No, McKinsey, You Got It All Wrong About Developer Productivity, activities like design discussions, documentation, and mentoring are essential but invisible in commit logs​.

Claim 2: Remote Engineers Are More Likely to Be “Ghost Engineers”

Rebuttal: Remote work relies on asynchronous collaboration, where documentation and long-term planning take precedence over immediate outputs. Simplistic comparisons risk stigmatizing effective remote models​​.

Claim 3: Low Commit Activity Correlates with Poor Team Performance

Rebuttal: High-performing teams often include specialists whose contributions are less visible but critical. For example, a security engineer resolving vulnerabilities or a DevOps engineer optimizing CI/CD pipelines may not show up in commit logs​.

Claim 4: Organizations Could Save Billions by Addressing the “Ghost Engineer” Problem

Rebuttal: Cost-cutting measures based on flawed metrics often lead to higher technical debt, increased turnover, and diminished morale. As argued in Business Value Delivery by Engineering Teams in Startups (Part 2), true cost efficiency lies in maximizing impact, not minimizing headcount​.

Impact vs Code-Commits: Understanding the Misalignment

A recurring issue with productivity metrics like code-commit frequency is their inability to reflect the true impact of an engineer’s work. The volume of code changes often says little about the value delivered, as demonstrated by the following examples:

Example 1: A Cosmetic UI Change vs. A Critical API Update

Imagine a product manager requests a seemingly simple change: update a button’s color from purple to orange. While this may sound trivial, it could involve:

  • Updating CSS libraries: A cascade of dependencies might require 1,000+ lines of revisions.
  • Testing for accessibility: Ensuring compliance with color-contrast guidelines adds complexity.
  • Regression testing: Updating snapshot tests or fixing broken visual diffs.

This cosmetic change could result in dozens of commits, each addressing a specific dependency or edge case.

Contrast this with a backend engineer’s work on the API gateway to improve application concurrency. This might involve:

  • Identifying bottlenecks: Profiling existing workloads and implementing a solution to reduce latency.
  • Optimizing database connections: Reducing round trips or improving query performance.
  • Deploying with minimal disruption: A single, concise commit could encapsulate weeks of planning and testing.

Here, the backend change’s impact far outweighs the UI update, even though it appears smaller in terms of commit frequency.

Example 2: Bulk Refactoring vs. Precise Bug Fixing

A mid-level engineer is tasked with refactoring a legacy module, updating deprecated methods, and restructuring a monolithic codebase for better readability. This effort generates hundreds of commits and thousands of lines of changes, none of which immediately improve the product’s features.

On the other hand, a senior engineer identifies and fixes a critical bug that intermittently crashes the application. The solution, a one-line code change after hours of debugging, resolves a high-severity issue affecting thousands of users.

From a commit-count perspective, the refactoring task appears more productive. However, the senior engineer’s single-line fix has a far greater immediate impact.

Example 3: Feature Addition vs. Security Enhancement

A frontend developer introduces a new feature, such as a user profile editor. This entails:

  • New UI components: HTML and CSS for the form.
  • Frontend validations: JavaScript-based constraints for data inputs.
  • Integration tests: Mock API responses for various test cases.

The addition spans 2,000 lines of code across 20 commits.

Meanwhile, a DevSecOps engineer works on a critical security vulnerability. The task involves:

  • Rotating access tokens: Updating key secrets stored in the CI/CD pipeline.
  • Implementing security headers: Adding CSPs to prevent XSS attacks.
  • Hardening configurations: Minor changes in deployment scripts to reduce attack surfaces.

Although the security enhancement generates fewer than 10 commits, its value in preventing potential breaches and compliance penalties is enormous.

Key Takeaways

  • Context Matters: Evaluating productivity requires understanding the context and complexity of the task, not just the output volume.
  • Quality Over Quantity: High-impact changes often involve fewer commits, while low-value tasks may inflate commit counts.
  • Recognizing Diverse Contributions: Engineers working on performance, security, or architecture frequently produce less visible yet highly impactful work.

This misalignment underscores the need for organizations to adopt holistic evaluation metrics that consider both quantitative output and qualitative impact. By focusing on the latter, teams can better recognize and reward meaningful contributions.

The Danger of Flawed Productivity Metrics

Simplistic metrics can have cascading negative effects:

  1. Burnout: Engineers may feel pressured to prioritize activity over quality.
  2. Stifled Innovation: Overemphasis on visible output discourages experimentation and risk-taking.
  3. Loss of Talent: Talented engineers in specialized roles may leave if their contributions are undervalued.

As emphasized in Is the Myth of a 10x Developer Real?, effective engineering is about multiplying impact, not maximizing visible output​​.

A Holistic Approach to Productivity

To address these issues, organizations must adopt nuanced evaluation frameworks:

  1. Impact-Driven Metrics: Evaluate contributions based on outcomes, such as improved system reliability or customer satisfaction.
  2. Recognize Invisible Work: Acknowledge tasks like mentorship, technical debt reduction, and long-term strategic planning.
  3. Foster a Culture of Trust: Empower teams to experiment and innovate without fear of being misjudged by flawed metrics.

Conclusion

The “ghost engineer” narrative oversimplifies the multifaceted nature of software engineering. By relying on metrics like commit counts, it risks undervaluing critical contributions and fostering unhealthy workplace dynamics. As I’ve argued across multiple articles, effective engineering teams succeed by delivering value, not just output. The industry must move beyond flawed productivity metrics and adopt more comprehensive frameworks to recognize the true contributions of every engineer.


References and Further Reading

  1. Denisov-Blanch, Y. (2024). Twitter Thread on Ghost Engineers. Retrieved from link.
  2. Denisov-Blanch, Y. (2024). Stanford Research on Software Engineering Productivity. Stanford University. Retrieved from link.
  3. Polyakov, A. (2024). Ghost Engineers—Utter Non-Sense! Medium. Retrieved from link.
  4. No, McKinsey, You Got It All Wrong About Developer Productivity. Nocturnalknight.co. Retrieved from link.
  5. Is the Myth of a 10x Developer Real? Nocturnalknight.co. Retrieved from link.
  6. Bridgwater, A. (2024). Code Busters: Are Ghost Engineers Haunting DevOps Productivity? DevOps.com. Retrieved from link.
  7. Business Value Delivery by Engineering Teams in Startups (Part 1). Nocturnalknight.co. Retrieved from link.
  8. Business Value Delivery by Engineering Teams in Startups (Part 2). Nocturnalknight.co. Retrieved from link.
  9. Long, K. (2024). Are Ghost Engineers Undermining Tech Productivity? Business Insider. Retrieved from link.
  10. Passionate Geekz. (2024). Can a Company Increase Its Market Value by Laying Off Employees? Retrieved from link.
Is NoOps the End of DevOps?

Is NoOps the End of DevOps?

Some say that NoOps is the end of DevOps. Is that really true? If you need to answer this question, you must first understand NoOps better.

Things are moving at warp speed in the field of software development. You can subscribe to almost anything “as a service” be it storage, network, computing, or security. Cloud providers are also increasingly investing in their automation ecosystem. This leads us to NoOps, where you wouldn’t require an operations team to manage the lifecycle of your apps, because everything would be automated.

Picture Courtesy: GitHub Blog

You can use automation templates to provision your app components and automate component management, including provisioning, orchestration, deployments, maintenance, upgradation, patching and anything in between meaning significantly less overhead for you and minimal to no human interference. Does this sound wonderful? 

But is this a wise choice, and what are some advantages and challenges to implementing it?

Find out the answers to these questions, including whether NoOps is DevOps’s end in this article.

NoOps — Is It a Wise Choice?

You already know that DevOps aims to make app deployments faster and smoother, focusing on continuous improvement. NoOps — no operations — a term coined by Mike Gualtieri at Forrester, has the same goal at its core but without operations professionals!

In an ideal NoOps scenario, a developer never has to collaborate with a member of the operations team. Instead, NoOps uses serverless and PaaS to get the resources they need when they need them. This means that you can use a set of services and tools to securely deploy the required cloud components (including the infrastructure and code). Additionally, NoOps leverages a CI/CD pipeline for deployment. What is more, Ops teams are incredibly effective with data-related tasks, seeing data collection, analysis, and storage as a crucial part of their functions. However, keep in mind that you can automate most of your data collection tasks, but you can’t always get the same level of insights from automating this analysis.

Essentially, NoOps can act as a self-service model where a cloud provider becomes your ops department, automating the underlying infrastructure layer and removing the need for a team to manage it.

Many argue that a completely automated IT environment requiring zero human involvement — true NoOps — is unwise, or even impossible.

Maybe people are afraid of Skynet becoming self-aware!

NoOps vs. DevOps — Pros and Cons

DevOps emphasizes the collaboration between developers and the operations team, while NoOps emphasizes complete automation. Yet, they both try to achieve the same thing — accelerated GTM and a better software deployment process. However, there are both advantages and challenges when considering a DevOps vs. a true NoOps approach.

Pros

More automation, less maintenance

By automating everything using code, NoOps aims to eliminate the additional effort required to support your code’s ecosystem. This means that there will be no need for manual intervention, and every component will be more maintainable in the long run because it’ll be deployed as part of the code. But does this affect DevOps jobs?

Uses the full power of the cloud

There are a lot of new technologies that support extreme automation, including Container as a Service (CaaS) or Function as a Service (FaaS) as opposed to just Serverless, so most big cloud service providers can help you kickstart NoOps adoption. This is excellent news because Ops can ramp up cloud resources as much as necessary, leading to higher capacity, performance & availability planning compared to DevOps (where Dev and Ops work together to decide where the app can run).

Rapid Deployment Cycles

NoOps focuses on business outcomes by shifting focus to priority tasks that deliver value to customers and eliminating the dependency on the operations team, further reducing time-to-market.

Cons

You still need Ops!

In theory, not relying on an operations team to take care of your underlying infrastructure can sound like a dream. Practically, you may need them to monitor outcomes or take care of exceptions. Expecting developers to handle these responsibilities exclusively would take their focus away from delivering business outcomes and wouldn’t be advantageous considering NoOps benefits.

It also wouldn’t be in your best interest to rely solely on developers, as their skill sets don’t necessarily include addressing operational issues. Plus, you don’t want to further overwhelm devs with even more tasks.

Security, Compliance, Privacy

You could abide by security best practices and align them with automatic deployments all you want, but that won’t completely eliminate the need for you to take delicate care of security. Attack methods evolve and change each day, therefore, so should your cloud security controls.

For example, you could introduce the wrong rules for your AI or automate flawed processes, inviting errors in your automation or creating flawed scripts for hundreds or thousands of infrastructure components or servers. If you completely remove your Ops team, you may want to consider investing additional funds into a security team to ensure you’re instilling the best security and compliance methods for your environments.

Consider your environment

Considering NoOps uses serverless and PaaS to get resources, this could become a limiting factor for you, especially during a refactor or transformation. Automation is still possible with legacy infrastructures and hybrid deployments, but you can’t entirely eliminate human intervention in these cases. So remember that not all environments can transition to NoOps, therefore, you must carefully evaluate the pros and cons of switching.

So Is NoOps Really the End of DevOps?

TL:DR: NO!

Detail: NoOps is not a Panacea. It is limited to apps that fit into existing #serverless and #PaaS solutions. As someone who builds B2B SaaS applications for a living, I know that most enterprises still run on monolithic legacy apps and even some of the new-gen Unicorns are in the middle of Refactoring/Migration which will require total rewrites or massive updates to work in a PaaS environment, you’d still need someone to take care of operations even if there’s a single legacy system left behind.

In this sense, NoOps is still a way away from handling long-running apps that run specialized processes or production environments with demanding applications. Conversely, operations occur before production, so, with DevOps, operations work happens before code goes to production. Releases include monitoring, testing, bug fixes, security and policy checks on every commit, etc.

You must have everyone on the team (including key stakeholders) involved from the beginning to enable fast feedback and ensure automated controls and tasks are effective and correct. Continuous learning and improvement (a pillar of DevOps teams) shouldn’t only happen when things go wrong; instead, members must work together and collaboratively to problem-solve and improve systems and processes.

The Upside

Thankfully, NoOps fits within some DevOps ways. It’s focused on learning and improvement, uses new tools, ideas, and techniques developed through continuous and open collaboration, and NoOps solutions remove friction to increase the flow of valuable features through the pipeline. This means that NoOps is a successful extension of DevOps.

In other words, DevOps is forever, and NoOps is just the beginning of the innovations that can take place together with DevOps, so to say that NoOps is the end of DevOps would mean that there isn’t anything new to learn or improve.

Destination: NoOps

There’s quite a lot of groundwork involved for true NoOps — you need to choose between serverless or PaaS, and take configuration, component management, and security controls into consideration to get started. Even then, you may still have some loose ends — like legacy systems — that would take more time to transition (or that you can’t transition at all).

One thing is certain, though, DevOps isn’t going anywhere and automation won’t make Ops obsolete. However, as serverless automation evolves, you may have to consider a new approach for development and operations at some point. Thankfully, you have a lot of help, like automation tools and EaaS, to make your transition easier should you choose to switch.

The 5 ways to Fail as Engineering Managers in Startups

The 5 ways to Fail as Engineering Managers in Startups

This article is a compilation of multiple years of my experience being an Engineering Manager and subsequently running the Tech Org and managing multiple Engineering Managers. I have tried to summarise and condense them.

Having a good manager can make you feel supported, can boost your career growth (and sometimes personal), and help make your team and company a happy place. On the other hand, having a bad manager can make your work-life miserable and could hinder your growth and drain you.

Engineering Managers have a huge impact on their team’s, morale, outcomes, timelines and most importantly the professional growth and help them carve a career path. But, you may have seen, heard or felt that some or most Engineering Managers are anything but the above description, right? Do you want to know the root cause of the problem?

It is the practice of making a high-performing Individual Contributor/Engineer the Tech Lead and thence to an EM!

Trust me when I say this, I have seen it multiple times. I have seen many good Engineers burn out as soon as they have people management responsibilities. An Engineer may be okay to mentor some junior devs and help them get the right design etc. But, S/he needs to have a people-first mindset to become an Effective Engineering Manager (or any of the myriad titles with the job function).

The 5 ways to Fail as an Engineering Manager!

So, assume an Engineer is looking to move into Engineering Management, the following are the pitfalls S/he should be aware of as these are the most common ways EMs fail.

1, Too much Solutioning, not enough listening.

Interestingly, this can happen both when you’re not confident as a leader and when you are too confident. We tend to focus on solutions too much instead of supporting/empowering others or listening for more context. Sometimes people only need someone to vent to and are not looking for solutions immediately. Even when they are, we can act as coaches and guide them to the solutions, helping them grow in the process so that next time they will be able to solve on their own. Even when they need an immediate solution, we might fail to get the whole context by not authentically listening to them.

Such leaders usually jump to solutions right after hearing about an issue, and even when they ask for more details and input, they are not listening authentically. They might get impatient when the discussion drags on.

There are two critical Skills to practice to overcome this pitfall. Effective Listening and asking more Leading Questions.

2. The silver bullet or the Golden Rule Fallacy

We might not be very conscious about it, but we all have a natural, default style when it comes to management. This is sculpted by our general personality, our experiences, our bosses and how they treated us and things we’ve learned along the way. As managers, we unconsciously rely on this style, and without guidance, we tend to use that style with every direct report. Even when it becomes conscious, we justify this with ‘this is who I am’ and sometimes even with core values and our self-image

Don’t “Treat others as you wish to be treated”

The above statement could be borderline Blasphemy to many people in many aspects (including cultural or religious). How could it be untrue? If most major religions/cultures preach it?

The reason for this paradox is simple, we all assume we want to be treated fair. But, fairness to me may be unfair to you and the other way around.

For example, I tend to react very well to negative stimuli, i.e: critical remarks. I use them to better myself and continuously improvise (most times, at least) whereas some other person may feel it draining, for them, the Positive Reinforcement techniques may work well.

While having strong core values is vital to being a successful leader, using a single management style just simply won’t work with all your Team Members over the years. Doing this way WILL HARM some of the Team Members (and of course hinder your performance as an engineering manager, too). The Golden Rule managers often talk about the one true way to do things. They get overprotective/defensive about their style as they face more and more challenges. They often see the failure to be with the team members who don’t respond well to their style instead of adapting to theirs. This is especially important as more and more of you’re team members tend to be Millenials.

The most obvious display of the Golden-Rule/One-Trick Managers is hiring #minimes. They hire a team full of similar styled team members. You may have recognised certain trends over the years, a very hands-on manager will not only hire, but also treasure a very hands-on problem solver by empowering them. On the other hand, a Process-oriented manager will hire their lieutenants to be fully process-driven ones.

The problem with the first example is, you’ll have an army of Debuggers, Fixers and Solvers but very few(if any) to think & execute in a scalable & sustainable way.

The problem with the second example is, you’ll have an entire team quoting the “Rule-book” to each other in no time and meanwhile, the company may be bleeding.

There is only one approach here, As managers, it’s our core job to form a good working relationship with our team members. This will require us to adapt our style or adopt new styles.

3, Low self-confidence

Yes. I meant it. I have known multiple awesome engineers in my career who started having Low Self-Confidence after they became managers.

Honestly, I have gone through it myself at various points, before climbing up the rope. The reason is also quite obvious, when I was an IC/Sr.Dev I know what was the outcome and what was the timeline and quality of deliverables was something I prided in. So, nothing was ever out of control for me (except maybe twice).

And if something exceptional happened, I can “Report” it and either get the “Scope” or “Timeline” modified and my self-worth was left unchanged. Now, as the first-time manager, I realised that I am that “Exception Handler”. Sure, I can go to my Delivery Director or Group Program Manager etc, but I am supposed to be the first line of defence from exceptions affecting the Business! This is the no: 1 cause for low self-confidence.

But, it is by no means the only one. The second most cause according to me is delayed feedback and low observability of Business Value delivered. It’s usually really hard to see our work’s positive effect, feedback loops are just too long, and cause-and-effect relations aren’t always easy to see or quantify.

People with low self-confidence usually have a hard time saying “I don’t know”, which is essential as an engineering manager. We cling to the thought that we have to know answers to everything that comes up; otherwise, we’re just not good enough.

I’ve seen some insecure managers trying to do team members’ jobs. They do this not because they don’t trust their team, but they need something they’re proficient with to feel more secure and confident. Another way for such managers to feel that they are still worth something is to be too nitpicky, for example, in code reviews or simply when giving feedback.

Among many things, all this can lead to the engineers feeling that their engineering manager is competing against them in a way. This is THE worst feeling you can give to your team and a sure way to fail as a Manager.

Be the force multiplier to the team, not another grunt.

There are proven ways to come out of this zone. Discuss with your peers (other EMs/TLs) and your Manager, open up your insecurities & fears. You will realise that this is much more common and also learn from them.

4, People or Business Attitude (as opposed to People for Business)

There are two most common styles of management, Too much Business Focus and Too Much People Focus.

There are Managers and Leaders who are only into Business and view upon their team as only “Resources”. They are driven by Goals, deadlines, KPIs and Metrics. They seemingly don’t care about their team’s wellbeing.

There are Leaders who are only into the people part of their team. They create a virtual haven for their team. They shield and protect their teams from the other parts of the company and the world at large. They seemingly don’t care about business outcomes or performance that much.

Needless to say, these two styles are diametrically opposed.

Fortunately, I have seen and worked with organisations with both styles of Management and Managers. (And believe I did pick some elements from both). In the StartUp eco-system, Boot-Strapped and bootstrap influenced organisations tend to be slightly tilted toward the People First management philosophy. And generally, organisations that are VC funded and with an aggressive growth appetite will be tilted toward the Business First management philosophy.

But universally, all leaders I have worked with accept/agree that the key to success is balancing the two approaches.

Too much focus on the business in a leader will sometimes result in that leader prioritizing short-term wins over long-term ones. Such managers will talk a lot about holding people accountable. They are generally okay in abandoning the team members who don’t fall in-line in terms of Team Commitments and Performance, instead of coaching or aligning. The cost here could be enormous. People will get burnt out quick and will leave, The company culture suffers.

Too much focus on people without the consideration that your team is responsible for the company successful can be even worse. Such leaders will position themselves as the “Gatekeepers of hell” with their team. They will defend their team no matter what and will view every discussion/motion as “the Battle of Thermopylae”!

In the end, is is not as much as balancing these views. Its actually building synergies between these two seemingly conflicting ideals. You as a leader and manager will have to find ways for your teams to grow and be successful in tandem with the business goals.

5 – Not Delegating Enough.

The most common mistakes for leaders and managers are usually focused around delegation; either a manager is delegating too much or not enough. This is especially common for an Engineering Manager. Most Engineering Managers think of themselves as a “Specalist” Engineer than a Manager, especially applicable to an EM at the early part of his career. Any manager who fails to delegate will become overloaded and fail to move the business forward. A manager who over delegates with no explanation as to why could lose the respect of their team. The key rules to live by as a manager when it comes to delegating are:

  • Only ask someone to do something you would be happy to do yourself if you had the time
  • Only delegate a task to someone who is happy to take on the task
  • Only delegate to someone is capable of completing it to a level you would be happy with yourself or can get there with quick review comments

The trick is to know when to Cascade, Delegate & Escalate!

Concluding Remark

Obviously, this list is not-exhaustive and there are other significant issues causing to failures of Engineering Managers. But, this is a Ranked list from my personal experience.

I was extremely fortunate to work with some of the best leaders and managers and each one of them has shaped my skill, style and everything in between. While mentioning my “managers”, “My Teams” over the last 8-10 years have played an equally important role in this transformation.

Also, If you’re looking forward to learn how can you be a manager/leader your team will not run away, check out this short course by Laurie Ruttimann – https://www.linkedin.com/learning/be-the-manager-people-won-t-leave/be-someone-people-trust-no-matter-what

Business Value delivery by Engineering Teams in StartUps – Part 1

Business Value delivery by Engineering Teams in StartUps – Part 1

In this multi-part post, I will try to articulate my view on the importance of business value and its delivery by engineering teams. While most of this is written from the view of a StartUp, some elements of an established organisation are also used.

Part 1: Defining Business Value & Role of Leadership in it.

Business value is a concept that can mean multiple things to multiple people and the tricky part is all of them could potentially be valid. A product manager may value a long list of features that his/her customers have demanded for months. Another Product Manager working with internal teams to improve efficiency (revenue) will value the enhancements the accounting or support team was after. While the support manager may value a more stable product to keep the customers, s/he deals with happy. 

Business value & impacts are a difficult thing to define and deliver, while it is even more difficult to measure.A collaborative effort is required to define and deliver business value, with consideration needed to ensure all voices are heard.

While most of what I will be covering in this article is typically the purview of product management, I have learned that engineering leaders have a critical role to play in this space. (Will write more on that in the next part.)

Engineering leaders bring product development experience and technical expertise to the table to provide a crucial element to the delivery of business value which I will try and explain in this article.

What is Business Value?

I would define “Business value” as any improvements to systems, processes or people that augment the products or the ability to deliver products or services to the customers, thereby increasing the revenue or experience or both. No two companies will have the same definition of business value. Forget two different companies, a company in its 5th year will have a very different perception of value to its first year. This is due to their products and customers being different and requiring different elements to add value. One company may find value in the ability to build out its new product offering quickly. While another may find value in responding to customer support requests in a timely manner. 

Due to the rapid changes around us, the things that businesses value changes often. Companies often face new challenges that require a quick response.

Be agile, be nimble” is the key phrase.

These challenges can come in the form of new product features released by competitors, or a specific feature request by a key customer, or changes in the market that render the current product/feature obsolete. Business needs or desires, therefore change just as quickly as any of these external changes.

You have probably worked for a company that comes to the engineering team with new requirements, seemingly daily?

It is not because they cannot make up their mind; It is in response to the changing business needs. This changing goalpost is one of the main reasons that Agile development practices have taken precedence from more traditional waterfall methodologies for software development. 

Velocity is everything, a report by McKinsey on how Developer Velocity fuels Business Performance will give more insights on this. A snapshot from the report is below.

Why is business value important? 

Reacting to change and delivering business value with haste is a crucial area of importance for modern businesses. All companies exist for a purpose. The majority of companies exist to return a profit for their owners (individuals or shareholders), while some companies exist to provide a social service. The critical thing to note is that they all exist to fulfil a specific purpose which guides their definition of business value. 

No matter the company large or small, if they stop innovating, and their products or services stop being relevant to society at large and market in particular, that company will whiter and eventually die.

Kodak is a prime example of this occurring in recent history. In today’s world, IT, whether it be hardware or software, is the largest driver of business value. It is therefore critical that the software engineering teams keep delivering the things that the business need to fuel their innovation.

We, as engineers, are not employed to just build that shiney app in the latest technologies, but to deliver our contribution in support of the business purpose (If not drive it!)

The importance of Engineering Leadership in Delivering Business Value

An engineering leader is, of course, a People Leader, and s/he is also responsible for the Execution, both technology and delivery of the engineering team. However there is a third dimension which often goes unrecognised, is that great engineering executives must also be great Business Leaders; they help drive alignment with other leadership/executives and shape the strategy and direction of the business itself.

It is this underutilised/forgotten element which I will try to detail here.

A People Leader & an Execution Champion:

Engineering leadership is often naively thought of as being simply a great Architect or Engineer or a Manager. But most of you already know it’s more than that. Team leadership will involve some combination of team building, culture, leadership development, and performance management.

For detailed coverage on Engineering Leadership – Please checkout my Previous Post

Most of this responsibilities will be bang in the middle of the comfort-zone of a rising Engineering Leader.  But one of the hardest things for most engineering leaders as we scale is, to continue having an accurate forecast of when products and features will be delivered – what the business always asks for.

That is partially because this bleeds into the third, and the least recognised dimension of engineering leadership.

The Missing Sauce: A Business Strategist

Engineering leadership isn’t just about delivering products faster, or making engineers more productive. It’s about guiding the team in the same direction as the business, about continuously improving, and it’s about being the voice of engineering as a part of the decision-making process of the executive team. Of course, these are all dependent on our ability to understand the work our engineering teams are doing and how it aligns to business goals.

The third dimension – Business Alignment – is often overlooked or made difficult by other executives, but is absolutely necessary for the management of a successful engineering org. This is the strategic practice of engineering management, and all operational decisions depend on it. Business alignment means ensuring your organization is focused on the right projects that align with the business’s goals. 

The Product org can detail/design and Engineering org can build as many features as they can agree on, but what/how does it matter, if they do not align with the business objectives or goals? Business alignment involves the right allocation of resources that supports business objectives, and helping to drive those business decisions of which projects are strategically important. (at itilite, this is always the First Principle)

How do we deliver business value?

So how do we actually deliver business value? Business value isn’t created by a soloist delivering a virtuoso performance, but a collaboration of the business, product, engineering and customer success teams working together to realise a shared vision. 

Below are the five ways this can take place; together, these provide a roadmap for delivering business value;

  • Define systems development strategy
  • Help business define requirements 
  • Visualise the work and prioritise
  • Schedule and communicate delivery
  • Deliver value often and get feedback

I will try to articulate through each of these one at a time and dig into a little more detail in Part 2 of this article.

Bitnami