Accidentally in Code

Tag: Organization

High Throughput, Low Completion

Credit: Flickr / MeTaMiND EvoLuTioN MeTaVoLuTioN

I have never been someone who organises things.

I have a great memory and a high tolerance for ambiguity, and I evolved to match the era of the internet where searching things by keyword was sufficient. I documented, extensively. But I did not really organize. Not myself, nor – despite my job – other people. I used to joke that I caused people to organise themselves around me: I remembered everything and asked a lot of questions; working with me effectively required those below me to have it together.

In as much as I optimised for anything, I optimised for being able to think.

Big things documented. The weekly list on a sheet of paper. How they fit together, how to reason about things, how to prioritize… that lived in my head.

Like everyone, AI has shifted my workflows, and somehow I have become a person who organises things.

What broke

The first thing that broke is that Jean and I DDoSed each other. We got productive enough that relying on reliability of the other wasn’t enough – we needed a source of truth to know everything that was going on, and who was doing it. We threw out our system (although if I’m being honest, system is a generous description) and built a new one. Nothing that fancy – just a shared system in GitHub and clarity about the state something was in and what it was waiting on.

Then I DDoSed myself. Too many things in flight, flitting between them, nudging them along. So many terminals I needed to color code them in order to be able to find them. There’s an HBR piece on AI brain fry defining it as mental fatigue from oversight of AI tools beyond your cognitive capacity, with measurable effects on errors and decision-making. This was 100% what I had done to myself. The brain fry is the feeling. The result was too many things moving and nothing finishing. I worry in general that the push to “AI driven productivity gains” drives people into this headspace – with all the harm that brings – and misses the point of the productivity, which is the outcomes the productivity is meant to drive.

Jean suggested I look at turning Claude code into a “chief of staff”, and so I forked the repo and started iterating aggressively. My trello board went in the bin – the API that had seemed like a nice to have a week earlier suddenly a fundamental requirement – GitHub became the source of truth. I added in my existing skills for email and social media. I figured out how to version and symlink them.

It was an expensive and chatty todo list. Becoming more like an actual chief of staff required a set of underlying skills – for course operations, inbox triage, analytics, social, the things I do every week – and a way to surface state. Given the starting point, it became the place I looked to put the things I needed, as I realised I needed them.

This is essentially the principles of context engineering, applied to my own effectiveness. As an engineering manager, my role was to notice and remove bottlenecks. To figure out the failure mode and make (or cause to be made) the process that addresses it. To build the structure that makes individual output add up to team output. Now my productivity has gone way beyond what I thought was achievable as one person, and the result was looking a lot less like individual productivity problems used to, and much more like the kind of problems that occur in a team.

The value of organising things became a lot more apparent. In the same way people used to organise themselves in order to manage up to me, now I create organizational systems to build skills that can help me manage myself – help me finish things, rather than starting one more thing, because the green terminal isn’t currently running anything and it could be.

My prompts are short, and laden with typos. But a collection of skills makes me effective. The working-with-cate skill tells Claude how to be effective with me in return. The DRI program manager skill surfaces the things that need attention. The inbox management skill ensures loops get closed and don’t fall through the cracks, the content manager skill keeps me on track on the internet. Some are just for me. Increasingly, they are shared with the people I work with.

The skill alone is not enough, they need to be backed by data. For my non-technical colleagues, that is often notion. For other engineers, it’s often GitHub. Or another API. Combining an API on DRI with the GitHub repo is what makes the DRI PM skill accurate – and as such, useful.

In functional programming, we talk about pure functions, and side effects. AI alone was like a pure function where I – the lossy human – was responsible for the side effects. Increasingly, to be more effective, I want the side effects. I want the skill to write to the source of truth, and flag updates to itself when it realises it is less useful than it is supposed to be.

To manage the side effects, you need guardrails. Now my collection of skills has progressed such that I added a structured rubric to run skills against.

The ever increasing burden of reviewing

