My adored Camille is writing a book on management, which will no doubt be amazing, and asked me to contribute a section on being an organised manager. She says, “Managing people is hard, and and as an industry we’re bad it. We lack the experience, the tools, the texts, and the frameworks to do it well. From mentoring interns to working in senior management, this book will take you through the stages of management, and provide actionable advice on how to approach the obstacles that come up as a technical manager.” For updates on the book you can subscribe to Camille’s newsletter. Anyway, here is what I know about being organised as a manager. Which apparently I am.

Shipping

My weekly schedule revolves around the build that we cut every Thursday, every other of which we aim to promote to Production. Our weekly meetings revolve around this – we used to do Monday / Thursday meetings where Monday was “what goes in the build” and Thursday was “what is really going in the build”, but once we had a rhythm that was working well for us, we decided to move to two week sprints, with a sprint planning meeting on the Friday after the production candidate build gets cut.

If the production build comes back clean from QA, we cut another one with production certificates, and that gets a second QA and then we ship it to the app store.

For high priority bugs, we can promote an “off” build to a production candidate build. However this is something I consider to be an emergency, and we aim to be a zero-emergency team.

1:1s

1:1s are the most important activity as a manager, and a meeting that I never want to reschedule. I do bi-weekly 1-hour 1:1s with each of my direct reports. Instead of recurring meeting times, which used to get disrupted, I switch to allocating Friday’s for 1:1s (this works well with shipping the build on Thursdays), alternating which team (iOS / Android) each week. My admin then goes and schedules specific times a few days before. If I can’t do 1:1s on a Friday (e.g. if I am travelling) then I will push back to the following Monday.

I also try to make a point of checking in with everyone in my team every day via DM on slack, and taking it to a call if they have something on their mind. Typically in the afternoon I will go through and say hi to anyone I haven’t spoken to that day, and ask them how their day is going. On a remote team, you miss social cues. The purpose isn’t to check up on people, but to continually build and maintain a relationship where they will tell me what is going on.

Topics in 1:1s are firstly, whatever they want to talk about. Because we have an hour together, we have time to work on something. For example, if someone is thinking about submitting a conference talk, we can work on the abstract together in the 1:1. I try to have a bigger picture thing related to their work that we can talk about, for example we might talk about giving feedback effectively (e.g. in code review). I want us to use the time we have together and consider the context of their day-to-day work and career. 1:1s are not for status updates, but especially with tech leads, we will sometimes use it to talk about the why of the status update. E.g. if a project has not been going to plan, we’ll talk about what has not been working well and how to improve it.

Typically for one set of 1:1s a month, I will pick a theme for them. For example, after I read First Break All The Rules, I took everyone through the first set of questions in our 1:1, which helped me evaluate how I was doing as a manager. Then, the next month I went through the second set of questions in the book. Another theme might be vacation – we have a minimum vacation policy, but it’s important to encourage people to take it. The point isn’t that they decide that in the 1:1! But that they start thinking about it.

For people who don’t report to me, but who I work with closely, e.g. the PM for my team, I have a weekly 30 minute 1:1. It’s time for us to connect, and talk about how rather than just what. I also find it’s a useful relationship building activity when working remotely. Often we don’t use all the time, but as with 1:1s for my team it’s my commitment to make time for them.

Daily Team Communication

As a remote team, we work really hard to stay in sync with one another. As a mobile team, everyone posts what we call “123” in our slack channel.

1. What must happen today.
2. What will hopefully happen.
3. What I’m filling in the gaps with.

I also post mine. It’s easy for days not to go to plan, and what matters is when weeks start not going to plan. A warning sign of that is when the 1 stays the same for too long. If things start to show up every day, it’s a sign that something is going wrong (or not being broken down enough). Because it’s in Slack. it’s not necessary to go on “feelings” but I can scroll back and look at things.

I also expect to see a PR from everyone on the team every day. Again, this isn’t a hard and fast rule, but a potential early warning sign. Because there’s aren’t those in person signals that you get when co-located, I find heuristics really help. Every engineer on the team should be reviewing PRs 2-3 times a day, and fitting that into their workflow. As a team, we have agreed that in general, PRs are not things that should cause interruptions (trigger notifications on Slack), with exceptions for PRs that fix broken builds etc.

