For example, in the verification step of my /setup skill, I wanted the AI to double-check it had properly filled in all <placeholders> when processing a template. Initially I had this:

SKILL_DIR=[skill base directory]
grep -ohE '<[^>]{1,80}>' ${SKILL_DIR}/assets/README-template.md | sort -u
# -> <how to use the project> <medium description> <Name> <other sections>
#    <pointers at docs/> <project> <short description>
And then assert each of those is absent from the actual README.md.

These instructions started out as codifying how the AI had been instructing itself to do the verification, taking into account that the template can change and that there’s multiple templates. But having the AI invoke bash to run grep to then process a list of placeholder tokens further is slowing things down for no good reason.

While the skill its templates do change, they do not change often, and when they do, they go into GitHub and through CI/CD tooling. So the grep commands can be run once, without AI involved, and the results can be inlined into the skill file. The result becomes:

assets/CODE_OF_CONDUCT-template.md
  ...
assets/README-template.md
  <how to use the project>
  <medium description>
  <Name>
  <other sections>
...

A lot of the words for the initial skill and also for this update rewrite was done by AI. It also wrote the script that keeps the list updated, and suggested this specific improvement in the first place.

You can tell this is AI-written, I think. Besides the em-dash, another clear tell is the sentence “if the list is empty, this skill is broken: stop and report it rather than reading no tokens as no placeholders”. Opus 5 is often too careful when it is trying to instruct other AI; I think the CI setup is good and so I don’t think it is likely I will mess this up.

In software development we learned “premature optimization is the root of all evil” and then “There are only two hard things in Computer Science: cache invalidation and naming things“, with caching being one kind of optimization. So we developed a sense of taste to avoid caching until really needed.

But now with agentic coding, I find myself reaching for such caches and other optimizations sooner, to limit AI cost but especially to limit AI latency. I feel that, when I keep my agent skills fast, I reach for them more, my AI stays on the rails better, I experience less in-session frustration, and then I can spend my cognitive energy on judging the things that matter, like whether it is properly accomplishing the thing I want it to do.

(You can probably also tell that like this post, last sentence is not written by AI. Too long, too many commas, ambiguous grammar. I’m leaving it in.)

Example improvements made with /setup

Here are some pull requests from running /setup along with some of the improvements the agent decided to make:

• Python project: pinning uv dependencies, adding actionlint;
• Rust project: pinning cargo dependencies, adding cargo-deny;
• Docs project: running linting in CI, adding starlight-links-validator.

How it works

The skill is written for opus-class agents, giving high-level instructions that exercise the model’s ability to think and reason. Specific templates ground the model so it knows what good looks like, and it verifies its own work in a fresh context. A sonnet-class model can use the skill but in testing made less comprehensive improvements.

The skill works for greenfield and for brownfield repos. It will initialize new projects based on template projects, while for existing projects it will add what’s missing. The skill is not fully autonomous. It explores first and then asks the user questions in a short batch, but it will ask for more user input and decisions if needed.

This skill works on a large variety of projects. I’ve tested Python / TypeScript / Go / Rust / Monorepo / Markdown and have templates for each of those. It works well for small hobby projects and scales to at least a medium size (~250k LoC) repo.

YMMV

This is an opinionated skill, based on 25 years of setting up software projects and doing large-scale platform engineering to set up many parallel projects. While flexible and context-aware, my preferences and my judgment are encoded in it, so if you disagree with me about what a good project setup really is, you need to swap out the templates.

TIL: phases

It’s good to divide agent skill documents into phases for the agent:

• exploration and fact-finding
• plan to do the work
• ask the user to fill in gaps, assumptions, and make decisions
• complete the plan based on those answers
• execute the plan to do the actual work
• verify the work done achieved the goal (with fresh context)
• fix the work that failed verification
• re-verify the fixes

This plan/do/check/act pattern is very similar to an AI-assisted spec-driven TDD loop (spec → tests → code → refactor), with some additional ergonomics to make working with the skill easier for humans.

Rewriting the skill to this structure made the changes it proposed more cohesive and more comprehensive.

Installing

