Accidentally in Code

Tag: learning

Understanding the Game

Credit: Unsplash / hpzworkz

I used to panic when someone asked me what I thought about an acquisition. I had vague opinions, weakly held, because I didn’t know enough to reason about it. My opinions were about the product and the team. Knowing that most acquisitions fail to deliver their value (and having seen a couple up close) the idea of justifying an acquisition as a good idea was inconceivable to me.

This gap was a product of both the kind of work I’ve done and the environments I’ve worked in. I’ve never managed a budget. I’ve never been in a “monthly business review”. I decided it was more than time to fill it, and so once I had more time on my hands, I registered for the LSE MBA Essentials course.

I had wanted to do this for a year, but my last job wouldn’t pay for it. It was hard to allocate several thousand euro when I had just given up a regular salary, but I really believed it was the next thing for me to learn, and I finally had time. It was good timing beyond that – leaving a “normal” job for the unknown is scary, and having a structure where whatever else was happening, I was at least learning, was good for me. It was relentless, and it was hard – one weekend in Prague giving a talk had me paying for it for weeks – so I’m really glad I didn’t try to do it on top of a more than full time job that didn’t support it. But it gave me a structure and sense of accomplishment that was good for me.

The Limit of Reading Books

I did the altMBA back in 2017. It was a writing-and-reflection course more than a business one – writing prompts, feedback from your cohort three times a week, and a reflection script after each one. The most useful part, I decided afterwards, was the reflecting, and it was useful independent of whether the feedback was any good. The value was in the process. My goal going in was vague on purpose – get better at product, get better at carving out strategic time – the whole point was exposing myself to things I didn’t know I didn’t know.

There’s an idea that if you read enough of the right books you can replace an MBA – this is the foundation of the altMBA. It deliberately and explicitly avoided accounting, finance, and operations. Perhaps it’s not surprising that was the gap that remained.

MBA Essentials was the opposite course. A specific gap, a subject with right answers, and feedback from people who knew them. I don’t think you can really read your way into understanding the financial apparatus, but what would I know, I was too intimidated to understand even the financial reports from my own Ltd company in depth.

The Diff

Finally, I understand how acquisitions get reasoned about. An acquisition isn’t priced on what something earns now. It’s a question about future cash flows and when they arrive, discounted back to today. It’s a way to reason about money and opportunity cost, a fundamentally different way of thinking about it than “what does this group of people and product add, and what does it cost to make that work?”

Now the justifications made sense, as did the only one I thought was a good idea not going anywhere. I saw this with other bits of financial stuff that had gone by – repeatedly, I found myself seeing the number on the P&L that seemingly random or arbitrary decisions had contributed to.

I learned to read a company report. 100+ pages? Where to begin. I stuck it in Claude and started querying it. I finally know what kind of questions to ask in order to get under the overarching narrative to what lies underneath. Everything is (or should be) in a company report, but not everything makes the index page or letters from the CEO or Chair of the board. Those letters tell you what they think you should pay attention to. The numbers themselves can help you form your own opinion of how true that is.

One concrete takeaway: I built a break-even model for DRI Your Career. Which is helping us reason about how we’re doing, model partnerships, payback periods for course development. I find it incredibly useful.

These things matter more than the grade, but I did score in the high nineties. Possibly a function of me working too hard to prove something and being too in need of validation. But usefully, there was an assignment where I didn’t get full marks. I’d worked hard on it, I’d committed to one reading of an ambiguous figure, and I was wrong. There’s value to that – I won’t make that mistake again.

Capitalism from the inside

Everyone who knows me knows I’m mad about capitalism, so perhaps it’s strange that I wanted to do this so much. It was jarring, to see something I dislike from the inside. But I always think there’s a distinction between playing the game that’s on, and making a new one. Here I wanted to understand the game that’s on better. And I do.

Some of the negotiation and power material. There’s a technique where you commit to a supplier up front and pay them below market, and the justification offered is that they “know what they’re getting” – certainty in exchange for money. It’s a way of using a stronger position to pay less.

Uber, taught as a triumph of the platform model. The innovation, substantially, is that the costs and the risk were pushed onto the workers – classified as contractors, in some places now ruled illegal.

I did economics at A level, and there I enjoyed the cleanliness of the model. But having been out in the world for a while since, it was both familiar and jarring: market forces get taught like physics. As if they were discovered rather than designed, natural laws with no politics in them. They’re not. And the models assume people are rational, which they are demonstrably not.

Now what?

I’m glad I did it. It filled the gap I’d identified, and gave me the structure I needed at that time. Deadlines, concrete wins, the feeling of making progress on something that mattered to me. Part of me wants to keep going, part of me wants to focus less on the theory and more on the reality of building a business.

