So we optimized for readability. For naming. For clarity. For structure that could be navigated by someone who didn’t write the code.

That assumption is breaking.

Code is now generated more than it is written. It is traversed by machines before it is ever read by humans. It is modified, expanded, and reorganized by systems that do not need meaningful names or carefully crafted layers to understand what is happening.

Humans are no longer the primary readers of code. We are reviewers at best. We serve as auditors for a system that is becoming increasingly self-reliant.

Despite this, we persist in optimizing as if a future developer will manually navigate the system and comprehend every line.

We are optimizing codes for the wrong audience.

The industry still treats the code as literature.

It is increasingly closer to bytecode.

And because of that, a large part of what we call “good engineering” has quietly become unnecessary. Meaning, patterns, and languages are becoming less important.

The Cost Model Has Inverted

This transformation is the shift most people haven’t fully internalized.

In the old model, writing code was expensive. Changing it was risky. Running it was relatively cheap. So we optimized everything around reducing change. We introduced patterns to isolate impact. We introduced abstractions to avoid rewriting. We introduced processes to minimize risk.

In the new model, writing code is cheap. Changing it is cheap. Running it—at scale, continuously, globally—is where cost accumulates. So the optimization target changes.

We should no longer be asking, “How do we make the code easier to maintain?” . We should be asking, “How do we make the software cheaper to run, easier to validate, and faster to evolve—even if that means rewriting it?”

We spent decades optimizing the cost of writing code. We are entering a phase where the dominant cost is running it.

DDD, Hexagonal Architecture… Were Always About Fear

SOLID principles, Domain-Driven Design, ports and adapters, hexagonal architectures…we were taught these as markers of maturity. These were taught as indicators of engineering rigor. These were taught to distinguish amateurs from professionals.

But underneath, they all share the same assumption: we don’t know what will change, and when it does, it will be expensive.

So we prepare. We abstract. We decouple. We introduce interfaces that may never have more than one implementation. We create layers of indirection to absorb hypothetical futures.

We built systems that are easy to change because changing them was hard.

AI changes that equation. We are now operating in a world where regeneration is getting cheaper faster than abstraction.

Abstractions exist to preserve structure over time. They reduce the need to change codes by anticipating variations.

Regeneration does the opposite. It embraces change. It assumes that structure is temporary and can be recreated as needed.

We Now Care More About Product Quality, Not Code Quality

We haven’t stopped caring about quality. But it’s moving from structure to behavior. The focus has shifted from code elegance to system outcomes.

Validation shifts toward runtime instead of relying entirely on compile-time guarantees. Observability becomes more important than internal structure, because what matters is not how the system is built, but how it behaves under real conditions.

We move from designing systems that are easy to understand to systems that are easy to evolve.

The source of truth shifts.

It is no longer the code.

It is the behavior of the system in production.

TypeScript, C#, and “Developer-Friendly” Languages Were a Local Optimum

We chose our languages based on developer experience.

TypeScript, C#, Python, Java… All of them share a common goal: make it easier for humans to write and maintain code.

That was the right optimization—when humans were the ones writing most of it.

Now the cost of writing code is collapsing. The marginal effort of producing another implementation, variation, or approach is close to zero when AI is in the loop.

So the axis shifts.

If developer time is no longer the dominant cost, then optimizing for developer ergonomics is no longer the dominant strategy.

What starts to matter is not how easy code is to write but how it behaves when it runs.

We spent the last two decades optimizing the authoring experience, but we are entering a phase where the dominant cost is execution.

The Return of Low-Level Thinking

This phase is where things get uncomfortable.

If code is cheap to generate and cheap to change, then performance, memory efficiency, and runtime predictability become more important.

Not because systems got bigger. But because the cost structure shifted.

The trade-off flips. We no longer optimize for developer time. We optimize for machine time.

And that naturally pulls us toward languages and paradigms we spent years abstracting away from.

We might return to low-level languages not because developers improved, but because developers matter less in the loop.

The Part Nobody Wants to Admit

A large part of modern software engineering exists to compensate for human limitations.

We built patterns to help us think. Languages to help us express intent. Architectures to help us avoid mistakes.

Those constraints were real. They shaped an entire discipline. But they are not as dominant as they used to be. If the constraints change, the practices built around them do not automatically remain optimal.

Clean Architecture didn’t become wrong.

SOLID didn’t become useless.

TypeScript didn’t become a bad language.

They became expensive.

And most of the industry hasn’t noticed yet.

🗞️ Other articles you may like

✌️ That’s all folks

I love hearing from readers, and I’m looking for feedback. How am I doing with The Engineering Tax? Is there anything you’d like to see more or less? Which aspects of the newsletter do you enjoy the most?

Use the links below, or even better, hit reply and say hello. I’d love to hear from you!

• 😍 Awesome

• 😐 Okay

• 🤮 Bad

Please don’t hesitate to connect with me on LinkedIn and send a message. I always respond to everyone!

What has not changed is everything around it.

• Decisions are still slow.

• Validation is still uncertain.

• Alignment is still expensive.

This creates a structural imbalance: the system can now produce more than it can meaningfully process.

At that point, improving speed stops being useful and just hinders the system.

What matters is how the system decides what deserves to be scaled.

1. Optimize for Learning Velocity, not Delivery Speed

Speed only creates value if it is connected to learning. Shipping faster does not matter if the system cannot determine whether what was shipped was correct. The real loop is not:

build → ship → repeat

It is:

decide → build → learn → adjust

And in many organizations, the “learn” step is the weakest.

Feedback is delayed, indirect, or disconnected from the original decision. By the time signals arrive, multiple layers of work have already been built on top of unvalidated assumptions. The system moves quickly, but without a tight connection to reality.

Improving this does not require more data, but better alignment between decisions and feedback.

Every initiative should define, upfront, what change it expects to create—whether in user behavior, system performance, or business outcomes. Feedback mechanisms should be designed to observe that change as directly as possible. When that is not feasible, uncertainty should be made explicit rather than ignored.

Research on software delivery performance consistently shows that high-performing teams are defined not just by speed, but by how quickly they can detect and recover from mistakes.

In a world of cheap execution, the advantage is not who builds faster.

It is who learns faster.

2. Design for Flow Efficiency, not Resource Efficiency

Most organizations are still optimized for keeping people busy. Maximizing utilization. Filling roadmaps. Ensuring constant activity.

This made sense when execution was expensive—when writing, testing, and shipping software required significant effort and time. But that constraint is fading. AI has reduced the cost of execution dramatically.

What hasn’t changed is how organizations are designed. Activity is no longer scarce. Attention is.

And yet, many teams continue to optimize for utilization, as if idle time were the primary risk. It isn’t. The real problem is not idle engineers—it is work that doesn’t move.

Work that sits in queues. Waiting for decisions. Waiting for alignment. Waiting for context. Waiting to be understood. This is where most time is lost.

Flow efficiency shifts the lens. Instead of asking whether people are busy, it asks whether work is progressing smoothly through the system. Whether ideas become outcomes without unnecessary friction.

This leads to very different design choices.

Smaller batches, so uncertainty and decisions surface earlier instead of accumulating. Fewer parallel initiatives, so attention is not fragmented across competing priorities. Reduced handoffs, so context is preserved and rework minimized. Clear ownership, so work does not stall in ambiguity or shared responsibility.

These are not optimizations of effort—they are optimizations of movement.

Research in lean systems and software delivery consistently shows that reducing work-in-progress and shortening queues improves system performance disproportionately. Not by increasing output, but by eliminating waiting time and coordination overhead.

Because when execution becomes fast, queues become the dominant constraint.

And most organizations are full of invisible ones.

3. Institutionalize the Ability to Say No

When execution becomes cheap, the default response is to build more. More features, more initiatives, more surface area. Work enters the system easily, almost automatically, because the cost of saying “yes” has collapsed.

But the cost of carrying what you build has not.

Every addition introduces complexity. Dependencies increase, constraints accumulate, and the system becomes harder to evolve. These costs are not immediate, which is why they are often ignored. Over time, the system doesn’t fail because it lacks capability—it fails because it has too much of it.

At that point, speed stops helping. You can still ship, but each change requires more coordination, more context, more effort. The system moves, but with increasing friction.

This is rarely framed as a consequence of saying “yes” too often, but that is exactly what it is.

In most organizations, saying no is informal. It depends on individuals, moments, and negotiation. That makes it inconsistent. Some things are rejected, many are not, and very little is ever removed.

Without removal, complexity only grows.

Research on cognitive load consistently shows that beyond a certain point, more options and features degrade both usability and decision quality. More is not neutral. It actively makes the system worse.

In a world where building is cheap, the constraint is no longer creation.

It is how much you allow into the system—and how much you are willing to remove.

Conclusion

Execution now scales easily. That is no longer where advantage comes from.

What defines the system is how quickly it learns, how smoothly work flows, and how much unnecessary complexity it avoids. These are not improvements on top of the system—they are what the system is now built around.

Organizations that continue to optimize for output will produce more.

Organizations that adapt will produce less—but with far greater clarity and impact.

Because once building becomes cheap, the real discipline is not in what you create. It is in what you choose not to carry forward.

We invested in better tooling, faster CI/CD pipelines, cleaner architectures, and platform engineering capabilities that reduced friction across the delivery lifecycle. Entire organizations reorganized around improving developer productivity, shortening lead times, and increasing deployment frequency. The assumption was simple: if we could make engineering faster, everything else would follow.

And for a long time, it did.

But something subtle has changed.

Today, teams can build faster than ever before. AI has further reduced the cost of execution, compressing hours of work into minutes and making exploration almost free. Yet despite this acceleration, most organizations are not seeing a proportional improvement in outcomes. Delivery performance is not dramatically better. Quality is not consistently higher. In some cases, stability is even degrading.

That mismatch is not accidental.

It’s a signal that we are still optimizing for a constraint that does not exist.

Engineering is no longer the bottleneck

For most of modern software development, execution was expensive.

Writing production-grade code required time, coordination, and deep expertise. Testing, integrating, and deploying safely introduced additional layers of friction. Improving these areas had a direct and measurable impact on performance, which is why so much focus was placed on optimizing them.

Frameworks like DORA reinforced this approach by showing how capabilities such as deployment frequency, lead time, and change failure rate correlated with high-performing teams. The industry responded accordingly—investing heavily in automation, DevOps practices, and platform engineering to remove bottlenecks in delivery.