Using skills.sh:

npx skills add lsimons/lsimons-skills

/setup tries to use /complete, so also install that.

Or you can manually copy the setup directory and the complete directory into the skills folder of your agent.

All words in this post were written by me, not by AI, but AI did help review early post drafts and it helped write the skill (Anthropic Claude Opus).

Domain-driven design works best when the people who know the domain can check the model. Most modelling notations get in the way of that.

Fact-based modelling helps. Instead of starting from tables or classes, you describe the domain as short sentences that a domain expert can confirm or reject. This post walks through that way of working, then translates the result into LinkML, a schema language with good code generation.

Think in facts

The best-known fact-based method is Object-Role Modeling (ORM). Its core idea: a domain is a set of facts, and every fact can be read out as a sentence.

Each Team has at least one lead, who is a Person.

A product manager can read that sentence. A DBA can read it. The person who runs the team can read it and tell you it’s wrong. “Teams go without a lead for months during reorgs” is cheap feedback at a whiteboard and expensive feedback after you ship a NOT NULL constraint.

You find these facts by talking with domain experts, using concrete examples (“take the platform team. Who’s the lead there?”), plain language, and simple drawings. Examples do double duty: they help you discover a fact, and they test it. If the expert can’t fill in your example table, the fact is wrong.

Read Halpin & Morgan Information Modeling and Relational Databases for details.

Sketch first, formalize later

Keep formal notation off the whiteboard. Circles and lines and sticky notes are enough: a circle per kind of thing, a line per fact, the sentence written along the line, examples on stickies underneath. ORM has a precise diagram notation, and in a workshop that precision turns contributors into spectators: the expert who happily corrects a sentence will hesitate to touch a diagram symbol.

For many domains, a whiteboard photo plus the agreed sentences is the whole model, and stopping there is fine. See Caseum for more about such a lightweight approach.

From facts to schema

Sometimes you can’t stop there. You need a JSON Schema for an API, a database schema, docs that stay current. Maintaining those by hand, in parallel, is how the drift starts. Better to keep one source file and generate the rest.

ORM tooling is not in the best state. LinkML is a great alternative. It is a YAML-based schema language with generators for JSON Schema, SQL, ER diagrams, documentation sites, and typed Pydantic and TypeScript classes.

A small HR domain as fact sentences:

Each Person is identified by an id, which is a URI.
Each Person has exactly one name.
Each Person (the coachee) may have one or more coaches, each of whom is a Person.
Each Person has at most one Department.
Each Team has at least one lead, who is a Person.

The same model as LinkML (hr.yaml):

id: https://example.org/hr
name: hr
prefixes:
  linkml: https://w3id.org/linkml/
  hr: https://example.org/hr/
default_prefix: hr
default_range: string
imports:
  - linkml:types

classes:
  Person:
    attributes:
      id:
        identifier: true
        range: uri
      name:
        required: true
      coach:
        range: Person
        multivalued: true
      department:
        range: Department
  Department:
    attributes:
      id:
        identifier: true
        range: uri
  Team:
    attributes:
      lead:
        required: true
        multivalued: true
        range: Person

Each fact becomes a slot (LinkML’s word for an attribute), and the how-many wording maps directly:

Settle on a fixed set of phrases like this and turning the whiteboard into a schema stops being design work and becomes transcription, which AI can do for you.

From schema to software

Use the LinkML tools to create other files from the model. For example:

JSON Schema

Run gen-json-schema hr.yaml:

"Person": {
    "additionalProperties": false,
    "properties": {
        "coach": {
            "items": { "format": "uri", "type": "string" },
            "type": [ "array", "null" ]
        },
        "department": { "format": "uri", "type": [ "string", "null" ] },
        "id": { "format": "uri", "type": "string" },
        "name": { "type": "string" }
    },
    "required": [ "id", "name" ]
}

Mermaid ER diagram

Run gen-erdiagram hr.yaml:

erDiagram
Department {
    uri id
}
Person {
    uri id
    string name
}
Team {
}

Person ||--|o Department : "department"
Person ||--}o Person : "coach"
Team ||--}| Person : "lead"