I wasn’t sure how much of this was about learning and how much was about confidence. Having finished, I think the answer is both, and that’s healthy. My instincts weren’t bad or wrong, but they were incomplete and at times misdirected. Now I understand the framework better.

June 30, 2026
The Value of Getting Closer to the Work

Scaling

The core problem of scaling a team is that not everyone can know everything. Scaling is the work of systematizing that – so that things are understandable, knowable. It’s turning “tribal knowledge” into documentation, automation, and process. It used to be that only the automation was for the machine, but now documentation is machine critical and process is machine readable.

With humans, things bubble up and down. You don’t – in general – make systematic fixes for the first complaint. First you validate, check the scale of the issue. You try the softer interventions – trying to get people to actually talk to their team mates – before you start building process. Maybe you make a change a month to the way a team works. Carefully, thoughtfully. Because no effective person wants to be on a team where the job seems more process than impact.

Automation was always the most effective, but also usually the most expensive. The thing that gets put in when “please follow this checklist” fails frequently and severely enough to be worthwhile. An incident can be the gift that delivers the agreement on priority that always seemed necessary to those close enough to it, by making the cost of not doing it clear.

As we are deep in replatforming Twill, I’m back to being a developer, and as I operated my orchestrator and dispatched agents on the backlog, even though in some ways everything is wildly different, some parts of it that I reached for out of habit felt very familiar: scaling.

+AI

AI feels like speed-running some of the team scaling stuff that previously I orchestrated over months – years even. The economics have shifted to make automation much cheaper, so it’s no longer deferred, but top of the list.

With people, knowledge lives in two places – in the people and in the systems. With AI, only the systems part persists. Every session starts contextless. This is the problem that surfaces all the documentation that wasn’t written, and all the automation that was never built – a core part of why building with AI from scratch is so much easier than retrofitting onto an existing setup.

On DRI, when Jean started building the platform, we talked affectionately about “intern Claude”. Over time, we matured away from that framing. We put the guardrails in. We stopped treating it as a novelty to be supervised and started treating it as a system to be designed. With Twill, I started from a higher level of understanding, and the baseline was higher.

The snark, which I’ve also expressed: people will do for a machine what they were never willing to do for their team. Write the doc. Define the work clearly. Build the guardrail. Forgive the mistake.

I stand by it. But that doesn’t mean those of us who were always trying to do this for humans gain some moral high ground by not doing this for machines.

The rigour was always good practice. The humans operating the machine will have a much better time if those machines are set up to succeed. I think the call for EMs to “get closer to the work” has been poorly expressed and executed, but at the core of it – having got much closer to the work myself – I have come to see the validity of it. The scaling problem that managers used to deal with is now happening at higher speed, and the only way to have fidelity on it is to understand the work being done. Because so far, there is no playbook – we all have to write our own.

The best example of this is CLAUDE.md. For both DRI and Twill, it’s a living team artifact, and the churn on it is a good thing – the way of working should keep evolving, as we evolve our understanding, our work, our effectiveness.

Three terminals

“Dispatch a review agent” was encoded in our process for months. It’s very helpful. But I would still find the odd issue or untracked follow up. Then, tired of Claudes colliding on CI and wasting build minutes, I made a merge queue. It serialises merges across concurrent sessions, files the follow-ups, and sends PRs back when they’re not ready.

The next round of reviews I dispatched came back clean. And the next. And the next.

Turns out merge queue Claude, reviewing work it had no part in, was stricter than the Claudes that had done the work.

The reason is the contextlessness. Which gets talked about like a strength or a weakness as we look for metaphors about working with this thing that is new and we don’t yet fully understand. I’ve given up on metaphors, and think this aspect, like this shift in general, is best treated as a neutral.

The reviewer had no investment in the work. Nothing to rationalise. No “well, I did it that way because.” It knew only what the standard said and whether the code met it.

So many times, after reading a review or finding something that didn’t work as I expected it to, I’ve thought that something should be already prevented by CLAUDE.md and asked why it wasn’t. The answer was always clarity – fair. But turns out, like humans, the answer could also be process.

The common manager refrain on AI is that it separates those who think from those who don’t. Fair. But one of the core skills you have to develop in leadership is knowing what to pay attention to and what can be ignored. The broader your scope, the more you need to be brutal.

How many times have I told someone “that’s not making it onto my list”? Too many to count. Enough that people have been known to text me when they find themselves saying it. Now, having so many things in flight at once, I’m always trying to figure out what to pay attention to and what not.

The mechanical guardrail is encoded in CLAUDE.md: hit the same issue twice, stop. A lesson learned the hard way after burning a bunch of build minutes on something stupid, because it only got intermittent attention and seemed like it should be fine. It’s inclined to keep pushing through, but telling it to stop also tells me to stop, to give that problem some attention, to think.

