People

Team setup

Before writing a job description, I would look at the work we need to do next and who can take responsibility for it. In a small team, the founders may still be doing product work alongside engineers. I would make that division explicit so a new hire understands where they can decide and where they need help.

Most of the first engineers I hired had been on my previous team. I knew their judgement, how they worked and how they disagreed with me, which gave me confidence while I was occupied elsewhere. I still had to ask whether the strengths I valued inside a much larger company were the ones we needed at this stage.

I am choosing a more experienced core team this time and accepting the higher initial salary cost. My bet is that people who can judge what matters, use AI well and own the result will help us reach something valuable sooner. I still need to assess that judgement. Familiarity and confidence with tools do not establish it on their own.

In AI Is a Multiplier, Not a Signature, I described what I wanted that experience for:

An engineer who can frame a problem and recognise when an approach needs changing has more room to work with these tools. I still owe them the outcome and constraints.

That is the judgement I want to assess when hiring senior engineers: how they decide what to pursue, check what AI produces and recognise when they need more context. I would ask them to explain those decisions through work they have done, including what they changed when an approach did not hold up.

Hiring

A hiring process should be short, tell the candidate what each stage is for, and collect enough structured evidence to make a fair decision. Long take-home exercises and trivia add noise.

How I do it now

Everyone is expected to help source, refer and interview candidates. The hiring manager owns the process and keeps it moving. For engineering roles that is usually me.

Technical roles go through four stages, usually within about two weeks.

Stage	Who	Format	What we look at
Intro	Hiring manager	30 minutes, video	Background, motivation and role fit, plus the candidate's questions
Technical	Senior engineers	30 to 45 minutes, video	General technical knowledge, ways of working, and a chance to meet the team
System design	Senior engineers	60 to 90 minutes	How the candidate thinks about designing systems and tradeoffs. A discussion, with no live coding
Founder chat	Founders	30 minutes	Values, vision and mutual fit

The system design stage uses scenarios from our real platform. We ask candidates to state assumptions, propose options and choose between them.

What we look for at every stage:

• Clarity of thinking: explaining tradeoffs and assumptions, beyond the outcome.
• Ownership, and the ability to work without heavy process.
• Low-ego collaboration.
• Practical AI fluency: using AI to amplify engineering judgement, and being able to say how they use it responsibly.
• Comfort with ambiguity and shifting priorities.

Interviewers use a shared question bank, where each question lists what good looks like and what to watch out for. Feedback is written the same day where possible, and it has to be specific: what was said or done and what it signals. The panel decides together. If an interviewer is unsure, we ask them to say what additional signal would change their mind.

Culture and keeping people

Hiring also shapes how the team works together. In Ten Years in Startups, I wrote about the early colleagues who carried the habits we valued. When they left, replacing their responsibilities did not automatically replace their influence. As new managers joined, their ways of working became the culture their teams experienced every day.

I want to pay attention to those habits during hiring, especially for managers. How do they respond when someone disagrees? What do they do when a colleague needs help? I want the values we talk about to be recognisable in how people work together. A manager should be able to explain which practices from a previous company would fit this team and which would need to change.

At my first startup, we initially hired junior people, kept costs down and offered equity. Later, more experienced leaders arrived. Some early colleagues lost motivation when they felt responsibilities were going to people hired above them without enough help to grow into those roles themselves. Around Series B, some started leaving. My specialist work gave me opportunities and trust that others did not always have, so my experience was different from theirs.

I want the people joining now to have a chance to grow into the roles we will need. Bringing in experience should help the people already here develop too. I would use goals, feedback and progression conversations to agree what someone could take on next and what support they need.

When someone joins the team, they need a clear role, help settling in and room to develop as the work changes. That starts during the interviews and continues as their role and the company grow.

For a CTO, this includes examining the conditions around someone's work. In my first year, engineers held technical knowledge I needed, while I held customer and founder context they were missing. Before treating a missed expectation as an individual's failure, I need to ask whether the expectation, authority and necessary information were available to them. I describe how my involvement changed as the team grew.

The handover from hiring to joining

Once someone accepts the role, the expectations we discussed during interviews need to become work they can actually do. I would write down those expectations before they start, then review them together as they learn the job.

The manager owes them the resources, introductions and feedback needed to meet those expectations. If we discover that the role differs from the one we hired for, I want that discussed while there is time to adjust. Waiting for a final review would waste the period in which we were supposed to help them settle in.

The first ninety days

The first ninety days give that support a structure: clear expectations, introductions and regular chances to discuss how things are going.

Prepare a draft plan before the person arrives, then work through it together in the first week. I would treat the draft as a starting point and revise it once they can ask informed questions.

