Skip to content
Kumar Chandrachooda
Engineering Practice

Leading Without the Title

Leadership weighs 15 in my competency framework and not one point of it requires authority - decision making, alignment, mentoring, process thinking and facilitation as evidenced skills, plus the two quiet disciplines that complete the model.

By Kumar Chandrachooda 04 Apr 2026 7 min read
Arrows falling into line behind a point that wears no crown

Every team I have worked on had two organisational charts. The official one lived in the HR system and said who reported to whom. The real one was invisible and said whose judgement people actually sought before committing to anything. In part 4 I covered Feedback and Collaboration — the disciplines that keep a team functioning hour to hour. This part covers the three disciplines that draw the second chart: Leadership, and the two quieter disciplines that share the page because they answer the same question from different angles — Self Organisation and Business Acumen & Strategy. Between them they carry 32 of the framework's 100 points, and not one of those points asks what your job title is.

Leadership is a skill set, not a seat

I weighted Leadership at 15 — third highest in the framework, behind Engineering Craft's 25 and Delivery's 18 — and the placement is the argument. Leadership, as this framework defines it, is not about title or authority. It is a bundle of five assessable skills: making good decisions, aligning people toward common goals, developing others, improving how work gets done, and enabling productive group discussions. Every engineer exercises these skills, usually without noticing. What distinguishes senior engineers is doing it deliberately, consistently, and at increasing scale.

The weight of 15 encodes a career observation I have watched play out repeatedly: leadership is the primary lever for progression beyond mid-level. The gap between a strong senior engineer and a staff engineer is rarely technical depth — both can build. The gap is whether their decisions affect only their own work or the whole team's, whether alignment happens because they built it or despite them, and how many other engineers are better because they were around. Leadership is where individual contribution turns into multiplied contribution, and a competency model that under-weights it quietly tells its best engineers to stay individual.

Sub-discipline Weight The skill in one line
Decision Making 25 Deciding well with incomplete information, under time pressure, with real consequences — and owning the outcome.
Driving Alignment 20 Getting people moving in the same direction without borrowing anyone's authority.
Mentoring 20 Developing other engineers through guidance, feedback and example.
Process Thinking 20 Reasoning systematically about how work gets done and improving it — the right process for the context, not more process.
Facilitation 15 Structuring discussions so a group produces its best thinking and an actual decision.

Decision making earns the biggest slice

Decision Making takes 25 of Leadership's 100 because every other leadership skill ultimately serves it. Alignment exists so that decisions stick. Mentoring exists so that more people can make good decisions. Process thinking exists so that decisions about how to work are made once, deliberately, instead of daily, accidentally. The skill itself is unglamorous: weighing trade-offs, gathering the right input without gathering forever, deciding at the right level of confidence, communicating the decision clearly, and standing behind it when it turns out to be wrong.

The three twenty-point skills are three distinct mechanisms of leverage. Driving Alignment is leverage over people's direction; Mentoring is leverage over people's growth; Process Thinking is leverage over the system everyone works inside. I hold Mentoring to a specific standard in assessment: the mark of a senior engineer is not what they can build but how many others they enable to build. Mentees who measurably grew are evidence; good intentions are not.

Facilitation carries a slightly lower 15 because it is more situational — but in group settings it is the skill that makes the other four land. A facilitator does not dominate a discussion; they orchestrate it: drawing out the quiet voices, keeping the thread, summarising what was actually decided. Watch a design review run by a good facilitator and a bad one and you will see the same five engineers produce entirely different outcomes.

Self Organisation, the discipline nobody notices until it is missing

Self Organisation weighs 10, and the low number is a deliberate statement about where growth investment pays off. This is the discipline of personal effectiveness — the habits and professional conduct that make an engineer someone the team can depend on. It is an enabler, not a differentiator. An engineer who is unreliable or unaccountable creates drag on everyone around them, so the baseline is non-negotiable; but past a solid baseline, further investment here yields diminishing returns compared with the same effort spent on Delivery, Leadership or craft. The weight is calibrated to exactly that shape: essential to get right, not where the leverage lives.

Two of its three sub-disciplines are weighted identically at 35 because they are two sides of one coin. Reliability is the consistency of doing what you said you would do, when you said you would do it — being the person nobody has to chase. Delivery Accountability is ownership of the outcome rather than the task: following through past “I finished my part” to whether the thing actually worked, and raising problems early instead of letting them compound. Trust is built on the pair, not on either alone; I have known engineers who never missed a deadline and never once asked whether what they shipped achieved anything.

Economic Thinking takes the remaining 30, and it is the sub-discipline I most wish appeared in more frameworks. Every hour spent on one thing is an hour not spent on another. Evaluating build-versus-buy honestly, resisting over-engineering, treating team capacity as a finite resource, choosing what not to do — these are engineering decisions in the fullest sense, and engineers who cannot make them export the cost to whoever plans around them.

Seven points for the business, on purpose

Business Acumen & Strategy carries 7 — the lowest weight in the framework — and I want to defend the number, because a low weight is not a dismissal. This is the discipline of understanding the commercial context software lives in: how the product creates value, what the revenue model rewards, which technical investments the business will actually feel. Its three sub-disciplines split the ground evenly: Product Thinking (35) for understanding user and product value, Business Acumen (35) for the commercial mechanics, Strategic Work (30) for connecting engineering investment to long-term advantage.

The reason for 7 is that business acumen behaves as a meta-skill. It rarely produces value alone; it amplifies everything else. An engineer with product sense makes sharper prioritisation calls — that value lands in Delivery. One who understands the business asks better questions of stakeholders — that lands in Feedback. One who sees where the company is heading designs architecture that survives the journey — that lands in Engineering Craft. Deep commercial expertise is properly the domain of product management and engineering leadership; for most engineering roles, a solid working understanding is the right target, and the framework prices it accordingly.

There is an honest asterisk on the number, recorded in the framework itself: the weight should rise significantly for staff-plus engineers and tech leads, where connecting technical decisions to business outcomes stops being an amplifier and becomes the job. The default weights describe a balanced engineering role; your role may not be balanced the same way, and the model expects you to adjust it rather than worship it.

The invisible chart, made visible

So why model leadership — and its two companions — independently of job title at all? Because coupling them to the title breaks the model in both directions. Engineers without the title wait for permission: if leadership is something you get promoted into, then mentoring, alignment and process improvement are someone else's job until the day they abruptly become yours. And engineers with the title coast unmeasured: a lead whose leadership is assumed rather than evidenced can go years without anyone checking whether their decisions hold up, their meetings decide anything, or their mentees grow.

The weighted, evidence-based framing fixes both. A mid-level engineer who consistently facilitates retrospectives that end in acted-on changes has Leadership evidence, title or not. A tech lead who cannot point to a mentee's growth or a decision they made and owned has a gap, title or not. That is the same person showing as Level 4 in Leadership and Level 2 in Business Acumen, or the reverse — profiles the next part makes precise. The framework measures leadership as behaviour with evidence attached, which means nobody needs permission to start and nobody gets credit for the chair they sit in.

The real organisational chart — the one showing whose judgement people seek — was always a competency map. This discipline trio just writes it down.

Next, the ladder every one of these disciplines is measured on: five levels and observable evidence, and the tables that keep the ratings honest.