Before, the discipline was: you found a bug, you wrote a test so it wouldn’t come back. Good practice. Now, I do that, and then I ask: how do we guard against this class of problem?

Competent humans rarely make the same mistake twice. AI will make the same mistake endlessly.

Making a class of issue impossible is not cheap. This is why we didn’t use to do it. A minor bug spawns five-plus follow-ups – graduated solutions of increasing complexity. A null-handling issue that threw 500s; fixed in one PR, but the follow up issues to eliminate the pattern and add a tripwire in CI so it can’t come back got added to the backlog, ready to be picked up, implemented by the orchestrator as a slot becomes free. Done within the week. Because now it’s possible. It’s tractable: it’s bounded, well-defined work, which makes it exactly the kind of thing you can hand to an orchestrator and let run in parallel.

I keep reading all this stuff about “working with AI” and it’s so depressing that most of it seems to be about building things that run AI agents. What’s the point of it? What are you actually shipping? Is this just some game, like The Sims: But Make It Programming (and also really expensive)?

Cranking through a bunch of stuff to launch, I’m running Claude in three tabs. The first is an orchestrator. The second is the merge queue.

The third is the terminal where I actually define, decide, and unblock things. The most important one. In this one sometimes I feel like a product manager, sometimes an engineering manager, sometimes an architect. Sometimes I’m just wiring up secrets and things, feeling like some modern day version of the ENIAC women who used cables and switches. At least I get a manual.

Scaling a team, you keep coming back to the same need: be clearer. Clearer about what’s expected, who owns what, what good looks like. Clarity. Clarity. Clarity.

The work of the third terminal. Clarity.

The tools have changed. The work is the same.

June 23, 2026
A Season of Learning

Credit: Unsplash / Patty Spahr

There’s a concept in computer science called explore vs. exploit. Exploitation means using what you know to get reliable returns; exploration means trying new things at the cost of those returns. Most algorithms skew too hard toward exploit. Humans have also been known to do this – including me. The known path is comfortable.

My last job, I was deep in exploit mode. I had playbooks. I refined them. I ran them. I wrote them up into a book. But often I worried I wasn’t growing. Part of why I left – and chose the particular shape of what came next – was to return to a place of genuine learning. I had enough concreteness that I could exploit, but also space to explore.

So what does that actually look like? A few things I’ve been in the middle of this season:

Formal learning. I’m currently enrolled in LSE’s MBA Essentials Course. I’ve long felt under-equipped on business fundamentals. Every time I was asked for an opinion on an acquisition, I would panic that I didn’t know how to reason about it. Structured training has been helpful for me to prioritize time for learning – I did the Co-Active coaching training a few years ago, but that was immersive; a few days I could slot in when it made sense. MBA essentials is 8-10 hours a week for 10 weeks and that felt like a different ask entirely – not one I felt up for adding onto a more than full time job without organizational support. Prioritizing it for myself, finally filling in a gap I’ve known about for years, feels good. Some combination of learning and building confidence – I’m not sure how much of which yet – but so far, it’s interesting.

Getting back to the work. As you get up the org chart the job stops being the work and starts being the work that makes the work happen. It’s necessary and done right it’s impactful and I do enjoy it, but I missed the feeling of actually building. For the past few months I’ve been back to the code again, building tools, co-building a course platform – I pushed a fix to production this morning! In a time of huge change, being closer to the work feels important. I want to understand this shift deeply because it will be affecting our whole industry for some time to come.

Deep collaboration. The best periods of my career have always featured a great collaboration. But the higher up you go, the lonelier it gets. Coming back to a real, balanced, give and take collaboration feels like a glass of cold water on a hot day. I love it. We negotiate to our strengths, balance getting stuff done with having fun. I also learn a surprising amount just from being close to another person’s workflow.

Fractional CTO work. This is a different kind of leadership than I’ve done before. In some ways it’s like running a large org – you have to be deliberate about your time because it’s limited. The strategic work (my favourite) is more visible when every decision counts and resources are limited. In other ways it’s very different – more hands-on with the actual infrastructure decisions, closer to an IT function than I’ve ever been (not a strength for me, I’m working on it).

Social media. For me, Twitter was everything in one place – community, self-promotion, ambient industry conversation – not that I had to be so clear about that. It worked so well for me and I missed it for a long time, without doing anything about figuring out how to fill the holes it left. I miss the community most, and I’m slowly trying to find it again. Given everything I’m doing, I need to figure out self promotion that doesn’t give me the ick.