Recent observations across teams show that even as execution becomes significantly faster—especially with AI assistance—system-level performance does not improve at the same rate. In fact, some studies suggest a more complex picture: while developers report feeling up to 55% faster when using AI tools, controlled experiments on complex tasks show that experienced engineers can actually become slower, as they spend additional time validating, correcting, and integrating AI-generated outputs. At the same time, broader delivery metrics show little to no improvement in throughput and, in some cases, a decline in stability.

This contradiction points to a deeper reality:

When improving one part of a system no longer improves the whole, it usually means the constraint has moved elsewhere.

The real bottleneck: coordination and decisions

Modern engineering is not a pipeline—it is a network.

Value is not created in isolation by writing code but through a continuous flow of decisions across multiple domains: product defining priorities, design shaping user experience, security enforcing constraints, compliance defining boundaries, and business stakeholders driving commercial direction. Every meaningful change in the system crosses these boundaries.

And at each boundary, coordination is required.

Research into organizational dynamics has consistently shown that as companies scale, collaboration overhead increases non-linearly. Studies on “collaborative overload” highlight how a small percentage of individuals, often in central roles like engineering leads and senior developers, become bottlenecks because they sit at the intersection of too many dependencies. At the same time, research on attention residue demonstrates that frequent context switching significantly degrades cognitive performance, reducing the quality of decision-making and increasing error rates of those individuals.

In practice, this means that a growing portion of engineering time is not spent building but navigating communication: meetings, alignment discussions, clarifications, and trade-offs.

This is where the real work happens.

Deciding what to build.
Aligning on why it matters.
Understanding how it fits into an evolving system.
And validating it affects the correct metrics in the expected way.

These activities are inherently slower, more ambiguous, and harder to optimize than execution. And unlike code generation, they cannot be easily automated.

This has always been and will continue to be a bottleneck, as it’s a system absorption problem and not a procedural optimization.

AI didn’t remove complexity—it accelerated exposure to it

AI has not simplified this system. It has intensified it. By dramatically reducing the cost of execution.

AI increases the rate at which teams can generate output. More ideas are explored, more features are started, and more changes are introduced into the system. On the surface, this looks like progress. But each of those outputs carries a hidden cost: it requires decisions, alignment, and validation.

And those layers have not accelerated because:

• Customer feedback still takes time.

• Understanding real impact still takes time.

• Aligning multiple stakeholders still takes time.

So what emerges is a structural mismatch:

• Execution operates at one speed.

• Decision-making and validation operate at another.

The result is predictable.

Teams hit the coordination bottleneck more frequently. More work enters the system than the organization can properly process. Context switching increases. Alignment becomes fragmented. And decision quality begins to degrade under pressure.

We did not remove complexity. We increased the rate at which we collide with it.

Conclusion: The constraint is now cognitive, not technical

For years, we thought the limiting factor in engineering was only technical.

How fast we could build.
How safely we could deploy.
How efficiently we could execute.

Today, that has been shown not to be the truth. The constraint is something less visible but far more fundamental: our ability to make good decisions, align across boundaries, and validate before scaling.

And most organizations are not designed for this.

They are still optimized for a world where execution was expensive and slow. A world where the primary challenge was building the thing.

That is no longer the challenge.

Now, the challenge is knowing whether the thing we are building should exist at all—and proving it before we scale it.

The interesting part is that this is becoming normal.

What used to feel like exceptional productivity is quickly turning into baseline. Features that once required days of focused work now emerge in hours. Entire systems can be scaffolded in a single sitting. The barrier between idea and implementation has almost disappeared.

And if you look at most engineering teams right now, the signals all point in the same direction: more output, faster cycles, and shorter time to code.

So why does it feel like nothing is actually improving?

Output is exploding; outcomes are not

Across teams, the pattern is hard to ignore.

Developers are shipping more code than ever before. Pull requests are increasing, backlogs are moving faster, and the visible indicators of productivity are trending up. On dashboards and status reports, it looks like acceleration.

But when you step back and look at the system as a whole, the picture becomes less convincing.

Quality is not improving in a meaningful way. Delivery performance remains largely unchanged. In many cases, rework is quietly increasing. The system absorbs more activity, but it does not translate into better outcomes.

This is not just anecdotal. Early data is starting to surface a contradiction. Some studies show developers feel significantly more productive—reporting perceived speed increases of over 50% when using AI tooling. At the same time, controlled experiments on complex tasks show performance can actually degrade, particularly for experienced engineers. And broader delivery metrics show little to no improvement in throughput, with stability in some cases declining.

At the individual level, everything feels faster.
At the system level, nothing really moves.

That is the paradox.

AI optimized execution, not decisions

The reason becomes clearer when you separate two layers that are often conflated: execution and decision-making.

AI has dramatically improved execution. Writing code, generating tests, exploring implementations—these activities are now cheaper, faster, and easier than ever before. The friction that once slowed down development has largely been removed.

But the hardest part of engineering was never execution.

It was deciding what to build, why it matters, and how it fits into a broader system of constraints. It was aligning multiple stakeholders with different incentives. It was designing systems that could evolve without collapsing under their own complexity.

None of that has changed.

Modern engineering is not a linear pipeline; it is a network of interdependent decisions spanning product, design, security, compliance, and operations. Value is created—or destroyed—at the boundaries between these domains. And those boundaries are still governed by coordination, judgment, and trade-offs.

Research consistently shows that as organizations scale, these coordination costs grow faster than the teams themselves. More stakeholders, more dependencies, more alignment overhead. In many environments, the majority of time is already consumed by communication, meetings, and context switching rather than actual building.

AI does not remove this complexity.

It simply makes it easier to execute whatever decision has already been made.

You can now scale bad decisions

This is where the dynamic becomes dangerous.

When execution was expensive, it didn’t just slow teams down—it created space for validation. Building something took time, and that time allowed reality to catch up. Teams could observe how features behaved in the wild, understand trade-offs, and adjust direction before moving forward.

That constraint is now gone. Execution is nearly instantaneous, but validation is not. Customer feedback still takes time. Business impact still takes time. Understanding whether something actually works still takes time.

So we’ve created a mismatch. Decisions are made quickly. They are implemented even faster. But they are validated at the same speed as before.

That means teams are now chaining decisions that haven’t proven themselves yet. A feature is extended before its value is clear. A direction is reinforced before it’s tested. An assumption becomes a roadmap before it becomes evidence.

What used to be a sequence of build → learn → adjust is quietly turning into build → build → build. We are not just scaling bad decisions. We are scaling unvalidated ones. And the more we accelerate execution without closing that validation loop, the weaker the connection becomes between what we build and the value it creates.

More output doesn’t mean more impact. It just means we are moving faster on assumptions we haven’t yet earned the right to trust.

Conclusion: The bottleneck has moved

For years, engineering was constrained by execution. Now it isn’t. We can build faster than ever before. But we cannot validate, align, or decide any faster than the systems around us allow.

And that creates a new kind of bottleneck.

Not in code.
Not in tooling.
But in understanding.

The ability to decide what matters.
The ability to align around it.
The ability to validate it before scaling it.

That is now the limiting factor.

And most teams are still optimizing for the layer that stopped being the constraint.

In the next issue, I’ll break down where the real bottleneck is hiding—and why most organizations are not designed to handle it.

As organizations scale, governance expands. Reporting structures multiply, compliance requirements mature, alignment rituals increase, and cross-functional touchpoints become more frequent. None of this is inherently problematic. In fact, process often emerges to reduce chaos and increase predictability.

However, there is a tipping point.

At a certain stage of organizational growth, engineering leaders begin to notice a structural shift: the majority of their time is no longer invested in enabling value creation or shaping long-term direction. Instead, it is absorbed by coordination, documentation, reporting, and operational synchronization.

This is the moment the process starts eating the day. The risk is not that the process exists. The risk is when the process begins to systematically displace strategic and value-generating work.

The paradox is clear: process is introduced to support value creation, yet beyond a certain threshold, it competes with it.

Governance in Growing Environment Normally Becomes Self-Reinforcing

As organizations grow, process layers are often added in response to past incidents or perceived risk. Rarely are they removed. Over time, leaders inherit overlapping rituals, redundant reporting, and duplicated reviews.

Research on digital transformation from McKinsey indicates that complexity is a primary cause of execution failure in scaling organizations. High-performing digital companies actively simplify decision-making and reduce unnecessary procedural friction.

When process expansion is not accompanied by intentional simplification, it gradually dominates leadership bandwidth as governance complexity compounds over time.

Engineering leaders become coordinators of governance rather than designers of systems.

Value Work vs. Process Work

To understand the tipping point, it is useful to distinguish between two categories of leadership effort:

Value-oriented work includes:

• Architectural & strategic direction setting

• Technical & non-technical prioritization

• Developer experience improvement

• Talent development and mentoring

• Long-term system design

Process-oriented work includes:

• Status reporting

• Governance documentation

• Compliance questionnaires

• Budget control & updates

• Recurrent alignment meetings

• Escalation handling

Both categories are necessary. However, only one category compounds long-term engineering capability.

Beyond the time allocation, there is also a cognitive dimension to this problem. As value-oriented tasks require uninterrupted cognitive bandwidth. When leadership calendars are saturated with 30-minute blocks dedicated to reporting, coordination, and alignment, deep thinking becomes fragmented.

The result is not immediate failure, but a slow erosion of strategic clarity:

• Architectural decisions become reactive.

• Technical debt accumulates incrementally.

• Innovation slows.

• Platform investments are deferred.

The organization continues operating, but its engineering foundation weakens. In engineering leadership, process overload does not merely consume time; it reduces strategic depth.

The Strategic Opportunity Cost

The most significant cost of process saturation is opportunity cost.

Time invested in incremental reporting is time not invested in:

• Platform modernization

• Reliability engineering

• Developer productivity tooling

• Technical innovation

• Architectural resilience

These investments may not generate immediate visibility, but they determine long-term competitiveness.

DORA research demonstrates that elite-performing engineering organizations achieve both higher velocity and stronger stability. This dual capability is not accidental; it results from consistent investment in foundational engineering practices.

If leadership capacity is absorbed entirely by governance management, the organization risks optimizing for short-term coordination while sacrificing long-term capability.

Restoring Balance: Designing for Strategic Capacity

The solution is not eliminating the process. Governance is necessary in complex systems. The objective is balance.

