Read Time: 6 minutes

Engineering teams verify code functionality through various types of tests, but leadership behavior often goes unverified beyond performance reviews and promotion cycles. This creates a double standard: rigorous validation for code, but largely faith-based validation for leadership. By treating leadership principles as function signatures with expected outputs and artifacts, we might identify and fix “leadership bugs” before they cascade into organizational problems.

In this article, we will first highlight the existing verification gap in leadership practices, explore how unit-testing leadership behaviors could close that gap, discuss practical limitations, and suggest ways to practically implement and iterate upon this approach.

The Verification Gap

I was stumbling across a Substack note which got me thinking: “How do we actually test leadership?”

Many organizations define principles. At Kleinanzeigen, our SHAPE values serve as our guiding leadership principles. These values factor into our hiring decisions, regular feedback sessions, and performance reviews. They help us to evaluate leadership potential and performance against a consistent framework.

• Solutions-oriented

• Honest feedback

• Act ahead with accountability

• Prioritize impact

• Empower our people

Throughout the industry, there remains a challenge of verification: these leadership evaluations, while valuable, typically rely heavily on impressions and qualitative feedback rather than concrete observable artifacts. They also tend to happen at scheduled intervals rather than a continuous week-by-week rhythm. Makes sense: Giving written, weekly feedback, even for just 3 people, will quickly result in an explosion of effort, when considering every other person doing the same.

This creates a strange inconsistency: we trust our system design only after thorough verification, but we trust our leadership system largely on faith and good intentions. Yet the cost of a leadership failure is typically higher than a code failure.1 It affects team morale, user experience, and strategic outcomes simultaneously—some more direct, some more indirect.

With clear principles like SHAPE already in place, we have a solid starting point for identifying observable artifacts that could make leadership behaviors as verifiable as our code.

From Theory to Observable Behavior

What would it look like to treat a leadership principle as a testable specification? Take our "Solutions-oriented" value:

function solutionsOriented(problem): Solution[] {
  // Must return at least one solution per problem
  // Solutions must address root causes
  // Implementation must avoid blame narratives
  return solutions;
}

Instead of assuming compliance, we could verify it through specific artifacts:

Writing down these examples reminds me that I drive too many RFCs myself, rather than delegating them down (or sideways). One nice side-effect is mapping these leadership principles to smaller, observable artifacts is that you expose yourself more frequently to them. Values and Principles mean only so much if you do not start actually basing your day-by-day actions on them. Building the habit to think more often about them is the hard part.

From Failed Tests to Behavioral Debugging

If we detected a pattern of such failures, we might approach them the same way we approach code bugs:

1. Debug: Identify which principle is being violated and why. In my RFC example, the principle was clear (Empower people), and the reason (wanting to ensure thoroughness and quality) wasn't about technical capability but about my own control tendencies.

2. Patch: Define the corrective behavior specifically. Not "Delegate more," but "For all RFCs, identify an IC owner who drives the process with my support, rather than me driving it directly."

3. Regression Test: Create a scenario to verify the fix. In this case, assigning the next RFC opportunity to a team member and providing support rather than taking the lead myself.

While treating leadership behaviors as testable specifications offers clear benefits, it’s important to recognize the potential pitfalls. Just as high code coverage doesn’t always indicate high-quality tests, unit-testing leadership behaviors comes with its own limitations. Let’s examine where this approach might face challenges:

The Practical Limitations

At this point, you might have raised your hand and said: “Wait a second, this will backfire!”:

• Measurement effects: Would leaders start optimizing for test-passing rather than actual leadership? (👋 Goodhart’s Law!)

• False binaries: Many leadership situations involve legitimate trade-offs between principles.

• Documentation burden: Do we really want to add more administrative overhead?

Goodhart’s Law observes that once a metric becomes a target, it loses its effectiveness as people find ways to game the system, causing the measurement to no longer reflect the original goal it was designed to track.

These are valid points. Our current people management systems exist for good reasons. Traditional leadership evaluations capture nuance that binary tests might miss. And crucially, humans aren’t code. Their motivation and buy-in matter in ways that programs’ don’t.

That said, I wonder if there’s a middle ground where we maintain our existing leadership evaluation approaches while adding more verification similar to how we might add automated tests to supplement or relieve manual QA.

Where This Fits in the Leadership Landscape

The tech industry struggles with measuring leadership effectiveness. Current approaches typically rely on three dominant paradigms:

1. Performance-based evaluations that measure outcomes (DORA, business results) but not the specific behaviors that created them

2. Skills-based frameworks that assess competencies in structured scenarios but miss day-to-day leadership behaviors

3. Values-based assessments that depend on subjective interpretations of alignment with company principles

What’s notably missing is a systematic approach to connect stated leadership principles with observable behaviors and artifacts.2 While organizations increasingly use metrics like employee retention and satisfaction to evaluate leadership impact, these are primarily lagging indicators that don’t provide real-time feedback on specific leadership behaviors.

Rather than relying solely on abstract principles or subjective impressions, recent research shows that translating leadership values into concrete, observable behaviors-and systematically measuring their outcomes-results in more effective leadership and improved team performance.3

The unit testing approach differs by creating direct links between principles and observable artifacts. Rather than waiting for annual reviews or quarterly engagement surveys to reveal leadership issues, it proposes a verification system that could catch and address problems before they affect team performance or morale.

This doesn’t aim to replace existing evaluation frameworks but to complement them. Similarly to how automated tests don’t replace code reviews but provide an additional layer of quality assurance that catches different types of issues.

Where This Might Lead

For now, this remains a thought experiment that I'm still exploring. I'm planning to start small by testing it on myself. I maintain an “achievement” log for each calendar week, writing down important outcomes, goals met, progress. For the next months, I will start categorizing those via our SHAPE values, reference observable artifacts and see whether this approach will yield insights for myself—do I have blindspots (like my RFC example) or am I excelling at a specific one?

I'm particularly interested in whether “leadership bugs” follow the same patterns as code bugs—do they cluster in specific areas? Are there “edge cases” that commonly trigger failures? And are there equivalent “design patterns” that make certain principles easier to uphold?

While I’ve framed this from a management perspective, these principles apply equally to ICs. If you're aiming to grow your impact or advance toward leadership roles, consider tracking a specific leadership value in your weekly activities. Fostering these habits early not only strengthens your leadership potential but prepares you effectively for future roles.

Perhaps there’s a way to bring more engineering discipline to leadership without losing the human element that makes leadership work in the first place.

If you’ve tried something similar or have thoughts on potential pitfalls I’ve missed, I’d be curious to hear about your experiences. Leave a comment or get in touch with me!

Enjoyed this article? Leave a like and restack it, mentioning your favorite takeaway!

Thanks,

Tim

This is the first article of my series “Bit-sized”. While my focus is on comprehensive articles, I also want to publish smaller, anecdotal pieces. I hope you’ll enjoy reading this digestion-first format. Let me know in the comments!

Read Time: 5 minutes