which Mermaid renders as:

(Mermaid is supported by many Markdown tools, including on GitHub)

SQL

Run gen-sqlddl hr.yaml:

CREATE TABLE "Person" (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    department TEXT,
    PRIMARY KEY (id),
    FOREIGN KEY(department) REFERENCES "Department" (id)
);

CREATE TABLE "Person_coach" (
    "Person_id" TEXT,
    coach_id TEXT,
    PRIMARY KEY ("Person_id", coach_id),
    FOREIGN KEY("Person_id") REFERENCES "Person" (id),
    FOREIGN KEY(coach_id) REFERENCES "Person" (id)
);

Testing the schema with examples

Given ada.yaml:

id: https://example.org/people/ada
name: Ada
coach:
  - https://example.org/people/grace

and bob.yaml:

id: https://example.org/people/bob
department: engineering

Here’s what testing looks like:

$ linkml validate -s hr.yaml -C Person ada.yaml
No issues found
$ linkml validate -s hr.yaml -C Person bob.yaml
[ERROR] [bob.yaml/0] 'engineering' is not a 'uri' in /department
[ERROR] [bob.yaml/0] 'name' is a required property in /

There is more to LinkML, but the shape is clear: one schema file, kept under code review, with tool automation so that artifacts do not drift from each other.

Remember the facts

Compare the written fact

Each Person (the coachee) may have one or more coaches, each of whom is a Person.

with the LinkML model slot:

coach:
  range: Person
  multivalued: true

The sentence names both roles, coach and coachee, and reads aloud in either direction. The slot names one direction and buries the rest in structure. A domain expert can verify the sentence but not the YAML.

Keep the written facts and their examples around, right next to the schema. Your AI is excellent at English and so can help keep facts and LinkML in sync.

But I think my coding agent, with all its own settings and quirks and approach, should be distinguished from everyone else’s. I use more than just Claude Code (I also use GitHub Copilot, Gemini CLI, pi, …). I thought my coding agent better have some personality.

So I’ve set up a dedicated @lsimons-bot, put it in a VM sandbox, and instructed it to identify me as its co-author. I’ve even given the bot its own blog. Now I get pretty commits with two authors which are me and robot-me:

I’ve tuned the settings so that when I am doing tightly controlled AI-assisted development, the git commits have me as main author and @lsimons-bot as coauthor. When I’m doing vibe coding in the VM, it’s reversed. And it’s also nice to see the bot make pull requests which I then review and merge.

In Claude Code it is possible to configure its attribution settings, but not all the coding agents I use can do this just yet, so as of right now I’m instead wasting tokens on it.

Steve Yegge is back with “Welcome to Gas Town,” a novella-sized blog post about his new multi-agent coding systems, full of Mad Max references. It’s an entertaining but puzzling read. He describes a chaotic world of “polecats”, “GUPP”, and “Convoys”, covering the architecture with thick narrative lore.

To decipher what he is actually building, I fed the post and his GitHub repository into Gemini. It helped me understand Steve’s vision of a Kubernetes-like control plane for AI code agents and then helped write this blog post.

Decoding the Metaphors

Yegge’s system manages the chaos of running 20–30 concurrent AI agents in parallel in YOLO mode. Key parts:

• The Controller (“The Town”): A central Go binary that orchestrates agent lifecycles across projects.
• Git-Backed State (“Beads“): The atomic unit of work isn’t a database row; it’s a JSON file committed directly to the project’s Git history. This makes every task, status, and message persistent and version-controlled.
• The Interface: The system uses tmux as a dashboard (HUD) to manage the fleet of agents.

The Workforce

The “Gas Town” roles map to standard distributed system components:

• “Mayor” (Interface): A persistent agent acting as a Chief of Staff for the human user.
• “Polecats” (Batch Workers): Ephemeral agents spun up to execute tasks and vanish.
• “Refinery” (Merge Queue): An engineer agent that resolves merge conflicts when multiple workers submit code.
• “Witness” (Watchdog): A monitor that detects and restarts stalled agents.

Tackling complexity