Which brings us to the skill of reviewing. When my job was weighted more toward reviewing other people’s work than producing my own, AI looked, frankly, like a productivity tool for everyone except me. It is much more fun to be a creator than a reviewer in this timeline. The skeptics aren’t wrong about slop.

But liberated from other people’s nonsense and trying to grapple with my own, I stopped debugging at one level of indirection, and started getting to the core of it.

The answer is not “stop reviewing.” The answer is to get structurally better at reviewing – which mostly means asking better questions and shaping the work so it’s queryable.

For example, PRs. I know there’s a debate on this, and I get it. I still believe PRs are useful. Firstly because they segment the change – if it breaks something, you know where to look. Secondly because the PR itself is a queryable unit. You can run rules over it, check whether the standards you encoded are being met. Reviewing – for me at least – looks less like looking at the code, and more like thinking through how to validate the work, ensuring that has happened, and figuring out what to learn when it has not.

There’s a good chance my opinion will be different next week. The willingness to put everything I think I know in the bin weekly if not daily is currently the most useful thing I can do to accelerate my own learning. I don’t think anyone really knows what they are doing yet; the constant iteration is necessary to navigate the learning curve.

The metric isn’t output, it’s completion

The trap I fell into is that the cost of generating drops and you can have a lot more things going. Just because you can doesn’t mean you should.

Individual productivity is not a pure function. There are side effects and interdependencies. Hooking up the waiting list to my email and to GitHub is a win – when the thing I’m waiting on comes in, the item moves from waiting to needing my action. Similarly, surfacing the things others are waiting on from me is a reminder that team movement beats individual productivity.

Part of why I wasn’t given to organize things, is that I’m an ADHD-creative type. Executive function is boring, which makes it expensive, which makes me not do it. Building an operational floor for myself helps liberate me from worrying about things, from expensive “did I remember this” panic. I’ve given that work to the robot, so I can work to my actual strengths.

In the first period – before the DDoSing began – I felt the high of AI making me more capable at the things I’m good at. Now I’m leaning into how to be effective at handing off the things I’m bad at. We’re not going to be winning any prizes for organisation, but that’s okay because organization is not the point. The point is the output. The point is finishing the thing. Shipping it.

Everyone is figuring this out

If it is this much work for one person spanning two small teams, of course large organisations are struggling. The learning curve is hard — trying to navigate new tools and a step change in productivity at one time. I’m unconvinced anyone has it figured out, despite some people loudly claiming they do. I’m so grateful I have this time to work through this learning curve working with fewer people, in a more collaborative set up.

I was heads down for a while, but lately I’ve been talking to more people, being more willing to share where I’m at, and offer suggestions. In doing so, I realised I had rewired my brain. Things seemed obvious to me that weren’t obvious before. How to reshape a problem, how to systematise it, how not just to increase the throughput, but drive the overall goal forward, too.

This rewiring happened because I had the space to mess around – to try things, abandon them, try different things, talk it through with someone who was also open they are figuring it out. You cannot build that space by reading a blog post about it. You have to do, and badly, and give yourself permission to learn.

Fundamentally, I’m optimistic about the value of engineers, despite the narrative that we can be replaced by AI. I think learning and adapting is a core skill for us, and we have it to call on, even if the timing is not what we would choose. But sometimes that skill alone feels insufficient, and for that, Jean and I built Navigating the AI Shift. We saw the dissonance and the struggle, and designed a structured space for engineers and EMs to do some rewiring, with the support and accountability of coaching but at a more accessible price point.

The first cohort starts May 11. We’d love you to join us.

May 5, 2026
How I Offloaded My Anxiety to Trello
I’ve never been good at what you might call “life admin”, but I used to keep track of it through having a high level of 1) recall, 2) guilt and anxiety.

I can’t say this system was working well, I was pretty behind on this stuff (such as… still having an Australian bank account five years after I moved away). But the critical things were mainly taken care of and the non-critical… remained in runtime memory.

A bit over a year ago, having dealt with what I termed the “inner monologue of self hate”, my every failing as a person was no longer running on a loop in every moment of downtime. At this point, I realised I needed a system that didn’t involve me remembering everything and worrying about it.