How clear, action-oriented language accelerates incident response and strengthens team dynamics

When an incident strikes, the difference between a swift resolution and a delay in MTTR1 often comes down to communication. I’ve observed firsthand how ambiguous language can paralyze decision-making and delay critical actions. This article explores how embracing direct, action-oriented communication makes communication easy—particularly during high-pressure situations.

MTTR stands for Mean Time To Repair. It’s a metric that measures the average time it takes to restore a system.

The Hidden Cost of Ambiguous Language

“We should probably check the database.” “Maybe we could roll back the deployment.” “I think something’s wrong with the API.”

These statements share a common flaw: they identify vague problems without driving solutions. When an engineer uses phrases like “we should” or “we could,” they create a vacuum of responsibility that often results in inaction.

I’ve seen it play out in some incident cases at my current employer. We have an On-call rotation which includes team members from week one. In my experience, both junior and senior engineers can struggle with taking explicit ownership during incidents. Juniors might not yet have the system knowledge and fear making things worse, while some experienced engineers who lack incident management practice can fall into the same hesitation patterns despite their technical expertise.

This hesitation results in significant consequences: extended downtime, unnecessary context-switching for the entire team, and degraded customer experience. What appears as politeness or caution is actually creating ambiguity that prevents forward movement.

Incidents are just one example of how engineering actions carry financial consequences. From opportunity cost to poorly explained tech debt, our decisions (and how we communicate them) ripple across the business. For a deep dive into how to make technical decisions with financial impact in mind, have a read here:

Actionable takeaways:

• Immediate: Review your team’s last incident response and highlight instances of ambiguous language. No blame, promise?

• Medium-term: Establish team norms that encourage explicit ownership statements.

• Long-term: Incorporate direct communication training into onboarding team members into On-call roles.

How Polite Language Causes Incident Delays

The conjunctive mode (“we could,” “we should,” “we might”) serves an important social function in regular conversation. However, during incidents, this linguistic hedging undermines action when it's needed most.

Ambiguous language enables what psychologists call the “bystander effect”2—when multiple people are present, individuals feel diminished responsibility to act. As per my example earlier, engineers with less experience of the system often hesitate to claim ownership, especially when they're unsure about systems they're still learning.

Instead of tentative suggestions like “We should probably check the database” effective incident communication requires:

1. Clear statements of intent

2. Named responsibility

3. Specific timeframes

4. Default actions

For example: “I propose a rollback. I'll execute it now unless there are objections in the next 60 seconds.”

Leading by example and shadowing inexperienced engineers in their first few On-Call shifts are a great way to help them shape their finesse in tough situations.

Balancing Formality: When to Be Direct vs. Conversational

While this article advocates for direct communication, context matters. The appropriate communication style should align with the situation’s urgency and impact.

I took the liberty to categorize communication contexts into three zones:

1. Critical Zone: Production incidents, data integrity issues, security breaches

   • Requires maximum directness, explicit ownership, and time-bound actions

   • Example: “If no one vetoes in 30 seconds, I will revert deployment X now. Jane, please verify the database load after the deployment.”

2. Collaborative Zone: Planning discussions, architecture reviews, retrospectives

   • Benefits from a mix of direct proposals and open exploration

   • Example: “I propose approach Y because of reasons A and B. What considerations am I missing?”

3. Community Zone: Team building, knowledge sharing, mentoring

   • Thrives with conversational, inclusive language

   • Example: “I’ve been exploring this approach to API design. What has your experience been?”

Understanding which zone you're operating in allows you to adjust your communication style appropriately.

What to avoid: Treating all engineering discussions with the same communication style, regardless of context or urgency.

Actionable takeaways:

• Immediate: When entering a discussion, mentally identify which communication zone applies.

• Medium-term: Set communication guidelines in specific communication channels such as Incident Calls or Slack Channels—and hold your peers accountable.

• Long-term: Incentivize and celebrate proper usage of direct language in critical contexts. (“John, you did a fantastic job in taking ownership and coordination of this incident!”)

Conclusion: Why Direct Language Accelerates Incident Response

The ability to communicate with clarity and decisiveness represents a significant competitive advantage for engineering teams. By eliminating ambiguity, embracing direct language, and establishing clear ownership, teams can significantly reduce incident resolution times while improving overall effectiveness.

The key takeaways from this article include:

1. Replace conditional language with active commitments

2. Establish clear ownership for every required action

3. Optimize the information-action ratio in critical communication

4. Adjust communication style based on the context's urgency

5. Cultivate a bias for action that eliminates the bystander effect

The next time you find yourself saying “we should probably...” pause and consider the alternative: “I will...” The difference might seem subtle, but the impact on your team's effectiveness will be profound.

I’d love to hear how you deal with passive language? What has helped you adopting a more action-oriented language? Leave a comment or get in touch with me!

Enjoyed this article? Leave a like and restack it, mentioning your favorite takeaway!

Thanks,

Tim

Read Time: 20 minutes

In an era of rising cloud costs and shrinking tech budgets, the most valuable engineers combine technical excellence with understanding the business impact of their decisions. You don’t need to become an accountant, but in today’s ROI-driven tech landscape1, financial awareness acts as a powerful multiplier for your technical impact.

Return on Investment (ROI) is a performance measure used to evaluate the efficiency of an investment or compare the efficiency of several different investments. It directly measures the amount of return on a particular investment, relative to the investment's cost.

Introduction: Engineering with Real Impact

As engineers, we often focus on performance, scalability, and shipping value fast. But behind every commit is something most of us rarely think about: a price tag.

I learned this lesson the hard way. Eight years ago, while working at a startup, I led the development of an end-to-end chatbot configuration platform. Microservices were generating lots of buzz at the time, and I eagerly jumped onto the trend. In my enthusiasm for building “modern” architecture, I designed every configuration step as its own microservice.

While the accidental complexity was off the charts anyways, it also turned out that AWS Fargate was quite expensive, in comparison to our startup’s runway. With that realization I just had to merge the services together. The preferable architecture was a simple, monolithic application, deployed on AWS Elastic Beanstalk. What would have been 6 Fargate instances, became a single service, much cheaper, much less accidental complexity.

Boring and simple—usually the best choice anyways.

Where This Fits: Financial Thinking for Every Engineer

While discussions of engineering economics exist in various forms—from specialized FinOps resources2 to leadership books to platform-specific optimization guides3—there’s a noticeable gap in practical guidance for everyday engineers. Most resources either target specialized roles or focus narrowly on technical optimizations without developing the underlying financial mindset.

This article addresses that gap by focusing on how individual engineers at any career stage can develop financial awareness as a core competency that amplifies their technical impact. Rather than treating financial thinking as a specialized discipline or a leadership-only concern, I argue it’s a fundamental skill that belongs in every engineer’s toolkit.

The Financial Foundations of Engineering

Every technical decision carries financial implications—whether visible or hidden. Before we dive into specific practices, let’s explore the fundamental financial principles that underpin effective engineering. These core concepts will provide the foundation for everything that follows, helping you think more holistically about the true costs and returns of your technical work.