Periodic process audits are important. Every recurring meeting and reporting requirement should be evaluated against a simple question: does this materially improve decision quality or reduce meaningful risk?

If not, it should be simplified or removed.

Protecting strategic bandwidth is not optional. It is a prerequisite for sustainable engineering performance.

Conclusion

The moment the process work starts eating the day is rarely dramatic. It is incremental. A few more meetings. Additional reporting cycles. Expanded review layers. Increased cross-functional synchronization.

Over time, the cumulative effect is substantial.

Engineering leadership requires governance, but it also requires protected space for value creation and strategic direction.

When process displaces strategy, long-term engineering capability erodes.

The responsibility of engineering leadership is not to resist governance but to prevent it from overwhelming the system it was designed to support.

Sustainable organizations do not eliminate process. They design it intentionally and defend the time required to build the future.

In technology-driven organizations, engineering is not merely a delivery function — it is the execution engine of the business. Strategic ambition, product vision, commercial commitments, regulatory obligations, and operational reliability ultimately depend on engineering capacity.

As organizations scale, this structural dependency becomes increasingly visible. Engineering leaders often experience a shift in role: from managing teams and technical systems to managing organizational interdependence. The realization that “engineering is everyone’s dependency” reflects how modern companies are architected.

Research supports this structural centrality. The DORA (DevOps Research and Assessment) “Accelerate State of DevOps” reports, now published by Google Cloud, consistently show that high-performing engineering organizations outperform peers in profitability, productivity, customer satisfaction, and resilience.

Similarly, McKinsey research on technology performance indicates that companies with strong engineering and digital capabilities significantly outperform competitors in revenue growth and operating margin.

When engineering performance correlates directly with business outcomes, dependency intensifies. That dependency introduces both leverage and complexity.

Engineering as the Organizational Convergence Layer

In digital-first companies, every major initiative requires engineering participation:

• Product strategy must be validated against technical feasibility.

• Sales commitments require implementation capacity.

• Security and compliance frameworks require system-level integration.

• Financial efficiency initiatives often depend on architectural optimization and automation.

Cross-functional coordination has grown accordingly. A Harvard Business Review analysis on collaboration overload by Rob Cross and colleagues found that time spent on collaborative work has increased dramatically over the past two decades, often consuming more than 50% of managers’ time. In environments where engineering sits at the center of execution, this coordination burden is amplified.

The dependency of multiple functions on engineering does not inherently create dysfunction. However, it does create a system in which engineering leaders must continuously reconcile competing priorities within finite capacity constraints.

The Leadership Role as Translation and Integration

As cross-functional dependency increases, the engineering leader’s role evolves toward translation and integration.

This translation includes:

• Commercial urgency into technical feasibility

• Regulatory requirements into implementation scope

• Architectural constraints into business timelines

• Operational risk into product decisions

Each department operates under distinct incentives. Sales may optimize for quarterly revenue. Product may optimize for feature velocity. Security may optimize for risk minimization. Finance may optimize for cost predictability.

Research on organizational misalignment suggests that cross-functional friction increases when incentive systems are not synchronized, for example Harvard Business Review has documented how siloed performance metrics create coordination inefficiencies.

Meaning engineering leaders must therefore create shared decision principles that align incentives around system-wide outcomes rather than local optimization. Without a structured translation, engineering becomes reactive.

Finite Capacity in a System of Expanding Demand and its Cognitive Fallout

One of the defining characteristics of engineering dependency is simultaneous urgency. Growth initiatives, enterprise deals, compliance obligations, reliability improvements, and platform modernization all present as high priority.

However, engineering throughput is bounded. The Theory of Constraints, introduced by Eliyahu Goldratt, provides a useful systems lens: in any production system, throughput is limited by its bottleneck. In software organizations, engineering frequently becomes that constraint.

Empirical research reinforces this. The DORA research program highlights that elite-performing teams focus on improving flow efficiency and limiting work in progress rather than maximizing parallel initiatives. Organizations that attempt to advance too many simultaneous priorities experience degraded delivery performance.

When engineering is everyone’s dependency, the leadership challenge shifts from evaluating importance to sequencing work deliberately.

As dependency increases, so does coordination load. Research on “collaboration overload” shows that high-performing individuals often become central nodes in communication networks, leading to disproportionate demand on their time.

Engineering leaders frequently occupy these central positions. Their involvement is requested in roadmap alignment, incident reviews, enterprise negotiations, hiring decisions, governance discussions, and architectural trade-offs. Yet deep technical and strategic thinking requires sustained focus.

Additionally, studies on multitasking and context switching in cognitive psychology demonstrate measurable declines in efficiency and increased error rates when individuals switch frequently between tasks.

If unmanaged, structural dependency can erode strategic bandwidth. Leaders become responsive rather than directional.

Dependency as Organizational Leverage

Dependency is not inherently a liability. It is a form of leverage. However, leverage does not imply universal ownership.

A common failure in scaling organizations is conflating technical dependency with total accountability. Because engineering enables execution, other functions may gradually transfer policy, risk, or coordination ownership to engineering. Over time, engineering becomes the default owner of decisions that properly belong elsewhere.

Effective governance requires explicit distribution of ownership:

• Security owns policy and risk appetite.

• Compliance owns regulatory interpretation.

• Product owns prioritization intent.

• Commercial functions own revenue commitments.

• Engineering owns architecture, implementation, and system integrity.

Engineering is frequently consulted, but consultation is not equivalent to full domain ownership.

Collaborative research further demonstrates the risk of concentration. Studies on collaboration overload show that central actors absorb disproportionate coordination demand.

Without structural safeguards, clear intake processes, explicit decision rights, work-in-progress limits, and capacity visibility, leverage degrades into overload.

Conclusion

Engineering centrality is not a theoretical claim; it is an observable structural feature of modern enterprises. As revenue, compliance, and operations become software-mediated, engineering performance directly influences business outcomes.

Research across DevOps performance (DORA), digital transformation (McKinsey), collaboration science (Harvard Business Review), and cognitive psychology converges on a consistent finding: unmanaged demand and ambiguous ownership reduce organizational effectiveness.

Sustainable leverage requires defined interfaces.

Engineering enables execution across domains, but accountability must remain with their respective functions. When ownership boundaries blur, coordination load concentrates, context switching increases, and system performance degrades.

Engineering is a core operating layer of a company, and its effectiveness depends not only on technical excellence but also on governance design that balances central integration with distributed accountability.

I was navigating the same things I was trying to write about:

• Scaling pressure.

• Coordination overload.

• Process multiplying faster than value.

• The quiet emotional weight of leadership.

And I found it hard to give recommendations while I was still inside the fog. It felt dishonest to write “how to lead clearly” when I was figuring it out myself. So I stopped.

Over this last year, something clicked. The problem wasn’t a lack of ideas. It was that I was trying to write about leadership as if it were clean and structured.

It isn’t.

Engineering leadership at scale is messy. It’s trade-offs. It’s governance creep. It’s explaining why output isn’t outcome. It’s protecting teams from becoming process administrators. It’s absorbing pressure so others can build.

That’s when the name became obvious.

This newsletter is no longer Leadshorizons.

It’s now:

The Engineering Tax

Because that’s what I’ve been living.

The tax of coordination.
The tax of growth.
The tax of AI hype.
The tax of emotional load.
The tax nobody budgets for.

This is not a newsletter about perfect frameworks.

It’s about:

• The real cost of scaling engineering

• Revenue per person over vanity metrics

• AI as leverage, not magic

• Leadership under cognitive and political pressure

• And the uncomfortable truths we don’t post about on LinkedIn

If you’re leading engineering in a growing company, you’re paying the tax already.

The question is, are you aware of it? And are you getting a return?

I’m writing again — not because I figured everything out. But because I’ve lived enough of it to speak honestly.

Welcome to The Engineering Tax.

Definition of feedback

Let's take the definition from wikipedia:

Feedback occurs when outputs of a system are routed back as inputs as part of a chain of cause and effect that forms a circuit or loop. The system can then be said to feed back into itself.

This type of feedback requires an event to occur before it can become an input for future iterations. In human interactions, we typically think of Corrective feedback:

A practice that typically involves a learner receiving either formal or informal feedback on their understanding or performance on various tasks by an agent such as teacher, employer or peer(s). To successfully deliver corrective feedback, it needs to be non-evaluative, supportive, timely, and specific

While this sounds great, it’s not always a silver bullet.

The weak point of feedback

While this definition seems straightforward, complexity arises when two or more parties engage in conversation. A feedback system emerges, creating a snowball effect through the conversation's cause-and-effect nature:

Simple causal reasoning about a feedback system is difficult because the first system influences the second and second system influences the first, leading to a circular argument. This makes reasoning based upon cause and effect tricky, and it is necessary to analyze the system as a whole. As provided by Webster, feedback in business is the transmission of evaluative or corrective information about an action, event, or process to the original or controlling source.

— Karl Johan Åström and Richard M.Murray, Feedback Systems: An Introduction for Scientists and Engineers

We can represent this with the next graphic:

This dynamic often leads to a situation where the feedback provider includes their personal views on the receiver's output, introducing bias or prejudice into the system. As a result, what should be feedback becomes merely an opinion or judgment.

The difference between Feedback, Judgment & Opinion

While we've defined feedback, there are related concepts that often get confused with it:

1. Opinion: An opinion reflects a perspective or feeling about something, often based on personal beliefs, experiences, or interpretations. Unlike feedback or judgment, opinions are subjective and can vary depending on the individual's circumstances or emotions. Opinions are less formal and more likely to be influenced by personal viewpoints rather than objective analysis.

2. Judgment: Judgment involves evaluating situations, analyzing information, and making decisions based on reasoning or experience. It is often based on facts, logic, and critical thinking, but it's also influenced by personal biases, emotions, or values. Judgment is more structured and reasoned compared to an opinion.

As humans, we find it challenging to provide pure feedback, since we're not machines. Our own biases and prejudices influence our input. When communicating, we tend to over-explain and insert our views about what the next iteration should be.

Ensure feedback remains untainted by the observer's perspective

Like many complex problems, the solution lies in simplification. Here, we can remove layers of bias and prejudice by leveraging the recipient's capacity for self-reflection.

Why this approach avoids bias:

• Neutral perspective: Reflection allows you to observe the situation and the person's reaction without pre-judging or assigning blame.

