Discover with us what makes a great Engineering Leader. In these interviews dedicated to tech leaders, we’re sharing personal stories and insights on how they manage their teams… and themselves!
Their diverse professional journeys and personal backgrounds point to the importance of self-reflection and perseverance. But of course, Engineering Leaders have their own interpretation of what key factors can help you become an even better manager.
In today’s interview, we’re thrilled to share with you the conversation we had with Michael Lambert, currently Engineering Manger at EstimateOne. Thanks Michael!
# Could you tell us a bit about yourself and your professional journey?
My journey into IT wasn’t planned. In high-school I wanted to be an architect, but my grades in maths prevented me from doing the pre-requisite subjects, so I started to pursue a career in computers! Not long after I started my tertiary studies, a computer shop opened across the street, four months later I dropped out and started my first IT role as a CTO for an Internet access provider.
Unfortunately I learnt a few lessons the hard way. I burnt myself out after a couple of years and decided to leave my role. As I entered the world of being an employee I discovered that I was at the absolute peak of Mount Stupid as often appears on graphs of the Dunning-Kruger Effect; thus I began my journey through the ranks in IT.
Over the last 25 years I’ve held a variety of roles, mainly centred around Internet access provision and web development. My early career didn’t have many highlights apart from 2001 when I was one of the small team involved in writing the successful tender that won AusRegistry the rights to run the Registry operations for the .AU namespace. In 2013 I moved into my first role with a SaaS organisation, this was the start of my journey to leadership.
Looking back at my career I recognise a few roles that had a significant impact. My first role provided an amazing foundation for my career; with a huge amount of learning in a short space of time. My role at AusRegistry gave me a lot of confidence in relation to business. At Ento I had the opportunity to really learn and understand cloud technologies which has given me an invaluable understanding of the different architecture required. Then my role at Vault IQ allowed me to show my leadership skills as I started on the first day of the COVID-19 lockdown in Victoria, Australia and led the team into the adoption of best practices, adjusting to fully remote working and ultimately the acquisition of the company.
The final role I want to call out as having a significant impact was a role I had in 2003. That role was as the bar, stock and purchasing manager at what was, at the time, the cheapest pub in Victoria. This taught me how to deal with people; once I learnt how to tell a drunk patron that we wouldn’t be serving them any more alcohol, communication in a business setting became a lot easier. I also gained a great understanding of estimation based on historical data, the importance of budgeting, and how to lead a team of staff in a high-pressure environment. Without this role, I think it would have taken me a lot longer to develop the skills I needed to be a leader.
# What made you decide to become an Engineering Manager?
I think it was sometime in 2015 or 2016, prior to that I had always firmly believed that I would be a coder until I died of old age, at my desk, while working.
As I started my role at Ento in 2016 I had the expectation that I would move into a PHP tech lead role, as the team expanded. Of course things don’t always go as planned, at that time the company also needed someone to take ownership of the cloud infrastructure. Another senior PHP developer had also come onboard recently, and ultimately it was decided that I would become the infrastructure lead and he would become the PHP team lead. This left me managing a team of me. With hindsight, this was actually a positive for me. Due to the team structure and office layout I ended up with a desk next to the CTO, this gave me the opportunity to act as a sounding board for him and also to take on some of his work when he was backlogged.
I finally reached the point where I decided that remaining at Ento could not fulfil my leadership desires, so I took a conscious step backwards to a senior PHP developer role, but at an organisation that was significantly larger and with a manager who was willing to coach and mentor me. Unfortunately the promises of my manager were not honoured by the company, but the reduced responsibility and the systems in place at a larger organisation gave me an opportunity to focus on self development.
I spent significant energy attending meetups, learning everything I could about leadership in both technical and non-technical situations. I undertook Scrum certifications; I became involved with Agile coaching groups; I attended courses on video presentations and public speaking; I also invested in a personal branding masterclass to ensure I was marketing myself correctly.
As I began searching for my next role, I was determined to put the tools down and move into a purely leadership position. After months of searching, I found an organisation that saw my potential. I accepted the role as a lead developer with the understanding that the CTO wanted to get back on the tools and I would not only be leading the team, but setting technical and hiring strategies.
Despite the challenges of 111 days of COVID-19 lockdown, being introduced to my team via a video call, and all the problems the team was having adapting to a new manager and fully-remote working, I knew without any doubt that I had made the right choice.
# What metrics have you found most useful for teams to measure their performance?
Despite pressure from senior management, I always push back on measuring team performance. I’ve seen organisations attempt to measure performance through employee engagement surveys; through KPIs on lines of code; through deployment frequency; and even through story points delivered. I’ve never seen any of them actually gauge a team’s performance.
At a meetup I attended recently, a diagram was presented showing six competing forces that need to be balanced to maintain a high-performing team. If too much focus is applied to any one of these then the others will suffer. These values are:
- Do the right stuff (value)
- Do it predictably (consistency)
- Do it right (quality)
- Do lots (quantity)
- Do it fast (speed)
- Keep doing it (resilience)
The challenge with these values is how to measure them, the best way is to ask the development team as individuals. In my current role I have identified two statements for each of these values. At the half-way point of each sprint I ask the team to respond to each statement with a happy, neutral or sad face. Ultimately I would like each team member to respond to each statement with a happy face, if they can do that then I know they are performing at their maximum sustainable level.
By asking each team member to respond anonymously this pulse check can be completed in less than 5 minutes. The individual nature of it means that everyone can respond without feeling overpowered by other team members.
My main interest is in any short-term spikes; a sudden drop in resilience may be the symptom of a stressful event, or it could be an indicator that the team is too pressured to deliver. A secondary assessment is on the long-term changes and trends; this shows if the team is ebbing or flowing and through retrospectives we can work to identify root causes and potential solutions.
In my current role we’ve also started plotting the team level aggregation of responses on a radar chart. This has enabled us to compare and contrast teams and to look for any outliers. Using this we’ve been able to see the impact on a single team when a respected team member resigned; we’re also able to locate commonality between teams and recognise that it may be a sign of a larger department or organisation level issue.
Of course this measure of team health is limited only to the team. I also believe other metrics are useful. The DORA metrics are excellent for verifying system health (where system is the system of working); time in flight and WiP limit measures can be used to highlight potential problems with ways of working; but these measures aren’t assessing the team, they’re assessing the system around the team.
# What are your best practices to ensure your engineers and leaders keep continuously learning and self-improving?
I believe the primary purpose of my role is to help my team and team members improve. I’ve observed that over a two week period, I generally spend:
- One and a half days on team ceremonies
- Half a day on reporting obligations
- Between half and one day on self-development
This leaves me with around 7 days. That’s just enough time to spend half a day per week focusing on each team member in a “two pizza” team. The half day per team member, per week, includes their 1:1s. But also coaching or mentoring as required, and allows me to find answers to their questions, and challenges to push them forward.
When I first join a team I spend several weeks getting to know each team member. What drives them? How do they like to communicate? How do they best learn? What are their career ambitions? In some cases I’ve even worked with team members to help them define a career goal and to then plan how to get there.
By getting this level of understanding of each team member I can then ensure I use my time to find a way to help them on their journey. For some team members I may recommend specific meetups (if they are apprehensive, I’ll even accompany them for their first one). Every team member is different and has a unique set of needs at any given time.
# How do you structure 1:1 conversations and how often do you have them?
I like to leave a lot of the choices up to each team member. I highly encourage weekly one-on-ones of at least 30 minutes, but I’ve had team members who prefer them to be 30 minutes every fortnight and others who like a full hour every week. From my observations, those that want them more frequently and/or longer tend to be in a growth phase in their career, whilst those who prefer shorter or less frequent one-on-ones are in a period of consolidation.
Where possible, I will try to arrange for 1:1s to be hosted in an informal environment, but tailored to the individual. In terms of one-on-one content, I will always come prepared with some backup topics, but I encourage my team members to steer the conversation and focus on what’s important to them. No matter the topic, I’ve always found these sessions valuable.
One-on-ones are an amazing forum to build trust. I have found it is vital to display honesty; I’ve found huge benefits in being able to relate the other person’s stories to my life (where appropriate) and to share some of my learnings from similar situations; I’ve also found it a great forum to demonstrate my desire for them to succeed.
It feels like I’ve avoided the question about one-on-one structure in some ways, so I’ll touch on how I structure my 1:1s with my manager; I hope this will give some clarity about what works for me as an individual.
My manager has shared a document with me in which he adds notes as we talk; personally I haven’t found the need to do this for my team members. I added an additional section to the document to add notes for our next one-on-one; I make sure this is populated during the week and I’ll review it in the 15 minutes before our scheduled time.
The conversation usually starts off with a bit of friendly chat about our weekends. Unintentionally, this leads to work related topics about 75% of the time (usually because either my manager or I have done some work on a side project over the weekend). We then work our way through the list of items I’ve added to the document until we run out of time. If there’s something important to raise then my manager will lead that bit of the conversation, but most of the time it is left to me to guide and steer the conversation.
I will generally walk away from the conversation with some ideas of things to try and an ever improving understanding of my manager. I hope I am delivering this same value to my team members; and based on the feedback I have received so far, I think I am.
# What advice(s) would you give to a software engineer considering becoming an Engineering Manager?
Choosing to move from being an individual contributor to a people leader or manager is a huge decision and one that should not be taken lightly.
Thankfully many organisations are now creating technical paths as well as people leadership paths; developers are no longer forced to move into people management to continue their career. This means developers have the opportunity to control their future path and to ensure it aligns with their interests, skills and desires.
When talking to developers who are considering making this change I will often suggest ways for them to get some experience in the role before making a final decision to progress down this path. One of the most valuable ways to determine if people leadership is right for an individual is to try the role. If the stars align nicely it may be possible to step into a role for a period of time to see how you perform and assess your desire to perform the role. If you want to test the role in this way, be open and honest with management about your skills and also your concerns. Ask them to allow you to act in the role for a period of time (up to 3 months) before they hire someone. After two months in the role you will have a good idea of your future desires.
I also find that attending meetups and conferences can provide a large amount of value. I focused on leadership and agile events, but I also attended events such as product management, coaching and mentoring related events. Through this I was able to learn about the role, gain an understanding of the roles that I would need to regularly interact with, and experience some aspects of the role. Once I felt confident that I was far more interested in people than in code, I made the leap.
A secondary bit of advice I would give to someone taking the journey into people leadership is to establish some time and an idea for a side project. I remember after my first day as a people leader, I looked back at what I’d done for the day and realised I hadn’t opened a code editor, GitHub or any technical tool. I’d spent the day using Zoom, writing documents and talking to my team. That evening I sat down and refactored the CI/CD process for my blog; the transition off the tools was too quick.
The final bit of advice: talk to your manager and your peers about how to recognise value delivery. As an individual contributor, it is simple to see the value provided; with every line of code, every pull request, every deployment, the value is highly visible. As a leader, your value delivery is in the long term; some items will reveal their value in days, some will take a sprint, some may take much longer. The further you move up the levels of management, the longer the horizon on value delivery.
No matter if you decide to follow a people leadership track, a technical path, branch off to product or something else, I wish you the best of luck with your journey!