Every Engineering Decision Is a Business Investment

Your time is expensive. Your infrastructure is expensive. Your complexity is expensive.

Engineers are hired to generate value through code that exceeds their cost. When an engineer consistently delivers work costing more than the value produced, it signals a fundamental misalignment in priorities—unsustainable for both engineer and company.

I’m sharing this to create transparency, not anxiety:

• When you refactor, quantify the return: “This will reduce our debugging time by 5 hours per sprint”

• When you add a dependency, calculate the maintenance burden: “This saves us building in-house but adds complexity to our update cycles”

• When you provision infrastructure, right-size it: “This instance is 40% cheaper and meets our performance requirements”

At my current company, we use a internal tool called “Cost Finder”. It analyzes our infrastructure and gives you notifications, if there’s under-utilized resources and presents you the calculated savings. Convenient downsizings like these, save significant monthly costs with zero impact on performance. A nice demonstration of engineering maturity and finesse.

Think of every technical choice as a small investment. When you develop the habit of weighing cost against return, you’ll naturally make better decisions.

Beyond Code: Mastering Opportunity Cost

The most common mistake I see engineers make goes beyond technical issues—they often work on things that feel productive but create minimal actual value.

You might spend a week polishing an internal library that saves each developer five minutes per month. But what if that same week could have gone into fixing a critical user-facing bug affecting thousands of customers? We call this opportunity cost, and your ability to recognize it often separates good engineers from great ones.

Polishing internal libraries to perfection was something I did in the past. You want to become more conscious recognizing when good-enough is good-enough? Have a read here:

Before starting any significant work, ask yourself:

• Does this eliminate effort, prevent outages, or meaningfully accelerate delivery?

• Will this directly help the company make money or save money?

• Can I explain this investment to a non-technical executive in terms that would make sense?

Try framing even technical debt in business language. Rather than saying, “We need to refactor this module because the code is messy,” try something like: “Our team currently spends approximately 8 hours per month debugging issues in this module. This refactoring would reduce that to 1 hour per month, saving us a full engineer-week per quarter.”

I know, it’s hard and feels quite unintuitive at first, but this thinking will ground your decision-making further by transforming technical concerns into quantifiable business investments. When you start attaching concrete financial metrics to your technical initiatives, your decisions become more accurate, data-driven, and the outcomes more predictable and measurable, rather than relying on intuition and proxy metrics alone. Weighing off opportunity cost will get much easier.

When you communicate in these terms, product teams and leadership begin to view your technical judgment with greater credibility. You transform from being seen as merely a technical person into a true business partner.

The Compounding Cost of Technical Debt

You won’t find technical debt on any financial report, but make no mistake—it extracts a real price that compounds over time.4

We’ve all seen it happen. Teams ship fast without proper engineering investments, creating a temporary illusion of velocity and “making that deadline”. Then six months later, the reality hits: you struggle to integrate new features, tests become increasingly flaky, onboarding new engineers drags from days into weeks, and delivery timelines keep stretching longer.

I’ve found these costs are surprisingly quantifiable:

• If features take 30% longer to implement due to tech debt, you’re effectively losing 30% of your engineering time to inefficiency—looking at you, opportunity cost.

• When an outage occurs due to accumulated technical debt, calculate the cost: engineer time to fix it, lost revenue, and potential brand damage (e.g. bad press)

• When onboarding engineers takes three weeks instead of one because of complex, undocumented systems, that’s two weeks of salary with zero productive output

Especially as a staff engineer or engineering leader, your job goes beyond just identifying technical debt—you need to translate it into business impact. This approach moves you from merely pointing out problems to practicing genuine ownership of both code and organizational success.

While technical debt represents the “hidden costs” in our codebase, cloud infrastructure often constitutes the most visible and immediate financial impact of our engineering decisions. As we move from examining the costs embedded in our code, let’s explore how modern cloud environments make financial awareness both more urgent and more actionable for engineers:

Financial Awareness in Modern Tech Environments

The shift to cloud computing and consumption-based models has fundamentally changed how engineering decisions impact finances. This new landscape creates both challenges and opportunities, making financial awareness more urgent and actionable than before. Let’s study how modern tech environments have transformed the financial implications of engineering work.

Understanding Cloud Economics: The FinOps Advantage

The public cloud has fundamentally transformed how we build software. It has also made costs much more visible and immediate, creating both new challenges and valuable opportunities.

Enter FinOps (Financial Operations)—a practice that gives engineers both the tools and mindset to take ownership of infrastructure costs. At its core, FinOps brings financial accountability to the traditionally separate worlds of engineering, finance, and business.

The waste can be substantial:

• Development environments with expensive loads that run 24/7 when they’re only used during business hours or a sprint.

• Services that were scaled up for Black Friday but never scaled back down

• Redundant storage containing duplicate or outdated data that no one reviews

Gartner research shows that organizations typically waste 30-70% of their cloud spend due to idle or improperly managed resources.5

Engineers with FinOps awareness naturally understand that resources spent in one place can’t be invested elsewhere—making opportunity cost a constant consideration. In practice, they:

• Monitor and question infrastructure spend

• Design with cost-efficiency patterns from the start

• Identify quick wins that reduce waste without compromising quality

The Impact of Consumption-Based Pricing

The rise of serverless and consumption-based pricing models has fundamentally changed the financial calculation for engineers.6 Unlike traditional fixed infrastructure where overprovisioning was the primary concern, these models put costs "in your face" with direct correlation to usage patterns. This creates both challenges and opportunities:

• Costs become more variable and less predictable

• Optimization shifts from capacity planning to usage efficiency

• Performance and cost become even more tightly coupled

• Small code inefficiencies can quickly compound into significant expenses

The upside is that consumption models push us toward higher resource utilization and create immediate feedback loops between engineering decisions and costs—reinforcing the financial thinking mindset.

While FinOps principles apply broadly across tech organizations, their adoption becomes particularly crucial—and often mandatory—in certain business contexts. Private equity ownership represents perhaps the clearest example of how financial awareness shifts from optional to essential, with FinOps practices becoming a cornerstone of engineering operations rather than just a nice-to-have capability:

Private Equity, Cost Pressure, and Strategic Engineering

At my current employer, we experienced a significant shift when we were acquired by private equity. Suddenly, the focus on return on investment and operational efficiency became much more pronounced.

Many PE firms define specific target operational models with clear financial parameters. Department sizes are often strictly managed with headcount targets that expect net-zero growth—any new role typically needs to be balanced by efficiency gains elsewhere. It directly impacts your ability to staff projects and address technical challenges.

These ownership structures amplify the visibility of opportunity costs, as limited resources mean any technical investment directly affects another potential initiative. This leads to fundamental shifts in engineering approaches:

• Product priorities become explicitly ROI-driven, requiring to clearly articulate the business case for technical investments

• Engineering initiatives needed clearer justification tied to business outcomes

• Cost-awareness transformed from a "nice to have" to a core expectation