AI workflows. Having space to actually play with this – without the constraints and overhead of an organization – has been revelatory. What works, what doesn’t, where it helps and where it’s just noise. The context matters enormously for perceived impact: if you use AI to do a mid version of someone else’s job inside an org, it’s insulting and will cost you in credibility. If you use it to do a mid version of something you otherwise couldn’t do at all, it gets something done and helps you learn. Jean and I are building a course platform, running cohorts, developing new material… with plenty of other things going on for both of us. We’ve used AI to create efficiency and leverage, to build something we couldn’t otherwise have built, while retaining the time and attention to make sure the pieces that should be human are.

I do really love running bigger teams. But you end up constrained – by org structure, by politics, by the cost of starting anything new, the difficulty of changing direction when you’re already moving, the morale hit of killing something even when it’s the right call. In a time of this much change, the number of people becomes its own constraint; change management could easily be the whole job right now, and not an enjoyable one.

It’s good to be free for a while. A hill-climbing algorithm will always find a peak – but it might not be the highest one. Sometimes you have to go down before you can go higher. I don’t think careers have to go up and to the right, and this season is making that clearer every day.

If everything is changing, you may as well choose the change you want.

March 31, 2026
From Chaotic Learning to Intentional Growth
Credit: Brett Jordan / Pexels

Before the pandemic I was always on the move, and I would have told you always learning. I found myself at various events, talked to many different people, was always reading something, and my job changed frequently, even within the organisation I was in. I also wrote a lot, which helped me consolidate and clarify my thinking.

Then, the pandemic. Everything came to a halt and that included my own learning… I no longer had the breadth of experiences that made me feel like I was learning constantly, and some days I barely felt I could write a text message, let alone anything else.

At some point, I realised that I was stagnating – that I was executing a familiar playbook, and couldn’t list anything that I had learned recently – and tired of it. That I wanted to feel like I was learning and growing again, but that I would need to find a different way. The world had changed. My job had changed. I had changed.

It took some time and experimentation, but eventually I shifted to a more deliberate, outcome driven approach. This looked like:
- Signing up and paying for specific courses (like CoActive coach and leadership trainings), and blocking out the time to learn.
- Shifting away from habits and to more outcome driven personal projects (this was the difference between writing a book and blogging every week).
- Rethinking my organisational systems to be more goal oriented (my Trello board is now oriented around outcomes rather than habits).
Basically I stopped managing my learning the way I manage my fitness (a blend of habits and whims, which mostly works, but probably only because I genuinely enjoy working out) and started managing it how I would manage a large project. Identifying high level goals, defining supporting strategy, and then using that to confirm or deny. Less visible activity, but more outcomes. Less validation, more meaning.

I think prioritising professional dev is often hard because it’s IC work on top of your existing job, that you have to fit into your schedule. It’s also often a shift in mindset – from meetings to doing, or from coding to writing… The most important learning is important but not urgent, which means it can always be put off until tomorrow when you will have more energy – even if you know that’s not really true.

It’s much easier to just do things you’re committed to (aka conference talk driven development) and/or what you want and argue that something is better than nothing. Something probably is better than nothing, but it doesn’t mean your effort-impact actually makes sense. The less effort you have time or capacity to put in, the more the impact matters.

Essentially this change made me both the manager and the IC. Doesn’t everyone joke they are their own worst manager and difficult to manage IC? I am no different. Manager-Cate would set goals for Cate-the-IC that seemed like a cruel joke at the end of a long day or week. The only thing that I’ve found that helps (so far, suggestions welcome), is to split the activities:
- Carve out time to think deeply about what my next proximate objectives are (strategy). The end of year quiet and the year compass is a helpful exercise for this.
- With my manager hat on break down and prioritise the tasks.
- With my IC hat on, see what I can chip away at.
Do I feel like I have my professional dev on lock? No. There were things I wanted to do in 2025 that I didn’t figure out how to fit in. But at the same time, I can see that I accomplished more with this approach than I would have done without it. Such as:
- I read 12 non-fiction books this year.
- My Irish citizenship application is in (will give me freedom to work in the EU again).
- Jean and I shipped DRI your career.
December 30, 2025
Explore / Pursue / Depth
My friends and I went pottery painting recently. Next, we’re trying crotchet. The pottery painting was fun, and my star shaped bowl painted in rainbow colors came out better than I expected. I’m thinking to go back and paint a dragon next.

My friends and I, we’re exploring. Trying some new things. Seeing what we enjoy. No pressure to be good at it, or even do it a second time. It’s oddly liberating. I think this is good for me, because I get too focused on being good at things, which makes me too likely to stick to what I know, unwilling to branch out and explore.

It also reminds me of professional development. Sometimes I know what I’m trying to learn and how to do it – I’m pursuing it, in a depth mode. For example when I took the full co-active coaching training, or when I wrote the book.