Before they start. The manager writes a ninety-day plan with clear, measurable goals, at least seven days before the start date.

First week. Share the plan and set expectations. It covers their goals for the ninety days, who they should get to know, and what to read or use.

Throughout.

• One-to-ones at least weekly.
• A check-in at the end of the first and second month against the goals in the plan.
• Notes of what was discussed kept in the plan, and shared with the new starter so they can see everything that is recorded.
• The new starter is expected to ask questions, give their own feedback, and say what extra support they need.

At ninety days. Review the work and the support provided against the agreed expectations. Here is an example of a UK employee probation process, with three possible outcomes. It covers employees and excludes agency workers, consultants and contractors:

1. They pass, and the manager sets longer-term goals.
2. They made clear progress and fell just short. The period can be extended, usually by one month and by no more than three, and only once.
3. They missed the expectations of the role, and employment is likely to end.

If there are concerns, the manager raises them as soon as they appear, well before the review.

The ninety-day template makes the intended outcome, support and evidence visible at each check-in. For an engineer, I would ground it in using the product and delivering a bounded change with someone available to help. That starts in the first week.

Getting a new colleague started

A small piece of real work gives a new engineer a reason to use the team's tools and meet the people they will depend on. I would want them to run the product, understand an actual customer journey, find its current goal and ask the Owner or Sponsor a question. They need to see where a decision belongs and follow a change through the relevant checks with someone who knows the release path.

This would also test my setup. A missing permission, an outdated instruction or an unexplained acronym is something for us to fix. I would ask the new colleague to record where they got stuck and have the person responsible for that area resolve it. Being new gives them a useful view of assumptions the rest of us have stopped noticing.

We have a local development entry point and written management guidance. I still need to turn the first-week path into one maintained checklist, with an owner for each access request and a clear distinction between permissions needed immediately and those granted later.

Starting as a manager

Helping a new colleague settle in also asks something of the manager: time to listen, clear expectations and the willingness to let someone else do the work. For someone leading a team for the first time, these are useful habits to establish.

• Set the tone in the first team meeting. Share your expectations about feedback, meetings and logistics. Say what you do not know yet and ask for feedback on how it is going.
• Look for quick wins. Ask the team what they should stop doing and what the worst part of their job is. Removing one of those builds rapport quickly.
• Your success is the team's output. It is tempting to jump into every fire yourself, especially if that used to be your job.
• Set goals and write them down, so the next meeting has something to check progress against.
• Shield the team when a request is unreasonable, and look for a middle ground when it is not.
• Do not attend every meeting you are invited to. If you add nothing, say so.
• Respect the maker's schedule. People producing work need long blocks; coordination runs on a different clock.
• Hold regular one-to-ones, find a mentor, and keep learning.
• Say thank you, specifically.
• Think of yourself as a coach.

The change in my own day-to-day work is in Habits.

One-to-ones

When I moved from annual reviews to regular check-ins, some of the same problems came with us. The check-ins became status updates. Feedback became a stream of small corrections, and recognition started to look like a popularity contest. I had changed how often we talked without making enough room for development. I wrote about that in Rethinking Performance Management.

That experience affects how I approach one-to-ones. The meeting and its template need to help someone discuss a real problem. A completed form tells me very little about whether they received useful feedback or had a chance to practise something new.

Cadence. At least every two weeks, usually thirty minutes. Weekly during onboarding or a demanding project. Both people are responsible for making sure they happen.

Who owns the agenda. The report does. The manager may add topics, such as progress on goals. Larger subjects, such as development and career, come up at least once a month.

Template. Four questions for the report to prepare:

• What am I proud of accomplishing?
• What am I focused on next?
• Where do I need feedback?
• What are my next steps for development?

Close by confirming who is responsible for what, the next steps, any new deadline and when you will discuss it again.

Keeping track. One shared document that both people add to, with notes of decisions, dates and follow-ups.

For the manager.

• Keep a consistent cadence and do not cancel.
• Make sure the setting is private.
• Ask what would make the meeting most useful to them.
• Start each one knowing what you want from it.
• Balance positive and constructive feedback.
• Coach before you solve: help the person find the answer.

When the team already has stand-ups

Our working cadence has stand-ups three times a week. I would use the board for the delivery detail already covered there, and reserve the one-to-one for what that update leaves out. Which decision is the person finding difficult? Are they getting enough context? Is the work giving them a chance to develop? What have I promised to do for them and not followed through on?

The correction I described in the performance-management post was to choose a capability to develop, understand the current difficulty and agree a small experiment. The one-to-one template leaves space for that without requiring a career conversation every week.

Setting goals with a report

A development conversation needs something to return to. Set goals in a new starter's first two weeks, then each quarter after a review.