Platform teams individually each do a standup, which seems redundant. However, standup is the only meeting where I tolerate some degree of inefficiency. It’s about how rather than what, and as a remote team I love standup as a way for us to start the day by connecting with each other. It’s a good chance for people to offer and receive help, and make plans to pair if that would be helpful.

Team Collaboration

Everything is kept in GitHub, and we organise feature work in feature milestones (which helps us see how close they are to completion). We use labels to denote sprints. Specific sprints each have their own labels, which means we can see when tickets have dragged on.

Effective Meetings

I don’t think meetings should necessarily have an agenda, but they should have a goal. E.g.

• Agree on what goes into the next sprint.
• Discuss and conclude a technical decision.
• Break down a feature into tickets.

For my team, I typically facilitate rather than participate in meetings. If I’m not useful as a facilitator, then I probably shouldn’t be in the meeting. This means:

• Ensuring the discussion is on-topic and productive.
• Helping people talk about the same things.
• Stopping circular debate – keeping things moving.
• Identifying action items.

Personal Organisation

I maintain a simple text document with my TODO list, which I break down by days of the week. Typically I review it in the morning, and push some things to later days. It’s in the Notes app, which means it’s also on my personal computer and my iPhone, so it’s easy for me to capture other thoughts even when I’m not “working”. Write it down, and let it go.

This list doesn’t just capture tasks, but also things like if I need to speak to someone about something, I add it under their name and the day for their next 1:1.

For small things that I don’t plan to do myself, my DM channel with my admin contains a stream of consciousness of things that I want to happen. From sending a gift to a conference organiser, to scheduling meetings, to checking my travel.

I live by my calendar, which my admin mainly manages for me. I’ll try and review the upcoming week at the end of the previous one, or over the weekend, and see if anything needs to change or anyone needs to be notified of anything (e.g. if I will be out, more on that below).

I hate managing my calendar myself, because I try to over-optimise it and just end up stressing myself out. It’s also really hard for multiple people to manage a calendar, and I find that often when I try to schedule things myself I end up double-booked. It’s much easier for me to have someone else manage it, because I can give them heuristics, like max 2 non-work things a week, or not scheduling calls on weeks when I’m travelling. My admin also puts mealtimes on calendars (localised to wherever I happen to be). I don’t always obey those events but otherwise I am liable to forget to make time to eat.

For unscheduled time, if there’’s a short amount of time I’ll:

• Review and organise my TODO list or calendar.
• Check in with people via DM.
• Do code review (PRs should not be blocked on me, I aim for an SLA of every PR, once. I do not meet it.)

Larger amount of time:

• Pull something from the day’s list.

For important, larger blocks of work – especially in periods with a heavier than usual meeting overhead – I’ll have time blocked out in my calendar.

Communicating Travel

Around a week before a trip my admin assembles 2 emails for me to send communicating my whereabouts and availability. The first goes to my team and contains detailed flight and city information. The second is more general and contains just days and country level information.

Non-Work-Work

Aside from my job, I co-run a newsletter (Technically Speaking), write a blog and a second newsletter (Where the Hell is Cate), give a number of conference talks, and work on my own app. I’m also an advisor at another startup. These take varying amounts of time, but typically take place before 9am or after 6pm.

Technically Speaking is written in Markdown and checked into GitHub, and sent via TinyLetter. My blog runs on WordPress. Where the Hell is Cate is written in the Notes app (sometimes on my iPhone in the car on the way to the airport) and sent using TinyLetter from the airport every time I leave somewhere. In general if I have thoughts on these projects during the day – an idea for a blogpost, or something for WTHIC, I’ll just drop those thoughts into the Notes app and leave it for later.

Typically I work one day of the weekend on “non-work-work” and spend the other day disconnected. This doesn’t work quite as well when I travel (this was written on a plane!). My blog is (usually!) scheduled in advance, and Technically Speaking just needs to be put into TinyLetter and sent before I start work on a Tuesday morning. When this goes well, any time I have for personal projects during the week is a bonus, and allows me to get a jump on the following week. This does not always go well.

As a manager, I spend much of my time focused on other people. I find that an hour in the morning for me really helps me deal with this. Either the gym, or some time on personal projects, or breakfast with a friend (or a book) is a stronger foundation than just getting up and getting straight to work. At the end of the day, I go and work out, or for dinner and a walk, before coming back to some non-work-work. It gives me a chance to disconnect. If I work in the evening, it’s usually on less demanding things like catching up on reading (e.g. for Technically Speaking), filing expenses, or email.