This transition is rarely smooth. Many engineers are accustomed to optimizing primarily for technical quality and throughput—not cost. But the best engineers adapt quickly, recognizing that constraints often drive innovation.

The stakes become quite personal: While revenue growth remains the expectation, the key success metric shifts to ensuring this growth outpaces operational costs. If not, margin pressure can trigger uncomfortable consequences like reduced merit increases, limited growth opportunities, or in worst cases, layoffs. This isn't abstract corporate finance—with performance bonuses often directly tied to revenue and EBITDA targets, engineers suddenly find financial awareness impacting their own compensation.

EBITDA stands for Earnings Before Interest, Taxes, Depreciation, and Amortization. It measures a company's operational profitability without accounting for financial decisions or tax environments.

Managing cultural transformations require deliberate change management strategies to bring the entire organization along. Have a read on this blog article, showing practical approaches for software engineers:

Let me be clear: this shift focuses on sustainability, not penny-pinching. Under PE ownership, having ROI top-of-mind isn’t optional—it becomes a non-negotiable requirement for engineering teams to maintain credibility and influence. The reality of today’s economic climate means engineering organizations must connect technical decisions to business outcomes or they’ll increasingly struggle to justify their existence.

Having explored how ownership structures like private equity and cloud economics intensify the need for financial awareness, the obvious question arises: How do we maintain our innovative edge while operating within these financial constraints? While reducing costs is a important challenge, the actual key is optimizing for the right combination of innovation and efficiency:

Balancing Technical Excellence and Financial Responsibility

Technical excellence and financial responsibility are complementary aspects of engineering maturity. Finding the right balance requires nuanced thinking about when to optimize for cost and when to invest for the future. This section explores how to navigate these tensions and make decisions that serve both technical and business needs.

Finding Balance Between Innovation and Financial Prudence

Wielding the “revenue-sword” as your only tool will quickly earn you disrespect from engineering teams. Similarly, allowing engineers to build overblown “money-burners” without constraints damages your credibility with business stakeholders.

The key is understanding the business context and strategy first, then using that knowledge to shape the solution space collaboratively with engineers. This approach allows you to:

• Bring financial perspective without stifling creativity

• Help engineers understand strategic priorities that justify certain investments

• Focus perfectionism on areas with genuine business impact

• Allow exploration within defined guardrails

Navigating these tensions requires both tactical awareness and strategic thinking. Using concepts like a simple value chain or a more sophisticated Wardley Map7 can help—understanding where components sit on the evolution axis helps determine appropriate investment levels. Core infrastructure that supports multiple visible features often justifies higher investment, even if the immediate ROI is less obvious.

Wardley Mapping is a strategic technique that visualizes the evolution of technology components from novel to commodity. It helps engineers prioritize where to invest effort—custom-building components that provide competitive advantage while efficiently standardizing those that don’t.

Penny-Wise, Pound-Foolish: When Cost-Cutting Backfires

Financial awareness becomes harmful when it leads to short-sighted decisions like:

• Cutting team events that cost fractionally compared to engineering salaries

• Reducing development environments that enable innovation

• Postponing maintenance that leads to disproportionately larger issues later

• Focusing on trivial costs while ignoring architectural inefficiencies costing orders of magnitude more

True financial maturity means knowing where cost control matters and where investment is essential.

Having explored how ownership structures like private equity intensify the need for financial awareness, the obvious question arises: How do we maintain our innovative edge while operating within these financial constraints? While reducing costs is a important challenge, the actual key is optimizing for the right combination of innovation and efficiency:

When “Overspending” Is Actually Strategic

There are definitely times when spending more is the right engineering choice:

• Critical Foundational Work: Investments that support multiple value streams or prevent major outages often justify higher spending, as the cost of failure can far exceed prevention costs.

• Emerging Technologies: Areas like AI/ML and generative tools may require higher initial investment to build organizational capabilities and competitive advantages or in some cases, level the playing field.

• Innovation Initiatives: Explorations that open new business opportunities deserve protection from excessive cost constraints, as they represent potential step-changes in value.

Research shows that companies maintaining strategic investments during economic downturns often emerge stronger when markets recover.8 The key is distinguishing between wasteful spending and strategic investment.

Critics of financially-driven engineering often argue that excessive focus on costs leads to short-term thinking and technical compromise. There’s legitimate truth here—Organizations optimize themselves into technical corners that ultimately cost far more to escape from.9 However, this represents a misapplication of financial awareness rather than a flaw in the principle itself.

True financial maturity recognizes that some technical investments defy simple ROI calculations. Engineering practices like automated testing, comprehensive observability, and architectural modernization often deliver their value through risk reduction and opportunity creation rather than direct cost savings. These investments require a more sophisticated financial lens that accounts for risk-adjusted returns.

Now that we’ve established why financial awareness matters and explored its various dimensions in engineering decisions, let’s shift our focus to practical application. How can you begin developing this mindset regardless of your current expertise level? The journey from theoretical understanding to practical financial awareness starts with simple but powerful steps.

Implementing Financial Awareness in Your Work

Moving from theoretical understanding to practical application requires specific tools and approaches. Whether you’re just starting to think financially or looking to enhance your existing practices, these implementation strategies will help you integrate financial awareness into your daily engineering work.

Getting Started with Financial Awareness

If you’re completely new to financial thinking in engineering, here’s a practical approach I’ve found useful:

1. Start with a “somewhat based” architecture costs calculation of what your current architecture costs

2. Sleep on it, then try to design a completely different approach to the same problem

3. Calculate the costs of this alternative approach

4. Compare not just the immediate costs, but maintenance burden, operational complexity, and scalability costs

While maintenance and complexity are topics that us engineers often talk and think through, we rarely do it through a financial eye. This exercise often reveals surprising insights—sometimes architectures with similar functionality have vastly different cost profiles. Even when the differences are minor, this practice builds the muscle of considering financial implications alongside technical ones.

Making Financial Awareness Measurable

Just as we track technical metrics and user impact, engineering teams should integrate financial metrics into their practices:

Sprint-Level Cost Tracking:

• Estimate and track infrastructure costs for new features

• Document savings from optimization efforts

• Calculate the fully-loaded cost (including engineering time) of major initiatives

Quarterly Reviews:

• Present engineering investments in terms of business impact

• Quantify technical debt in financial terms

• Showcase cost efficiency improvements

Post-Mortems with Financial Context:

• Add financial impact to incident reviews

• Track both user impact and cost impact of outages

• Document the cost of fixes vs. preventative measures

My goal here isn’t to create a culture of fear around spending. Instead, I want us to bring the same thoughtfulness to financial impact that we naturally apply to technical decision-making.

Common Pitfalls to Avoid:

• Tracking only infrastructure costs while ignoring engineering time costs, creating incomplete ROI calculations

• Focusing exclusively on short-term savings while missing long-term infrastructure investments

• Over-optimizing stable systems with minimal traffic/cost, instead of focusing on high-growth/high-cost areas

Financial Awareness Self-Assessment:

