leadership
Notes on leading engineering teams: autonomy, ownership, accountability, and enabling others to make good decisions.
9 articles
Technical Leadership: A Task Has an Assignee. The Commitment Belongs to the Team.
leadership
Ammar Najjar · October 31, 2026 · 4 min readTL;DR When time-sensitive work stops moving, someone other than the unavailable assignee must explicitly own the decision about what happens next.
I recently saw two pieces of work sit untouched for almost two weeks even though both had clear deadlines.
Read more →Technical Leadership: Treat Late Constraints as a Test of the Decision
leadershipAmmar Najjar · October 24, 2026 · 4 min readTL;DR Check a late constraint against the reasons for the preferred option. Revisit the affected criteria and keep the rest of the reasoning available.
I was recently involved in a planning decision with two reasonable options. We had compared practical constraints, looked at who could participate, weighed cost and logistics, and gradually developed a preference. The choice was not final, but the discussion had enough momentum that it started to feel settled.
Read more →Technical Leadership: An Invitation Only Creates Ownership When Declining Is a Real Option
leadershipAmmar Najjar · October 19, 2026 · 4 min readTL;DR A leader's invitation carries weight that can turn an opportunity into compliance. Say plainly whether it is required or optional, then let a decline stand.
By the time this happened I had started opening some of our recurring technical discussions to people who would otherwise only receive the outcome. The reason is the one I wrote about in Ownership Starts Before the Decision: I wanted colleagues to build that context directly rather than always receiving it through me.
Read more →Technical Leadership: Ownership Starts Before the Decision
leadershipAmmar Najjar · October 14, 2026 · 4 min readTL;DR Invite colleagues who may face similar decisions to see the reasoning while it develops. Keep summaries available and treat greater independence as an aim to work toward.
For a while, I treated information flow mainly as a communication problem. When something important happened in an architecture, operations, or cross-team discussion, I tried to make sure the relevant people heard about it afterward. I summarized decisions, shared links, and added notes where they could be found later. That helped with transparency, but I started to notice a limitation in this approach.
Read more →Technical Leadership: A Good Impact Story Still Needs a Measurable Direction
leadershipAmmar Najjar · October 9, 2026 · 3 min readTL;DR Separate local value from expected movement. Ask what should change in the outcome you care about, and proceed with open eyes when the answer is learning or risk reduction.
Before one planning discussion, I noticed that part of the data we needed was missing. We already had a broader business goal, but the dashboard did not make it easy to see how much our own product was contributing to it. Before the discussion, I worked with a colleague to add a per-channel breakdown that made our product's share visible. Once that view existed, we could look at the current state directly and ask how each planned initiative was expected to move it.
Read more →Technical Leadership: Turn Disagreement into a Testable Decision
leadershipAmmar Najjar · October 1, 2026 · 5 min readTL;DR Replace longer debate with a small spike: agree on the criteria first, review the evidence together, then decide.
I recently found myself in an engineering discussion that kept circling around the same disagreement. We were considering two ways of structuring part of a frontend application, and both had reasonable arguments behind them. One approach promised a cleaner separation and more consistent structure. The concern from the other side was that we would pay for that structure with additional indirection and make future changes harder to follow.
Read more →Technical Leadership: Separate the Practice from the Problem
leadershipAmmar Najjar · September 28, 2026 · 3 min readTL;DR Name the problem, the outcome, and the constraints first. Then the proposed practice becomes one option among several, and the team can keep the problem even if it rejects the solution.
In one team conversation, we were discussing whether to introduce test-driven development. The discussion could easily have turned into the usual exchange of opinions about TDD, its benefits, its overhead, and whether it fits the way the team works.
Read more →Technical Leadership: Stop Acting as the Proxy
leadershipAmmar Najjar · September 24, 2026 · 4 min readTL;DR Help clarify the problem, then step out: connect the decision-maker with the affected person instead of carrying the decision back and forth.
A situation I have encountered is this: someone brings me a request that needs an exception, and that exception can only be granted by whoever owns the decision. My first impulse used to be to carry it forward myself: explain the context, bring the answer back, and handle the follow-up questions in between. What has worked better is helping sharpen the request and then connecting the person directly with them, so the reasoning behind the answer arrives firsthand instead of through my retelling.
Read more →Technical Leadership: Give Autonomy a Time Boundary
leadershipAmmar Najjar · September 17, 2026 · 3 min readTL;DR Autonomy works when the team owns the approach and the leader makes the outcome, the fixed constraints, and the review point explicit.
In a discussion about an operational problem, the team had several reasonable ways to handle it. I had a preferred approach, but the group wanted to try something different. My first instinct was to keep the discussion open and let them work through it. I wanted to give them room to decide, but an important question remained unanswered: when would we know whether their approach was working well enough?
Read more →