Guides
How software engineers use skill graphs to plan promotions, identify gaps, and navigate career transitions.
Software engineers are the original power users of skill graphs — and for good reason. Engineering careers are uniquely structured around measurable, stackable capabilities. You can point to a pull request, a system design document, or a production deployment and say: "this proves I can do X."
A skill graph formalises what experienced engineers do intuitively: track their stack, identify blind spots, and plan their next level. The difference is precision. Instead of a vague sense that "I should learn more about distributed systems," a graph tells you exactly which sub-skills you have, which are missing, and what evidence you would need to prove depth.
Most engineering ladders define levels with broad criteria:
These descriptions are too vague to be actionable. What does "designs components" actually require? A skill graph breaks it down: system design (proficient), API design (proficient), database modelling (working), trade-off documentation (working), stakeholder communication (working).
Now you know what to work on.
Structure your graph around the domains that define your engineering discipline. Here are common structures by specialisation:
Backend Engineer:
Frontend Engineer:
ML/Data Engineer:
Engineers have the best evidence sources of any profession:
| Evidence Type | What It Proves | Where to Find It |
|---|---|---|
| Pull requests | Code quality, problem-solving approach, collaboration | GitHub, GitLab, internal repos |
| Design documents | System thinking, trade-off analysis, communication | Internal wikis, Google Docs, Notion |
| Incident post-mortems | Debugging skill, systems understanding, crisis management | On-call records, incident databases |
| Production metrics | Impact, reliability awareness | Dashboards, monitoring tools |
| Code reviews given | Teaching ability, quality standards | PR review history |
| Open source contributions | Self-direction, community engagement |
The most common mistake engineers make is over-rating familiar skills. "I use Python every day" does not mean expert. Ask yourself:
If all three are yes, you are expert. If only the first, you are proficient. If you mostly write Python with guidance or by following existing patterns, you are working level.
The transition from mid to senior is primarily about scope and independence:
| Common Gap | Why It Blocks Promotion |
|---|---|
| System design | Cannot own a component end-to-end without senior oversight |
| Technical writing | Cannot document decisions for async review |
| Cross-team communication | Cannot coordinate with adjacent teams independently |
| Testing strategy | Writes tests but cannot design a test strategy for a new system |
| Estimation and planning | Cannot reliably scope work for sprint planning |
The transition from senior to staff is about influence and technical leverage:
| Common Gap | Why It Blocks Promotion |
|---|---|
| Architecture documentation | Cannot produce RFCs that drive alignment across teams |
| Technical vision | Cannot articulate a 6–12 month technical direction |
| Mentoring | Has domain expertise but cannot transfer it effectively |
| Build-vs-buy analysis | Cannot evaluate and recommend third-party solutions |
| Stakeholder management | Cannot translate technical constraints into business terms |
This transition is about organisational impact:
| Common Gap | Why It Blocks Promotion |
|---|---|
| Cross-org influence | Expertise is localised to one team |
| Industry awareness | Deep in internal systems but disconnected from industry trends |
| Executive communication | Cannot present technical strategy to non-technical leadership |
Overlay your graph against your company's level expectations. If you have 80%+ coverage at the next level, you are ready to have the promotion conversation — and your graph is the evidence package.
Before applying, overlay 3–5 job descriptions onto your graph. If most of your skills match, it is a lateral move. If there are significant gaps, it is a stretch — and you can prepare for interview questions about those gaps.
If you are considering a transition (IC → manager, backend → ML, startup → big tech), a skill graph shows you exactly which skills transfer and which are new. This makes the transition less daunting and more plannable.
Use the Skill Graph generator to extract your skills from your CV or LinkedIn. The AI identifies technical and professional skills, assigns initial levels, and creates your first graph in under 3 minutes.
A GitHub profile shows activity and contributions. A skill graph shows capability structure — what you know, how well, and how skills relate. A busy GitHub profile with many small contributions does not show whether you can design a system. A skill graph does.
If they develop independently, track them separately (e.g. "Python" and "Go"). If a tool is inseparable from its ecosystem, combine them (e.g. "Kubernetes" rather than splitting into kubectl, Helm, and CRDs).
Update your graph monthly. Over time, the history of level changes tells a growth story. "Moved from exposure to proficient in system design over 8 months with evidence from 3 design documents" is a powerful narrative for promotion discussions.
| GitHub profile |