• Person focus: You prioritize their feelings, intentions, and growth over your own insecurities.

• Fairness: The feedback is shaped by understanding rather than simply critiquing.

This approach creates a safer environment for growth while ensuring that feedback remains genuine and less influenced by personal biases. This reflective practice also encourages the person receiving 'feedback' to take ownership of their learning.

Final Thoughts

Feedback is often celebrated as a powerful tool for growth, but its true effectiveness depends on how it’s delivered. While some may claim to provide feedback, the focus on feelings, fairness, and authenticity can make all the difference in fostering genuine improvement. By prioritizing understanding over critique, we create safer spaces for learning and ensure that feedback remains meaningful and impactful. Ultimately, the best feedback empowers individuals to take ownership of their development while encouraging continuous progress.

With this said, I am not good at feedback. I also try not to claim that I provide feedback to others. The fact of pushing thoughts to others is itself a selfish thing. If you really care, ask the person to reflect on the situation and explore their own self-awareness.

👋 Let’s connect

You can find me on LinkedIn, Bluesky, or Mastodon.

I share daily tips to level up your skills and become a better manager.

You can also hit the like ❤️ button at the bottom to help support me or share this with a friend. It helps me a lot! 🙏

In many organizations, systems operations teams are often segmented into specialized units such as DBA, backend operations, networking, etc. While this specialization ensures deep expertise and support to teams in complex situations. It also leads to inefficiencies as it focuses on the reactiveness to the needs of the teams & company and not a proactive approach towards the same long-term needs due to the lack of common vision. It also has the drawback that enforces the dev vs ops culture and not a DevOps culture that has shown over and over again the positive effect on quality and speed of delivery of stream-aligned teams.

’DevOps’ or ‘Dev vs Ops’

Traditionally, Dev and Ops teams have operated in silos, each with their own distinct goals and priorities.

Focus Priorities Dev Culture Development teams are primarily focused on creating new features, writing code, and ensuring the software meets user requirements. Speed and innovation Ops Culture Operations teams are responsible for maintaining the stability, security, and performance of the software in production environments. Reliability and uptime

This separation can lead to several challenges:

• Communication Barriers: Lack of communication between Dev and Ops can result in misunderstandings and delays. Developers may not fully understand the operational constraints, while Ops may struggle with the rapid pace of development.

• Conflicting Goals: Developers prioritize speed and innovation, while Ops prioritize stability and reliability. These conflicting goals can create friction and hinder collaboration.

• Inefficiencies: Siloed teams often duplicate efforts and use different tools, leading to inefficiencies and wasted resources.

The DevOps Solution

The goal of DevOps is to create a culture of ownership to stream aligned teams to do development and operations, breaking down traditional silos and fostering a more integrated approach to software delivery. While the existing operations teams become a provider of abstractions that simplifies that work, reducing the cognitive load of operating the system.

This brings the next benefits:

• Enhanced Collaboration: Breaking down silos fosters a culture of collaboration, enabling teams to work together more effectively and share knowledge.

• Improved Efficiency: Streamlined workflows and standardized tools reduce redundancy and improve operational efficiency.

• Greater Innovation: A unified approach allows teams to quickly adapt to new technologies and methodologies, driving innovation and continuous improvement.

• Customer-Centric Approach: By aligning development and operations goals, teams can better understand and meet the needs of end-users, resulting in higher customer satisfaction.

The Birth of the Platform Team

A platform team acts as a service provider for all internal stream-aligned teams, offering essential tools, infrastructure, and support to streamline their work and enhance productivity. We could start enumerating systems and solutions that a platform team can own. But the reality is that would be the same as creating a product without doing any research on your clients.

To truly drive value within an organization, a platform team must deeply understand and address the needs of stream-aligned teams. These teams are directly responsible for delivering products and services to customers, and their success hinges on the support and resources provided by the platform team. Here’s how a platform team can effectively drive value by focusing on the needs of stream-aligned teams:

• Active Engagement and Communication: work collaboratively with stream-aligned teams to develop solutions that address their specific pain points, fostering a sense of shared responsibility and mutual support.

• Continuous Improvement and Innovation: Implement iterative development practices to continuously refine and improve tools and services.

• Metrics and Performance Tracking: Establish key performance indicators (KPIs) to measure the effectiveness of the platform team’s support and use data-driven approaches to make informed decisions about resource allocation and process improvements.

• Empowerment and Autonomy: Develop self-service platforms that empower stream-aligned teams to manage their own resources and workflows, and provide comprehensive training and support to ensure proficiency in using the tools and services offered by the platform team.

The key benefits this strategy tries to achieve are:

• Efficiency: By centralizing infrastructure management, tooling, and support, the platform team reduces redundancy and improves operational efficiency. Stream-aligned teams can focus on delivering value to customers without worrying about underlying infrastructure.

• Consistency: Standardized tools and processes ensure consistency across the organization, making it easier to manage and scale applications.

• Reliability: A dedicated platform team ensures that the infrastructure is reliable and secure, minimizing downtime and enhancing the overall stability of applications.

Closing thoughts

By fostering a culture of ownership and collaboration, and by providing abstractions that simplify operations, the platform team can significantly reduce the cognitive load on stream-aligned teams. This transformation brings enhanced collaboration, improved efficiency, greater innovation, and a customer-centric approach, ultimately driving the success of the organization.

As we continue to evolve, the key to driving value lies in deeply understanding and addressing the needs of stream-aligned teams. Through active engagement, continuous improvement, metrics tracking, and empowerment, the platform team can ensure that stream-aligned teams are equipped to deliver exceptional products and services to our customers. This strategy not only centralizes infrastructure management and standardizes tools but also ensures reliability and consistency across the organization, paving the way for sustained growth and success.

Why Transparency Matters

Transparency in leadership is about being open, honest, and straightforward with your team. It involves sharing information, explaining decisions, and being clear about expectations and goals. This openness builds trust, fosters a culture of accountability, and encourages open communication.

When leaders are transparent, they create an environment where team members feel valued and respected. They know that their leaders are not hiding anything from them and that they can rely on the information provided. This helps to:

• Building Trust and Credibility: Trust is not something that can be demanded; it must be earned. By being transparent, you demonstrate integrity and honesty, which are crucial for building credibility.

• Encouraging Open Communication: When team members see that their leaders are open and honest, they are more likely to reciprocate. This creates a culture where everyone feels comfortable sharing their ideas, concerns, and feedback.

• Fostering Accountability: When you are open about your own performance and hold yourself accountable for your actions, you encourage your team to do the same. This culture of accountability leads to higher performance and continuous improvement.

• Enhancing Employee Morale and Engagement: Employees who work in a transparent environment are generally more satisfied and engaged. They appreciate knowing that their leaders are honest and forthcoming, which creates a sense of security and belonging. When employees feel informed and included in the decision-making process, they are more likely to be committed to the organization's mission and values.

Transparency in a Healthy Chain of Command

A healthy chain of command relies heavily on transparency. In a transparent organization, information flows freely up and down the hierarchy. Leaders at all levels are open about their decisions, goals, and challenges, which ensures that everyone is aligned and working towards the same objectives.

When transparency is lacking, it can lead to misunderstandings, mistrust, and a breakdown in communication. Team members may feel left out of the loop, leading to disengagement and decreased morale. On the other hand, a transparent chain of command fosters a sense of unity and collaboration, as everyone is aware of their roles and how they contribute to the organization's success.

The Importance of Avoiding Secrecy in Strategic Decisions

While there are instances where strategic secrecy is necessary, it's equally important to recognize the potential downsides of keeping strategic decisions hidden from your team. Transparency in strategic decision-making can significantly enhance trust, engagement, and overall organizational performance.

Here’s why avoiding secrecy in strategic decisions is crucial:

• Enhancing Trust and Engagement: When leaders are transparent about strategic decisions, it builds trust within the team. Employees feel valued and respected when they are kept in the loop about the direction of the organization. This trust fosters a sense of ownership and commitment, leading to higher levels of engagement and motivation. Research has shown that organizations with high levels of trust and transparency tend to have more engaged employees, which directly correlates with improved performance and lower turnover rates.

• Improving Decision Quality: Transparency in strategic decision-making encourages diverse perspectives and input from various levels of the organization. When employees are aware of the strategic direction and the reasons behind it, they can provide valuable insights and feedback that might not have been considered otherwise. This collaborative approach leads to more informed and well-rounded decisions, ultimately benefiting the organization.
  For example, a study by Harvard Business Review found that companies that involve employees in strategic planning processes are more likely to achieve their goals and adapt to changes effectively. By avoiding secrecy, leaders can tap into the collective intelligence of their team, leading to better outcomes.

• Preventing Misinformation and Rumors: Secrecy can often lead to misinformation and rumors, which can be detrimental to organizational morale and cohesion. When employees are left in the dark, they may speculate and create their own narratives, which can lead to confusion and mistrust. By being transparent about strategic decisions, leaders can ensure that accurate information is disseminated, reducing the likelihood of rumors and fostering a more cohesive and informed team.

Conclusion

In conclusion, transparency is a cornerstone of effective leadership and a healthy chain of command. By being open and honest, leaders can build trust, encourage open communication, foster accountability, enhance employee morale, and drive organizational success. As you aspire to take on leadership roles, remember that transparency is not just a strategy; it's a commitment to creating a positive and thriving workplace culture.

Embrace transparency, and you'll be well on your way to becoming a trusted and effective leader.

To the question “During your career, did to pass a Job probation period?” the most common answer will be “Yes”. Traditionally, it is viewed as a tool for employers to evaluate potential hires, nevertheless it's crucial to recognize that these periods serve a dual purpose. They are, in fact, a two-way street that benefits both employers and employees alike.

What is in for Us?

The probation period is an evaluation period, it can even be seen as an extension of the interview process, as you will never get to know a person you will spend most of your awake workday day with.

With this in mind, the same as in interview, we need to remember is not a one-sided evaluation, Employers should evaluate ROI & employees should evaluate company fitness.

From an employer's standpoint, probation periods offer several advantages:

• Skill Assessment: Employers can evaluate a candidate's practical skills and how they apply their knowledge in real-world scenarios.

• Cultural Fit: It provides an opportunity to assess how well the new hire integrates with the existing team and company culture.

• Performance Evaluation: Employers can gauge the employee's productivity, work ethic, and ability to meet deadlines.