More than the specific solution it’s interesting to see the underlying problems being solved for. Claude Code is polite and it stops to ask for confirmation, so, control systems are built to make it continue. Claude Code context compaction can remember the wrong things, so structured external memory is provided in specific and evolving ways. Etc.

The git repo reveals more of such complexity not fully explained in the blog, with the docs containing some of the more interesting insights of what happens when you do vibe coding at scale. For example, why identity of (sub)agents matters.

The repo’s AGENTS.md is interesting too. Agents are explicitly forbidden from asking permission to push; they must run tests, commit, push, and verify success before reporting back.

Looks like quite a serious attempt to build an industrialized coding factory, turning the developer from a coder into a manager of a synthetic manager of synthetic workers.

Looks like most of the work to make this happen is handling accidental complexity, not essential complexity. I wonder how much of that is due to building on top of Claude Code. Perhaps a future iteration integrates its own less-polite less-error-prone coding agent, something like pi?

(Yegge being co-author of the book Vibe Coding, who recently said in a talk “if you are using an IDE [in 2026], you are a bad engineer“, because you should use a coding agent)

Fast forward to today, and we’re seeing a return to that mindset based on the practical demands of AI-assisted development.

Spec-Driven Development: A Modern Twist

To keep tools like GitHub Copilot, ChatGPT Codex, and Claude Code behaving, developers are increasingly writing natural language specifications that guide code generation.

This trend, often called spec-driven development, emphasises writing structured, human-readable descriptions of what software should do — before writing any code.

These specs aren’t just throwaway prompts. They’re version-controlled, reviewed, and treated as first-class artifacts. They are what helps keep the AI on the rails.

The Parallel with Literate Programming

What’s happening here mirrors Knuth’s vision. In both cases, the developer is encouraged to think clearly and write clearly. The difference is that now, the audience isn’t just other humans — it’s also an AI model that can turn prose into functioning code.

Modern tools like Jupyter already blurred the line between documentation and implementation. This hybrid approach is now becoming a valuable way to avoid AI slop.

Why It Matters

This isn’t just a tooling shift — it’s a cultural one. We’re moving away from “vibe-based coding” and toward a more deliberate, explainable, and collaborative process. And in doing so, we’re rediscovering the value of code as a form of communication.

Co-authored with AI (Anthropic Claude Sonnet 4.5).
Normally I don’t publish content that AI helped to write, but I wanted to see how it feels.

Short video introduction:

It doesn’t work!

Disclaimer

Though I incorporated feedback from a lot of colleagues, this was never “the” SBP framework. Our company culture is as informal as it can be, with just enough structure. Making a framework such as this official is more than we need. We do not want people to think of their careers as a checklist to complete or as a ladder to climb. Instead, we suggest people mostly focus on growing their impact, picking up and mastering new competencies along the way.

Framework

The base framework is rather abstract, defining 10 coarse-grained competencies that apply to all engineering roles, such as “maintaining quality” or “planning and organizing”. The competencies have up to 7 different levels. These 10 competencies are grouped into Craftsmanship, Human, and Leadership categories.

The Progression app is organized into strict levels. To make the tool work for us, the online version of the SBP framework defines these levels too. But these are not actually used within SBP! It’s quite common to have some competencies at a very high level and others still much lower, and that’s ok with us. One common example is engineers with very highly rated craftsmanship skills but lower rated teamwork skills. The reverse also happens!

Roles

In this framework there are only three roles defined: engineers, tech leads, and technology officers.

Engineers are our individual contributors (ICs), an industry term we don’t usually use. When engineers lead others, they do so primarily by example, based on the content of their work.

Tech leads (TLs) are engineers that accept additional leadership responsibilities. Tech leads are not in charge of teams, we expect servant leadership of them.

Technology officers (TOs) are a lot like tech leads but with somewhat different leadership responsibilities. While tech lead engineers lead one specific team, our technology officers have a somewhat broader scope. They’re a bit further removed from the day-to-day engineering work, giving them time to focus on cross-team topics and to do work for which there isn’t a dedicated engineering team available, like presales.