Right now I’m in more of an exploratory mode. I have some broad themes that I’m interested in, but I’m not quite ready to commit to anything that big. I was inclined to be a little self-judgemental about that, like, I ‘should’ know and focus and achieve. But I’m trying instead to find the beauty of the exploration. The freedom to make small decisions, the lack of pressure when I can truly believe that it’s okay to be wrong, the joy of following my own curiosity, just because.

As a result I’m:
- Listening to wildly different podcasts (a history one!)
- Reading an interesting book with no real practical application
- Redoing a new version of a program I took before, and experiencing it very differently
- On a program committee for a conference I really like
- Planning on taking a course that feels wildly different from anything I’ve done in a long time
- Working on a fun / exploratory project with a friend
In an exploratory mode, I feel much less of a sense of progress, perhaps because it’s so much more chaotic than when I’m more focused on something specific. But I think maybe that’s part of what makes it good for me right now. Exploring is a more generative activity, as in, generating of ideas and perspectives. Depth is more of an exploitation of ideas and perspectives that are already there. Post writing a book – basically a packaging and exploitation of years of exploring – I really want to get back to a more generative space; and I’ve concluded that means I have to explore.

How about you? What have you been exploring lately, and what did you learn?
February 4, 2025
Co-Active: Synergy

The last course in my coach training journey – for now – was Synergy. This follows Fundamentals, Fulfillment, Balance, and Process.

The final course, this tied everything together. We learned about the attributes of a coach (fierce courage, aliveness, and connection), worked on range (including silent coaching!) and the idea of “stories”.

Going into it, I was focused on the finish line – this has been a significant undertaking, and I was excited to be “done”. The intention I set for the course was to stay present and “enjoy the last mile”. Mixed success here, 4.5 hours is a long time to be on Zoom, but at the end I felt somewhat bereft. Each course has created a small community, and this was the last one.

It has been quite a journey. I took fundamentals at the end of 2020, after wanting to take it since 2018-19. Spacing out the courses meant that most of my previous classmates had left me behind, although it was nice to reconnect from someone from Process and even another person who had been in my Fulfillment group! Most people get through the courses more quickly, but I’ve been glad to give things space. It makes each one very distinct for me, and that’s helped cement my understanding of the tools that get introduced each time.

I’m glad I chose to make time for it all, I got much more out of it overall than I was anticipating. It has fundamentally changed my thinking and how I approach things. Beyond the impact on me, it’s spread to my team. Four of my teammates have now taken Fundamentals! It’s been fascinating to see what they got out of it, and the overall impact on the team.

As for what’s next, despite the certificate, this still feels like very much the beginning. I continue to bring this mindset to my day job (where useful/appropriate) and the handful of external clients I work with. I continue to stay in touch with some of my classmates, which I love. Beyond that, I’m debating whether (and when) to go through the certification process, and other options for continued learning, but likely nothing more in 2022 as I want to focus on other things for a while.

So much gratitude to everyone who has supported me in this adventure.

February 21, 2022
Further Adventures in Android Development
Credit: Wikimedia

I suspect one of my limitations as a programmer is that I don’t hack. I don’t beat away at something until it works. I read things, and I reason about it, and I write a lot of tests.

This makes me very effective on platforms I’m familiar with, but I worry I’m as a result not as effective when I’m picking new things up as someone who will just hack away. I’m searching for the moment when things start to make sense.

I’ve done some Android over the past few years. I really wanted to learn it, but when I started working on it, it really wasn’t that fun. It was an over-engineered codebase, and as I tried to find my way in it, the feedback I got in code review was often of the “I would have done it differently” variety. Often that way didn’t even work, so that was… rewarding.

The first breakthrough was that a lot of stuff is just more work than iOS. For instance, if you want to take a photo on iOS you just like… launch the camera and implement the delegate.

If you want to take a photo on Android, you mount the hard drive, allocate space for the photo, launch the intent, and handle it returning. I always thought managing hardware and memory was a job for the Operating System, but what do I know about Operating System design, anyway.

Aside: as I learned this lesson one of the guys I worked with told me that I must be wrong about how annoying it is to take a photo on Android. Then – once I had got it working – sent me a code review of his from a previous project and said (I paraphrase) “that is the right way to do it actually, because that’s how I did it too”.

So I returned to Android this year with a degree of trepidation. I really wanted to be better at it, but based on what I’d learned so far about it, mainly I was happy in Java and I’d learned maybe how not to do some things, but as I’ve commented before, that doesn’t always teach you that much.

Last week was the ~2nd week this year where I was able to focus on Android and things finally started to click. It was so exciting, because now I feel like I can pick up small bugs here and there, whereas before I felt I needed minimum 2 days to make progress. It’s like going from navigating with a compass to having a compass AND a (slightly fuzzy) map.

The big thing that clicked was understanding the ways in which the platform encourages bad design.