• Risk Mitigation: If the employee doesn't meet expectations, the company can part ways with minimal legal and financial implications.

Equally important, but often overlooked, is the employee's perspective on probation periods:

• Company Culture Experience: Employees can immerse themselves in the company culture and determine if it aligns with their values and work style.

• Job Satisfaction Assessment: It allows individuals to evaluate if the role meets their expectations and career aspirations.

• Team Dynamics: Employees can assess how well they work with their colleagues and immediate supervisors.

• Work-Life Balance: The probation period offers insight into the company's approach to work-life balance and flexibility

Maximizing the Probation Period

To make the most of a job probation period, both parties should approach it with openness and clear communication:

• Set Clear Expectations: Employers should outline specific goals and performance metrics for the probation period.

• Regular Feedback: Implement a system for frequent, two-way feedback to address concerns and acknowledge progress.

• Encourage Questions: Create an environment where the new hire feels comfortable asking questions and seeking clarification.

• Provide Necessary Resources: Ensure the employee has all the tools and information needed to perform their job effectively.

To achieve this, we need to use the correct tools for the job

Onboarding Plan

An effective onboarding plan should contain:

• Comprehensive introduction: Include an overview of the company's culture, policies, and procedures.

• Role-specific training: Provide training tailored to the new employee's specific job responsibilities.

• Introduction to team and colleagues: Facilitate meetings with team members and key personnel.

• Resource provision: Ensure the employee has all necessary tools and information to perform their job effectively.

• Assign a buddy: pair the employee with a more experienced colleague who can provide informal guidance and support that can help navigate the day-to-day aspects of the job.

• Assign a mentor: pair the employee mentor is usually a more senior employee who can provide guidance, share industry insights, and help them grow in their role over a longer period.

• Regular feedback sessions: as a manager, schedule frequent check-ins to address concerns and acknowledge progress.

A well-structured onboarding plan helps new employees quickly integrate into their roles and the organization, reducing the learning curve and increasing productivity during the probation period.

30-60-90 Plan

A 30-60-90 plan is a strategic framework used for onboarding new employees or setting goals for the first 90 days in a new role. It breaks down objectives and expectations into three distinct periods:

• 30 days: Focus on learning and understanding the role, company culture, and immediate responsibilities.

• 60 days: Begin contributing more actively, implementing initial strategies, and identifying areas for improvement.

• 90 days: Fully integrate into the role, start driving results, and propose long-term strategies or improvements.

This plan helps structure the transition period, ensuring clear expectations and measurable progress for both the employee and the employer during the probation period, with a framework that can help focus the feedback and

Evaluation of the outcome of a probation period

Pass

When a probation period results in a successful outcome, it's important to celebrate this achievement. Both the employer and employee should acknowledge the positive experience and use it as a foundation for future growth.

This is an opportunity to set new goals, discuss career development plans, and reinforce the mutual commitment to success. A successful probation period can lead to increased motivation, job satisfaction, and a stronger sense of belonging within the organization.

No Pass by Employer

If an employer decides not to continue the employment relationship after the probation period, it's crucial to handle the situation professionally and sensitively.

The employer should provide clear, constructive feedback about why the probation was unsuccessful, focusing on the root cause without personal criticisms. This feedback can be valuable for the employee's future career development.

Additionally, the employer should ensure all legal and contractual obligations are met, including any notice periods or severance pay if applicable. Treating the departing employee with respect and dignity during this process is not only ethical, but also maintains the company's reputation as a fair employer.

No Pass by Employee

When an employee decides not to continue after the probation period, it's equally important to handle the situation professionally.

The employee should provide honest feedback about their experience, highlighting any misalignment or concerns that led to their decision. This feedback can be valuable for the employer to improve their onboarding process or workplace environment.

The employee should also ensure they fulfill any contractual obligations, such as providing proper notice.

Conclusion

Job probation periods are an opportunity for both parties to evaluate the potential for a long-term, mutually beneficial relationship. By approaching these periods with transparency, open communication, and a willingness to learn, both employers and employees can make informed decisions about their future together.

This period should not be demonized, even if it ends in a “No Pass”, it should be taken as a good outcome as it's a relationship that would have most probably failed, or would create friction and other risks down the road when legal obligation from both sides are more complex. If you're the employee, remember this is not a failure. Your worth remains unchanged—it simply wasn't the right fit or timing. If you're the employer, don't be too hard on yourself. Not all relationships work out. The best approach is to move forward and end things on the best terms possible.

The Current Concept of Technical Task

Technical tasks are typically considered those that involve the underlying work on non-functional related endeavors. These can include activities like updating dependencies, improving performance, etc.

While they may not always have a direct visible impact on the end user, In reality, almost every task a development team undertakes has some level of impact on the product. Even tasks perceived as purely technical, such as improving code quality or optimizing performance, ultimately contribute to a better user experience and product reliability.

Understanding the Net Value of Tasks

Any team effort needs to have a clear purpose, whether it's technical or product-related.

If we approach our work with the previous quote in mind, any endeavor a team undertakes should yield a positive return on investment. Let's express this value as a simple formula:

where:

• Value: The benefit or worth that a task or project brings to the organization, often measured in terms of revenue.

• Cost: The amount of resources, including time, money, and effort, required to complete a task or project.

It's normally simpler to calculate the expected value of functional tasks because their impact on user experience and business metrics is more direct and measurable. However, even technical tasks, when evaluated through this lens, can reveal significant contributions to the product's overall value.

The benefit we will achieve from this approach is a more cohesive and efficient development process, where all tasks are recognized for their contribution to the product's success. This integrated approach to task management allows for more strategic prioritization. When all tasks are evaluated based on their potential impact on the product, teams can make more informed decisions about where to allocate their resources. This can result in more timely delivery of features and improvements, better risk management, and a more adaptable development process.

Example of Task Calculations

Functional Task: Adding a New Feature

Task: Implement a new user login feature.

• Value: This feature is expected to increase user sign-ups by 5%, leading to an estimated increase in revenue of $5,000 per month.

• Cost: The development team estimates that it will take a week to complete this task (around 40 hours). Assuming an average hourly rate of $50, the total cost is $2,000.

Non-Functional Task: Performance Improvements

Task: Optimize the application's performance to reduce load times and enhance user experience.

• Value: Faster load times are expected to improve user retention by 15%, leading to an estimated increase in paid users and an additional revenue of $7,000 per month.

• Cost: The development team estimates that it will take 50 hours to complete this task. Assuming an average hourly rate of $50, the total cost is $2,500.

With these examples in mind, it makes more sense to start with performance improvements and not working on the functional task.

Embrace a Unified Approach to Task Management

To truly integrate technical and product tasks, teams should adopt a unified approach to task management. This involves recognizing that every task, no matter how technical it may seem, plays a crucial role in the overall product vision. Here are some additional strategies to ensure this integration:

1. Unified Backlog: Maintain a single backlog that includes both product features and technical tasks. This ensures that all tasks are visible to the entire team and can be prioritized based on their overall impact on the product.

2. Cross-functional Teams: Foster cross-functional teams where developers, product managers, and other stakeholders work closely together. This can help bridge the gap between technical and product perspectives, leading to more informed decision-making.

3. Prioritize by Value: Prioritize the next thing based on its potential value, not by the category of a task.

Final Thoughts

In conclusion, the distinction between technical and product tasks is often more conceptual than practical. By recognizing the interdependence of these tasks and integrating them into a unified development process, teams can enhance both product quality and development efficiency. It's time to stop segregating tasks and start viewing them as integral parts of a cohesive product development strategy. This holistic approach will improve the end product and foster a more collaborative and productive team environment.

You may have noticed that I haven't been writing as frequently as I would like. I feel bad about this, but I was overwhelmed from overworking in multiple areas. Had this continued without any action, I might have faced significant burnout. So, let's talk today about mental health at work.

What is Mental Health & Why is it Important

Mental health goes beyond the absence of mental illness; it includes our overall emotional, psychological, and social well-being. It affects how we think, feel, and act, influencing our ability to manage stress, relate to others, and make decisions. Understanding and prioritizing mental health is crucial for maintaining a productive and positive work environment.

We typically spend 50% of our waking hours at work, this is why work can significantly impact our mental health.

Evaluating Mental Health

Self

It's important to regularly assess your own mental health. Reflect on how you're feeling, both physically and emotionally. While this can be challenging, several tools and methods can help:

1. Journaling: Keeping a daily journal of your thoughts, feelings, and experiences can help you identify patterns and triggers of stress or anxiety.

2. Mood Tracking: Apps or simple paper-based mood trackers can help you monitor your mood over time and notice any significant changes.

3. Online Assessments: Various websites offer self-assessment tools that provide insights into your mental health status. These assessments often cover areas like stress, anxiety, and depression.

4. Physical Health Monitoring: Since mental and physical health are closely linked, tracking physical symptoms like sleep patterns, appetite, and energy levels can provide clues about your mental health.

5. Professional Help: Regular check-ins with a mental health professional, even when you're feeling okay, can offer valuable insights and support.

Using these tools regularly can help you stay in tune with your mental health and take proactive steps to address any issues that arise.

Others

As leaders, it's equally important to recognize signs of burnout and stress in others. Here are some indicators to watch out for:

• Decreased Productivity: Noticeable decline in work output.

• Increased Absenteeism: Frequent sick days or unexplained absences.

• Changes in Behavior: Irritability, mood swings, or withdrawal from team activities.

• Physical Symptoms: Complaints of headaches, fatigue, or other stress-related ailments.

• Lack of Engagement: Disinterest in work or decreased enthusiasm for projects.

Factors That Affect Mental Health At Work

Several factors can significantly affect mental health in the workplace, and it’s essential to recognize these to create a supportive environment for everyone on the team. Here are some of the key factors:

• Workload and Stress: Excessive workload and high levels of stress are common contributors to poor mental health. When employees are consistently overwhelmed with tasks and responsibilities, it can lead to burnout, anxiety, and decreased productivity.

• Work-Life Balance: A lack of work-life balance can negatively impact mental health. When work encroaches on personal time, it can lead to stress, fatigue, and strained relationships. It’s crucial for organizations to promote a healthy balance between work and personal life.

• Job Security: Uncertainty about job security can cause significant stress and anxiety. Concerns about layoffs, contract renewals, or organizational changes can create an environment of fear and instability.