TLs and TOs are leaders but not managers. At many companies with career ladders and levels, TLs and TOs might be considered staff or principal engineers, i.e. they are still on the “individual contributor” track. While some engineers progress by taking a TL or TO role, it’s important to realize there are engineers at a “staff” or “principal” level without a TL or TO role. Those engineers could match a different staff-plus archetype (like Solver or Architect), or just not match up with such a rigid framework at all. It’s also possible to switch from a TL or TO role to a regular engineering role.

Engineers at SBP do have additional roles at times that require additional competencies. For example, engineers can become coaches. These are not part of the framework.

Competencies

While Progression is optimized for defining pretty specific skills for pretty specific roles, this particular framework is broad and generic, and so is focused around competencies.

There are up to 7 different levels defined per competency.

While the basic competencies are the same for TLs and TOs as for engineers, our expectations of where our leaders will focus are a little different, and so for some skills there is a leadership (L) variant defined. Since Progression doesn’t support such variant definitions, there’s some overlap/copies.

Competency example: Client Orientation

SBP is an outsourcing company. Our engineers work in self-steering teams dedicated to a single customer. Because all our engineers have a lot of customer interaction, the framework is relatively heavy on communication compared to many other progression examples.

Progression for comparing roles & levels

One cool feature in Progression is how it allows you to put different roles and different levels side by side. This can help engineers think about which direction they might develop in next, though since at SBP we don’t actually use levels it’s of limited use for us.

Progression for check-ins

A recent addition to Progression is a new check-in feature that arranges a guided conversation between engineers and their managers (or in SBP its case with no line management, coaches). The idea is to agree together on career progression.

I like what they’ve built here. I imagine it’s a good way for HR departments to help beginning engineering managers have decent-quality factful conversations. But it’s not the right tool for Schuberg Philis.

It’s a great example of our “too much structure” rule kicking in. We have an internal 360-degree feedback process that is less structured than this, asking open questions instead, focusing on the important feedback conversation more and happily sacrificing some structured/detailed record-keeping in the process. Maybe when SBP is 10 times bigger that has to change?

Spreadsheet version

I created the Progression version of this framework based on my initial spreadsheet version of this career framework. I’ve found most people feel quite overwhelmed (at best) when confronted with this spreadsheet, while HR professionals appreciate the comprehensive overview.

Success!

Developing this framework helped me think through career guidance in great depth and that has helped make my advice to others clearer. I sometimes refer back to it when helping to weigh or appraise feedback, during salary discussions, or when writing job specs.

Putting the framework in Progression really helped to compare our framework to other engineering companies and to benchmark our internal levelless ranking system to common industry levels. Sometimes I can use it to explain to our younger engineers that no, they would not be ranked as principal engineers at Google, yet!

The process of iterating on the framework together was valuable. Asking and discussing feedback helped to align our leadership’s thinking about how we appraise and value our colleagues. Beyond leadership, trying to describe very different work in common terms (dev and ops, for example) helped the people involved to understand more about each other.

Our HR professionals happily adopted the framework, for example to develop and finetune our internal leadership training. For my HR colleagues relatively new to IT organizations it really helped them to see and understand both the breadth and the depth of our careers.

Failure!

This framework hasn’t helped our engineers or their coaches! My colleagues may look at it, perhaps understand it as reasonable and sensible…and then will never use it during their career planning or career development conversations.

People are unsure why, but they tell me the framework “doesn’t feel right”.

I believe one problem is that the level of abstraction is so high people don’t know how to apply it for themselves in a practical way. Making more concrete roles (like “java developer”) with more concrete skills (like “java programming”) could help, but that’s a lot of work to set up and maintain.

I believe another problem is that the setup is still too constrained: our actual appraisal system is more free-form. I imagine if we were to strictly define career levels that would then prompt more colleagues to use this framework. Especially if we linked the levels to salary ranges. And…I don’t know that would be positive. SBP tries to be a place where all our colleagues can “become who they are”, which for many colleagues can mean quite an “unbalanced” set of competencies.

