Hello! What's your background and what do you do?
Hi! I'm Kevin, from Ireland, and I work at a digital health company called patientMpower as CTO.
Prior to working at patientMpower I studied Computer Science at Dublin Institute of Technology (now Technological University Dublin), but took a bit of a winding road to get there. My first attempt at college involved moving to England at 18 to study Sports Journalism. I was incredibly excited but very quickly realised it wasn't for me, so switched to Music Technology. After a year and a half I was still struggling, so I dropped out, came home to Dublin, worked for several months doing a data entry job for a utilities company, and then tried college again with CS. On the first day of my first Programming class, the lecturer asked everyone to raise their hands if they’d written any code at all before. I distinctly remember lying and raising my hand because I didn’t want to feel left out. It turned out this was finally the course for me though.
Since college I've mostly worked in full stack web development at MEG (another Irish health tech startup that was working out of the same office as patientMpower at the time), Workday, and RecommenderX (another Irish startup!). With all of that time at startups, I got a really wide exposure to engineering, but also the business, design, project management, and planning sides of things. I feel like the experience relatively early on in areas like backend services, native Android, cross-platform hybrid apps, frontend web, data engineering, and machine learning (all to varying degrees of depth), has been incredibly useful as a manager. As I started to abstract away from some of the intricacies software engineers were involved in, having at least a surface-level knowledge of their technologies (even just enough terminology to have a conversation) has been invaluable.
How was your transition from software development to management like?
My first foray into management was as an intern mentor at RecommenderX. I'd always thought I'd go down the management track eventually, and while reading Camille Fournier's excellent The Manager's Path I decided getting some experience mentoring would be a useful and low-risk way to see if people management actually was something I'd enjoy. I was lucky enough that the company typically took an intern from the same college I'd attended, so I knew the process and timing. I raised the idea with my manager about a month before I knew the college would be getting in touch with the company to see if they wanted to join the internship programme again, so I was involved early enough to take part in the CV reviews and interviews, which was really valuable experience.
When I joined patientMpower the team was very small, with three people (including me) in engineering, and I was not in management role. After a few months I was asked by the CEO if I wanted to take on a role leading the engineering team that had grown slightly, which I readily accepted. The big change for the company came with Covid-19. The pandemic has massively accelerated the adoption of digital solutions in healthcare, and patientMpower grew significantly in 2020 due to the increased demand for remote patient monitoring technologies like ours. A couple of months into the pandemic, after the successful launch of our Covid-19 platform in the Irish healthcare system, I was made CTO.
Just over a year into the role, I feel like the transition from engineering lead to CTO is still happening. At first, the pandemic-driven demand on the product meant I was still primarily writing code, but increasingly my focus moved towards hiring to meet that demand. Scaling the engineering team from three to eleven may sound like a relatively small change, but it was extremely challenging. Even though it’s not a big increase in absolute numbers, it’s a huge increase in communication channels. We struggled with this, as the engineering team was able to operate largely on institutional knowledge when it was just the three of us. With that bigger team now in place and settled though, I have more and more time to focus on the job of managing the members of that team, which I am enjoying immensely. I think that the earlier demand on my time to continue writing code ended up serving me really well, because I got time to connect with that team of mostly new people by working day-to-day with them before abstracting away to mostly managing them.
What does your day-to-day work look like, and what motivates you to do it every day?
I’m still involved in some programming, playing a relatively minor part in backend engineering. Any day I have to write some code, I try to do that before 10am when stand-ups start, so I can keep the sprint progress ticking over and not block the team. Apart from that small amount of time coding, my days typically involve the following:
- Code reviews
- I’m less and less frequently a first reviewer these days, but I usually try to throw my eyes over most merge requests to look for cross-cutting concerns that newer engineers to the company might not be aware of.
- Reviewing technical designs/investigations on upcoming projects
- Planning and implementing IT policies and procedures
- Meetings with clients and partners
- The nature of our work at patientMpower means we rarely work in isolation. Whether it’s a research group, hospital, or integration partner, there’s usually someone to touch base with.
- 1:1s
- Trying to establish policies and practices of management for me and my manager reports
- Keeping an eye on communication lines to make sure everyone is able to find
out about anything that’s going to impact them
- With patientMpower growing quickly, it can be easy to let information fall through gaps in communication
To help me stay on top of things I’ve recently tried a personal Jira project where I track my work in weekly “sprints”. It’s been working really well for me, a bit of creative use of epics, labels, and custom issue types can go a long way!
What are the biggest challenges you've faced so far? What did you do to overcome them?
One of the biggest challenges I’ve found is answering management-related questions with “I don’t know”. Especially in an engineering organisation that is scaling quickly, there can be a lack of defined processes and policies, leading to plenty of questions. I’ve often initially thought of responding with “I don’t know” as a sort of failure, especially if it’s not just something I don’t have an answer for, but something I never even considered as a question. As useless and non-actionable a solution as this seems if you’re in this position, I’ve genuinely found the best approach here is to be candid with people. I’ve yet to have an “I don’t know” turn into anywhere near as big a deal as I’d feared.
Another challenge is the lack of room for experimentation, compared with being an IC in a team. In a Scrum team, for example, you can bring up a new idea in retro, try it for a sprint or two, and throw it out if it didn’t work. Management processes tend to demand a bit more stability than that. Solid research and (again) candidness have seemed to be the best approach for me. Introducing a new idea with the caveat that it is in fact new, but sharing the (hopefully good) reasons for doing so, usually helps to both get buy-in if it’s going well and soften the blow if it goes badly.
What has been the biggest surprise so far? Something you didn't expect?
How incredibly different people are. In my 1:1s, for example, I have people who:
- Focus solely on technical details of current work
- Focus solely on technical details of upcoming work
- Are quite directed in training they would like to undertake
- Are completely happy without extra training beyond the skills they are learning within their team
- Are very curious about parts of the company unrelated to their job
- Have little to no interest in parts of the company unrelated to their job
- Use most of the time to chat about non-work topics
- Don’t use much of the time at all
It’s wonderful to get to know all of these people, and a really rewarding challenge to try to adapt my approach in the way that suits them all best.
What's the best advice you've received about being a manager?
When I was a teenager I played in a football tournament in the Czech Republic with a team of very talented players. A lot of them were very skillful, which I was not. I was a decent footballer, but skills and tricks weren’t something that came particularly naturally to me. After one match, our manager came up to me and told me he loved my new trick. I had no idea what he meant. It turns out he was talking about pointing. In that match I had started being more vocal about communicating with my teammates, keeping them informed of what was going on around them, and (apparently) physically pointing them into areas of space that they could utilise.
He explained afterwards that the value he saw in the pointing was that the other players trusted my information. Rather than having to think about where to go to receive the ball, they trusted my direction, and it freed them up to focus on what they were going to do once they had the ball. This focus allowed them to play to their full potential (which for most of them was certainly higher than mine ever was individually), which made the whole team better overall.
I try to bring this idea into people management where I can. Trust is the key aspect here. Your team needs to trust the information and direction you’re giving them, and if they do they can flourish. If I can provide enough direction to allow people to focus on the jobs they’ll do better than I ever could, everybody wins.
What do you tell developers who are considering making the switch or new to the role?
Use your own experiences. Most people making the switch or new to the role already have experience of management from the other side. Even if you’ve never put all that much thought into your manager’s style and what you liked or didn’t like about the relationship, spending some dedicated time thinking about those relationships will usually yield some insights into what you think good and bad management looks like. Combining these with whatever internal resources you have access to for how engineering management works at your company is usually a really good place to start. Once you have an idea of the kind of manager you want to be, talk to your own manager about it. They have the distinct advantage of, by definition, having been in your position before.
I’d also say one of the things you need to be prepared for is the lack of structure you might have compared to your role as an IC. Part of your job now is to be interruptible, and a lot of your job won’t fit neatly into a Jira board. One of the things I struggle with is balancing being available for my reports, while also having time to act on wider management tasks and the other non-people management areas for which I am accountable. It is easy to start off in a fire-fighting mode, but try to experiment with your calendar to see if you can carve out blocks of time for focus. This is especially needed if you still have coding responsibilities. Your and your reports’ lives will be easier if the times when you’re less available are consistent and predictable.
Final call to action! Where can we go to learn more about you?
I've been threatening to start a blog for a while, so watch this space, but in the meantime you can get me on Twitter or LinkedIn. :)