On iOS, that thing is mixing View Code and Control Code. The more tools I add to my arsenal to handle that, the better architected my iOS apps became. There’s another area of mixing model and persistence code. Really on iOS the design problem is mixing things that would be better separated. Learn that, make an effort to keep things apart, and everything seems more possible.

On Android things are very separated. This is not a problem you run into. The view is defined in xml. Any background processing work needs to live in a “service”. In fact on Android separation of things goes so far the other way, that the problem is state. When you rotate your phone, the activity gets recreated. So if you have anything with state, you need to save that state. If you have anything that might be happening in the background, you need to handle getting the same service.

This means:
- I don’t even know how you would get a stateful Android app working without Dependency Injection (luckily I had Chiu-Ki to help me with this, because it’s tricky).
- This encourages the use of Singletons (ai!) because it’s an easy way to make sure you get the same service when the phone is rotated.
- Automated dependency injection is nice and good for testing, but it can allow you to have very complex object relationships. I don’t see it as some panacea for good design, more as a something that obfuscates bizarre things you have done.
This is an app I’ve been porting over from iOS and it’s fascinating to me what’s different. Some things were easier, and some things were harder. But, Android makes a lot more sense, and I got things working enough to send out a beta, so that is exciting.
November 25, 2015
Achieving the Quasi-Possible, Just About On Time

Credit: flickr / brunoccunha

This Thursday, it will be two months since I arrived in Sydney. I came to work on a specific project, and that project came with a pretty ambitious deadline. I don’t know if anyone, including the person who thought this deadline up, really believed we would make it. But we did, just about. We as a team, did. And that moment, where you can say, “yeah, did that” – pretty awesome. But there are moments that happen before that, where people start to look at what you’re doing, and say, “hey, you just might do that”, and those are pretty cool, too.

I ran this project. Which means if we didn’t make that deadline, it would be on me. Making it, well, good leaders give away credit and take blame. But I do get to feel satisfied. But the biggest thing I get to feel satisfied about, is that in the last two months, I have consistently worked around 40 hours a week. I have gone out, a lot, and found friends and things to do in Sydney. Got (kinda) settled in my apartment, even taken a day’s vacation. Worked out 4-5 times a week, and averaged 4.5k fuel points a day. My life is a little loopy, but it’s definitely diverse.

Extensive reading around personal development, and watching other people run things, and running my own, much smaller, things meant I had some ideas about Planning, Leadership, and keeping sane under pressure. So this is my three most important things in each area, most of which I tested by breaking at some point.

Software Development Planning In General

Eliminate your Known Unknowns

This is the most important thing. You have a feature set and a deadline, some things you know how to do, and some things you don’t.

The thing you don’t know how to do is the most important thing you need to do today. This unknown falls somewhere on the scale between being very easy, and being hard / time consuming / requiring someone else to change their thing / flat out impossible. The sooner you know what it is, the sooner you can adjust your estimates, or your features, to be more realistic.

Think Medium Term

I don’t hack. I worry, actually, that I literally can’t hack. I can’t fight with something, and be happy with a one line fix labelled “DO NOT TOUCH THIS”. I always need to understand why, and to rationalize why things interact, or work the way they do.

Hacking is short term thinking. I’m in a hurry, do this quickly, come back later. It borrows time from future-you, to save time today. But you don’t know when future-you is going to pay the bill. You might find it’s tomorrow (before you ship) – that’s the worst case. And hacks multiply, the more you have, the more expensive each one will be to fix, so here’s the next worst case, you ship something full of hacks, and now you can’t do anything interesting until you unravel them all.

The thing about long term thinking, is that the world is going to be different a year, hell, a month from now than it is today. Long term is an investment in the future, but you have no idea what the future is going to look like. Isn’t that one of the awesome things about working in tech? Everything changes, all the time.

Medium term is the balance, and I find when I think medium term I know what issues will result from that decision, and I know roughly when they will occur. Choosing X over Y will mean that we have to adjust some things, in a relatively minor way, if we do Z, but I’m confident Z won’t be on any of the next few iterations I’m OK with that, but document it somewhere.

Medium term is doing things that will get harder over time sooner rather than later. In this case, Y is a pain, but needs to happen for Z. If we do it now, it’s very easy, and has and intermittent slightly higher overhead for a while. If we wait, it becomes a huge problem that takes someone a long and miserable time to unravel.

Ruthlessly Prioritize

Feature creep is the biggest problem with tight deadlines, and the temptation is always to slip things in because “things are looking so good”.

But why are things looking so good? Because you eliminated so much of this stuff. Because you were ruthless in the first place.

UX wants the widget to slide in and out, but when they realize it is as much work some feature, maybe they will reconsider.