The framework also hasn’t helped me! Our non-technical coaches have difficulty using the more technical competencies. You need an experienced technologist’s help to evaluate the quality of your solutions designs or implementation plans, to determine how competent you got. It sucks to have a conversation about those things with a non-technical coach.

So in the end even if my colleagues do use this framework, they will still ask for my help, and I save no time!

Fortunately, it’s the kind of conversation I love to have.

Permanent contract vs 1-year contract

Dutch employment law can get pretty complex, making the non-financial terms important when evaluating salary. One key factor is whether you’re looking at a permanent contract or not.

For more senior positions, permanent contracts are common. If you do your job well and the company is doing ok financially, your employer cannot easily fire you from a permanent contract, which makes these popular with risk-averse employees and unpopular with commitment-averse employers.

For more junior positions, 1-year contracts are common. 1-year contracts often get automatically extended, and then can convert into permanent contracts automatically after 3 years.

Getting a mortgage is harder without a permanent contract since banks are also risk-averse.

The base salaries for both contract types tend to be comparable, but permanent contracts usually have better non-base salary benefits leading to a better total benefits package.

Common benefits package components

A Dutch contract usually has a yearly salary listed for a full-time job. Usually full-time for developer jobs means 40 hours a week. If you work less hours you will be paid proportionally less, while if you structurally work more you typically do not get paid for that at all.

The base yearly salary includes 8% yearly holiday allowance, which is usually paid once a year in May. In May you receive 15.67% of your yearly salary, while in all other months you receive 7.67%.

Discretionary bonuses are now reasonably common in Dutch IT companies, paid out yearly, with 5%-20% of your yearly salary reasonably common, and 10% probably the most common percentage. Usually discretionary means that your manager informs you once a year if you get your bonus and how much you will get, i.e. your employer can decide for any reason not to pay you the bonus.

It is uncommon for Dutch employers to actually promise bonuses, or otherwise tie bonus payout to profits or performance targets in a transparent way. When that arrangement is written into your contract it is a performance bonus instead of the common discretionary bonus, which you may encounter for more commercial roles (i.e. a role as a presales engineer).

Stock options, shares, employee ownership plans, and profit sharing agreements are relatively uncommon for Dutch IT companies. Even when they are used, the “standard” approaches that exist in the US tech industry for stock options are not standard here, which means most US-centric advice on the internet about such things does not apply. The actual benefit of such programs relative to base salary can range from pretty neglible (more common) to pretty dominant (rare).

Cars in The Netherlands are expensive to own and drive, due to how taxes for them work as well as due to high taxes on gas. Lease cars are common, where your employer arranges a car for you (often of the type and with the options you choose) with a leasing company. Your employer pays for your car every month, including for any gas used. If you also use this car for non-work travel then you have to pay extra income tax based on the catalog value of the car. If you like driving a modern car this usually works out cheaper than other approaches. At some employers, lease cars are getting replaced with mobility budgets or public transport passes.

A full-time contract includes a mandatory minimum of 20 vacation days. These are a legal right; you might see them as a government-mandated benefit. Many employers include extra vacation days above 20, sometimes with various differing rules for exchanging days for cash, buying extra days, and so on. Besides vacation you also have rights to parental leave, sick days, and so on.

Paid overtime and standby shift compensation are rather uncommon for developers. If your contract does include paid overtime it is likely based on extra hours worked per week or month, which means tracking all hours. Night or weekend hours may be paid at 150% or 200%. Working a lot of overtime can mean quite significant additional income.

Most permanent contracts will include a pension, for which there are many different and confusing different setups that are hard to compare and value. It’s common these days that your employer pays some monthly amount into a fund on your behalf that is based on a combination of your base salary plus your age, with the amount being only a few percent for people under 30 and quite a lot for those close to retirement. The fine print around Dutch pensions is often more complex than for the rest of the employment contract combined.

Many employers also mention providing the things you need to do your job (like laptops, phones, and training budget) as benefits, or they point out lunch or snack arrangement or fun company events. While of course it’s nice if an employer provides such perks, when contrasting offers financially most of these are usually not significant. It’s also very rare for these perks to be promised contractually.

