I thought carefully about the best and worst bits of my previous jobs to work out what I really love doing.
I find retrospectives really helpful to understand what teams are finding good and bad about their work.
Recently I indulged in a retrospective of my own, thinking about the best and worst bits from all my previous jobs as a way of understanding what I actually enjoy doing.
Even though nothing was really a surprise to me, I found it incredibly insightful and bizarrely I feel like I understand myself a little better.
It’s personal, but I’ve found it cathartic writing this up. It’s meant for my future self really, but if you’re interested, then please do go ahead and have a read. And perhaps it’ll help you to do the same thing and understand yourself a little better too.
I used the trusty post-it note technique
The exercise was very simple - this is how to do it yourself:
- Make two areas on the floor called “best bits” and “worst bits”
- Cast your mind back through previous jobs and write post-it notes in each section, with a 🙂 or a 🙁 in the corner
- Once you’re done, look at all the post-its and try to write “I love …” statements which represent a group
- Move the post-its around their statement, and repeat until all post-its are captured by a statement
- Sort the statements in order of how many post-it notes they’re surrounded by - these are probably the most significant
Here’s what I discovered.
I love listening to people and deeply understanding their experience
This is my product side shining through. I’m happiest when I can listen directly to people and understand the nuance of their situation and problems.
One of the things I find baffling about Waterfall is the dreaded ‘requirements specification’. Typically there’s the ‘business analyst’ - the person who listens to the user - and the ‘developer’ - the person tasked with implementing the requirements written down by the business analyst.
Why would you keep developers away from users? People making products need to understand the people they’re making them for. I’ve written about this before.
- 🙂 Hearing good and bad feedback from real people
- 🙂 Listening to client problems then planning and implementing scrapers for them
- 🙂 Showing stuff to users, getting feedback and iterating
- 🙂 Listening to the Pilots and building them something useful
- 🙂 Getting feedback and iterating
- 🙁 Didn’t understand users or market well enough
- 🙁 No idea who we were building for or why
I love spending my time understanding and building products
I love spending as much time on product as possible and as little on the ‘other stuff’. I love going through the process of understanding problems, exploring possible solutions, then implementing them. I’m pragmatic about when not to build solutions, or when to implement a ‘furiously minimal’ product that gives an incremental improvement, then building out from there.
At times I’ve been my own worst enemy here - I think because I’m a good communicator and I have strong opinions on ethics and principles like openness, I often get drawn into politics and ‘selling’ ideas to investors or management.
I’m much happier and much more effective influencing by making real things that work, rather than making slide decks and opinion pieces.
- 🙂 Focusing 90% on product design & development
- 🙂 Building well tested and well documented API
- 🙁 Planning sales activities
- 🙁 Running the field research team
- 🙁 Lots of distracting meetings
- 🙁 Writing investor decks, businesses cases, innovate reports
I love automating things
This one’s a strong theme - I basically love making things that run themselves. There’s something deeply satisfying about amplifying our efforts by putting machines to work for us.
- 🙂 Automating G-cloud scraper, backing up and restoring databases
- 🙂 Automating collecting and processing weather data
- 🙂 Creating a standard scraper template
- 🙂 Automating sending PGP expiry emails
- 🙂 Automating processes like deploying our code
- 🙂 Building web scrapers
I love building and running things that actually work
I thought I just loved building things, any things, but it turns out that’s not the whole story.
Over the last few years I’ve done a lot of prototyping. The type of prototypes I’ve worked on having been fictional products - things which look like they work enough to test with users, but they’re not real.
They’re a super tool for communicating ideas. They can start a discussion about whether a potential solution could really solve a problem. And they can influence ‘senior management’ types - ‘imagine if this existed…‘.
But prototypes for the sake of communicating or influencing… that’s not for me.
So many of the ‘products’ I’ve worked on over the last few years turned out to be pretty think-pieces - nice illustrations to support a business case.
Contrast this to my prototype version of Expirybot - a fast-and-loose script to extract email addresses, then a hand-crafted email sent by Mail Merge. This was product release version 0.1 - the most furiously minimal version I could ‘ship’, learn from and iterate. It wasn’t an ‘experiment’ for the sake of learning - it was a real, working thing, helping out real people!
In summary, I’m a big fan of making things that actually do something for real people.
- 🙂 Building letters app with real users
- 🙂 Building Fetch app and backend API that actually worked
- 🙂 A handful of Pilots actually using our app every day
- 🙁 Never launching anything to the public
- 🙁 Never making anything beyond prototypes - nothing actually worked
I love autonomous working cultures
This one’s simple - I like being in teams that can decide how to work and how to get things done.
I don’t seem to suit big organisations well - I find they over-complicate things with ‘governance’, ‘approvals’, ‘alignment’ and ‘selling’ things to the business. I’m sure someone finds this useful but our precious lives are running out and I feel there are better things to spend our time on.
- 🙂 Very autonomous team
- 🙂 Relaxed working culture
- 🙁 Bureaucracy and political BS
- 🙁 Having to go through weeks of process to launch anything
I love feeling part of a community with a positive purpose
I really loved the Power Pack work, getting to know Community Energy groups, speaking to them on the phone, going to events and feeling like part of the community. That community has a strong mission which I’m really behind, so working with them felt completely easy.
Equally, I’ve loved feeling part of the internet freedom community through my PGP work. I love getting emails from random journalists, developers, lawyers, activists, and feeling like we’re working towards a common goal.
Both these groups are fighters - activists - thinking about the future and how to make it better. Love it.
Unfortunately I couldn’t say the same for my small experience of health or the marine logistics industry. For whatever reason I didn’t feel I was among ‘my people’ there.
- 🙂 Working in an area with strong ‘why’ like renewable energy, financial inequality
- 🙂 Feeling part of internet freedom community
- 🙂 Going to community energy events and getting to know the groups
I love working with talented people
Simple - it’s great working with talented people. I love the way designers can bring things to life. I’ve especially loved pairing with other developers and learning from them. I haven’t worked with other developers for a while and I’ve missed that learning - I’m worried I’m losing my skills.
I was a little surprised there wasn’t more about working with others, but when I think about it, it makes sense. Although I love working with other people and I’m good in teams, I’m also happy bashing things out on my own too. I’ve done a lot of gigs where I’ve been the only developer, and those were fine. It’s efficient - there’s less meta-work on organising the team. But the flipside is it’s a bit lonely, it’s worse for learning, and it puts a lot of burden on one person. It’s also hard to ever leave those gigs.
- 🙂 Working with designers
- 🙂 Pairing with other developers
I love making complex stuff simple for people
I had a great phone call this morning with a chap I met through my Expirybot emails and he said ‘I don’t really understand PGP, but you’ve enabled me to keep on using it’. That was really satisfying for me, knowing that I’ve made something complex a little more useable.
I do enjoy making things understandable for people - it’s fun to learn the nuts and bolts of something and help others get their heads round it too.
- 🙂 Making complex PGP stuff simple
- 🙂 Teaching people in a fun way through our cryptoparty
Well done for getting this far!