• Do you know the approximate monthly infrastructure cost of your team’s services?

• Can you estimate the fully-loaded cost (including engineer time) of your current project?

• Have you optimized any resources for cost in the last quarter?

• Do you consider cost implications when designing new features?

• Can you explain the ROI of your current work to a business stakeholder?

Building Your Financial Engineering Toolkit

To strengthen your financial engineering awareness, consider these resources:

Cost Visibility Tools:

• Cloud provider cost management consoles (AWS Cost Explorer, Google Cloud Billing, Azure Cost Management)

Decision Frameworks:

• Simple ROI calculations for engineering initiatives

• Cost of delay for technical debt prioritization

• Good/Better/Best options with cost implications

Communication Templates:

• How to present technical investments to business stakeholders

• Translating infrastructure costs to business metrics

• Building cost-benefit analysis for engineering projects

Financial Awareness Across Engineering Roles

The type of financial awareness needed varies significantly by engineering role:

SRE/DevOps Engineers: These roles typically have direct visibility into what actually costs money—the infrastructure itself. They’re often closest to the resource utilization metrics and spending patterns.

Backend Engineers: Architecture decisions at this level directly influence infrastructure requirements. The data storage patterns, processing approaches, and scalability models they choose drive downstream costs.

Frontend Engineers: While seemingly further from infrastructure costs, frontend decisions about asset sizes, client-side processing, and API call patterns can significantly impact backend resource needs.

Generally, the further down you are in the value chain (closer to infrastructure), the greater understanding you should have of costs, as your decisions will have cascading impacts upstream. But all engineers should have at least a basic understanding of how their work affects the bottom line.

Across all these company types and roles, I’ve found one principle holds true: engineering decisions made without considering financial impact remain fundamentally incomplete. This doesn’t push you toward always choosing the cheapest solution—rather, it empowers you to make conscious tradeoffs with full awareness of cost implications.

Once you’ve begun implementing financial awareness in your own work, the next challenge is extending this mindset beyond your individual contributions. Moving from personal practice to organizational impact requires navigating diverse contexts and sometimes difficult conversations. Even the most financially sound engineering decisions can face resistance, misunderstanding, or competing priorities from different stakeholders. As you develop your technical and financial toolkit, you’ll need complementary skills to advocate for financially responsible approaches across various organizational environments:

Navigating Financial Conversations and Contexts

Financial awareness doesn’t exist in a vacuum—it happens within specific organizational contexts and conversations. Different environments require different approaches, and effectively communicating financial thinking can be as important as the thinking itself. Let’s explore how to adapt these principles to various situations and advocate effectively for financially sound engineering.

Different Contexts, Same Principles: Financial Awareness Across Organizations

The financial awareness needed by engineers varies across organization types, though the principles remain consistent:

Bootstrapped Startups: In organically growing companies, every cent spent on infrastructure directly impacts runway. Engineers in these environments need to be ruthlessly pragmatic, often choosing "good enough" solutions that preserve capital for growth.

Private Equity-Owned Companies: These organizations typically focus on operational efficiency and EBITDA improvement. Engineers need to frame technical investments in terms of measurable returns, often with shorter time horizons.

Enterprise Organizations: Larger companies operate with more complex budget cycles and CapEx/OpEx considerations. Engineers need to understand the difference between capital and operational expenditures and how budget cycles impact project approvals.

CapEx vs. OpEx: Capital Expenditures (CapEx) are major purchases that will be used long-term, while Operational Expenditures (OpEx) are ongoing costs to run the business. This distinction matters for engineering decisions because many organizations budget differently for these categories, often finding it easier to approve OpEx.

Navigating Organizational Tensions

Introducing financial awareness into engineering practices isn’t without challenges. Common resistance patterns include:

The Ownership Barrier: In many organizations, infrastructure decisions are controlled by specialized teams (like SRE) who may restrict technology choices. This can create friction when engineers want to experiment with new approaches.

The Innovation vs. Cost Dilemma: Too much focus on cost can artificially constrain the solution space. For example, I’ve encountered situations where we were discouraged from creating separate development environments due to cost concerns, despite their value for exploration.

The Technical Debt Justification Challenge: Long-term investments in code quality can be difficult to justify when benefits are diffuse and costs are immediate.

Navigating Financial Disagreements with Stakeholders

When you encounter resistance or disagreements about the financial value of technical work:

1. Always assume best intent from all parties

2. Gather and present multiple perspectives rather than pushing a single view

3. Develop several options with different cost/benefit profiles

4. Present clear trade-offs to decision-makers rather than binary choices

5. Focus on business objectives first, then show how technical approaches support them

This approach builds trust and positions you as a thoughtful partner rather than someone defending their technical territory.

Engineers who consistently demonstrate this awareness:

• Gain outsized influence across functions

• Focus on truly impactful work

• Build reputations as business-savvy problem-solvers

Most importantly, they future-proof their careers in an increasingly cost-conscious tech economy.

Throughout this article, we’ve explored how financial awareness transforms engineering practice—from individual technical decisions to organizational contexts. Having seen how this mindset applies across different environments, let’s now examine the ultimate impact of financially-aware engineering:

The Wrapup: The Impact of Financially-Aware Engineering

What’s the ultimate outcome of developing financial awareness as an engineer? This section examines how this mindset transforms not just your technical decisions, but your overall impact and career trajectory. We’ll look at both immediate benefits and long-term advantages of approaching engineering with financial awareness.

Engineers Who Understand Money Create Sustainable Value

I want to emphasize this core message: Financial thinking is about making strategically sound decisions, not about cutting corners.

Engineers who consistently demonstrate financial awareness:

• Gain broader influence across functions by speaking a language business leaders understand

• Focus on high-impact work by evaluating initiatives through both technical and financial lenses

• Build reputations as problem-solvers who connect technical excellence to business outcomes

future-proof their careers in an increasingly cost-conscious (and AI powered) tech economy

Key Takeaways

• Every engineering decision is an investment that should generate meaningful returns

• Technical debt has quantifiable costs that compound over time

• Different organizational contexts require different financial approaches, but the core principles remain

• Financial awareness varies by role but should exist throughout the engineering organization

• Balancing innovation and cost-efficiency requires understanding business strategy

• Some strategic “overspending” is actually valuable long-term investment

Engineers who understand financial impact write code that creates sustainable business value.

At any career stage—from junior developer to staff engineer—developing financial awareness will amplify your impact. You don’t need to become an accountant; you simply need to bring business context to your technical decisions.

I’d love to hear how financial thinking shows up in your work? How has your organization bridged the gap between financial and technical thinking? Leave a comment or get in touch with me!

Enjoyed this article? Leave a like and re-stack it, mentioning your favorite financial insight!

Thanks,

Tim

Read Time: 10 minutes

Why Time Management in Engineering Requires Strong Leadership

Great engineering leadership isn’t measured by output squeezed from teams, but by value unlocked through the right conditions. After years guiding engineering teams through challenges, I’ve come to re-evaluate some classic management principles through a modern engineering lens.