One aspect that is not considered a perk is what working from home arrangements have been made. Besides your own preferences around this, not having a daily commute may save you money & time, while not having your home office setup paid for may cost you money or health.

Salary ranges

Dutch developer salaries are perhaps €43k average, compared to €38k median salary across the country for all jobs. I’ve never heard of a developer making half that average, while double the average and more does happen. Most developers make close to and perhaps a bit less than the average, while a select few developers make a lot more. What’s going on?

• Senior developers switch into different higher-paying jobs that have different titles, like architect, manager, or consultant.
• Senior developers go freelance, so they write invoices instead of receive a salary.
• Senior developers don’t do things to increase their salary, instead doing things they find more fun or interesting.
• We have no idea what individual developers are worth, so there are few good arguments for employers to pay much higher than average.

Even for those salaried developers that do continue to hone their craft and gain the experience that clearly makes them more valuable, I believe the salary curve flattens out. A bit of this is simply due to how The Netherlands thinks about what’s a fair distribution of income. A bit of this is because developers don’t like salary negotiation so their employer ends up paying them what they can, instead of what they are worth.

Evaluating benefits packages

With all that basic understanding in place, you might now enjoy playing with this google sheet of example developer salaries that I invented to make the above graph:

The sheet might help as a baseline for evaluating different benefits packages and contrasting some different salary ladders against a simple baseline. The absolute values are probably less useful, though I did attempt to have them be reasonable based on my own experience and some general awareness of 2021 numbers at a couple different companies.

Sample goal: cool company where no-one worries about money

FAANG pay high salaries but not everyone wants to work for them. You may choose to work for a smaller company, or a cooler one, or one with better values. Perhaps then we can pay a bit less?

Let’s look for a really cool small company with solid values, and see what they pay. Bryan Cantrill’s Oxide Computer pays everyone who works at their company a $180k base salary (€160k). That is enough:

1. to live comfortably with 3 kids in the Bay Area;
2. to be in the top 5% of income in the US;
3. to not worry about money, even when putting extra organic raspberries in your shopping basket.

They also provide good benefits like healthcare and stock options. For them, €160k is enough to take money of the table as a employee demotivator, enough to assemble a great team.

The people that work at Oxide Computer could earn more at other employers. That’s ok: beyond some amount, more money simply matters less than other things, like pursuing autonomy, mastery, and purpose. What they offer candidates is something like join a great team, try to make something cool following decent principles, live comfortably, and have a small chance to become independently wealthy.

While it’s not a goal for them forever, Oxide so far has (quite) senior engineers only, of which Bryan writes “engineers at the earliest stages of their career are unlikely to be a fit for us right now”.

Let’s imagine we start a similarly cool company, with similar hiring goals, but in Amsterdam, The Netherlands. Let’s imagine we want to hire (someone like) Bryan as our first awesome senior engineer. He’ll get options or shares of course, and a nice pension, and so on, but what base salary should we pay him so money is not a worry?

€76.000?

The estimated modal income in The Netherlands for 2022 is €38k gross. €38k is the income where 50% of employees make less and 50% make more than that. An example of a job where you can expect to make about €38k is as a nurse with a college degree.

€76k is double that modal income. Ignoring market conditions, I consider double-modal quite a decent benchmark salary for individual contributor senior software engineers with a lot of experience.

• Until our recent housing crisis, a double-modal income was enough to buy a house, support a family, and otherwise live quite a comfortable life in The Netherlands;
• €76k is more than the average senior software engineer makes in The Netherlands, which is probably about €60k;
• Above-average does seem reasonable to me, after all this is Bryan Cantrill we’re trying to hire!
• It feels right to me.

Unfortunately, with the rising house prices, €76k salary is currently not enough for Bryan to buy a comfortable Amsterdam family home, and it’s definitely not enough for unlimited organic fruit. We should deal with our housing crisis and make healthy food cheaper, but in the meantime…

€100.000??