• Agree three to five goals that support both the person's development and the team's objectives.
• Define the expectation in detail, and say what criteria you will use to evaluate it next time.
• Make each goal specific and measurable, achievable, relevant and time-bound. It should be clear afterwards whether it was met, ideally with evidence. “Run 5km in under 25 minutes by the end of June” passes; “get better at running” does not.

Before settling on a goal, check the following:

• Committed. Both of you agree with the goal. A slightly worse goal you both believe in beats a better one only the manager wants.
• Owned. The report writes it. If they do not own their development, nobody will.
• Inspiring. Not every goal has to be, but if none are, something is wrong.
• Followed up. Motivation is highest just after goals are set. Check regularly, and rewrite a goal that is no longer right.

These are personal goals for a report. Delivery goals, with an Owner and a Sponsor, are in Delivery.

A development goal also needs a manager's contribution. If someone needs to improve how they explain technical decisions, I can give them customer context, make the decision owner clear and arrange an early review of an outline. Assigning the goal and waiting until the next quarter leaves those conditions unresolved.

Giving feedback

Between those goal-setting conversations, people need feedback on the work itself. Tie it to a concrete situation, be specific, and avoid “never” and “always”.

Stop, start, keep.

• Keep: “You excel at [action], and I would love to keep seeing that from you.”
• Keep, with a third party: “I encourage you to keep doing [action]. I have had feedback that it helped the team [result].”
• Stop: “My feedback is for you to stop [action] because it results in [consequence].” Use it for something observed more than once.
• Start: “I encourage you to start [action] because it will help you [result].” Often easier to hear than a stop.

Situation, behaviour, impact. Name the situation, describe what the person did, and say what it led to. For constructive feedback, add what they could have done differently.

How as well as what. Recognise how someone worked as well as what they delivered: achievement, communication, craft, growth, leadership and teamwork, tied to our values.

How I try to receive feedback is in Collaboration.

Suppose an engineering task becomes harder than expected and the engineer does not raise it early, leaving other people blocked. I would discuss the point at which help was needed, what prevented the person asking, and what they should communicate next time.

I also need to say when I have observed a problem. Asking a sequence of coaching questions until someone guesses the criticism in my head is unfair. I can state the observation and its impact, then listen to their account before deciding what needs to change.

Recognition

The same care belongs in recognising good work. Naming what someone contributed helps them understand what was useful and gives other people a chance to learn from it.

• Make it frequent, or it looks contrived.
• Be specific about what you appreciated, and cite the example.
• Pass on praise you hear from others, quickly.
• Know who prefers public recognition and who prefers private.
• Offer more responsibility, a seat in a meeting they would not normally attend, or a learning opportunity.
• Act on a suggestion. It shows what you think of their judgement.
• Perks matter far less than trust in a manager.

When someone thanks you, accept it without dismissing the work they noticed. You can thank them and acknowledge anyone else who helped.

The meeting cadence I use now gives the weekly All hands a slot for this: Owners demo shipped goals and recognise the people who helped.

I would keep the praise attached to the contribution, rather than choose an employee of the month by counting kudos. A count can miss the engineer who helped someone else finish, maintained an awkward service or prevented a problem. I want to hear what the person did and why it mattered.

Psychological safety

Feedback also needs to travel back to the manager. People need to be able to raise a problem, ask for help or disagree with a decision. Amy Edmondson calls psychological safety a shared belief that the team is safe for interpersonal risk-taking. She gives three things a leader can do:

• Frame the work as a learning problem.
• Acknowledge your own fallibility.
• Model curiosity and ask a lot of questions.

To make room for people to speak up:

• Gather opinions on an important decision in writing before meeting to discuss it.
• Let everyone put ideas forward before you say which you support.
• Thank people who challenge your view.
• Make sure people with less authority on paper are heard.

Edmondson's questions for measuring it ask how strongly people agree with statements such as: mistakes are held against you on this team; members can bring up problems and tough issues; it is safe to take a risk; it is difficult to ask other members for help.

I wrote about doing the second of Edmondson's three. I told the team where I had fallen short and asked them to explain their parts of the system to me; see Imposter Syndrome Is Real.

The performance review meeting

A performance review brings those ongoing conversations together. Nothing in it should be a surprise; anything raised there should already have come up in a one-to-one.

Preparing.

• Give as much notice as possible and meet in person where you can.
• Assess performance against the person's goals before reading their self-evaluation, so their reflections do not sway yours. Then compare the two.
• Plan the points to cover and check yourself for bias across the whole team.

In the meeting.

1. The report talks through their self-assessment first.
2. The manager follows with theirs, mostly emphasising and adding what was not covered.
3. Agree goals for the next period and concrete next steps.
4. Thank them.