I think it’s pretty easy to eliminate the large things, if you are ruthless about it, you’re clear about how long things take, and your PM and UX people are realistic. The thing to watch here is the small things. I find these are the things that I could fix in an hour or less, and it’s tempting to just agree to them, because it wouldn’t take much more time to write the code than have the conversation – and coding is more fun than having meetings! But I think you get 4-6 hours of good coding a day. So 4 “little things” and you’ve just allocated most of your day away, and were these things the most important things you could be doing?

Maybe not.

Leadership

Give Away The Stuff You Know

It is super tempting to look at the list of things to do, identify the things that you know and could do quickly, and just get cracking on them. You’ll feel an awesome sense of accomplishment, you’ll make super fast progress, and then there will be barely anything left, so that won’t take long at all.

This is complete nonsense. Especially if you have new people who you don’t know. If you give them something you know, you can evaluate how they do it, provide guidance, easily conceptualize it in the bigger picture. If there’s an issue with it down the road, you’ll be able to fix it.

And, importantly, you can instead work on one of your Known Unknowns. And when you’ve figured that out, you give that away too, so you are continually at the boundary of what you know and what you need to do, figuring out how it all fits together. You have the big picture in your head, and enough detail on everything to dive into it at need. Maybe you don’t know anything the best, but you can rationalize about everything, and that is really, really useful.

One of the biggest mistakes I made, that came closest to causing us to miss the deadline, was that I gave away something I only 50% knew how to do. I missed something crucial, and it became an emergency as a result.

This isn’t about being a control freak, it is about you knowing enough about everything, even if there is nothing you know everything about.

Learn Your Superpowers

I learned one of my most important lessons about leadership from someone I worked with, not at the time, a year after the fact.

We worked at a camp, and she was the director. A year later she tells me, “I always used to show you the numbers of how many kids we had in each class, because you would just remember them”. And so she could ask me at any time and I would just know. I could also lay out the classrooms in my head at need.

This, to me, was completely normal, so it didn’t occur to me that not everyone would remember a list of numbers after seeing them. But my friend knew it wasn’t, so she used it to make her life easier, and I never even noticed her doing it.

I think people can be really bad at knowing what they are good at. They don’t always value or notice things that are so natural to them that they don’t realize they are doing them. The more you notice about it, the more you can give people the things that they are fantastic at. The person who has a really good eye for UI flow, and usability, they get that slightly un-specc’d feature. The person who is really stubborn and diligent gets that tedious problem that is going to take patience and bloody-mindedness, rather than a flash of brilliance to fix.

Create a Space

This is about balancing the desire and need to shield your team from the outer world – politics, negotiations, long term planning, and the need to situate what you’re doing in some wider coverage.

Too little shielding, and too many people are worrying about things they have no control over. Too much, and your decisions can seem arbitrary and unfounded.

Some things are “PM problems”. I can’t do anything about them, but I need to know the status of them. I stay out of them and try not to worry about them. I probably want to share that there is a PM problem, when it is clear that it is going to hold something up.

Eng problems I’ll share as they come up. Like, I know it seems like I’ve gone mad on test coverage, but this is coming from these directions and this is why it’s important. I know it’s frustrating that we are doing X, but there is this medium-term plan of doing Y, and investing in X now pays dividends then.

Personally

Don’t Miss What You’ll Resent

I took a day off to go skiing. I knew if I missed it, I would be sad and resentful that I didn’t ski during the winter here. So I went, and it really energized me. Those things if you miss out on, you’ll really miss, you don’t want to lose out on those. Your work is part of your life, it’s not something that should happen at the expense of it. And your life is not something you should put on hold for something that is not 100% under your control.

Don’t Borrow From Tomorrow

My theory of working late is that in the best case I borrow time from tomorrow, and in the worst, I do that and I break things, which I then also need to fix.

So when I feel like I’m done, I go home. I go home well before I start breaking things. One of the things I find as a result, is that I am consistently productive 5 days a week. There’s less of a range. In grad school, I had insanely productive days, and some which were just a write-off. There was so much variance, that it was really hard to know how much I could get done in a given week. Now I have a pretty good idea, and I have evenings and weekend to myself, both of which greatly improve my happiness.

It’s Not Just Hours, It’s Energy

Last Thursday night, my friend and I are in a cab headed out to a comedy show. We were running late, because we’d both been completely absorbed in what we were doing and hadn’t really considered how we were getting there, or even where we were going, and there was terrible traffic.

And we got there, and had a great time, but waiting in the traffic jam, I admit that I think Thursday nights should be reserved for the gym and mall food (the mall food here is delicious, and the mall is only open late on Thursdays).

My friend says “Yes! By Thursday, I have made so many decisions, that if I don’t recharge I have no decisions left for Friday”.

Even the “worst” weeks I had probably didn’t exceed 45 hours. The most stressful day I had, I finished working before 5. But that didn’t mean I had any emotional energy left when I left the office for the day. I was exhausted.

