Krylox Applied: How a Side Project's System Became a Company's Core Career Ladder

Every career ladder starts somewhere. Most are born in HR meetings, drafted by committees, and polished into generic matrices that fit nobody perfectly. But a few begin differently — as a side project, a personal experiment, a system someone built to solve their own confusion about growth. This is the story of one such system, and how it became the core career ladder for a growing company.

We call it the Krylox pattern: a purposeful daily system that starts small, proves its value in a constrained context, and then scales — sometimes awkwardly, sometimes beautifully — into an organizational standard. In this guide, we'll walk through the original side project, the decisions that made it work, the adaptations required for company-wide adoption, and the hard lessons learned along the way. If you've ever wondered whether your own side project could become something bigger, this is the playbook.

Why This Topic Matters Now

Career ladders are broken in most organizations. They're either too vague to guide real decisions, or so rigid that they stifle growth. A 2023 survey by a major HR platform found that nearly 60% of employees felt their company's promotion criteria were unclear. Meanwhile, startups and scale-ups are desperate for lightweight, transparent systems that don't require a full HR department to maintain.

The story we're about to share isn't hypothetical. It's a composite of several real-world cases where a side project — a simple spreadsheet or Notion page — became the foundation for a company's entire career framework. The pattern is replicable, but only if you understand the mechanics and the pitfalls.

The Stakes for Teams and Individuals

For teams, a poorly designed career ladder leads to retention problems, perceived unfairness, and a culture of politics over performance. For individuals, the lack of a clear path means they either stagnate or leave. The side-project-to-company-ladder pattern offers a third way: a system built by practitioners, tested in the trenches, and iterated based on real feedback.

This matters now because remote and hybrid work has made career progression even more opaque. Without hallway conversations and visible mentorship, employees need explicit, written frameworks. A side-project ladder, born from the need for clarity, can fill that gap better than a top-down HR initiative.

Core Idea in Plain Language

At its heart, the system is deceptively simple: a career ladder that defines levels not by tenure or title, but by the scope of impact and the degree of autonomy. The original side project was a single-page document — a grid with four levels and three dimensions: technical skill, project ownership, and mentorship. Each level had concrete, observable behaviors rather than abstract competencies.

The Three Dimensions

The creator, a senior engineer working on a two-person side project, found that existing ladders focused too much on technical output. They added 'project ownership' to capture who drives the work from idea to delivery, and 'mentorship' to reflect how knowledge spreads. This triad became the backbone.

For example, at Level 1, technical skill meant 'can complete well-defined tasks with guidance,' project ownership meant 'takes responsibility for their own tickets,' and mentorship meant 'asks good questions.' At Level 4, technical skill meant 'designs new architectures,' project ownership meant 'defines the roadmap for a multi-quarter initiative,' and mentorship meant 'develops other senior engineers.'

Why It Worked as a Side Project

The system worked because it was built for a specific context: a small team with a clear mission. The creator could test each level against real people and real work. When someone was promoted, the rationale was transparent. When a level didn't fit, it was changed the same week. This tight feedback loop is nearly impossible in a large organization, but it's exactly what made the system trustworthy.

The side project also avoided the common trap of trying to be comprehensive. It covered only the roles that existed (backend engineers) and ignored edge cases (managers, designers, data scientists). That narrow focus allowed the ladder to be sharp and actionable.

How It Works Under the Hood

The system's mechanics are best understood as a set of decisions encoded in a lightweight format. The original was a Markdown file in a GitHub repo, with each level as a heading and each dimension as a bullet list. The company that later adopted it turned it into a web page with interactive checkboxes, but the logic stayed the same.

The Level Definition Process

Each level is defined by three to five 'must-have' behaviors per dimension. These are not vague statements like 'demonstrates leadership' but specific, observable actions: 'leads a postmortem for incidents they did not cause' or 'reviews at least 80% of pull requests from junior team members.' The behaviors are cumulative — to be at Level 3, you must meet all Level 2 behaviors plus the new ones.

The Calibration Mechanism

Promotions aren't decided by a manager alone. The system includes a calibration step: a small panel of peers and senior engineers reviews the evidence. The candidate submits a written self-assessment with examples mapped to each behavior. The panel then votes, and if there's disagreement, they discuss until they reach consensus. This prevents manager bias and ensures the ladder is applied consistently.

The Adaptation for Company Scale

When the company grew from 2 to 300 people, the side project had to change. The first adaptation was adding a 'scope' dimension for cross-team impact. The second was creating separate tracks for managers and individual contributors. The third was formalizing the calibration process with a dedicated tool (a simple app) to track evidence and votes. But the core triad — technical skill, ownership, mentorship — remained untouched.

What made the adaptation successful was that the original creator was still involved. They acted as the 'ladder steward,' reviewing every proposed change and ensuring the system's philosophy wasn't diluted. That role became crucial as the company hired more people who hadn't lived through the side project era.

Worked Example or Walkthrough

Let's walk through a concrete example: a mid-level engineer named Alex who wants to be promoted from Level 2 to Level 3. Alex works on the payments team and has been at the company for 18 months.

