Velo Blog

Tag: hiring

  • The day 1 onboarding checklist we finally trust

    The day 1 onboarding checklist we finally trust

    Our first attempt at onboarding was a Google Doc that nobody updated. Our second was a Notion database with fourteen owners and no owner. This is the third version, which has run through nine hires without a rewrite, and which our last four joiners have said was the first day at a job that felt planned.

    The rule we work backwards from: nobody sits idle. Not the new hire, not the buddy, not the manager. Every hour on day 1 has a defined output, and we can point at the output the next morning.

    The twelve items

    We track this as a Linear project cloned from a template. Each item is a ticket assigned to the person responsible, with a due time in London hours. If a ticket slips, it pages the hiring manager in Slack. Nothing here is aspirational; every item has failed at least once, which is why it made the list.

    1. Laptop imaged and on the desk by 08:30. IT owns this. If shipping is late, we send a loaner from the office by courier the night before.
    2. Accounts provisioned in Okta. Google, GitHub, Linear, Slack, Notion, Datadog, Figma, 1Password. Provisioned the Friday before, tested by IT with a throwaway login so we catch a missing SSO group before Monday.
    3. Buddy assigned and confirmed. Named two weeks in advance, blocked on the calendar for the whole day, not a stretch assignment for someone already underwater.
    4. Welcome standup at 09:15. Fifteen minutes with the immediate team. Names, what each person is shipping this sprint, one question the new hire wants answered.
    5. Dev environment running by 11:00. We keep a bootstrap script in the main monorepo that clones, installs, seeds the database, and runs the test suite. If it fails on a fresh machine, that is a P1 for the platform team.
    6. First PR opened by 14:00. Every team keeps a small backlog of tickets tagged good-first-issue. Copy tweaks, config renames, a missing test. The point is to touch the pipeline.
    7. First commit merged by end of day. The buddy reviews, the CODEOWNERS bot approves, CI runs green, and it deploys through our normal path. No ceremony, no exemption from the release train.
    8. Three intro coffees on the calendar. Not scheduled by the new hire. The manager picks three people outside the immediate team and books thirty minutes each across the first two weeks.
    9. Engineering handbook read. Sixty pages in Notion. It covers how we branch, how we write RFCs, how we run incidents. We ask two questions about it at the retro.
    10. Shadow the 15:30 standup for the sister team. We want new joiners to see how another team runs before their own becomes familiar.
    11. Post in #intros. A short paragraph and a photo of something the person likes. Not a policy, but a norm every hire has followed for two years.
    12. End of day retro with the buddy. Twenty minutes. What worked, what was confusing, what the new hire wants to change tomorrow. Written up in the Linear ticket and read by the manager the next morning.

    Why the first commit matters

    People argue this one with us. They say it puts pressure on the new hire, or that the commit is trivial and doesn’t prove anything. Both criticisms are fair, and both miss the point.

    The first commit is not a test of the new hire. It is a test of us. If a fresh joiner cannot ship a one line change on day 1, we have broken something: the bootstrap script, the CODEOWNERS file, the CI pipeline, the deploy access, or the buddy’s calendar. When we started measuring this, we found that on average two of those five were broken for any given hire. Now it is closer to zero.

    The first commit is a test of us, not of the new hire.

    The commit itself is often a typo fix in the marketing site or a colour token in Figma renamed in code. What matters is that the person walked the full path, saw the review comments, watched CI go green, and got the Slack notification when their change went live in production.

    What we cut

    The first version of this list had twenty six items. We cut fourteen. The pattern for cutting was consistent, and worth naming.

    • Anything that could wait until week two, waited until week two. Payroll paperwork, benefits enrollment, the security training module, the office tour with facilities. None of these help someone feel oriented on day 1.
    • Anything that produced no artifact came off. A “meet the CTO” slot without a follow up was noise. The CTO now joins the Friday demo instead, which is a real meeting with a real output.
    • Anything owned by more than one team came off. Shared ownership meant nobody chased it. Every remaining item has exactly one accountable owner, listed in the Linear ticket.

    We run this checklist every Monday and most Tuesdays. Nine hires in, the pattern holds. The buddy is tired by 17:00, the new hire is tired by 17:30, and the manager has a written retro to read on Tuesday morning. Nobody sat idle.

  • A take-home task that respects candidates

    A take-home task that respects candidates

    What we ask

    Our take-home is capped at two hours. We say two hours, we mean two hours, and we check on it. If a candidate spends four, we treat that as our fault for scoping poorly, not theirs for being slow.

    The prompt is a real problem we hit last March: a Linear webhook was dropping payloads under load, and our on-call channel in Slack filled with duplicate alerts. We strip the business context, sanitize the payload shape, and hand candidates a repo with the failing test already written.

    What we pay

    Two hours of senior engineering time is not free. We pay 200 pounds per completed submission, regardless of outcome. Finance flagged it as unusual the first time; now it runs through the same expense flow as contractor invoices.

    A short list of what the pay covers:

    • The two hours of coding.
    • The 20 minute walkthrough call afterward.
    • Any follow up questions we send over email.

    The rubric lives on GitHub

    Our scoring rubric sits in a public repo, versioned like code. Candidates read it before they start. We grade on four axes: correctness of the fix, quality of the test coverage, clarity of the pull request description, and whether the candidate flagged the ambiguities we planted.

    If you cannot show a candidate how you will grade them, you do not have a rubric. You have a mood.

    We do not hide the trick either. There is a race condition in the retry logic that most candidates miss. That is fine. Missing it is not disqualifying; pretending it does not exist in the walkthrough call is.

    Why bother

    The hiring market tells engineers their time is worth nothing until an offer lands. We think that assumption poisons the relationship before day one. When someone joins us on a Tuesday, they have already seen how we write tickets, how we scope work, and how we handle disagreement. Nothing about the first week is a surprise.

    Two candidates last quarter turned down our offer. Both cited compensation. Neither cited the interview. We will take that trade.

  • Salary transparency, eighteen months in

    Salary transparency, eighteen months in

    In January of last year, we pushed a Notion page live to the whole company. It listed every role at Velo, the band it sat in, the floor, the ceiling, and the multiplier we used to convert level to base. We wrote about it on a Wednesday afternoon in Slack. By Friday, three people had asked for a chat.

    Eighteen months later, that page is still up. Some of what we expected happened. Most of what mattered did not. We wanted to write down what we published, what we held back, and one thing that broke.

    What we put on the page

    The Notion doc has six tabs. It contains everything a new hire or a curious teammate would ask us in a one to one:

    • Level definitions for engineering, design, product, and go to market, with three example projects per level.
    • Base salary bands for every level, in GBP and EUR, refreshed each January using Radford and our own market pulls.
    • The formula that turns level into offer: floor plus a location factor, capped at the ceiling.
    • Equity grants as a range of shares, plus a plain English note on our 409A and the strike price at the last round.
    • The rubric we use in promotion committee, including the four criteria and how we score them.
    • A change log at the bottom, so people can see when a band moved and why.

    We linked it from the onboarding checklist in Linear and pinned it in the #comp channel. New hires get a Loom walkthrough on day two.

    What we did not publish

    We were honest with ourselves about the gaps. A few things stayed off the page on purpose:

    • Individual salaries. We publish bands, not names. Two teammates asked for a fully open sheet in month four. We said no, and wrote a short doc explaining why.
    • Bonus targets for the two people on commission. Their plans are bespoke, and putting a range on them would have misled the rest of the team.
    • The one off retention grants we handed out during a rough patch last summer. Three people got them. We told each of them the same thing: this is not part of the standard rubric.
    • Founder salaries for the first year. We added those in month nine, after a Datadog outage weekend where the on call engineer asked, in a Slack DM, whether the founders were still on a discount. It was a fair question and we should have answered it sooner.

    We are still uneasy about the retention grants. If you publish a rubric and then quietly step outside it, you owe people an explanation. The next time we do one, it will show up in the change log with a category, even if the individual amounts do not.

    The hire that fell through

    In April, we were close to signing a senior backend engineer out of Berlin. She had spent an hour on a Figma review with our design lead and shipped a small GitHub PR against a starter repo. The team was ready.

    Our offer was the top of the L5 band. She had a competing offer that was twenty two percent higher, from a US company hiring in Europe. She sent us a screenshot of the other letter. We said no to the counter, because raising for one hire would have blown a hole through the band we had just published.

    She took the other job. It was the right call and it stung. If our page had been private, we would have found a way to say yes and moved on. Publishing the numbers meant we could not privately break our own rules without someone finding out on their first day. That constraint cost us a good hire.

    The point of writing something down is that it becomes harder to walk away from. That cuts both ways.

    The quiet compression

    The thing we did not predict was what happened to the bands themselves.

    Before publishing, our L4 engineering range spanned roughly forty percent floor to ceiling. Managers used the full width. Two people at the same level, hired six months apart, could sit twelve thousand pounds apart based on how the negotiation went.

    Once the numbers were visible, the top of the band became a promise. Anyone below the midpoint asked, reasonably, why. Over three review cycles, the width of that band shrank to about eighteen percent. Not because we changed the policy on paper, but because managers stopped defending the low end and stopped offering the high end without a clear promotion signal.

    The average went up. The variance went down. Our comp spend for the L4 cohort grew by nine percent year over year, and we lost the flexibility we used to have to reward a rare skill without moving someone a level.

    We are not sorry about it. It made every one to one about pay shorter, and it turned promotion committee, which meets the second Thursday of each month, into an argument about evidence rather than an argument about numbers. Two people got promoted last cycle who would have been talked out of it under the old system, because the manager could no longer say, quietly, that they were already paid like the next level.

    What we would do again

    If we were starting over, we would publish sooner and narrower. Wider bands look generous on paper. They also give managers room to make decisions they cannot defend in daylight. We would rather have the argument up front.

    The Notion page is still open in a tab on our screens most Fridays. It has not fixed hiring. It has made the conversation we have about pay a smaller, calmer thing. Given where we started, that is enough.