Enter: Trello.

Board 1: Life Admin

I created a board that I “jokingly” called “Life Failures” (since renamed to Life Admin), and set up a bunch of columns. I don’t exist kanban style in my life so the main features are:
- A list of areas of responsibility, such as “finances”, “house”, “car” etc.
- Labels, primarily: “waiting”, “work hours phone call”, “easy”, “blocking”. During lockdown I created a “post-pandemic” label to filter out visually the things I couldn’t expect to make progress on, which was helpful.
- A done column that resets each month, i.e. “Done – June”, and “Done – July”. I tend to keep the previous month’s around and then archive when I create a new one. So right now in July, June is still around. When I create August, I will archive June.
- Extensive use of checklists.
Each card is on some level a mini life “project”, and I keep tabs on things using the labels and the checklists. This is the one where I changed my bank account, it entered waiting / blocking states multiple times, was closed off in May, even though it began in March.

This sometimes creates a disconnect between the amount of work I’ve done and the amount I really get to “check off” but I am trying to embrace with this list the idea that life admin is something that is continually chipped away at. The goal is not to empty the board, the goal is to be more on top of things and not create cascading failure in my personal life (again).

Since adopting this system I’ve made progress on so many things that have dragged on for years. Particularly in the “financial” list which has always been my biggest struggle (there is no visual reminder, it’s extremely boring and usually bureaucratic which I find disproportionately stressful). The Australian bank account is closed, I finally managed to transfer my stock from the Conglomerate out of the mandated system and to my regular investment manager (this was so painful and had stopped and started multiple times before we really made a concerted effort earlier this year). I managed to untangle the mess of paying emergency tax for ~18+ months over three tax years. Addressing these things doesn’t really affect my day to day, but it does make it easier to make bigger decisions, because everything is accessible and where it should be.

The board is broad, and there are obvious ways to streamline it or break things out into their own board, but I choose not to. The board is broad because life is broad, and because some months I may move things from one column, and other months from other columns, the point is that everything is tracked, and moving overall.

List of columns:
- Finances
- House
- Car
- Travel
- Cate as a Person
- Self-Employment
- Professional
- Writing
- Misc
- Things to buy
- Done – Current Month
- Done – Previous Month
Board 2: Day to Day

At the start of this year, I created a second board, which I call “Day to Day”. The idea of that one is to capture the repeating tasks. This consists of three lists:
- Week
- Month
- Current Month
At any given time I have a “week” card which captures the things I try to do every week, and a “month” card which captures the things I try to do every month. When the week is up, I move it under the current month, and then I archive that at the end of the month. Initially I had “day” cards but I found that it was just annoying me, so I got rid of them.

I use template cards, so each time I create a new week or month card, they come with the same checklist. If I was going to add something, I would add it to the template card. For instance, I didn’t feel the need to track going to the gym on the week card because it was 1) more of a daily thing, and 2) a strong habit. After the gym being shut for nearly 4 months, I might add it in as I rebuild that habit.

This is the current state of the board:

This is the current state of July:

The month list is relatively short, and really just captures 1) taking some time for myself (the spa!), 2) a task that I dread (the personal expense report) and 3) the vague thing that I feel is best done through continuous small efforts (the “external thing”, a profile building/maintaining exercise).

This is the current state of this week:

The week list is longer, and captures the aspects that I think create a well rounded life – good friendships (regular social interaction, doing something nice for other people), personal well being (writing, cultural experiences, regularly chipping away at the hardest list in life admin) and self care (making an effort with my appearance, maintaining a beautiful home). It’s always interesting what drops off depending on circumstances.

Initially I had the idea that these lists should capture everything, and had the concept of “extras” where I would note down things not covered by the list. But over time I’ve concluded that it works best for me when the concepts are general, and it creates regular opportunities to consider what, of the things I consider important, am I making time for? And what am I not?

✅