Step 1: Self-Assessment

Alex opens the ladder document and reads the Level 3 behaviors. For technical skill, one behavior is 'independently designs and implements a feature that touches multiple services.' Alex recently built a fraud detection module that required changes in three microservices. They write a short paragraph describing the design decisions, the challenges, and the outcome.

For project ownership, the behavior is 'defines the scope and timeline for a medium-sized project and delivers it with minimal oversight.' Alex led the fraud module from kickoff to deployment, coordinating with the data team and the frontend team. They document the timeline and how they handled a scope creep when a new requirement emerged.

For mentorship, the behavior is 'regularly reviews code from two or more junior engineers and provides constructive feedback that they act on.' Alex has been reviewing PRs for a new hire and a junior on another team. They include a specific example of a feedback session that helped the junior avoid a common bug.

Step 2: Evidence Review

Alex submits the self-assessment to the calibration panel — three senior engineers from different teams, plus the ladder steward. Each panel member reads the document and scores each behavior as 'meets,' 'almost meets,' or 'does not meet.' They also add comments. For the fraud module, one panel member asks whether Alex had to escalate for help, which would indicate less independence. Alex responds in a follow-up meeting, clarifying that they only escalated for a security review, which is standard.

Step 3: Calibration Meeting

The panel meets for 30 minutes. Two members initially rate Alex as 'meets' on all behaviors, but the third thinks the mentorship behavior is weak because Alex only reviewed code for two juniors, not consistently over time. After discussion, they agree to promote Alex but with a note to continue developing mentorship breadth. The ladder steward documents the decision and the rationale.

Step 4: Outcome

Alex is promoted to Level 3 with a raise and a new title. The self-assessment and panel notes are saved as part of the permanent record. Alex now knows exactly what Level 4 requires, and the team has a transparent, repeatable process. The whole cycle took three weeks from submission to announcement.

Edge Cases and Exceptions

No system survives contact with reality unscathed. The side-project ladder encountered several edge cases that forced adaptations.

The High-Performer Who Hates Mentoring

One engineer, call them Priya, was technically brilliant — she could design systems that handled millions of requests per second. But she had no interest in mentoring. The ladder's mentorship dimension blocked her from Level 4. The solution was not to lower the bar but to create a parallel 'senior individual contributor' track that emphasized technical depth over mentorship. This was a compromise: it added complexity but retained the ladder's integrity for others.

The Manager Transition

When the company hired its first engineering manager, the ladder didn't fit. Managers needed skills in hiring, performance management, and strategic planning — none of which were in the original triad. The company added a separate manager ladder with its own dimensions (team health, delivery, people development) but kept the same level structure (1–4) to maintain parity.

The Cross-Functional Project

Another edge case: an engineer who led a project that touched design, product, and data science. The ladder's ownership dimension assumed technical ownership, but this engineer's impact was organizational. The panel had to interpret 'project ownership' broadly, and the ladder steward later added a note that cross-functional leadership could substitute for technical ownership if the impact was equivalent.

The Remote Worker

Remote work made the mentorship dimension harder to assess. In the office, mentoring happened naturally over lunch or whiteboard sessions. Remote, it had to be deliberate. The ladder was updated to require documented mentoring activities (e.g., scheduled pair programming sessions, written feedback) rather than informal observations.

Limits of the Approach

The side-project-to-company-ladder pattern is powerful, but it has real limits. First, it relies heavily on the original creator's judgment. Without a ladder steward who deeply understands the system's philosophy, it can drift into a checklist exercise. The steward role is not scalable — one person cannot review every promotion in a 500-person company.

Second, the system works best for engineering and other craft roles where output is relatively observable. For roles like product management or design, where impact is harder to attribute, the ladder becomes subjective. The company tried to adapt the same triad to design, but it required significant redefinition of 'technical skill' (replaced with 'craft skill') and 'ownership' (replaced with 'product impact'). The result was a ladder that felt forced.

Third, the calibration process is time-consuming. Each promotion requires three to five senior people to spend an hour reading and discussing. As the company grew, the volume of promotions threatened to overwhelm the panel. The company had to institute quarterly promotion cycles and limit the number of candidates per cycle.

Fourth, the ladder can create a false sense of objectivity. The behaviors are concrete, but their interpretation still varies. Two panel members might disagree on whether a feature was 'independently designed.' The system reduces bias but doesn't eliminate it. The company learned to embrace discussion and disagreement as a feature, not a bug.

Finally, the system is not a substitute for good management. A career ladder is a tool, not a solution. If managers aren't having regular growth conversations, the ladder becomes a bureaucratic hurdle. The company had to invest in manager training to ensure the ladder was used as a guide, not a weapon.

Despite these limits, the side-project ladder remains the company's core career system. It's been in use for over five years, through three rounds of funding and a pandemic. It's been forked by other teams and even other companies. The lesson is not that every side project should become a company standard, but that a well-designed system, built with purpose and humility, can scale further than anyone expects.

If you're thinking about building your own career ladder, start small. Define a single level for your team. Test it with one promotion. Iterate. And when it outgrows you, find a steward to carry it forward.