1. To live in a modern 4 bedroom house in the greater Amsterdam area, Bryan’s mortgage will be about €550k, for which he will need a salary of about €100k;
2. He’ll pay about 40% income tax, so will have net income of about €60k, which puts him in the top 5% of income in The Netherlands;
3. After base costs, perhaps €30k remains as disposable income, which should be plenty for all the raspberries he’d like, plus a couple of family ski trips a year, plus buying carbon offsets for that trip.

€100k ought to be enough of a base salary based on the goals we picked. It’s is a lot more than most software engineers make in The Netherlands, but $180k is of course also more than most software engineers make in the USA. We want excellent people so we will have to pay an excellent salary

€140.000???

Most expats prefer living in Amsterdam itself instead of merely close to it. It’s nice when the staff at the local organic grocery shop speaks fluent English as they point out the organic raspberries isle. To live in Amsterdam itself, Bryan’s cost of living goes up a lot, especially for housing.

1. He will need perhaps an €800k mortgage, for which he needs a salary of about €140k;
2. His taxes will then be a bit higher too, for a net income of about €80k, which now puts him in the top 2% of income in The Netherlands;
3. Perhaps €35k of that is now disposable income, still plenty for those more expensive Amsterdam raspberries.

Beyond just money, the living standards for the top 5%/2% of earners in The Netherlands are arguably quite amazing compared to the Bay Area. After all The Netherlands is one of the best places to live in the world! Rather than try to flesh out that argument here I’ll point out the excellent YouTube channel NotJustBikes.

So is this €140k enough to get Bryan to join us? Of course €140k isn’t €160k…but since The Netherlands is so awesome, it does seems somewhat reasonable to me to have to take a bit of a paycut to live here, just like it also seems reasonable to take a bit of a paycut to work for an amazing company such as Oxide Computer. That 12% paycut might be ok to Bryan, and is a bit less than the 15% cost of living difference between the Bay Area and Amsterdam, so day to day it may not feel like a big paycut to him.

€160.000????

It’s 2022 and many US tech companies are all-in on full-remote work, often no longer adjusting for cost of living when setting global salaries. More and more of these companies will pay those Bay Area salaries over here, so to be globally competitive in the job market €160k now really is the rate to match and that’s what our imaginary Amsterdam startup should probably do.

Wow. While €100k is already considered a high salary by most Dutch standards for just about any regular job, €160k plus benefits is more than most Dutch software engineers imagined they could make at any point in their careers. Over here that €160k makes you a part of the 1% even before considering the rest of your benefits package. Many software engineers are loyal employees who don’t like to change jobs, but finding out a life-changing amount of money is perhaps on offer (while building cool things with Bryan Cantrill, no less!) many of us are tempted!

On the other side of the negotiating table, as a hiring manager who pays their engineers €76k or perhaps €100k and thinks that it is quite a generous and reasonable amount, it can be jarring when we hear that those same engineers now earn 60-100% more somewhere else for the same (or more fun!) work. Should we try and somehow match the US salaries, or, should we accept we’re not a globally competitive employer and risk losing some of our best people? Ugh! That also doesn’t feel right.

How high will salaries go?

Over the last few quarters a lot of Dutch employers are bumping engineering salaries by 10-20% or more, German IT salaries are going up fast too, and probably this really is true across Europe. Employers are trying to remain competitive in the job market…but is a 10% bump enough when 60% or 100% more salary is on offer elsewhere?

Since the scarcity of senior software engineers won’t be fixed change quickly, and the BigTech companies can afford to pay a lot, it seems like the top global salaries are poised to still go up further in the short term, in turn creating further strain in our local job market, and keeping the money topic on the table for most IT employers and employees everywhere.

Will salaries come back down?

Perhaps. The global economy seems to be overheating. It could be we are in another bubble, which could burst, which could turn the scarcity of engineers into surplus of engineers really quickly as investment drops. Since no-one really understands how the global economy works, it’s hard to be sure.

(Disclaimers: I work in outsourcing, not at a startup. I work and live in the Amsterdam area but not in Amsterdam itself. This is not how compensation is set up where I work. I make a lot less money than Bryan Cantrill, who was also not consulted about this blog post (I owe you some raspberries, Bryan).)