A definition

💡

Being effective means doing the right thing well.

It is not enough to be blameless in defeat, one must seek victory. This means being adaptable and focusing on doing right not just being right. As Richard Rumelt puts it in Good Strategy, Bad Strategy

To take responsibility is more than a willingness to take blame. It is absorbing ambiguity, handing back to the organization a simpler, solvable problem.

Guiding principles

💡

The human aspects of technical work are not incidental but rather essential to the work.

If you are right but can’t bring others along, then your effectiveness will be limited. Let’s use an analog to illustrate this principle. Consider this equation:

40/8(5+3)

What does it resolve to? Some might arrive at 0.625, others at 40. The observation worth noting is that the question, as written, is ambiguous and ambiguity invites error. Rewriting it with parenthesis -(40/8)(5+3) - eliminates that ambiguity and invites correctness.

Mathematical convention (BOMDAS / PEMDAS) provides rules for such cases, but these rules are commonly misapplied. This illustrates the distinction between merely being right and being effective. Once you know that misapplication is a common source of error, your goals should influence how you use that knowledge.

For instance, if your goal is to teach math, then it may be prudent to let students trip in order to learn from experience to be mindful of this class of error. If, however your goal is to minimize potentially costly errors, then write the formula in such a way that reduces the risk of error.

💡

Being clear about your objectives informs what course of action is most effective for a given context and set of constraints.

With these principles in mind, here are tactics that I’ve found to help me be more effective, reduce the chances of errors, and overall increase the likelihood of success for the projects

Decision-making frameworks

Mental frameworks serve as collections of heuristics and pattern recognition models. They enable us to evaluate trade-offs and benefits systematically, leading to informed, literate decision-making.

The trinity of execution

Understanding the variables

Project delivery success depends on three fundamental variables:

Timing: Committed dates and/or deadlines (when)
Scope: Requirements (what) and implementation/solution (how)
Resources: Team allocation and composition, tools available, etc (who)

Working within constraints

An aspect of effective engineering leadership is understanding to what extent (and by what means) these constraints can be adjusted. For instance, when timing and scope are fixed, leaders must secure necessary resources. Conversely, with fixed resources and timing, leaders must clearly define achievable scope.

The trinity of prioritization

Assessment criteria

When determining project scope and technical debt tolerance, consider:

Hypothesis validation: Has the concept been proven, or are we testing assumptions?
Risk assessment: What are the potential failure modes, their impact on stakeholders, and our mitigation capabilities? Technical feasibility and effort assessments fit here as well.
Impact assessment: What is the potential scale of positive outcomes?

Prioritize learning/insights over fidelity

Technical debt is incurred when either an implementation doesn’t serve its purpose well or when concessions are made to ship work within given constraints. Like financial debt, unwise accumulation of tech debt can encumber a team, slowing velocity and eroding morale. Also like financial debt, pragmatic tech debt can be capital investment within long-term returns.

When you have an unvalidated hypothesis, Do things that don’t scale because An MVP is not a Cheaper Product, It’s about Smart Learning. Consider what can be done manually until you learn if it’s worth automating.

An effective engineering leader works with domain experts such as User Researchers, Data Scientists, and Product Managers to define these variables in order to figure out what opportunities to pursue and in what order.

Prioritization matrix

Validated hypothesis	Known risk	Impact	Framing	Prioritize
No	Low	> Low	Don’t know if it will work out but worth a shot to find out	Speed of learning. Small, quick tests
No	High	Mid-High	Might be worth a shot but it might cost us customers if we do it wrong	Reducing scope and focusing on the quality of the remainder.
Yes	Low	> Low	Known best practice / table stakes. People may not notice if you do it, but they’ll notice if you don’t	Quality of monitoring & alerting. Paying off any tech debt accumulated when prioritizing small, quick tests
Yes	High	High	Totally about execution.	Quality, roll-out and roll-back procedures

Mitigating risk: prioritize the unknown over the known.

Focus on illuminating the largest sources of uncertainty in a project first. These areas have the greatest risk of derailing projects. In practice that means that,

💡

When faced with a wide estimate range for a given project or task, identify and front load exploration of the areas that are the largest contributors to the uncertainty.

Doing so reduces the risk of finding out that you are nowhere close to done because of complexity discovered towards what you thought was the tail end of a project.

Make cheap decisions quickly

💡

If a decision is reversible and the options are defensible, pick one and roll with it. Excessive deliberation can eat into focus & execution time.

For instance, choosing between server-side rendering (SSR) and client-side rendering (CSR) has significant implications as there are APIs available on web browsers that aren't available on the server and vise versa. But choosing between SSR and static site generation (SSG) is a more reversible decision because in either case, a server - either a web sever in the case of SSR or a build sever for SSG - determines the output.

Communication frameworks

Make highly literate decisions

💡

A literate decision is one in which the driving factors are communicated along with the actual decision, and communicate to the right people.

For a software engineer, for instance, this might mean conveying the technical and organizational factors that went into a decision. Literate decision-making is an essential part of developing ownership and autonomy in effective teams.

The goal of these communication frameworks is to help make and convey literate decisions.