One concept I frequently encounter in discussions about productivity is Parkinson’s Law. This seemingly simple principle has profound implications for how we lead engineering teams—but not necessarily in the way many think.

In this article, I revisit Parkinson’s Law, unpack its misapplications, and offer a leadership playbook for navigating what I call the “perfection-pressure spectrum.”

What I've discovered might surprise you: the real challenge is giving engineers permission to stop instead of getting them to work harder.

As we’ll see, in engineering contexts, work expands not through bureaucratic inefficiency or laziness, but through unchecked perfectionism—a commitment to craft that, paradoxically, can work against delivering value. And it explains why these traditional “productivity hacks” backfire: they solve for idleness when the real challenge is excellence run wild.

The Origins: What Parkinson Actually Meant

I first encountered Parkinson’s Law while reading Tom DeMarco and Timothy Lister's influential book Peopleware.1 The law, coined by historian Cyril Northcote Parkinson in 1955, states that “work expands to fill the time available for its completion.”2

It's like making a sandwich. Give yourself 2 minutes, and it's bread-meat-cheese-done. Give yourself 30 minutes, and suddenly you're cutting the tomatoes into perfect circles, toasting the bread just right, and arranging everything in layers. Same hunger, same basic sandwich, just a lot more time spent on it.

Parkinson observed this, not in the kitchen, but in administrative contexts, particularly noting how British Civil Service bureaucracy grew regardless of the actual workload. He wasn't speaking about knowledge workers solving complex problems—he was describing bureaucratic inefficiency.

As DeMarco and Lister point out in Peopleware, this context matters:

“Parkinson’s Law almost certainly doesn’t apply to your people.”

Their skepticism makes sense. Parkinson based his observations on administrative tasks with clear endpoints. It’s not the complex, creative problem-solving that characterises modern software engineering. And yet, something about the law still rings true in our world.

What Research Reveals About Engineering Estimates

The research around time estimates in engineering projects tells an interesting story. The 2013 edition of Peopleware references a particularly compelling 1985 study by Lawrence & Jeffery from the University of New South Wales that examined how different scheduling approaches affect team productivity.3

Their findings were striking:

The study showed that teams without deadlines achieved productivity significantly higher—on the order of 40-50% better—than even the best of the deadline-bound groups. This wasn’t just slightly better; it was dramatically better.

As DeMarco and Lister quote metrics expert Capers Jones: “When the schedule for a project is totally unreasonable and no amount of overtime can allow it to be met, the project team becomes angry and frustrated... morale drops to the bottom.”

This data seems to suggest Parkinson’s Law has little place in software engineering. If anything, it appears counterproductive when interpreted as justification for imposing tight deadlines.

Yet the real world introduces complexity. Engineering teams operate within broader systems—stakeholders, product roadmaps, cross-functional dependencies, and budgets. At some point, milestones must be set.

While some argue that estimates should be abandoned entirely, I find that view often overlooks how businesses actually operate. Software exists to serve users and align with broader strategy and not just to ship tickets. The real insight is that realistic time estimates aren't restricting—they're valuable tools that balance engineering freedom with organizational needs. The key is ensuring these estimates come from thoughtful team input rather than arbitrary deadlines.

When Parkinson’s Law Does Apply to Engineers

While research challenges the traditional application of Parkinson’s Law in creative knowledge work, I've observed that work expansion still occurs in engineering teams—just through a different mechanism than Parkinson originally described.

Engineers have a natural tendency toward perfectionism and completionism, rather than laziness or unengagement. Without clear constraints, many engineers will:

• Continue refining solutions well past the point of diminishing returns

• Add “nice to have” features that weren't in the original requirements

• Refactor code that’s already functional but could be “more elegant”

• Delay shipping until they feel the solution is “complete”

It’s the opposite of laziness. It’s a commitment to quality that, paradoxically, can work against delivering value efficiently.

While engineers often expand work through perfectionism and craft, there is also the classic manifestation of Parkinson’s Law when intrinsic motivation is absent. I’ve seen skilled developers who had mastered tasks but no longer found them challenging—work stretched not through careful craftsmanship, but through reduced engagement. This is the intrinsic motivation problem: without autonomy, mastery challenges, or purpose connection, work becomes something merely to complete rather than excel at. In these cases, tighter timeframes might temporarily increase output, but the sustainable solution is reconnecting engineers to what drives them internally.

The Perfection Trap: When Excellence Becomes a Blocker

What appears to be Parkinson’s Law in action is often what I call the “perfection trap.” Engineers aren’t filling time with busywork—they're pursuing a 100% solution when an 80% solution would deliver the needed business value.

During a time-sensitive release, one teammate spent two weeks perfecting an integration test already covered by unit tests. In hindsight, we should have offered clearer leadership and clarified priorities earlier. Even with that, the teammate was especially insistent on implementing certain refactorings, leading to extended debates on class structure rather than shipping urgently needed features. While their drive for quality was admirable, this “perfection trap” delayed real business value.

A widely known example of the perfection trap is Google’s Gmail, which famously remained in ‘beta’ for over five years.4 While continual refinement improved features, this unchecked perfectionism delayed broader business adoption, particularly in enterprise settings where “beta” signaled instability. Google engineers weren’t delaying due to laziness—they were continuously perfecting the product beyond what users actually needed, illustrating how Parkinson’s Law in engineering manifests through craft, not complacency.

The perfection trap stems from several psychological factors:

• Professional identity: Engineers often tie their self-worth to code quality

• Fear of judgment: Concerns about peer criticism during code reviews

• Positive intentions: Genuine belief that perfectionism serves the product’s long-term health

These instincts come from good places: commitment to craft, attention to detail, and professional pride. But when left unchecked, they can prevent timely delivery of value and create unpredictability in your engineering process.

The Diminishing Returns of Perfection

As Steve McConnell argues in Software Quality at Top Speed, pushing for ultra-high defect removal rates—above 95%—can actually slow delivery, offering marginal benefit outside of life-critical systems. This illustrates how chasing “perfection” in software quality can quickly become counterproductive.5

At my current employer, we once had a product principle that captured this tradeoff well: “Don’t cover all the cases.” It was a deliberate cultural stance. It encouraged teams to move quickly, ship value fast, and address edge cases iteratively. It worked well in that stage of our growth, when speed of learning and delivery mattered more than polish.

This explains why Parkinson’s Law manifests in engineering: work expands through misallocated craftsmanship, not laziness.

Leadership’s Role: Setting Healthy Constraints

“So if Parkinson’s Law doesn’t fully apply as traditionally understood, how should engineering leaders approach time management?”

While the temptation might be to impose arbitrary deadlines, effective engineering leadership calls for:

1. Understanding the team's true capacity—not wishful thinking or pressure-based expectations

2. Setting constraints that challenge without demoralising—deadlines should feel ambitious but achievable

3. Clearly establishing a “Definition of Done”—what features and quality level constitute a shippable product?