Both boards combine to address the nagging sense that I’m behind or not doing enough, and allow me to capture what goes into keeping my life moving along and the things make me happy. The things I “should” do no longer run in a loop in my head; they are captured in Trello, and it’s a vastly better way to live.
July 22, 2020
Bi-Monthly Rituals: The State of All the Things
Credit: Pixabay / geralt
At the end of last year, I somehow found myself as the lead of a team that was 4x as big as my previous one. Many things were different, but one of the big ones was changing from having one person on each platform who really knew everything that was going on… to having some unknown set of projects with unknown combinations of people involved. My first task, then, was to figure out what our multi-month multi-engineer projects were, what had happened on them so far, and what we were aiming for – in terms of scope and time. And that is how I accidentally implemented deadlines. Which I think is an example of what can go wrong when you arrive in a culture where something that is core to you is not thought about. I asked “when do you think this will be done?” because it’s impossible to me to be involved in anything and not have thought about this. But, that wasn’t the culture of the team – some people hadn’t. I think a sense of time is important, but if I knew it wasn’t there, I wouldn’t accidentally implement deadlines – I would very deliberately encourage setting goals. Which is where we ended up… eventually. Aside from that small SNAFU, this became a useful enough process that we repeat it every other month as an internal post we call “The State of All the Things”. The timeframes in the first one were very wrong. The second one – also very wrong. But over time, they’ve gotten less wrong. They allow us to see how we’re doing relative to where we thought we would be. As we no longer do lone wolf projects (we theme work so that everyone can be part of a “team”), it captures closer to the work of the entire team. They also provide a helpful high-level insight into what the team is doing that it’s easier for people outside the team to process. One of the things I find in a company that focuses very much on written communication is that it’s easy to communicate an overwhelming volume of low-value information. Selectively communicating a smaller amount of high-value information goes a long way. If someone really wanted to find out the state of one of our projects, they could using other means – but this is where the high level summary is. It moves the bar on finding that information from “dedicated investigator” to “passive interest”. For each project we include:
- If it’s shipped, that goes in the title (along with the launch post link).
- Who is the DRI? For the overall project, and for design.
- What are we doing and why are we doing it?
- What have we accomplished?
- What does “done” look like and where are we tracking what’s required to get there?
- When do we expect to be done?
- How are we doing relative to our expectations last time?
As a note on trust and accountability – it’s scary to admit that things aren’t going to plan, but when you’re up front about the ways in which that’s the case, people have much more faith in you to fix them, than when they find out by other means.
September 21, 2017
Things to Figure Out as a New Manager: Part 1, Your Schedule
Credit: Flickr / Maythee Anegboonlap

We normally talk about the challenge of moving to a manager’s schedule in terms of our desire to write code. But writing code is just part of it. As an IC, you probably had some kind of schedule that worked well for you. When we move to being managers, it’s tempting to try and slot “management stuff” into that schedule.

This generally doesn’t work that well. It can work, if you have a small team, with no major problems, and a clear roadmap. Otherwise, it’s probably going to fall to bits.

Small Team

It seems obvious that a larger team is more work than a smaller team, although this is not always the case because of other variables like organization, and team challenges. But we can break the major team time commitments down into two pieces – managerial, and person.

Managerial Overhead

This is the “stuff” you need to do now you’re a manager. Manager meetings (what happens in these? You finally get to find out). Process stuff. This differs everywhere, but in general there is some stuff you now need to attend to that you never used to worry about as an IC. Usually this involves some amount of meetings, and some amount of non-meeting work. This is the stuff more like a “fixed cost” in economics – it doesn’t change that much with the size of your team.

Person Overhead

This is the per-person responsibilities. Obviously, 1:1s are a huge part of this. Performance Reviews (whenever they happen) will devour huge amounts of your time. Then there are things like vacation entitlements and expense reports.

People have a tendency to capture this by time in 1:1s, but it’s not just time in meetings – it’s also time preparing and following up.

This is more like a “variable” cost in economics. As you add one more person to your team, how much more time a week do you spend on them? Newer people, and more junior people will tend to need more of your time.