And it’s hard to go out with someone new, when there’s really only one thing on my mind and I just feel like I have no conversation. I have to make more time to do things that recharge me – reading novels, hanging out at the gym watching How I Met Your Mother. The morning after the most stressful day, I went in late because I felt compelled to spend 2.5 hours in the gym before I could face the next onslaught. The biggest challenge I’ve had, is feeling like because I leave the office by 6 I have the time and energy for daily early morning workouts and going out almost every night, and I just don’t. I’d sooner work out in the evening, because it decompresses and de-obsesses me before bed. I want 9 hours sleep when I’m stressed. And that’s OK.

September 25, 2012
Sharing Lessons From Stories We Can’t Tell

Credit: flickr / icedsoul photography .:teymur madjderey

Last week, I wrote that things have been a little bonkers lately. I have not spent seven days straight in Ottawa since the start of August and I’m stressed, discombobulated, and overwhelmed.

Normally, I figure things about by writing about them. Lots of work on? How can I be more organized/better at delegating/manage my time most effectively? Screwed something up? How can I do better next time? Working something out? What can I share as I go?

However, lately there’s been a number of things on my mind that I can’t write about – either because I’m not ready, or I don’t want to share someone else’s business, or because my writing about the situation would make something difficult and stressful worse. So the other day, Sacha and I had a long mentoring chat – which was great. I opened up about a bunch of things that had been bothering me and she was really helpful.

Something that we both touched on, though, was in these situations, you want to share what you’re learning but for whatever reason it’s hard. Sacha doesn’t publish everything she writes, but I don’t journal – I write to share. This is good because it motivates me to find a way to tell the story in such a way that I can share it, but in some situations that’s not possible – what then?

Perhaps we can share some high level observations, and the story – retell that later, when it’s less close to home. Here are some things I’ve been learning.

People will think what they want to think. If someone has made up their mind, it’s hard to change it. I’ve been in a situation lately where someone has made up their mind that I’m the bad guy and in doing so they’ve almost proved themselves right. I’ve been working very hard to be reasonable and not to react, but their determination that I must be against them means that anything I do – or don’t do – is inserted in the picture of “evil Cate”. I don’t understand why someone would live like that – it’s exhausting.

Don’t beat yourself up for your priorities at the time. I was stressing that I wasn’t living by my values – being truly “outside the box” (Leadership and Self-Deception, The Anatomy of Peace – both Amazon). Sacha asked me what more I could have done to make the situation better, and obviously some things sprang to mind – there’s always more you can do to make any situation better. However we talked about my priorities at the time where me doing something would have been helpful and I had more important things going on than this person’s drama. My priorities then have influenced this outcome – I can’t change that, and wouldn’t want to.

Other people have no concept of what your priorities are, or what your schedule looks like. One of my friends had been part of the situation and I was a little upset because I felt that he was buying into this person’s perception of me and my actions. Once we had a chance to talk and I had started explaining the separation between my actions as a facilitator and my personal views and he also realized just how much I’d had going on the last couple of months, his attitude changed and things are better between us now.

I’ve not been to the chiropractor since I got back from the UK because she will tell me I should come in 3 times a week and I just can’t do that when I’m flitting about so much! Meanwhile, Goodlife forced me to buy 60 training sessions and promised to sell any I had over because the assumption was that like other people I was exaggerating about how much I was flitting about. In fact, it ended up being an underestimate because new things came up and so I’m calling that promise in!

You can say “I haven’t spent seven straight days at home for the last two months”, but unless someone has/does live like that they have no clue what that means in terms of living. For me, going to the chiropractor is useful, but it’s not my number 1 priority. And when number 1 priority stuff isn’t happening, stuff that isn’t a number 1 priority sure isn’t.

Make a plan. Sacha quickly picked up on the fact that a big part of what was stressing me was the uncertainty. If X is happening, OK – I’ll take care of that. If Y – sure, I can work with that. Not knowing, though, is way more difficult.

So much of what we stress about doesn’t really matter. In the big picture, it doesn’t really matter if your sheets clash with your wall for a couple of weeks. A thesis is a big project – a couple of days in the midst of rushing probably won’t make a big difference. It’s sad that some friendships end, but hardly the end of the world. It’s horrible to be discussed behind your back, but the people who know who you really are won’t buy the stuff that isn’t true for more than a moment, if that. People disagree – and mostly we manage to rub along anyway.

And the final, biggest thing I’m realizing – you always think there is more time, until there is not. Are you living by your values, investing in the relationships that matter and living your life today? Because eventually, everything ends and everyone leaves. And the things we did not do… we better hope and work so that they are not the truly important things, that we never got around to making room for in our lives.

September 29, 2010