• Workplace Relationships: The quality of relationships with colleagues and supervisors can greatly influence mental health. Positive, supportive interactions can enhance well-being, while toxic or unsupportive relationships can lead to stress and dissatisfaction.

• Organizational Culture: A company's culture plays a vital role in mental health. A culture that values mental well-being, provides support, and encourages open communication can help mitigate stress and improve overall morale.

• Recognition and Reward: Feeling undervalued or unrecognized for contributions can negatively impact mental health. Regular acknowledgment and reward for hard work and accomplishments can boost morale and motivation.

• Physical Environment: The physical work environment, including factors like noise levels, lighting, and ergonomics, can affect mental well-being. A comfortable and conducive workspace can enhance productivity and reduce stress.

• Change Management: How changes are managed within an organization can impact mental health. Poorly communicated or managed changes can create uncertainty and stress, while transparent and supportive change management can ease transitions.

• Personal Factors: Personal issues such as financial concerns, health problems, or family responsibilities can also impact mental health at work. It’s important for organizations to be aware of and sensitive to these external factors.

• Team Dynamics: The dynamics within a team can greatly influence individual mental health. A collaborative, cohesive team can provide support and reduce stress, while a dysfunctional team can create additional pressure and conflict.

Strategies to Improve Mental Health

Addressing mental health in the workplace requires a multifaceted approach. Here are some strategies that can help create a healthier work environment:

Organizational Strategies

1. Promote Work-Life Balance: Encourage employees to take regular breaks, use their vacation days, and disconnect after work hours. Flexible work schedules can also help employees manage their personal and professional responsibilities more effectively.

2. Foster a Supportive Culture: Create a culture where mental health is openly discussed and supported. Encourage leaders to model healthy behaviors and provide training on recognizing and addressing mental health issues.

3. Provide Resources: Offer access to mental health resources such as Employee Assistance Programs, counseling services, and stress management workshops. Make sure employees know how to access these resources.

4. Manage Workload: Ensure that workloads are reasonable and that employees have the resources they need to complete their tasks. Regularly check in with team members to assess their workload and make adjustments as needed.

5. Encourage Social Connections: Foster a sense of community within the workplace. Encourage team-building activities, social events, and opportunities for employees to connect on a personal level.

Individual Strategies

1. Set Boundaries: Clearly define your work hours and stick to them. Avoid checking emails or working outside your designated work time.

2. Practice Self-Care: Engage in activities that help you relax and recharge. This could include exercise, meditation, hobbies, or spending time with loved ones.

3. Seek Support: Don’t hesitate to reach out for help if you’re struggling. Talk to a trusted colleague, supervisor, or mental health professional.

4. Stay Organized: Use tools like to-do lists, calendars, and project management software to keep track of your tasks and deadlines. This can help reduce feelings of overwhelm.

5. Take Breaks: Regular breaks throughout the day can help you stay focused and reduce stress. Even a short walk or a few minutes of deep breathing can make a big difference.

Closing Words

Mental health is a crucial aspect of overall well-being and productivity in the workplace. By recognizing the factors that affect mental health and implementing strategies to address them, we can create a supportive and healthy work environment. Remember, prioritizing mental health benefits not only individuals, but also the entire organization. It’s okay to take a step back, evaluate your well-being, and make necessary adjustments. Your mental health matters.

Regardless of whether you work within an agile or non-agile framework, most teams seem unable to complete the assigned work for each cycle. This indicates that we are maximizing utilization.

The Queuing Theory Behind Work

As work is a continuous stream of requests, it typically takes the form of a waiting queue and is governed by its principles. This is why queuing theory helps us understand how tasks accumulate and how delays can propagate through the system. By analyzing the flow of tasks and identifying bottlenecks, we can better manage workloads and improve efficiency.

Here are two formulas that actually drive the entire system:

Kingman's Formula

Kingman's Formula, also known as the VUT equation, is a widely used approximation in queuing theory. It helps estimate the average waiting time in a queue. The formula is given by:

Kingman's Formula highlights the impact of variability and utilization on waiting times. As utilization approaches 100%, waiting times increase dramatically, which is why it's crucial to avoid overloading systems.

Little's Law

Little's Law is a fundamental theorem in queuing theory that relates the average number of items in a queue (L), the average arrival rate of items (λ), and the average time an item spends in the system (W). The law is expressed as:

Little's Law is useful for understanding and managing queues in various contexts, including software development. It implies that to reduce the number of tasks in progress (L), you can either decrease the arrival rate of tasks (λ) or reduce the time tasks spend in the system (W). This principle supports the idea of not overloading development teams and allowing adequate time for tasks to be completed efficiently.

If we combine both formulas, we can have an obvious image of what happens to our system when a 100% utilization is reached and there is even the slightest amount of variability

Effects of +100% Long-Term Utilization

Now that we have clarified, the math being our task management at work. Let’s discuss the effects of long term sustained high utilization. There are many systems that follow the previous principles, allowing us to observe the stress test effects on both human and non-human systems.

For example, when a CPU or any other system is used at 100% for extended periods or overclocked beyond its standard limits, several adverse effects can occur:

1. Heat Generation: High utilization and overclocking increase the CPU's heat output. Excessive heat can lead to thermal throttling, reducing performance, and in extreme cases, hardware damage.

2. Reduced Lifespan: Constant high usage or overclocking can shorten the CPU's lifespan. Increased electrical stress and heat degrade the CPU's materials over time.

3. System Instability: Overclocking can cause crashes, freezes, and unexpected reboots. Even at 100% utilization, a system can become unresponsive if it lacks resources.

4. Increased Power Consumption: High utilization and overclocking lead to higher power consumption, raising energy costs and stressing the power supply unit (PSU) and cooling systems.

5. Performance Bottlenecks: Consistent 100% CPU utilization can bottleneck other components like the GPU, RAM, and storage devices, leading to suboptimal performance.

6. Noise Levels: Higher utilization and overclocking often require more aggressive cooling, increasing noise levels and potentially creating a less comfortable working environment.

Translating this to humans, constant busyness leaves no time for creative thinking or effective problem-solving, leading to burnout, decreased work quality, and overall productivity loss.

Preventing the Effects of High Utilization In Humans

Similar to a CPU, there are ways to mitigate these effects:

Be Strategic About 100% Utilization

Strategic planning for 100% utilization during critical periods can be beneficial but should be done cautiously to avoid long-term negative effects.

• Critical Deadlines: Reserve 100% utilization for critical deadlines or important milestones. Ensure the team understands the importance and temporary nature of this increased workload.

• Clear Communication: Communicate clearly about the reasons for the increased workload, its expected duration, and available support. Transparency helps manage expectations and reduce stress.

• Support Systems: Provide additional support during these periods, such as extra resources, temporary team members, or access to mental health services.

By being strategic about 100% utilization and ensuring adequate cooling-down periods, you can maintain a healthy and productive team, ready to tackle challenges without burning out.

Cooling Down

Allow periods of reduced workload for recovery and creative thinking to maintain long-term productivity and prevent burnout.

• Scheduled Breaks: Implement regular breaks throughout the workday. Encourage short breaks to rest and recharge, improving focus and productivity.

• Downtime Projects: Allocate time for side projects, learning opportunities, or innovation days. This gives a break from usual tasks and fosters creativity.

• Flexible Work Hours: Offer flexible work hours or remote work options to accommodate different working styles and needs, leading to a more balanced and satisfied team.

Monitoring and Feedback

Just as monitoring CPU temperatures and stability is crucial, regularly checking in on your team's workload and well-being is essential. This can involve:

• Regular Check-ins: Schedule regular meetings to discuss workload, challenges, and signs of burnout. Encourage open communication and provide a safe space for concerns.

• Performance Metrics: Use tools to monitor the team’s performance and workload. Metrics like cycle time, throughput, and work-in-progress (WIP) limits help understand the team’s capacity and adjust workloads accordingly.

• Feedback Loops: Establish continuous feedback loops for team input on processes, workload, and job satisfaction. This helps make informed decisions to improve productivity and well-being.

Preventing Bottlenecks

To prevent bottlenecks in your development process, consider these strategies:

• Task Prioritization: Prioritize tasks by urgency and importance. Ensure critical tasks are completed first to avoid overwhelming the team with less important work.

• Workload Distribution: Distribute tasks evenly among team members to avoid overburdening individuals, which can lead to delays and decreased productivity.

• Cross-Training: Encourage cross-training to ensure multiple team members can handle different tasks, reducing dependency on single individuals and allowing for a more flexible team.

Final Thoughts

It's easy to fall into the trap of continuous sprinting and overutilization at work, so recognizing the importance of balance is crucial. Allowing time for cooldown periods, fostering creativity, and ensuring a healthy work environment are essential for long-term success.

Sustainable productivity is about creating an environment where teams can thrive, innovate, and deliver high-quality work consistently. By being strategic and mindful, we can achieve a more productive and satisfied team ready to tackle any challenge.

One example that might resonate are companies that try to implement their goals through OKRs. Typically, the first year doesn't yield substantial value, leading to a gradual disregard in the second year. Before the close of year two, a new acronym supersedes the existing goal definition, setting off yet another cycle.

Understanding Why New Methodology Implementations Often Fall Short

Whether we're discussing company-wide methodologies like OKRs or team-specific practices like pair programming, it's common to see implementations fall short. Often, methodologies bear the brunt of the blame due to misalignment.

Let's delve into the reasons behind these failures, and assess whether the methodology itself is at fault.

• Difficulty in Tracking Results: When new methods are introduced, it's often challenging to see immediate results or advantages. This can lead to premature rejection of the new approach.

• Insufficient Engagement: This covers situations where members aren't entirely on board with the new process. This could stem from inadequate understanding, disagreement with the methodology, or simple resistance to change.

While there are other reasons for failure, they typically fall under or relate closely to these main points.

Boosting Success Rates via Engineering Culture

As we've previously discussed, enhancing the success rate of engineering changes hinges on shifts in the following cultural aspects:

Patience

Results take time

To foster patience within the engineering department, it's essential that the company culture not only values it, but actively encourages it. Here's how:

• Celebrate Patience: Recognize and reward patience in your workspace. This could involve acknowledging those who demonstrate patience when faced with challenges, or associating rewards and promotions with the successful long-term execution of changes.

• Highlight the Role of Patience: Keep reminding your people about the crucial role patience plays in long-term success. Share anecdotes or instances where patience has proven beneficial in the past.