No Major Problems

As a manager, it’s your job to fix the problems on your team, and at least mitigate the problems created in the wider organization. Three examples: re-orgs, performance, and conflict.

Re-orgs

There are logistical problems caused by re-orgs – your team is different and now you have to get to know people again! Your mandate has changed and you need to make sure your work is aligned with it.

But there are also people problems caused by re-orgs. Even the best organized and well communicated re-org does not leave everyone happy. ICs may not have insight into what caused the need for the re-org – why that director left, or what challenges exactly the organization is re-aligning itself to face.

And we all know that many re-orgs are neither well organized nor well communicated. At The Conglomerate they used to re-org every year. Many people who I knew there (including myself) have something that is best described as “re-org trauma”.

Re-orgs make people panic. They deliberately create change – which creates uncertainty. Even if people don’t leave because of it (which they often do), trying to create some kind of semblance of order and stability on your team will take a while. And when people leave, you have to deal with that as well.

Performance

Performance problems take a huge amount of time to manage. Biggest is the time you spend figuring out expectations, setting clear expectations, communicating those expectations, and then evaluating the person against those expectations.

You’ll also have to consider this when you plan, when you communicate what the team is doing. And you’ll have to deal with the people who notice what’s happening, without actually admitting what is happening and why.

Unless you’re some kind of monster, you’ll probably spend a lot of time feeling terrible and uncertain, too.

Conflict

Well-managed conflict will make your team better. Conflict arises because people feel strongly about things and disagree. This is great! People feel strongly about things! They have different perspectives!

This is also exhausting.

You’ll need to spend time with each person, understand where they are coming from and why, ask them questions that challenge their thinking, and lay some groundwork for them to listen to each other. You probably also want to be present to moderate the discussion and make sure it’s productive.

Also, pro-tip: if you have conflict on an engineering team, one of the first places it will show up is in code reviews. Especially with quiet conflicts that went on without blowing up and haven’t been resolved, or aren’t fully resolved yet, you can expect to spend a lot of time on code review – making sure they are done promptly, respectfully, and thoroughly. You may also need to spend time educating people on what good code review looks like, and modelling that behavior yourself.

A Clear Roadmap

If your team has a clear mandate, and a thorough PM, you’ll have a nice roadmap that they ask you for feedback on when they need it. You’ll give that feedback, highlight things that seem like a lot of work for little gain, do some sprint planning, maybe run regular retrospectives depending on how Agile you are.

If you don’t have a clear roadmap, expect this to dominate your working (and waking) thoughts.

What are People Doing Now?

If you don’t have a clear roadmap, and that’s not because you randomly had a surprise re-org yesterday, there’s a good chance that what people are working on now is uncertain and undefined. Hopefully people are working on important things, but are they working on the most important things? Do they know what the important things are, or are they drifting?

Before you figure out where to go next, you’ll need to figure out where you are now. Starting with the big, multi-month multi-engineer projects.

What are People Doing Next?

Is there stuff already scheduled? Is there stuff already promised to users or other parts of the organization? Are there things, or parts of things owned by your team that are on fire?

What Could We be Doing as a Team?

This is the endless list in the backlog or the ideas that people generate. But most important is to filter it by asking the next question:

What Should We be Doing?

What are the big opportunities that could potentially drive growth? How do we measure the potential? How do we break it down and measure progress – what metrics do we measure against?

Where’s the Organization Going?

It’s always important to stay tuned into the wider organization and be aware of decisions and projects that might impact your team. But when the roadmap is less clear this is especially important and liable to take more time. If your team doesn’t have a sense of where you’re going, it’s unlikely anyone else does either, and so you’ll need to look out for implicit expectations, and decisions made without you.