4. Promoting incremental delivery—breaking work into smaller shippable increments

5. Creating psychological safety—engineers need to feel comfortable shipping “good enough” solutions and iterating later

Instead of pressuring engineers to work faster, the objective is to guide them in recognizing the ideal moment to stop refining and ship. This approach channels perfectionist tendencies into delivering tangible business value.

The Middle Path: Between Arbitrary and Absent Deadlines

Finding the right balance is crucial. As I’ve observed in my teams:

• Too strict deadlines lead to cutting corners, technical debt, and eventual burnout.

• Too lenient or absent deadlines allow the perfection trap to take hold, delaying value delivery and increasing project costs.

  These perfectionist tendencies often flare up when engineers face ambiguity—whether from shifting priorities, unclear expectations, or changing org structures. If that resonates, I explore concrete strategies for navigating those transitions in this practical guide to change management for engineers.

The sweet spot is what I call “informed constraints”—timeframes based on a genuine understanding of the work and the team, with enough pressure to maintain focus but not so much that quality suffers.

Parkinson’s Law as a Tool, Not a Weapon

Reframed this way, Parkinson’s Law becomes a useful tool for engineering leaders. It reminds us that:

• Constraints can be helpful when they're realistic and informed

• Perfect is the enemy of done, particularly in fast-moving technology environments

• Engineers benefit from clear guidance on when to stop refining and start shipping

The law isn’t about making people work harder or faster—it’s about recognizing our natural tendency to expand work and setting appropriate boundaries. And crucially, it's about understanding when to apply that pressure, and when not to.

Practical Applications: The Perfection-Pressure Spectrum

The Perfection-Pressure Spectrum is a leadership tool I developed to help navigate the balance between quality-driven perfectionism and deadline-driven pressure, guiding teams toward delivering meaningful value through informed constraints.

Over the years, I've found these approaches particularly effective in managing the “Perfection-Pressure spectrum” while maintaining quality:

Recognizing the Perfection Trap

Watch for these warning signs:

• Endless refactoring without clear stopping criteria

• Features that were “90% done” for days

• Engineers reluctant to share work until it’s “perfect”

• Growing scope without corresponding timeline adjustments

Applying Informed Constraints

While the healthy constraints outlined earlier provide the overarching strategy for a supportive and realistic time management approach at leadership level, these informed constraints outline specific and actionable practices that implement the strategy.

1. Collaborate on estimates—involve the team in setting timeframes to ensure they're realistic and have buy-in

2. Define clear acceptance criteria—make “done” explicit and achievable using a clear definition of "good enough"

3. Celebrate shipping over perfection—reinforce the value of getting solutions to users by recognizing timely delivery