• Lead by Example: Leadership should portray patience in their actions and decision-making. This means resisting the urge to follow the latest trends without adequate evaluation, and allowing new processes sufficient time to integrate and yield results.

Aligning Knowledge

Teamwork makes the dream work.

To effectively share knowledge throughout the engineering department, it's essential that our company culture actively supports and fosters it. This includes:

• Transparent communication: It's crucial for everyone to understand why we're making changes and what we should anticipate. A thorough explanation of the process, timeline, potential challenges, and anticipated benefits can ensure we're all on the same page.

• Offering support and resources: As we've discussed, lack of support can lead to frustration and potential failure. We must ensure our people have the necessary resources to successfully implement new methodologies.

• Promoting open dialogue: We should create spaces for our people to share their thoughts, concerns, and feelings about upcoming changes. This approach encourages a sense of ownership and commitment, which can minimize the risk of premature termination.

Final thoughts

Remember, embracing change is a journey, not a race. It's important to acknowledge that while the process may be fraught with challenges, the benefits of perseverance often outweigh the initial discomfort or resistance.

Patience, coupled with knowledge alignment, can significantly increase the success rate of implementing new methodologies in engineering departments. By fostering a culture that values patience and open communication, we can better adapt to changes, overcome challenges, and achieve our long-term goals.

🗞️ Other articles you may like

📚 Picks of the Week

Perspectiveship

Occam's Razor - Mental Model

During my Electronics labs at university, one group could not get the oscilloscope to work so they asked for help. The professor went over to them and said "electrical devices work best when connected to power" — and he was right, they had not turned on the power…

Read more

2 years ago · 13 likes · 8 comments · Michał Poczwardowski

Data Gibberish

Ask Me Anything, June 2024

This is the first issue of the special monthly Ask Me Anything edition of Data Gibberish. This month, I picked 5 questions you asked: 🔍 How much data is enough, and how do you ensure data quality? 🤖 What are your thoughts on sanitising training data for LLMs…

Read more

2 years ago · 12 likes · Yordan Ivanov

·✌️ That’s all folks

I love hearing from readers, and I’m looking for feedback. How am I doing with Leads Horizons? Is there anything you’d like to see more or less? Which aspects of the newsletter do you enjoy the most?

Use the links below, or even better, hit reply and say hello. I’d love to hear from you!

• 😍 Awesome

• 😐 Okay

• 🤮 Bad

Please don't hesitate to connect with me on LinkedIn and send a message. I always respond to every one!

Some individuals are eager to tackle new challenges and progress rapidly, while others prefer maintaining the status quo. Do you find one approach more valuable than the other, and if so, why?

Drawing inspiration from the book Radical Candor, this article will discuss the categorization of engineers into Superstars and Rockstars. We'll examine their unique traits, contributions, and roles within the development process.

Superstar Engineers

Superstar Engineers are those who strive for more than just the ordinary, who are ready to take calculated risks for innovation. Within the technology sector, they act as catalysts for change and disruption.

Some traits you can find in the work of these engineers:

• They continuously pursue growth and development

• They’re not content with the status quo

• They’re willing to take risks to innovate

• They’re frequently the driving force behind breakthroughs in technologies, processes, practices, or products

• They’re motivated by a passion for innovation and growth

• They propel the team forward, ensuring it stays relevant and competitive

Rockstar Engineers

Rockstar Engineers are the backbone of the team, providing the dependability that keeps everything running smoothly. Without their steady influence, the boundary-pushing work of Superstars would be far less effective.

Some traits you can find in the work of these engineers:

• They provide stability and consistency within the team.

• They're domain experts, with a deep understanding of particular systems or processes

• They ensure the smooth running of systems and processes

• They manage and enhance existing systems

• They're highly reliable, often serving as the go-to person for issues within their domain

• They're incredibly dependable, often the first person you'd call for problems in their area

• They value quality and take genuine pride in their work

• While they may not be the most visible, their contribution to the team and the business is absolutely critical

Types of Engineers and engineering strategy

Having discussed different types of engineers, let's now explore how this impacts various aspects of our company or team.

Team & Company Composition

It's crucial to strike a balance between these two types of engineers inside a team or company. The optimal engineering strategy blends Superstars and Rockstars, ensuring the team has both the stability to manage current tasks and the innovative spirit required to stay competitive.

An overabundance of Superstars may lead to instability due to frequent changes, causing the team to remain in a perpetual state of upheaval.

On the other hand, an excess of Rockstars might lead to stagnation, preventing the team from adapting to necessary changes and reducing productivity.

Remuneration & Growth

Equally important than having the correct profiles is ensuring that both are valued equally.

This is often a challenge as engineering ladders tend to favor Superstars, who are generally more motivated to climb the ladder. These ladders often dictate an employee's financial compensation. Leading to Superstars accelerating their remuneration faster than Rockstars, who may hit a pay ceiling. For this, it's important to tie compensation not to a specific role, but to the unique value an individual contributes to the company or team.

Closing thoughts

Recognizing this duality and managing it effectively is one of the key roles of leadership in the tech industry. By acknowledging and valuing the unique contributions of both Superstars and Rockstars, leaders can foster a diverse, balanced, and highly productive team. This duality is not a hindrance, but a strength that can be harnessed to drive a team or company's success.

• A team that releases many cards

• The one that delivers high-quality code

• The one that has all the best engineers

The answer, at least for me, is none of the above.

What is a Team?

A definition by Professor Leigh Thompson of the Kellogg School of Management:

A team is a group of people who are interdependent with respect to information, resources, knowledge and skills and who seek to combine their efforts to achieve a common goal.

A group itself does not represent a team, for a group to become a team, there is a need for a common goal. As a group evolves into a team, it needs to go through several transformations.

Evolution From Group to Team

Teams typically go through various stages of development. These stages represent the journey from a group of strangers to a united group with common goals.

Tuckman's model describes the four stages of team development as:

1. Forming: This is the initial stage where team members meet for the first time. Everyone is polite and positive, and there are high expectations but little understanding of the tasks ahead.

2. Storming: As team members start to work together, differences of opinion may lead to conflict. This stage is marked by resistance, competition, and conflict as individual personalities emerge.

3. Norming: Gradually, the team moves into the norming stage where they start to resolve their differences, appreciate colleagues' strengths, and respect the leader's authority. The team begins to develop cohesion and unity.

4. Performing: This is the stage where the team is fully functional and works towards achieving the team's goals. There is a strong bond between team members, and everyone works collaboratively and efficiently.

On the top of Performing, we could say there is outperforming is where High-Performance teams live. This final stage is reached when the team consistently exceeds expectations and delivers exceptional results. The team is highly collaborative, innovative, and operates with a shared vision and purpose.

Transitioning from One Team Stage to Another

1. Forming to Storming: The transition from forming to storming requires team members to start working together and engaging in discussions and decision-making. It's important for each member to feel comfortable expressing their opinions and ideas, even if they differ from others. This phase often triggers conflicts due to diverse views, but it is a crucial part of the team's evolution, as it allows members to understand and appreciate each other's perspectives.

2. Storming to Norming: The shift from storming to norming is marked by the resolution of conflicts and the establishment of processes and norms. This stage requires effective conflict management and open communication. Besides, the team should focus on recognizing and appreciating the strengths of each member and fostering a collaborative environment. The team begins to feel a sense of unity, and a collaborative culture starts to develop.

3. Norming to Performing: Moving from norming to performing entails the team becoming more focused on achieving shared goals. The team has now established effective working relationships and understood each other's working styles. At this stage, it's important to stay focused on the team's objectives and ensure everyone is working collaboratively towards them. The team becomes more autonomous, with members taking on responsibilities and roles that align with their strengths.

4. Performing to Outperforming (High-Performance): The leap from performing to outperforming is achieved by exceeding expectations consistently. It's vital to maintain the momentum, continuously innovate, and strive for improvement. Commitment to the team's shared vision and purpose, trust among team members, and open communication are crucial factors in this stage. The team should also be flexible in adapting to changes and challenges and should be driven to continually improve their performance.

Traits Of a High-Performance Team

• Trust: This refers to the confidence among team members that each person will fulfill their responsibilities and maintain a commitment to the common goal.

• Mutual Support: This involves members actively helping each other to succeed, promoting a culture of cooperation and interdependence.

• Drive: This indicates the team's collective motivation and ambition to achieve their goals and continually improve their performance.

• Edit Their Needs: This implies the team's ability to self-assess and adjust their requirements and strategies based on the evolving circumstances.

• Open Communication: This refers to the team's ability to communicate effectively, ensuring that everyone feels heard and understood. Open communication fosters transparency and encourages team members to share their ideas and feedback.

• Do Not Depend on a Leader: This means the team operates in a decentralized manner where every member takes initiative and responsibility, rather than relying on a single leader for direction and decisions.

Example Tools To Improve Team Traits

Getting to Know the Human Behind: Team Personal Presentations

Team Personal Presentations is an exercise where each team member creates a short presentation about themselves to share with the rest of the team. This can include information about their background, interests, strengths, weaknesses, and even fun facts. The goal is to allow team members to get to know each other on a deeper level, beyond just their professional roles.

This exercise can help to build stronger relationships within the team, foster empathy and understanding, and improve team cohesion. It gives team members an insight into who their colleagues really are, which can lead to greater trust, better communication, and a more effective working environment.

Getting to Know How We Exchange: Communication Preferences

Communication Preferences is an activity that helps team members understand each other's preferred methods of communication. This can include when and how they like to receive information, how they handle conflict, and how they give and receive feedback. Understanding these preferences can greatly improve team collaboration and prevent misunderstandings.

Getting to Know What We Care About: Moving motivators

The Moving Motivators exercise is a tool from Management 3.0 that helps in understanding the intrinsic motivations of individuals within a team. It involves a deck of ten cards, each representing a key motivator such as acceptance, curiosity, freedom, or power.

The participant orders these cards in order of personal importance. Then, they consider a recent change in their work or life and move the cards up or down based on whether this change has positively or negatively impacted each motivator. This provides valuable insights into what drives a person and how changes affect their motivation, which is crucial for effective team management and leadership.

Getting to Know What Area to Improve Next: Team Health Check

The Team Health Check is an exercise developed by Spotify to assess the health of their teams.