Rebuilding Your Schedule
- Figure out your external commitments: what meetings do you need to attend?
- Schedule your internal commitments: team-meetings, and 1:1s.
  - Scheduling 1:1s all on the same day can be really helpful for noticing patterns, and avoiding context switching.
  - Make sure you pick a good day – e.g. if you always cut a build on Thursdays, Wednesdays and Thursdays are probably not good days for 1:1s. Friday would be better.
  - With 1:1s (well, with everything, but let’s start with 1:1s) the goal is to be effective rather than efficient. It can seem efficient to schedule all your 1:1s back to back, but it’s rarely effective. Either schedule more time than you need, or add breaks after each one. This gives you time to get more tea (or coffee!), write up your notes, deal with quick things.
- Figure out your priorities.
  - You might not be able to work on the “most important” thing immediately – either because you need to address:
    
    Something more immediate.
    
    Ground work for the most important thing.
    
    Something that will build credibility to enable the most important thing.
  - I like to chose a “theme” for each week. At the end of the week, I measure myself by the progress on that theme.
- Figure out your tasks.
  - What needs to be done today? This week?
  - The kind of system that worked for me as an IC does not work for me as a manager.
This is part 1 of a series aimed at new engineering managers. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.
January 5, 2017
The Kill List

Nearly a year ago now, I took myself off to Paris. I wanted to see the Eiffel tower, practise my French, and go for long walks in the crisp cold and contemplate.

Starting work again after a year as an international fuckwit of no fixed address, one thing on my mind a lot was time. At the start of my year of adventures, I’d felt this incredible feeling of time abundance. I felt like I could do everything I wanted to do, take every opportunity, catch every plane.

I was wrong.

I learned a lot in that year, but one lesson I took with me and still think about often is that even if you have complete control over your schedule, there are still a finite number of hours in the day. You would think that I could have learned that by looking at a calendar. And yet, I had not. It’s easy to think that if only you didn’t have to work that pesky full time job, you could do everything you imagine. I had proved – conclusively – that I (at least) could not.

You have to choose.

I had to make better choices.

There’s a category of unflattering requests, that I at least, have found easy to ignore and delete. People who misspell my name – it’s four letters, hit delete. Token women requests – negotiation practise. Bad requests for mentoring, I got more strict on. Corporate feminism – nope.

I started a new project this year. I killed something to make way for it, and I applied to it everything I knew about making projects sustainable. It’s been a successful project by any measure – the sustained execution, the achieving of the goals I had in mind for it, a random amazing surprises (including my current job). That thinking drove me to choose the chose the word “scale” for 2016 and create a text document called “The Kill List”.

At first I gleefully added things I killed or said no to, and then I stopped remembering to update it. I kept saying no though. About a month ago, I found it again and realised I had many more things to add. I killed the things I had finished learning from, and I said no to things that I didn’t think were the best use of my time.

As the year ends, I’m inclined to berate myself for all the things I didn’t achieve. But I look at that text document, and see a list of things that I stopped doing, or never started. And I’m grateful for the space I created, and the stress I saved myself. I’m glad that I made active choices to do, or not do, instead of drifting. I’m determined to keep doing that in 2017.

December 22, 2016
How I Run a Remote Team
Credit: Pixabay / IraEm

Processes:
- Daily 123 in slack: 1 – what definitely will happen today, 2 – what will hopefully happen, 3 – what I’m filling in the gaps with.
- Daily standup: this is separate from 123, which I find is a better way to share?what. Standup is a little more about?how.
- Pairing: this just means “working together on something”*. Talking about the plan before writing code, explaining some piece of non-code work. Screenshare liberally, and often.
- Weekly build to QA. This is the best way I know to measure concrete progress – what’s in the release notes? What’s better than last week? It’s easy to have a performance of progress, where a lot of code is written but few features are completed and few bugs are fixed. Pushing something out every week mitigates this.
SLAs:
- PR-review. My desired SLA is that I look at every PR once. In practise, I fall short of this goal.
- Every engineer submits a PR every day. It doesn’t have to be big, but if days go by with no PRs it can be a sign that someone is overwhelmed or has a task that should be broken down.
- Speak to every engineer on the team 1:1, every day. This can be the equivalent of “hi” as you pass each other by in an open office. Or it can lead to a longer conversation.
Warm and Fuzzy and Hard to Measure
- Engineers who report to me will give me feedback. On PRs, on planning, on processes.
- Engineers who report to me will tell me things. This is a sign of trust that they think things will be better for me knowing about them.
- I can tell if someone is bothered by something and ask the right questions to draw them out.
As in all things I write about management, there is very little evidence I have any idea what I’m doing. As in all things I write about processes, this is what I aim to live up to.

