Levell - Skills frameworks and performance reviews for eng teams
by•
Levell replaces your competency spreadsheets with a structured tool for engineering managers. Build skills frameworks, run cycle reviews, share self-assessments, and turn ratings into growth plans — all in one place your team actually trusts.
Replies
Hey Folks!
I built Levell because every engineering team I've seen does performance reviews the same broken way: a shared doc with role levels nobody reads, a spreadsheet that's out of date by the time reviews start, and a Notion template that lived for one cycle before being abandoned.
The actual problem isn't that managers don't care — it's that the tooling is so painful that the whole thing collapses to gut feel.
Levell is an attempt to fix that loop:
You define a competency framework — your skills matrix, your career levels, what "learning" vs "mastering" actually looks like at L3 vs L5
You run an evaluation cycle — manager ratings, plus a shareable self-assessment link you send directly to the engineer
You look at the data — radar charts, cycle-over-cycle diffs, team heatmaps, who's ready to promote, where the skill gaps are
That's the whole thing, a simple tool built by a tenured manager, for managers.
It's in early access and completely free right now — I'm still figuring out what people actually need before I start charging. If you try it and something is weird or missing, I genuinely want to know. Drop a comment or email me directly at support@levell.fyi.
Congrats Levell team! Wanna ask something.... since the server allows IDEs to write directly to the workspace, how do you manage role-based access control at the LLM layer? And how does the system prevent a developer's AI agent from accidentally altering historical evaluation data or overwriting calibrated manager ratings during a live cycle?
@taimur_haider1
Thanks! and thanks for your question!
Here's how it actually works under the hood:
When a workspace admin creates an API key, they pick read or read_write. A read -scoped key can only call GET endpoints — the MCP server will return a 403 on any mutation tool. So the easiest mitigation is: give your IDE agent a read-only key.
Submitted assessments are immutable by design: once submit_assessment is called, the API rejects any further rating mutations on that assessment at the database layer. It's not just a soft check — `rate_competency` and `bulk_rate_competencies` will error out on a submitted record. Historical calibrated cycles are safe regardless of what the agent tries to do.
What the agent can write: on a read_write key, the agent can create new draft assessments, rate competencies in those drafts, and submit them. It can't edit or delete existing submitted assessments or overwrite historical ratings.
What I'll admit isn't there yet: there's no per-user LLM-layer RBAC (e.g., "this agent can only touch assessments for employees in team X"). The key is workspace-scoped, not user-scoped. That's a real limitation for larger orgs and something on the roadmap as the product matures.
For now the pragmatic answer is: use a read key for exploratory/reporting agents, and treat read_write keys the same way you'd treat a service account — created intentionally, named, and revocable from settings at any time.
@alxpolanc Appreciate the transparent breakdown. I got it. And a massive good luck with the launch today!