Aim for the report to do about seventy per cent of the talking. Ask open questions and listen. Use clear, change-focused language, and ask what support they need.

Questions that help.

• What are you most proud of since the last review?
• What do you enjoy most about your work?
• What do people on the team rely on you for?
• What would you like to focus on next?
• What is holding you back?
• How can I improve as a manager?

Rating performance and potential

When a review includes a rating, I would establish the role's expectations and discuss the evidence before applying a label. One way to describe performance is this five-point scale, covering how someone works as well as what they deliver.

Potential is rated separately on three points, from ability, aspiration and engagement: high, medium, and matched to the current role. A “matched” rating is not a criticism. Someone may be happy where they are, and potential moves with what else is going on in their life.

I would not use a rating quota for a small team. My own experience with performance frameworks has made me more interested in the work, its context and the opportunity someone was given than in making a distribution look right.

Calibration

Once several managers are making those assessments, they need to compare how they apply the standard. Calibration gives them a way to check that people at the same level are being judged against the same expectations.

Before the meeting.

• For each person: what they delivered, how they worked, how they did against goals, and how they grew.
• Across your team: how people at the same level compare, and what separates those above and below expectations.
• Bring concrete examples.

In the meeting. Listen to how other managers apply the standard and be prepared to change your rating.

Checking for bias.

• What is my emotional response to this person?
• Am I only thinking about recent examples?
• Do I have evidence from more than one source?
• Does this person or situation remind me of someone else?

Managing low performance

A concern about performance may appear well before a formal review. Deal with minor concerns informally and early, with coaching and more feedback. If the concern continues, do not delay addressing it.

I would first separate a missing skill from a missing brief, lack of authority or workload the person cannot reasonably carry. Those need different responses. The performance-management work I described earlier starts with the current condition and an obstacle we can investigate. That inquiry belongs alongside clear feedback about an unmet expectation.

The two stages below are an example of how to structure that process.

Stage one: a documented conversation.

1. Focus on the opportunity to improve.
2. Set out the concern with examples and the standard that is not being met.
3. Let the person respond. Pause the meeting if they need time.
4. Agree actions, support, training and deadlines.
5. Be honest about what happens if nothing changes.
6. Send a written summary within twenty-four hours.

Stage two: a formal improvement plan. A formal plan may be needed when earlier support has not resolved the concern or a specific, observable improvement needs a structured plan. It sets expectations over a fixed period, with weekly reviews. The aim is for the person to succeed. Possible outcomes include meeting the plan, an extension of up to one business quarter after positive progress, or further employment action. The relevant People support needs to be involved in applying the procedure.

Throughout, the conversation is two-way and private. If a disability or other underlying reason may be involved, raise it at the start so adjustments can be considered.

Promotions and levels

The same attention to expectations and evidence matters when someone's responsibilities are growing.

In teams I managed, we discussed the career ladder in one-to-ones and used peer committees for progression decisions. The framework connected contribution and scope with development and compensation. I have written about the six-level model I used and its limits.

For a CTO, the useful conversation is about the responsibility someone is already handling, what they want to deepen and whether they want broader scope. Technical leadership and people management can contribute at comparable scopes. A strong engineer should not need to become a manager just to discuss growth.

I would bring a concrete piece of work to that conversation, the judgement it required, feedback from people who saw it and the person's own account. Then we can identify an opportunity to practise the next responsibility. A small company may not yet have a distinct role at every level. I need to be clear about the opportunity that exists, rather than promising a title the organisation cannot support.

Succession planning

When a promotion moves someone into different work, someone else needs to take on what they leave behind. Succession planning prepares for that handover so a key departure or move does not stop the company.

1. Identify critical and emerging positions.
2. Identify what makes someone successful in each.
3. Assess who could step up or move across.
4. Develop those people.
5. Measure and review.

Offer open roles internally before looking outside, except for confidential hiring, and record the critical knowledge each position holds. That last part overlaps with the section on single points of failure in Operations.

I am still working on handing over review, the board and some meetings. A named successor needs access, context, authority and time to practise. Operations describes how I would check a handover.

As the company grows

In a startup, I would begin with clear expectations, regular one-to-ones and useful feedback on actual work. With several teams and managers, I would add calibration so that people doing comparable work are judged against comparable expectations. The expectations and examples above provide a starting point for that discussion. I would still ask what each review or form helps someone decide, and whether the company can offer the development opportunity it describes.

Still to write

• A maintained first-week onboarding checklist, with tested instructions and named owners for access requests, and evidence from using it with new engineers.
• Examples of how we have used these approaches and what I changed.
• Letting someone go.