Teams collectively assess how they are doing on several aspects, such as collaboration, value delivery, mission, fun, learning, and leadership. Each team member votes on each aspect using a traffic light system (green for good, yellow for okay, red for not good).

The results are then discussed openly, helping to facilitate communication about challenges, improvements, and actions to be taken. The exercise is not about blaming or pointing fingers but about understanding and improving team dynamics and performance.

🗞️ Other articles you may like

📚 Picks of the Week

Perspectiveship

Hanlon's Razor - Mental Model

As an Engineering Manager I heard many times: This developer just wants to bury us in legacy code forever. The other team picked the wrong library with no backwards compatibility so we are all struggling now. This engineer caused a production break late Friday afternoon, so forced us to stay longer to fix it…

Read more

2 years ago · 22 likes · 6 comments · Michał Poczwardowski

Tech Unfiltered

When Agile, isn't agile

Today what' we’re going to be talking about is when agile, isn’t agile. If you’ve been in the industry a while, you’ll have probably heard phrases like Tech Unfiltered is a reader-supported publicatio…

Read more

2 years ago · 12 likes · 5 comments · Jade Wilson

·✌️ That’s all folks

I love hearing from readers, and I’m looking for feedback. How am I doing with Leads Horizons? Is there anything you’d like to see more or less? Which aspects of the newsletter do you enjoy the most?

Use the links below, or even better, hit reply and say hello. I’d love to hear from you!

• 😍 Awesome

• 😐 Okay

• 🤮 Bad

Please don't hesitate to connect with me on LinkedIn and send a message. I always respond to every one!

The Average Hiring Process

Whenever I step into a company, my gaze is often drawn to their recruitment procedures. Typically, the process aligns with or forms a subset of this schematic.

Most companies employ these steps as filters, aiming to discover the “ideal candidate” with the least possible commitment. This turns the hiring process into a lengthy, high-effort endeavor that can span multiple months. As you can see, from application to hire, we're looking at an average of 32 days and a time investment of 15.5 hours.

In competitive markets—such as the one I'm familiar with—the top candidates are often hired within a maximum of two weeks after applying for a job. How can this be?

The Issue at hand

Over-engineering can be pinpointed as the root cause of the issue. Here are the three main concerns that lead to this:

• Risk Avoidance Leads to Over-Complication: Trying to avoid any slip-ups during the hiring process often results in a complicated and lengthy procedure. This method is more about reducing the risk of a bad hire, even if it sacrifices speed and efficiency.

• Fear of Overlooking the Perfect Candidate: The worry of not finding that potentially perfect candidate leads to an exhaustive process. Every candidate is meticulously screened at each stage, lengthening the hiring period.

• Concern Over Wasting Employee Time: The fear of spending current employee time on unsuccessful hiring processes is a worry. This concern stems from knowing that time is valuable, especially in fast-paced work environments. If the hiring process doesn't yield a successful hire, it's considered a misuse of employee time that could have been used for immediate needs and goals.

However, lengthy processes are the embodiment of these fears. The rationale is straightforward: the top candidates are often the first to be snapped up. If your hiring process is sluggish due to numerous feedback loops, chances are you're missing out on top-tier talent.

Remember, most companies aren't engaged in rocket science, which means you probably don't need a rocket scientist on your team. What you do need are team players who can collaborate effectively and add value to your product.

Solving the problem

To attract and secure top-tier talent in a fast and efficient manner, it is imperative to streamline and reform our hiring process.

The objective is to create a process that is not only efficient in its operations, but also effective in securing the best possible talent for our teams. This approach must consider the existing challenges in the hiring process and devise solutions that counter these issues, while optimizing for speed and quality of hires.

To facilitate such transformation in the hiring process, we need to undertake the following steps:

Simplify Evaluation Process

The prevailing approach in many companies operates like a wishlist, confirming that candidates meet an extensive set of expectations. However, these wishlist often become an endless array of checkboxes that candidates must tick off.

A more efficient solution would be to invert this evaluation method, implementing a flagging system to identify what is unacceptable in a candidate. This method streamlines the process, as it's a true or false evaluation where we all have the same expectation. Instead of having a checklist of 100 items that can have different readings by the evaluator to be covered in 2 to 4 technically focused interviews, we're able to identify any red flags in just one or two interviews.

Let's see examples that I have seen in real life:

Here is how the simplified process looks like:

Reduce The Feedback Loops

In line with product development, minimizing feedback loops can enhance agility.

Inserting filters into the process simply creates delay in decision-making, as feedback must be revisited before proceeding. These waiting periods regularly lead to candidates disengaging from the process.

Moreover, these filters may inadvertently prevent a potential candidate from showcasing their full potential in later stages of the process, frequently leading to premature dismissal of suitable candidates for the position.

Eliminating filters from feedback loops can accelerate the process and lessen the burden on our existing employees. By removing reporting for future steps and not discarding candidates early, candidate success rate will increase, resulting in fewer interviews in the long run.

Final Words

In conclusion, the key to a successful hiring process lies in simplicity and efficiency. By focusing on eliminating unnecessary steps and reducing feedback loops, companies can accelerate their hiring process and attract and retain the best talent in the market, while they invest less of their current talent.

From a young age, we're taught the value of steady, incremental progress. The idea is that like a determined tortoise, we can reach our goals by moving deliberately in the right direction. But could there be a more efficient approach?

The Comfort Zone a Default State

It's widely recognized that individuals typically operate within their comfort zones. But what exactly is the comfort zone? Here's a potential definition:

The comfort zone refers to a psychological state in which one feels familiar, safe, and at ease. It is the area of experience where a person operates in an anxiety-neutral condition, using a limited set of behaviors to deliver a steady level of performance, usually without any sense of risk or need for change.

Sticking to what's familiar can often deter us from making significant strides in improving our lives. More often than not, we choose minor, incremental changes that don't veer too far from our routine.

This fondness for comfort zones isn't just personal—it extends into software development practices and product development too. Frequently, teams would rather make minor adjustments than take the risk of adopting an entirely new approach. This could be due to fear of failure, resistance to change, or simply not being aware of the potential benefits of a different approach.

Sure, these incremental changes are easier to manage and implement. They cause less disruption to our current systems and processes, letting us maintain stability and make small steps forward. But, they can also restrict our potential for innovation and growth. When we only focus on baby steps, we might overlook the chance to make a big leap that could bring about significant benefits.

This leads us to ask: Are these small improvements enough? Do they truly meet the needs of the team and the organization, or are they simply a safe and comfortable route that leads to average results?

Signs of Need For change

Let's consider some signs that may indicate the presence of comfort zones:

• Stalled Progress: If we see little to no significant progress over a lengthy period, it could mean our team might be tweaking things without making a real impact. In this case, the next level of improvement could be further than anticipated.

• Reluctance towards new ideas: A quick dismissal or resistance to new suggestions can indicate a deep-rooted reluctance to change. This resistance is often due to the comfort of the familiar, fear of the unknown, and potential risks associated with change.

• Unchanging strategies: If we find ourselves continually resorting to the same solutions or minor variations of past strategies, it suggests that we're stuck in a comfort zone. A hesitation to try new approaches, especially when facing repetitive challenges, signals a comfort zone.

Therefore, it's crucial to continually assess your team's adaptability. If there are signs of stagnation, resistance to change, or a lack of creative problem-solving, it may be time to challenge the comfort zone and think about making more substantial changes instead of small, incremental ones.

If you are already measuring the behavior, you will notice comfort zones can be represented as logarithmic functions.

Implementing Change

Recognizing the need for change is just the beginning. Here's how we can pave the way forward:

1. Spot key metrics: Initiate by spotting key metrics that accurately represent the area you're aiming to enhance. These metrics should be specific, measurable, and directly tied to the performance or behavior you're looking to improve.

2. Gauge the current situation: Use these as a benchmark to contrast your future performance and evaluate the progress of your initiative.

3. Set a North Star: Set a clear, ambitious yet attainable goal that will steer your efforts. This goal should push your team to step out of their comfort zone, but still be within reach. Ensure this goal is in line with your wider business objectives and resonates with your team members, providing them a strong incentive to aim for the initiative.

4. Estimate the gap: Evaluate the difference between your current performance and your North Star. This is the distance your team needs to traverse to achieve the desired improvement. Understanding this gap will give you a clear sense of the scope of the change required and will help shape your strategy for the initiative.

5. Plan the change: Having defined your key metrics and North Star, begin plotting the course required for the initiative. You will be faced with 2 options:

   1. Bold Move: Occasionally, a significant departure from the current state to your ultimate goal is necessary. Always consider this as your primary option.

   2. Gradual Progress: If the change appears overwhelming or too abrupt, reduce it by taking smaller steps towards your ultimate goal.

6. Review and Refine: Continually track your progress and compare it to your initial benchmark. Use this information to fine-tune your approach, adjust your strategy, and implement necessary modifications.

Final Thoughts

It's crucial to remember that change is not always easy, but it's often necessary for growth. Incremental improvements have their place, but occasionally, we need to take confident leaps to truly innovate and realize our full potential. By willing to step outside our comfort zones, we open ourselves up to new possibilities and opportunities for improvement. Next time you're with your team, ponder over these topics. It's vital to identify your guiding star to reach it. For example, consider this in the context of your team's productivity. What practices could make you the most efficient team? For me, the answer was Extreme Programming (XP). You might contemplate a significant shift from individual development with pull requests to mob programming, and smaller steps towards adopting Trunk-Based Development due to the need for additional tools.

Furthermore, don't hesitate to think creatively about product development. For instance, we often have to shift Key Performance Indicators (KPIs) to meet Objectives and Key Results (OKRs), like increasing the lead conversion percentage. If the leap percentage is high, you might need to implement revolutionary new strategies, rather than sticking with the status-quo.

📚 Picks of the Week

• ”When Agile, isn't agile” by

• “Not Sure What’s Killing Your Team’s Productivity?” by

• “First-principles - Mental Model“ by

🗞️ Other articles you may like

·✌️ That’s all folks

I love hearing from readers, and I’m looking for feedback. How am I doing with Leads Horizons? Is there anything you’d like to see more or less? Which aspects of the newsletter do you enjoy the most?

Use the links below, or even better, hit reply and say hello. I’d love to hear from you!

• 😍 Awesome

• 😐 Okay

• 🤮 Bad

Please don't hesitate to connect with me on LinkedIn and send a message. I always respond to every one!