* My initial reaction to “let’s pair” was “is this where you watch me code and judge me?” Much gratitude to the engineer on my team who taught me that is not the case.
May 12, 2016
Being Productive Offline
Rescue Time score from my flight

Normally I embrace flights as a chance to generally disconnect (who else is unenthused about in-flight wifi? Holla!). I read, sometimes I write, but I’m not too concerned about “achieving things”. Sometimes I try to find something to work on offline, typically at the last minute in the lounge and it’s not been very successful.

This last trip though… with so much going on and an 11 hour flight in business class (my travel agent got me a deal – yay!) I saw it as a chance to do some Real Work whilst disconnected.

One thing I think we lose by living “in the cloud” is that our computers have become portals to other people’s data centres and without internet much of what we do day to day doesn’t work. So it’s important to be organised.

I finally figured out how to be effective offline.
- In the week or so leading up to it, I started tagging things in my trello board with a label to mean that this could be done offline.
- I organised my Google Drive, made sure things were shared with the right account (offline multi-account support is lacking) and sync’d the folders that I needed to my computer.
- I don’t entirely trust Google Drive to work offline so I also downloaded reference things as a pdf as a backup (turns out: good decision).
- The day before I went through my “offline” tagged things and moved them to a plain text document (Trello offline support is sketchy).
- I collected things I needed (e.g. blog posts I’d written that I was building a talk from) with the list or in another plain text document.
- I made sure my GitHub repos were sync’d to my laptop.
When I got on the plane I was good to go! Key things that made a difference:
- I had a choice of things to do. Because I’d been organised I had around 5 significant projects to work on. I got through two. Turns out I was in the mood for refactoring, so I got through a bunch of coding tasks on Show and Hide, and then refreshed the slide deck for our workshop.
- I’d identified a bunch of coding stuff that was really straight forward where I wouldn’t need to look things up.
- I’m not usually a fan of “work on what I feel like” but having not had a huge amount of sleep, it was nice to take on a task that didn’t require me to be creative.
- Noise cancelling headphones. I love these Bose ones (Amazon), but they are pricy.
- Not gonna lie, being in business class. I had a little nap, and some delicious food, then feeling refreshed, I got to work.
Afterwards:
- The slide deck I put in the Google Drive folder, the next time I connected it sync’d to the cloud and Chiu-Ki could see it. No need to remember anything!
- Code was a little tricker. I’d done a significant refactoring and branches had built on each other. I kept a list of what order they were in, and then spent around an hour creating and reviewing my own pull requests early the next morning (yay early morning jet lag productivity).
- I caught up Trello on what I’d got done.
- Because I had prepped more stuff than I had got through I am covered for a bunch more time offline! A lot of it falls under important but not urgent and it’s nice to have time to focus there. My next long-ish flight, I picked up where I left off and made some more progress.
August 28, 2015
Structure, Meetings and Other People
Credit: PIxabay / geralt

When I started on this self-employed adventure, I had no structure. This was the first adjustment. I allowed myself to be distracted by potential projects, pitching things, doing unpaid work in the hope that it would pay off (it didn’t). Over time I created habits for myself, drew boundaries, evolved to this 5 days on / 1 day off which I have found works really well for me.

