Decision-Making and Feedback Loops

How decision-making evolves from immediate feedback in coding to long-term strategic choices as you progress through engineering leadership roles

Making decisions and getting feedback on them is crucial, but varies significantly across different engineering roles. In this short post, I'll summarize my perspective on how decision-making changes as you climb the career ladder, transforming into a role quite different from where you started.

What is meant by decisions and feedback loops

Let me first explain what I mean by this. Every employee in a company can make decisions that have an impact. You'll get immediate feedback for some decisions, while for others, feedback can take years.

This creates a loop because your next decision isn't made in a vacuum—it's influenced by the feedback you've received from previous choices. With this foundation laid, let's move on to practical examples.

Engineer

A typical engineer makes decisions about what code to write and how to write it. Usually, the "why" is defined by user stories or UI mockups. While engineers in smaller startups might have broader decision-making power, the scope tends to be more focused in large companies. Engineers can also often choose which tickets to work on.

Engineers receive immediate feedback through various tools like:

• Compilers

• Linters

• Formatters

• Automated CI/CD pipelines

This quick feedback loop provides fast, visible results—something I personally find deeply satisfying because it offers precise guidance for improvements.

However, not all feedback comes so quickly. When it comes to user feedback, the loop can stretch much longer. Issues might only surface weeks or months after completing the work. These longer feedback cycles are challenging, and companies often strive to shorten them through faster updates (for example, using automated CI/CD pipelines). While some industries can achieve shorter feedback loops, others face significant obstacles in doing so.

Architect or Staff Engineer

I'm summarizing these two roles together, although they can be quite different with various archetypes. For simplicity in this blog post, I've combined them. In these positions, your decision-making scope expands significantly. You become responsible for technical decisions across one product or multiple products, and you begin to influence other key decision-makers. While you still write code with quick feedback, your other feedback loops become much slower.

Technical decisions and their consequences can take years to fully reveal themselves. Consider these common scenarios:

• A wrong choice might only become apparent when a future feature exposes its limitations

• Products evolve in unexpected ways as customer usage patterns shift

• Technology advances can make previous decisions suboptimal

Through this, you learn that any decision might prove suboptimal in the future—and that's okay.

When influencing others' decisions, you enter a realm where discussions can stretch over long periods before reaching an agreement. In larger organizations, feedback becomes even more delayed as teams implement these changes. Sometimes, surprising feedback emerges later, pushing you to revisit topics and continue influencing more stakeholders.

Teamlead or Engineering Manager

In this role, depending on the company you work for, you might still do some coding. For most managers I've met, coding is their safe haven—it's the satisfying part where results are visible quickly. However, this role primarily involves talking to and influencing others. Whether you're advocating for team members' salary increases with your manager or deciding what to build next with other product teams, everything revolves around influence.

These feedback loops range from fast to very slow. Here's what you need to know:

• Getting team members promoted can take years

• You need to embrace the strategic nature of this role

• Focusing too heavily on technical aspects while neglecting management responsibilities can lead to systemic issues

Director, VP of Engineering, CTO

Some leaders in these roles still do coding, which serves as their safe haven since it provides the only fast feedback loop available to them. The amount of hands-on coding varies significantly by company size—in small startups, it may still occupy considerable time.

Most decisions at this level are long-term and extend beyond engineering into:

• Business strategy

• Financial planning

• Corporate initiatives

While you might get feedback on budgets within a year, other initiatives—like a three-year engineering strategy—naturally take years to validate.

There's also less peer interaction at this level compared to other roles. Even in large companies with multiple directors or VPs, there's often minimal overlap between their responsibilities. Unlike the team lead level, where mentoring and knowledge exchange are common, directors largely operate independently. You must build your own network to understand and navigate decisions.

This position is also furthest removed from hands-on engineering, requiring frequent interaction with Finance, Sales, Product, and Service teams. This creates a complex decision-making environment with multiple stakeholders and potential misalignments. These feedback loops can stretch for years, and you often need to adjust course as business conditions change.

While people who enjoy strategy and long-term planning can thrive in this role, it's important to maintain activities that provide quick feedback and visible progress. In my case, I still do some coding—but only prototypes, never in production environments.

Summary

We explored how decision-making and feedback loops evolve across different engineering leadership roles. From engineers who receive immediate feedback through code, the roles progress to architects, team leads, and executives who face increasingly longer feedback cycles. As one advances in their career, decisions become more strategic and less technical, with feedback loops extending from days to years.

Key Takeaways

• Quick vs. Slow Feedback: Engineers enjoy quick feedback loops through code, while higher roles must adapt to longer feedback cycles

• Strategic Evolution: Career progression often means moving away from immediate technical feedback to more strategic decision-making

• Influence & Network: Higher roles require strong influence and networking skills as decisions impact broader organizational scope

• Balance: Leadership positions need to balance long-term strategic thinking with activities that provide quick feedback

• Adaptation: The transition from hands-on coding to strategic leadership requires adapting to different types of satisfaction and success metrics