Collaboration

We meet to plan, share progress and work through questions. I want those conversations to leave people clear about what happens next and where to find a decision afterwards.

Several people I hired had worked with me before. We brought that trust with us, but the new company needed its own shared context: which decisions were theirs, what the founders had agreed with a customer and when someone else needed to be involved.

Meetings

A meeting should have a purpose someone can state and an output someone can find afterwards. I would keep the number small and give each one a single job, so that nobody has to work out which meeting a question belongs in.

Every meeting needs a page with its purpose, what to bring, the agenda and what comes out of it. It also needs an owner who prepares it, leads it and follows up on the decisions.

What happens after the call

I had proposed recording decisions where the work lives, and writing up decisions made on calls that day. That habit still starts with me. The note needs to say what is decided, what remains open, who is taking the next action and when the people affected should expect an answer. I can then point to it when someone asks, and they can point to the same record when they disagree.

This matters when the founders are in different places too. I am in the UK and the other founders are in Germany. Someone who missed a conversation should be able to understand its consequences without waiting for the same people to be available again.

One-to-ones

For me, the reason to protect that time is what might never appear on the board. Someone may be delivering well and still feel stuck in their role. They may need help with a relationship, want feedback they have not received, or be taking on responsibility without enough support. If I spend the meeting collecting updates I could have read beforehand, those subjects have to fight for whatever time remains.

The employee owns the agenda, and both people protect the time. Meet at least every two weeks, and more often during onboarding or when the work calls for it. A weekly meeting is a useful habit to build. I would agree a cadence with each person and make it dependable.

I would keep a shared note where either of us can add a topic before the meeting, then ask what most needs our attention. Make time for development and career aspirations at least monthly. I want to return to what we agreed: the introduction I said I would make, the work they wanted to try, or the concern that needed an answer. My own follow-up belongs in that note too, so they can hold me to it.

The cadence, agenda and template are in People. I wrote about moving from annual reviews to frequent check-ins in Rethinking Performance Management.

Feedback

Giving

Feedback is most useful early, direct and specific. Our values put it as directness with care over silence, and make conflict about facts, not people. On Slack the norm is to praise publicly and criticise privately.

When someone's decision goes badly, I first ask what they knew, and whether we had given them the context and authority we said we had. Sometimes there is a judgement to improve. Sometimes there is something I failed to provide.

Before giving feedback, identify the situation, the behaviour someone could observe and its effect. Then explain what you want to continue or change. I would check those details before the conversation. Saying someone needs to communicate better leaves them guessing which moment I mean and what I expect them to do differently.

I also need to hear their account. A late update could come from avoiding a difficult conversation, or from believing that somebody else had already passed it on. Those require different responses. I can be clear about the consequence while still being willing to correct my understanding of how it happened.

Recognition deserves the same care. I want to notice the person who made another person's delivery possible: explaining an unfamiliar service, finding a missing requirement or helping a colleague get unstuck. The visible demo rarely contains all the work that made it possible. Specific recognition helps me show which contributions I value beyond being the person presenting the result.

Receiving

An engineer once wrote to the whole channel asking us to hold ourselves to deadlines and work on one thing at a time. He wanted stand-ups to include what each person was working on and when it would be done. I read that message, and other decisions engineers picked up, as evidence against me. Their initiative was useful feedback about where I had left something unanswered. I describe that reaction in Imposter Syndrome Is Real.

I would make room for disagreement in ordinary conversations: ask for people's views before announcing my preference, give quieter people space to finish, and acknowledge a useful challenge without making the person defend their right to raise it. I can still make a decision they disagree with. They should be able to understand why, and see what happened to the concern they brought.

How the team is organised

At ten people I would organise by responsibility for an outcome. A reporting line would not tell anyone who decides what on a given goal. Titles matter less than knowing who owns a goal, who can change its scope and who has the final say in an area.

Without a product manager

We have no product manager. The work a PM would do did not disappear: understanding customer needs, choosing what to pursue, defining outcomes, deciding what to leave out. It sits with the founders, including me, and the Sponsor role is how it reaches each goal.

I do not know yet whether we need a dedicated PM. Two things would make me revisit it: more customer requests than we can triage in a week, or finding that we keep choosing from the existing backlog because nobody has time to find out what is missing. The reasoning is in Ten Engineers, No Product Manager.

Room to grow before there is a larger job

I want to discuss people's future in the company while there is time to help them prepare. A small company cannot promise every person a management role or create a title to settle the conversation. It can give someone a meaningful responsibility, the support to attempt it and honest feedback about what they need to learn. I want incoming experience to help the people already here grow too. That is one of the lessons I took from watching the original team change.

For an engineer, the next useful responsibility might be shaping a goal with its Sponsor, helping another person operate a service, or explaining a technical tradeoff to the founders. I would choose it with them, agree what support they need and make time to discuss how it went. Completing a difficult technical task and helping other people make progress are different things to learn. Both can matter to the role they want next.

Still to write

• Examples from my own one-to-ones and what I changed.
• Examples of development responsibilities we have tried, and what the person learned from them.
• Our actual balance of remote and in-person work across two countries.
• Offsites. We have not run one that I would hold up as a template.