Information architecture: don't bury the lede; lead with your proposals

💡

Rather than building extensive context before presenting recommendations, start with the proposal supported by essential context.

The way I used to lay out information in documents was to provide all of the background, options, alternatives, etc before laying out the proposal towards the latter end of a document. My rationale was I was creating a breadcrumb trail of sound logic and context so that by the time a reader got to the proposal, they would know exactly why I was making it.

But it turns out that it's more effective to start with the proposal accompanied by just enough context. The reader can them dive into the other details if they want or need to. The more removed a stakeholder is from the details of a project, the more effective this approach becomes.

This relates to the concept of Cognitive Ease as discussed in Thinking, Fast and Slow by Daniel Kahneman. His findings are that good information architecture doesn't just make your argument easier to understand, it makes your argument more appealing. Likewise bad organization reduces ease and therefore makes people more critical regardless of the merits of the argument.

Capture decisions made over time

💡

Document and seek explicit acknowledgment of decisions that affect project scope, estimates, or resource requirements. This practice prevents misalignment and provides clear reference points for future discussions.

Have you ever been in a meeting where a discussion, for example between an engineer, a product manager, and a product designer, results in a decision being made that may seem subtle but may have significant implications for the scope, estimates, or resources needed for a project? And that might be OK if everyone is on the same page about the outcomes of that discussion (and remembers it). Experience has taught me not to leave the retention of and agreement on discussions like that up to chance.

Explicitly capture decisions being made

Document decisions in either shared meeting notes or technical documentation
Practice: capture your interpretation of what was conveyed → check your understanding with participants → highlight trade-offs / implications that warrant consideration → run with the outcomes.

Call out the implications for implementation and for end user experience

If the decisions are happening synchronously, this step may not be able to happen in real time. But I’ll try to convey what I understand of the implications of the decision or set the expectation that a bit of time may be needed to think through them. Note that the goal here isn’t to challenge or veto decisions, but to make sure that whatever tradeoffs are happening are informed and intentionally or at least understood.
I might use “user story” format to convey information here. For example

As a user who does {action} while {condition} is true

Before change: I will get {result/behavior X}
After change: I will get {result/behavior Y}

Tables are a useful format for informed decision-making when there are many variables at play. It’s a bit simplified, but as an example

	User Action	Condition	Outcome	Notes
Before	User clicks X	False	Sees message 1
Before	User clicks X	True	Sees message 2
After	User clicks X	False	Sees message 1
After	User clicks X	True	Sees message 3, presented with options A and B	E.g. Requires localization, adds a week to release schedule

See the On effectiveness: notes on principles and practices for shipping projects from a technical leader - Don’t just tell, show section for more thoughts on presenting information effectively

Don’t just tell, show

Use screenshots or recordings

This one may be obvious but impactful enough that it warrants mentioning: visual aides can be more effective at clearing up misunderstandings than written descriptions alone. Especially when conveying unintuitive/erroneous behaviors.

I recall one instance in particular where I explaining how a system might behave in wonky ways under a specific set of circumstances. Based on the verbal explanation that I provided, that behavior may be deemed acceptable/not a big deal. However, later on during internal testing, that same behavior was reported as a critical bug. This goes back to doing right (pushing for making the right trade-offs) vs being right ( saying, “I told you so” after the fact).

The earlier the feedback, the cheaper it is to act on

For software engineers, creating draft code reviews is a great example. They’re a great tool for gathering early feedback on how you are approaching a problem. Offering peers something tangible to provide input on, pulls discussions out of the realm of the abstract into the realm of the concrete.

Manage up

The term “managing up” often has a negative connotation. However, my take is this:

💡

Managing up is anticipating the needs of relevant decision makers.

Think of it this way, if you are trying to accomplish something that requires input or sign of from others, it saves you time, energy, and potentially frustration to effectively provide input into the process. That allows you to steer the outcomes to the extent possible, get a decision, and get back to business. In other words,

💡

Managing up is about getting the outcomes that you need by providing the inputs that decision makers need.

The methods discussed in On effectiveness: notes on principles and practices for shipping projects from a technical leader - Communication frameworks can be used to accomplish the quintessential upwards management task of providing relevant context.

Conclusion

The approaches outlined in this post represent learnings on making better decisions and communicating them effectively, i.e. doing the right thing well. Fundamentally:

Creating clarity invites correctness: Clarity in communication and decision-making can have just as much impact on project success as technical competence. In practice, this means making trade-offs explicit, documenting decisions clearly, and ensuring shared understanding amongst all involved. Developing mental frameworks encourages making those decisions in systematic ways
Seeking early insights helps define correctness: Whether by limiting scope to prioritize learning, making decisions quickly by identifying when they are reversible, or posting draft code reviews, getting feedback early helps teams avoid costly late-stage discoveries and enables more effective course corrections.

"Do you really wanna win or just look good losing?" A masterful implementation of the wrong solution does no one any good. Being effective means choosing to do the right thing even when it’s inconvenient or harder than it should be. It requires pairing competence with human understanding to produce meaningful results. It means working through ambiguity to produce paths forward for yourself and your team.