In early 2020 we closed our Bulgarian office, and most of CoolPlanet's frontend expertise went with it. Software development had historically been split between Dublin (backend and infrastructure) and Sofia (frontend and QA); COVID had hit the business hard enough that we couldn't keep both. I picked it up, taking on responsibility for the frontend architecture and the development that went with it. As business recovered, I was asked to rebuild the team, this time hiring full-stack engineers rather than continuing the old split.
Growing the team
When I first moved into a management role in 2021 there was already one engineer on the team. Over the next four years I hired ten more. Eleven engineers in total passed through my reporting line between 2021 and March 2025.
This was new territory for me. I had to pick up a different set of skills (hiring, performance reviews, 1:1s, salary and career conversations) and work through a different kind of challenge from week to week, all while continuing to carry the technical leadership and responsibilities I already had on the team.
The chart below shows everyone who passed through my reporting line during those four years. Different colours represent levels in the career framework (junior, mid-level, senior), and the small badges within bars mark promotions between those levels. By the peak in 2024 I had eight direct reports, approaching what I'd consider the limit of what one person can sustainably manage.
Behind every bar is a person's career story: years of context, plenty of highs, and inevitably some lows. None of that belongs on a public page, and I wouldn't share any of these details without the person's consent. Some of the more challenging situations and difficult conversations are alluded to below rather than being spelled out.
The vertical marker in March 2025 is when the team formally transferred to a new line manager and I went back to being an IC. That move was my own decision, deliberate and planned. The why and how of it are covered later in this page.
Formalising what wasn't there
CoolPlanet was very much a startup environment. For most of the early years there weren't many (or in some cases any) formal processes in place around how we hired, onboarded, or developed engineers. As the team expanded, that gap started to matter. I led the design and rollout of each piece in close collaboration with the CTO.
Hiring
The first piece was a structured hiring process. It started with an initial interview, more of a screening conversation but still technical, where the candidate could learn about the company and we could get a sense of how they thought and communicated. If that went well, we'd send them a take-home technical assessment tailored to our tech stack. The candidate would work through it in their own time and then come back for a walkthrough call. We'd go through the code together, and what we were really assessing was how they explained their decisions, how they handled questions about tradeoffs, and how they reasoned about alternatives when pushed. That conversation was where you learned the most about a candidate.
The first interview I ever ran, I was probably more nervous than the candidate. After many, many more of them over the years I got very comfortable with it. Like any new skill, you have to practise it.
Onboarding
The CoolPlanet stack isn't a typical one. We run React/TypeScript on the frontend, Java/Spring on the backend, PostgreSQL for relational data, and SkySpark (a proprietary platform) which we use as a time-series database, a NoSQL database, and a host for much of our business logic. SkySpark is especially powerful for the integration layer that pulls data from the various sites we work with. It also has its own proprietary languages and almost no off-the-shelf learning material. There was no avoiding the need for a dedicated, tailored training programme, so I built one.
We also invested heavily in documentation. A new hire could set up their full development environment on their first day and start contributing to simpler tickets straight away. For anything more complex, though, they really needed the full onboarding exercise under their belt. The exercise intentionally mirrored our day-to-day way of working, top to bottom: picking up a ticket in Jira, integrating the designs from Figma, our branching strategy and code conventions on the frontend, how we designed our APIs in the backend, and how we structured the data all the way down to the database. Even a senior engineer joining a new company needs time to adjust to its specific way of developing software, and the programme was where that adjustment happened deliberately rather than incidentally.
A career framework
As the team grew, we needed a more formal framework for performance and progression. I wanted reviews to be objective, expectations transparent, and growth conversations more productive. We pulled shape from publicly-available frameworks at companies whose engineering documents were well regarded, and adapted what fit.
The framework was five axes (Technical, Execution, Teamwork, Communication, Vision) by five levels (SE1–SE5), with salary bands anchored to each level. It was designed around impact. The level descriptions weren't a checklist to tick off; they were example behaviours, and what mattered for promotion was the impact an engineer was having. The salary bands took discretion out of compensation decisions, and reviews focused on that impact rather than vague impressions.
We deliberately included the Vision column. We wanted engineers with a product mindset (putting themselves in the user's shoes) and a genuine interest in emerging technologies and how they might apply within our domain and stack.
The biggest effect was on growth plans and performance reviews. Once the level expectations were public, engineers could proactively target the areas they wanted to develop and put themselves forward for pieces of work that matched what they were trying to demonstrate.
Changing the way we worked
As the team grew, we started to experience some growing pains. Engineering, design, and product had always worked closely together and joined the same daily stand-up. We were disciplined about keeping it under ten minutes, but even then a fair bit of what was being said wasn't relevant to everyone listening. People might still be interested in the updates, but they didn't need to hear them. Depending on what epics were in play, sub-groups would naturally form to work on a piece together, then reshuffle when the next epic came along, and people ended up context-switching quite a bit. It wasn't just stand-ups either. When product wanted to scope a new requirement and discuss feasibility, it wasn't always obvious who they should be chatting to or who held the necessary knowledge for which piece of the platform.
We restructured into three pods. Two stream-aligned pods, each with four engineers, a designer, and a product person, owned a stream of work end to end. Within each, the tech lead, designer, and product person formed a triad: three points of contact who jointly owned direction for the stream. A third enabling pod, three backend and infrastructure engineers, sat alongside them. They didn't ship product features directly; they unblocked the stream-aligned pods and owned the shared platform work everyone depended on.
The structure was influenced by Team Topologies, which is where the stream-aligned, enabling, collaboration, and facilitating language comes from. We didn't adopt the framework wholesale. We took the parts that fitted a team of around a dozen and left the rest.
There were of course some teething problems when it first rolled out, but the change did help with assigning clear ownership and reducing the context switching and cognitive load on the team. The triad of tech lead, designer, and product person worked well together from early concept right through to deployment. We didn't have a dedicated QA function either, so when bugs or issues came in afterwards it was clear who was responsible for what. The pod boundaries also became a natural unit for the Teamwork and Communication pillars in the career framework to be assessed against.
More rewarding, less fun
Unlike code, people aren't deterministic. Each person you manage has their own life outside work that you only ever see part of, their own motivations, their own background and experiences, their own natural strengths and gaps, and their own conditions for doing their best work. No two people are the same, and what worked well for one engineer wouldn't necessarily work for another.
I made most of the typical first-time-manager mistakes along the way. I fell into micromanagement when I should have been tackling underperformance head-on. I avoided some hard conversations longer than I should have, and let things sit when they needed naming. I delivered feedback the way I'd like to receive it, rather than the way it would land best for the person in front of me. I held on to work I should have delegated, stayed as a bottleneck longer than I should have, and was slow to adapt my approach engineer-by-engineer. None of those mistakes are unique to me. They're the standard list of new-manager errors, but I still had to learn each lesson the hard way.
Over time, though, I did get better at the job. Not at any one of those things in isolation, but at the pattern recognition that builds up underneath them. I learned to read the person in front of me, to recognise the moments earlier, and to pick the response that fitted them. That kind of judgement is what management actually is, and it only comes with experience.
Someone framed management to me, around the time I was handing over my team, as:
More rewarding, less fun.
I've used the line a lot since. The rewarding part was the one I hadn't expected. Watching engineers I'd backed grow into the team's stack, take ownership of bigger pieces of work, and turn around to mentor the next starter, knowing I'd had a small part in that, is a different kind of satisfaction from shipping a feature.
Getting back on the tools
By Q3 2024 I'd lifted my head above water long enough to realise I wasn't enjoying my work as much as I used to. I'd become the single-threaded point of failure on too many things, my calendar was full of meetings, and I had a growing fear of my technical abilities atrophying. The role had drifted to roughly 80/20 managerial to technical, which wasn't the shape of job I wanted at this stage of my career.
The drift had happened gradually. The transition into management was never an intentional decision. Each time the business needed someone to take on the next piece (hiring, onboarding, reviews, a career framework, a difficult conversation) I was the natural fit, so I did the work. Years passed before I stepped back enough to ask whether the shape of the job still matched the shape I wanted.
As a manager you reach the end of a day, a week, a month, even a quarter, and you can point to fewer concrete things and say "that was me". IC work, by contrast, leaves an artefact at the end of every session. Building things directly is a kind of fun that managing people doesn't substitute for.
I'd been wearing both hats, technical and managerial, for some time, and the honest truth was I wasn't doing either job as well as I could have. I was spread too thin. I brought a case to senior management for a new hire who would own the people-management load and leave me the software-engineering technical leadership I'd been doing in parallel with management all along.
By the time the new manager arrived nobody was surprised. The team had always respected me as a technical leader, and they appreciated that I wanted to be more hands-on again. The handover was a gradual transition, and the formal team transfer went through in March 2025. That wasn't the end of the collaboration. We continued to work closely throughout the rest of my time at CoolPlanet.
Looking ahead
As it turns out (yet again), none of this is unique to me. Plenty of engineers end up swinging back and forth between IC and management over the course of their careers, and there's even a name for the pattern: the engineer/manager pendulum. Switching between the two roles makes you better at both, and treating management as a one-way door is harmful in both directions. For now there's a lot I'm still excited to learn about on the technical side, and I want to spend my days building.
Looking back, what surprises me most is how directly the years I spent wearing both hats, technical and managerial, have set me up to build the software factories of tomorrow. Software development is shifting away from writing every line yourself and towards orchestrating a team of capable agents that can execute on a clear brief.
You're setting the direction, deciding on the architecture, delegating at the right level of granularity, choosing what to trust and what to verify, putting in deterministic checks and gates to maintain quality, and watching for drift. That's exactly the shape of thinking those years built, just applied to a different kind of team.