Scaling Engineering Teams — An Approach
I recently spoke at the The Inaugural Event for CTOs in Manchester meetup alongside Mark Evans and Edson Ferreira — who were excellent BTW!
The talk was well timed for me as I was reflecting on my first year at Push Doctor and the approach I had established before I joined the business. I realised that while I was very deliberate in my approach, this was the first time I had talked publicly about it. I received some positive feedback after the event and it made me think that I should write it down and share it, so here we are!
Approach +/- 30
I believe that a good engineering manager is there to have impact and amplify their team. I very much sign up to the servant leadership style of running engineering teams. Over the past couple of years there has been an increase in the engineering manager readme movement and engineering managers sharing their readme.
My approach with Push Doctor was to use the 30 days before arriving and my first 30 days within the business to quite simply ‘figure everything out’, which of course is quite a challenge! In order to achieve this I initially focussed on the following areas:
- observing — observing interactions between engineers, between tech and other disciplines like product and design and the wider business, understanding ceremonies, etc.
- absorbing — reading collateral, docs and any form of information in whatever format it was available and noting what was not available.
- questioning — asking questions. Being the ‘new guy’ provides a unique opportunity to ask questions and be naive. Usually this wears off over time and people stop asking questions, but this is important and should continue.
- 1:1s — one-to-ones with all engineers.
- readme — I shared my engineering manager readme to each individual engineer along with an initial set of questions to answer so that I could get an understanding of what made people tick, their passions, frustrations and aspirations.
Within the first 30 days I also held a tech all-hands. I actually carried out 2 mini all-hands since our engineering team is split across two locations (Manchester and Birmingham). I decided to repeat this in each location so that I could discuss the themes relevant to each location face-to-face.
In the all-hands I emphasised that I would iterate and focus on the following seven things and that this would be (and still is) my approach to engineering management.
1. Understand the organisation, industry, constraints — Get to know the digital health sector, competitor landscape, technology landscape, constraints we operate in and so on.
2. What does good look like? — If we are doing well, what might this look like? This relates to the business doing well, what people expect from product development and technical delivery. Understanding how this is represented and measured makes it possible to know what we are optimising for.
3. Define & articulate the technical vision and strategy — establishing a clear vision and strategy is important and communicating it over and over is important too.
4. Team structure — Organise for success — hiring engineers is increasingly competitive but hiring is kinda the easy part. Motivating, developing and retaining talent is hard and ensuring there is a plan for that is also important to me. Most importantly, regular 1:1s is key for building strong relationships and teams versus 1 annual review conversation per year.
5. Build strong engineering culture — I believe aligning towards shared goals and principles is an important first step, especially in engineering. For example, do we believe in and practice clean code, pairing, code reviews? I/we do BTW! These elements form the basis of the engineering culture and allow individuals and teams to collaborate with less friction and therefore more efficiency. At Push Doctor we are working toward maintaining a sharing & collaborative culture and value 10x teams over 10x individuals/engineers.
6. Deliver — As a technical leader I’m expected to deliver business value and business metrics. I expect that of the team too. We have s$$t loads to do, all the time and we need to deliver consistently and quickly as well as innovate, learn/fail fast!
7. Build Tech for the future — We are building tech today for tomorrow and one day it will be regarded as debt by future generations. I believe we should pay off existing debt as well as evolve the product through new features, enhancements and improvements. This also includes focussing on Non-functional requirements (security, performance and many others).
I also believe that we should be lazy, not re-invent the wheel but instead focus on our USP.
Finally, I am ever so slightly obsessed with one thing
Automate EVERYTHING & reduce FAFF for our engineering team.
I don’t believe it makes sense to have engineers (or anyone) wasting time and being inefficient. It’s not great for speed of delivery or personal motivation and repetitive tasks are something which machines can do well without complaints! Keeping an engineering team motivated and happy is hard enough as it is, so reducing faff is a good general rule to have.
So, there we have it, my secret sauce. I hope you found this useful and in the next post I will introduce my SOLID Principles of Engineering Management.
