The problems I solve
06 Aug 2023You are the solution to a company’s problem. Finding a job is about finding the company which has the problem you are the solution to.
A professional connection said this to my husband recently and it really stuck with me. I’ve been on both sides of the hiring table and feel this statement to be so true.
In the spirit of that advice, and since I’m looking for work myself, these are some of the problems I’m the solution to:
- our service could improve its reliability
- our team needs someone with strong emotional intelligence
- we’d like someone with a delivery/product mindset
- our team needs an engineer who writes app AND infrastructure code
- we don’t do XP and we’d like to
- our platform team needs a lead
You want to implement SRE principles and practices
Fundamentally this is what I do: implement SRE principles and practices. I bring a software engineering mindset to traditional operations issues.
My approach to SRE is founded on: observability (how do we know what’s happening in a system), automation (how do we optimise a system by removing manual tasks), and simplicity (how do we design or refactor system to be simpler).
For me, observability encompasses things like SLxs, monitoring, and even attitudes to risk (our appetite for risk is related to our confidence in a system’s observability).
Automation exists both to optimise a system but also to free up time for engineers to do other things.
And simplicity? Simpler systems and designs often, but not always, lend themselves to reliability.
At the risk of tooting my own horn, I try to cultivate these SRE practices:
1. Analyze every change in the context of a (much) bigger picture
2. Be pragmatic and forward-thinking about that analysis
3. Move on when something isn’t actually helping
4. Embrace every opportunity to automate
5. Persuade organisations to do what needs to be done
6. Expand my existing skill set to include new tools and approaches
7. Trust the process
(see this blog on doing SRE well)
One thing to note: I’m a dolphin not an octopus. I like to be part of a dolphin pod and get sad when I’m not in a pod 🐬
This means I’m not the kind of SRE who likes to work solo. I want to feel connected to the people I work with and the product I’m building. I prefer working with other SREs so we can bounce ideas around, learn from each other, and nerd out about log aggregation.
Your team needs someone with EQ and technical skills
In a lot of ways I feel this is my calling.
For you Trekkies out there, I’m like the Deanna Troi of a team: I can command the ship and chat with Geordi LeForge about why a cryosensor is borked but my purpose is connecting and understanding people 🖖
Most of my downtime reading and thinking relates to psychology, team culture, communication, and leadership. I love combining this with a good tech side project.
My interest stems from an underrated aspect of doing SRE: interpersonal work. We communicate (sometimes in tense situations), we introduce and promote change, we teach, we see conflict –– all require emotional intelligence, practice, and learning about human skills.
I took classes on conflict transformation and then taught sessions on the topic for every subsequent team I’ve worked with. I’ve introduced processes to encourage team bonding and conducted sessions on the vulnerability loop. I’ve led teams, nurtured healthy team cultures, and created spaces where people felt comfortable taking interpersonal risk.
I studied anthropology and psychology at university and have taken courses on building high performing teams, practicing positive psychology, and understanding team culture.
I’ve applied everything I’ve learned within my teams and really see a shift in culture as a result.
You need an engineer with a delivery and product mindset
This is another calling.
I love delivery. I love working with a group of people towards a shared goal, breaking large problems down into smaller parts and figuring out roadmaps. I love organising.
I love collaborating with delivery and product managers, figuring out sustainable pace, and what the next most important thing is.
Making inaccessible engineering concepts accessible to a wider audience is pure joy. I used to be a teacher, that part of me has never left.
I also firmly believe in having a “product mindset”. The most fulfilling work I’ve done is create product solutions which deliver real user value and centre the user in what we do.
When I pick up a card on Trello I want to know why we’re building what we’re building, what value it delivers, and what kind of problem it solves for our end user.
In my time as engineer and tech lead I’ve collaborated with delivery, product, and project managers, developed roadmaps and OKRs, prioritised work, contributed to planning sessions, led rituals like retros and stand-ups, worked with UX/UI teams and conducted user research.
I sometimes joke I’d be a delivery manager if I didn’t love engineering so much.
You need someone who writes application and infrastructure code
In 2020, I worked as a fullstack developer on the Shielded Vulnerable People Service, a government COVID response project (you can read about here).
I wrote application and infrastructure code, and despite all the stress of that period it was some of the most fulfilling work I’ve done.
The mix of product development, thinking as a software engineer, and also solving operations issues resonated with me, especially because the end goal (delivering food to shielding people) was so urgent.
That project helped me realise I’m a generalist. I fit well in teams that need someone who can develop software and apply SRE practices.
I thrive on platform teams and small to medium-sized startups who need someone to wear a few different hats.
A note on being a generalist: my skill set is b r o a d, in some areas deep (especially team work and leadership), but not all areas have equal depth. Given I’ve focused my energy in the last four years on becoming a Senior SRE, I’d probably say I’m a mid-level software engineer.
You don’t do XP but you want to
I matured as a software engineer on an engineering team that practiced eXtreme Programming (XP). Moreover, my training at Makers was also grounded in XP principles.
I feel at home on teams which practice XP or places which want to introduce those practices.
Tiny caveat. My sense is that practicing XP is a bit like being remote-first, it’s done best when baked into the engineering culture from the start. It’s not impossible to introduce, but runs smoother when it’s the norm.
I have experience pair and mob programming, as well as teaching both to others. I TDD like it’s eating ice-cream: with relish and joy. But weirdly also like brushing my teeth, it’s a hygiene thing I do when I code.
I’ve worked in short feedback cycles, delivering a minimal viable solution to get feedback quickly from users. I’m used to making small frequent commits which turn into small frequent releases. I work iteratively and love it when others do the same.
I’ve led teams that work at a sustainable pace and worked on teams which achieve that goal. I’ve written stories based on user research and spiked solutions in order to reduce risk. I refactor wherever and whenever possible (it’s one of my favourite parts of engineering, possibly more so than building new things).
XP has inspired me to be a better software engineer, develop a product mindset, and build an effective communication tool set.
You need an engineering manager for a platform team
I’ll end on this note.
My long term professional goal is to become a Chief Joy Officer, a role I learned about from Dana Svoboda, Chief Joy Officer at Makers.
However, my medium term goal is to become an engineering manager one day.
I was the tech lead and then infrastructure lead on my last team and I loved the work. I wrote about it here.
I have the experience and skills to do team leadership and engineering management, especially on platform or infrastructure teams.
I’ve been involved in hiring (with a focus on building diverse and inclusive teams), mentored junior developers, career-coached software engineers, line-managed, handled interpersonal conflict with curiosity and grace, worked on improving hiring processes, developed career tracks for SREs, prepared line managees for reviews, and led sessions on giving feedback and holding effective 1-1s.
In an ideal world I’d prefer to join as an engineer first and then move into tech leading/engineering management but that’s not a hard and fast rule. I feel joining as engineer helps build empathy and trust between lead/engineering manager and the team they lead.
If you’re looking for an engineering manager we can always have a chat. It would be great to align my skills and interest in team work with a job whose goal is to promote team work.
The tools I use 🛠
👋 Hi there, welcome to my SRE journey and the tools I use.
I have built and maintained CI/CD pipelines, developed SLxs, migrated to cloud services, led incidents, built and managed containers (mostly Docker 🐳), been on call, designed and optimised infrastructure systems, managed cloud costs, wrote infrastructure as code, automated All The Things, scaled systems, developed effective monitoring tools (Hi Grafana! 👋), created meaningful alerts, wrote documentation, addressed security issues, worked with networking, and had a lot of fun along the way 🎉
I’ve worked predominantly with Linux (sorry Windows). Used AWS almost exclusively but played around with Google Cloud Platform in my downtime. Don’t feel left out Azure, I promise I’ll work with you one day!
For CI/CD, I’ve used GoCD, Concourse, AWS Code Pipeline/Deploy, Jenkins, and GitHub Actions. I’ve also used Rundeck from time to time and Packer for baking images. Puppet is my preferred configuration management tool but I’ve also worked with Ansible. I’d like to work more with Kubernetes.
In terms of databases I’ve experience with MySQL, postgres, and elastic, but I’d like to grow this skill set.
I’m most comfortable scripting in Python and Bash and have dabbled in Ruby. I’d love to learn Go and Rust. Terraform is my go-to choice for infrastructure as code. I work in Git and love conventional commits.
The weirdest thing I’ve worked with is FreeRADIUS, an open source WiFi authentication server. It’s niche.