4. Build in refinement cycles—plan for improvements after initial release rather than delaying to perfect (e.g., “We'll ship this now, gather data and improve it next sprint with more information”)

5. Implement timeboxing—allocate fixed time windows for refactoring or polishing, after which the team moves on

The right balance on this spectrum shifts based on context—medical software justifiably demands higher perfection than a marketing site, startups benefit from quick 70% solutions while enterprises may need more polish, and early products require rapid iteration while mature ones warrant deeper refinement. Effective leaders adjust constraints based on these factors rather than applying one-size-fits-all thresholds.

One practical approach I've used successfully: When a team member proposes adding scope or performing additional refactoring, ask them to quantify the user impact: “How many users will notice this improvement? What business metrics will change as a result?”

This bases engineering effort in user outcomes and business value—not just technical curiosity or craftsmanship.

The Perfection-Pressure Checklist

Use this checklist as a quick gut-check when leading your next project:

• Have we defined what “good enough” means for this feature?

• Are my constraints informed by team input and real business needs?

• Have I created a clear path for future improvements after initial shipping?

• Am I recognizing both timely delivery and quality work?

• Does the team understand the business impact of their technical decisions?

These questions help steer effort toward value—not just effort for effort’s sake.

Conclusion: Beyond the Law

Parkinson’s Law wasn’t written for engineering. But the core pattern—work expanding to fill available time—still plays out, just through a different lens: craft-driven overcommitment rather than bureaucratic inefficiency.

Modern engineering work rarely suffers from idleness. Software Engineering has never been so accessible before and is thriving from a vibrant community full of motivated and passionate problem-solvers.

The challenge is knowing when to stop refining and start delivering. That’s where leadership comes in—not to impose pressure, but to create guidance and clarity.

Clarity around priorities. Around scope. Around “done.”

When engineering leaders provide informed constraints, celebrate meaningful delivery, and keep value in focus, Parkinson’s Law becomes a helpful lens—not a hammer.

That’s the work. And it’s where great leadership shows up.

I’d love to hear how Parkinson’s Law shows up in your work? How do you manage perfectionist tendencies? Leave a comment or get in touch with me!

Enjoyed this article? Leave a like and restack it, mentioning your favorite takeaway!

Thanks,

Tim

Special Thanks go out to Maria Eduarda Auler (Frontend Engineer, Kleinanzeigen) and Matthew Goodwin (Head of Tech Program Management, Kleinanzeigen) for their valuable feedback, helping me shape this post!

Read Time: 8 minutes

Change is a constant in tech. As an Engineering Manager, I've had the opportunity to guide teams through evolving priorities, emerging technologies, and organisational adaptations. This isn't just abstract management theory—it's practical experience I apply daily to help talented engineers thrive during transitions.

In this guide, I'll share practical strategies for engineers dealing with various forms of workplace change—from team restructuring to shifting priorities and career uncertainty. These approaches have helped me and many engineers I've worked with maintain focus, motivation, and growth even during significant transitions.

The Reality of Uncertainty

Let's face it—uncertainty is everywhere these days. For software engineers, this has been especially jarring. After the COVID hiring boom, the job market has collapsed—job listings are down 70% from their 2022 peak.1 Engineers across the industry are feeling this shift. These aren't just statistics—they represent changing career trajectories and colleagues adapting to new market realities.

Meanwhile, generative AI tools like ChatGPT and GitHub Copilot are transforming how we write code, leaving many wondering what skills will remain valuable in five years. I've watched talented team members struggle with this whiplash effect, questioning their career paths in ways they never anticipated.

These rapid shifts in the job market and technology landscape can trigger profound anxiety and stress in even the most talented engineers. Many find themselves questioning their career choices, worrying about job security, and wondering if their technical skills will remain relevant.

Left unchecked, this uncertainty can lead to decreased productivity, burnout, and reactive decision-making. The following strategies offer a framework for regaining a sense of control and purpose amid these unprecedented changes.

Focus Where Your Levers Are

When everything feels chaotic—whether from industry-wide job market shifts, technological disruption, or organisational changes—I've found one principle helps more than anything: focus on what you can actually influence.

You can't control market conditions or executive decisions.

But you can control:

• How you develop your skills

• The quality of your code

• Your relationships with colleagues

• Your response to challenges

This approach isn't just about feeling better—it creates tangible results. When you focus on controllable factors, you maintain a sense of progress that keeps motivation alive, even during turbulent times.

I learned this lesson the hard way. Early in my career, I thrived on increasing responsibilities and frequent advancement, which naturally focused my attention on these external markers of success. Of course, career growth isn't linear in any healthy organisation—it involves plateaus and different types of growth. When my trajectory shifted toward depth rather than just upward movement, I initially found it challenging to recalibrate my motivation.

What helped me navigate frustrating staffing and priority changes was adopting the mindset: "Do the best job you can with the tools and context around you." The tools and context will change. What matters is consistently delivering quality work regardless of circumstances.

This doesn't mean ignoring the bigger picture. We all need to vent sometimes! Find trusted colleagues where you can express frustration safely. Just don't get stuck there—redirect your energy toward what you can change.

The Change Curve Isn't Linear

You might be familiar with the classic Kübler-Ross change curve—that model showing how we move from shock through denial and frustration before eventually adapting. It's useful, but in my experience, it's rarely that neat. It was designed for linear, one-time events like grief and struggles to capture the dynamic nature of modern software engineering.

In tech, change is continuous, often overlapping, and driven by feedback loops, making emotional responses far less predictable and linear.

Real change looks more like cycles within cycles. You make progress, then hit a new obstacle. Different team members experience different phases simultaneously. And just when you think you've adapted, requirements shift again.

Understanding this non-linear reality helps set realistic expectations for yourself and your team.

Engineering Challenges and Value Beyond Completion

Engineers face distinct challenges during organisational change: shifting priorities redirect effort, team structures evolve, and career trajectories adjust to new realities.

I experienced this firsthand while leading several teams through our company's strategic evolutions. In one case, after an experiment-driven cross-functional team achieved its objectives, the company naturally pivoted resources toward new priorities. Later, as market conditions evolved, our team's relative priority adjusted accordingly. These shifts meant adapting to changing resource allocations and team compositions.

Initially, I found these transitions challenging—it's natural to become invested in your team's specific direction. But over time, I recognised that organisational agility is a competitive advantage and that applying the mindset from earlier ("The tools and context will change") helps navigate these changes effectively.

The direct output of our work—code, designs, documentation—represents only a fraction of our contribution. The real impact persists beyond immediate deliverables.

Initiatives I've led that evolved from their original vision still:

• Bridged critical revenue needs during transitional periods

• Reminded us to measure business impact rather than just technical output

• Made the team more resilient to future changes

Connecting your work to broader business objectives provides perspective when specifics shift. Your expertise, collaborative relationships, and problem-solving create lasting impact regardless of changing structures.

In my experience, engineers who adapt while focusing on long-term value creation consistently navigate uncertainty more successfully than those fixated solely on technical implementation details.

Balance Your Motivations

While salary is obviously important (we all have bills to pay, hobbies to fulfill), pinning all your job satisfaction on external rewards makes you vulnerable during change.

As I mentioned earlier, I fell into the trap of focusing my motivation primarily on external factors, which backfired when my career growth curve inevitably flattened.

The engineers who weather transitions best focus on building value that persists regardless of organisational shifts:

• Taking on challenges that expand your technical toolkit

• Mastering skills that are in demand across the industry

• Building a portfolio of solutions to complex problems

• Developing collaboration skills that work in any environment

This approach not only creates mental stability during uncertainty but ensures you're continuously enhancing your market value. When the next change comes—and it will—you'll have tangible growth to show for your time, regardless of project outcomes.

Sometimes, though, that drive to deliver value turns inward—becoming perfectionism that delays shipping. I unpack this in The Perfection Trap, where I explore how perfectionism can quietly derail delivery—and what leadership can do to redirect it.

Talk to Your Manager

One of the most underused strategies during change is simple: talk openly with your manager about what's happening.

Be direct about how you're feeling and what you need clarity on. Frame your concerns as specific questions about e.g. priorities, expectations, and team direction. "How might these organisational changes affect our quarterly roadmap?" or "What should I prioritise given this resource shift?" are more actionable than general expressions of anxiety.

The outcomes of these conversations help no matter what you learn. At best, your manager can give you context that answers your questions. If they're also uncertain, you've still gained useful information and built trust through openness.

I've experienced this from both sides. As a manager, I've had team members come to me with concerns about roadmap changes. Even when I couldn't completely resolve their uncertainty, our honest conversations almost always improved the situation. Just naming the ambiguity reduced stress and allowed us to focus on what we could control together. As an engineer before that, I found that managers often had information or perspectives that significantly changed how I viewed certain situations.

Eliminate Uncertainty Where Possible

While some uncertainty can't be avoided during change, you can often clear up more than you think.

When things feel unclear:

• Ask direct questions instead of worrying about general concerns

• Write down what you know for sure vs. what's still up in the air

• Break big unknowns into smaller pieces you can tackle one by one

This takes guts. It's easier to just complain about feeling lost than to pinpoint exactly what you don't understand. Complaining might feel good for a moment but keeps you stuck; asking tough questions moves you forward.

Facts vs. Opinions vs. Rumours

During change, communication gets muddy. People blend verified facts with opinions and rumours until it's hard to tell which is which.

I've noticed how easily "doomsday" narratives spread through teams. "This restructuring means layoffs are coming" or "The company is abandoning our technology stack."

Train yourself to mentally categorise what you hear:

• "The company is restructuring team X" (verifiable fact)

• "This restructuring will lead to more layoffs" (opinion or prediction)

• "I heard from someone that..." (potential rumour)

This simple practice reduces anxiety and helps you respond appropriately.

Create Space for Team Processing

When your team is struggling with change, create structured opportunities to process together. In my team, we've held sessions to:

• Acknowledge where we are in the change process

• Identify specific frustrations and concerns

• Collaborate on what we can improve within our control

The key is balancing emotional processing with practical action. Acknowledge feelings, then focus on next steps.

Building Change Resilience

Change management isn't about eliminating discomfort—it's about developing tools to navigate it effectively.

The engineers I've seen thrive during uncertainty:

• Stay clear about what they can and cannot influence

• Balance external rewards with intrinsic motivations

• Communicate transparently with leadership

• Actively reduce ambiguity where possible

• Distinguish between facts, opinions, and rumours

These skills don't just help you survive change—they position you to grow through it.

The constant in engineering careers isn't stability. It is change itself. By applying these strategies consistently, you can transform uncertainty from a source of anxiety into an opportunity for development.

Your value as an engineer goes beyond any specific project or technology. Your problem-solving skills, teamwork, and ability to build useful solutions stay valuable no matter how your company changes direction. These strengths work well in any team or department, helping you adapt when priorities shift.

I’d love to hear about change management tactics that work for you! How do deal with anxiety? Leave a comment or get in touch with me!

Enjoyed this article? Leave a like and restack it, mentioning your favorite takeaway!

Thanks,

Tim

Special Thanks go out to (MTS 2, Software Engineer, Kleinanzeigen) and Max Tritschler (Head of Engineering, Kleinanzeigen) for their valuable feedback, helping me shape this post!