But projects started to come in, and my work started to change. I’ve had periods that were very busy with client work and heavily scheduled (e.g. at the start of May I was doing so many technical interviews). This past week I had:
- 1 technical phone screen
- 2 calls about a panel I’m moderating (+1 no show that I had to reschedule).
- 1 meeting about project A
- 3 daily standups about project D, plus two in-depth planning meetings and another people management meeting.
- 2 hours in-person work with admin (she finished the rest at home).
- Real-time work and back and forth with UX designer about the UI refresh.
The other thing that has changed is: I have more deadlines in my life. Right now there’s a list of things that I need to finish before I leave on Thursday that makes me want to panic. Instead I spent the last hour working (inefficiently) on something that has a deadline of the following Tuesday. I’m not sure if I’ve been engaging in structured procrastination, indulging my need to feel in control of something (anything!), or just having a normal approach to a Sunday morning.

There’s good things about this, not least of which: feeling overbooked means that I don’t chase work anymore. (I hated this, and also spent too long on back and forth that would go nowhere.)

I also feel more effective, but this isn’t the same as being more effective. I can point to a list of things that I did last week, but I see value in execution not in ideas (or meetings!). So I look at the list and see “oh that was a busy week I got stuff done” and then rationally think “did I really?” – how much of that will matter a week from now, a month from now, a year from now?

Maybe none of it.

Some Observations

Having say, 40-60% of my time structured has in fact meant that 100% of my time needs to be structured (and resulted in me needing to devote some time to getting organised). My day for my own projects has to be planned better and ruthlessly protected, because otherwise nothing happens. Similarly my day off comes with a list of goals because having more constraints around my time means that running the odd errand needs to be planned and can’t just be taken care of when I’m feeling like a break anyway.

I mainly feel the loss of large blocks of time. Tracking small things that can be taken care of in small gaps helps but isn’t a panacea because most small things in practise fall into categories of unimportant things that shouldn’t be done at all and things taking <5 minutes that should be done when you think of them.

It’s possible to carve out time for things that I want a day for. I’ve found it close to impossible to carve out time for things that I want more than a day for.

I am so focused on checking things of The List that I don’t make time for those things that are unknown.

Planning has become more natural to me. I have an all day flight next Friday and I already assembled a list of what I need to be able to work offline during it.
August 10, 2015
Organising Things

Credit: Flickr / quailwood

I have finally figured out how to make Trello work for me. I found having a board for each project overwhelming, and the items in cards too heavyweight. Often a reasonably sized task have a bunch of subtasks, and I might not manage to do them all at once.

1. Check Lists

I use these for task-specific TODO lists. For example “talk at X” will have a checklist of everything I need to do – abstract, bio, travel, all the way to filing the expense report.

2. Templates

For things that reoccur a lot I have a card with a checklist that I can copy – for example new trip cards, or talks all have a pretty standard list of things to do (you can copy list from other things, but I like having a generic one I can copy and customise).

3. Project Lists

I keep multiple projects within a board. Each project has it’s own list. And then I have a “done” list which I mark with a month (useful for updating this document), and can archive it when the next month begins – balancing the fact that I don’t want my completed tasks hanging around forever, with my need to feel like I’ve done something.

4. Current / Future / Low Priority

I have limited myself to three boards. The first: current priorities. This is the one I look at first, and where the bulk of my day (that isn’t already organised on a client board) should be spent.

Future priorities holds half baked ideas, projects that have been set aside for now. Anything that I shouldn’t be worrying about this month.

Low priority is all the bits and pieces that can fill up your task list but provide very little ROI. Blog ideas go here, trips I’m planning, talk ideas that I could flesh out and submit, projects that are ticking along but aren’t really under active development. These are the things that will never be a “true” priority but I want to keep track of.

5. Dates and Labels

Where applicable I add a date (e.g. a talk happens on a specific date), and use color-coded labels to indicate things like: has dependency on [person].

Downsides

The downside of this approach is that I’m not comfortable sharing these boards with people. Current priorities captures financial TODOs, and I don’t really want to share the whole board with people I work with on specific projects in order for them to see that list.

I figure these downsides are worth it. I want to capture the things that I own on these boards (which as someone who is self-employed ends up being everything). It’s more of a dashboard for the state of things than a project management system. But that’s fine.

July 31, 2015