Learnings from Tech Leading
I’ve been reflecting on my experience on being a leader in tech (as part of being on an upcoming panel) and thought writing this down might be a way to share and articulate my thoughts.
When I started in Tech
I’ve been in the tech industry since 2006 and for most of that time as a software engineer with experience in Java and Ruby and working with high traffic platforms.
When I first started, I wanted to learn more tech. I guess that wasn’t surprising given that I was starting my tech career and wanted to keep growing my tech skills. Once, I didn’t even consider applying for a senior position because I thought my learning was not done (which actually, in reality it never stops).
During this time, there were a few moments that stood out to me as significant.
- Promoting a culture of learning
I was recommended 2 great books to read — Effective Java by Josh Bloch and The Pragmatic Programmer by Dave Thomas. I learnt about good patterns to follow, what anti-patterns were, deepened my knowledge of Java and also learnt about things like best practise, refactoring, influencing change and working with people (that might seem like common sense, but something that takes lots of skill).
From this time there were other senior engineers who I was inspired by, they organised Java User Groups internally and gave us an avenue to learn from each other, as well as skill up the team.
I remember asking the architect what did I need to do to be like them, and he talked through each person’s learning habits and the extra time they put into their skills and different techniques they each employed.
It was in this environment that I learnt about the extra tech areas other than coding — like deployments, infrastructure, performance tuning, monitoring and troubleshooting.
2. Having great leaders
I witnessed really good leadership here. My boss at the time was and is still one of the few good leaders I know. The tech director and her reports downwards were great leaders.
They promoted a good environment to be in, they encouraged transparency, they encouraged learning, they empowered teams and trusted us to make good decisions. They supported us when we had problems, they were empathetic, they seemed wise, knew how to deal with people and had insight. To this day I still view them as inspiring and people I want to be like and lead like them.
3. The team was awesome
Everyone respected each other, helped each other, problem solved and most importantly had fun together. I’m still in contact with most of the people from that team and that time, that is a testament of a great team dynamic.
Now that I’ve set the scene, fast forward to my first experience into being a lead.
Stepping into a Lead Role
During this time I had started working in a different tech stack and my team had just delivered a high profile project (which had it’s own challenges — tight deadline, high stakes, new team members, cross-squad skills, being Agile and going through a transformation).
We had a great team and the dynamics were changing. The team structure was restructuring across the board and team lead roles were split into Tech Lead (focus on tech) and Solution Lead (focus on delivery). It was this time that I was promoted from senior to Tech Lead and I had a go at leading.
I faced what most new Tech Leads probably faced:
- More meetings
- Less coding time
- Leading the tech strategy
- Supporting team members
- Dealing with stakeholders more and more
What I worried about was:
- Losing my tech skills because of having less time to code
- Having to make up for this time by coding outside of hours
- Not supporting people properly because of lack of time
- Were we going to hit our tech milestones?
- Were people onboard and engaged with tech deliverables?
- Not knowing everything
I found that even though I didn’t have a team directly reporting to me, I still needed to have leadership skills, influencing skills as well as support multiple teams and make a positive impact.
I learnt a lot along the way too.
Time was an issue
To compensate for the lack of time, I tried to do it all. I found I was over-worked and spread myself too thin. This wasn’t sustainable and if I kept it up, people would expect me to keep delivering at the same pace, when would I hope to achieve work-life balance?
The ivory tower
There were a couple of times when I would research and made certain decisions on my own. I felt like it was my responsibility to set the strategic direction for some tech initiatives. For example we were migrating to AWS, I would research what the effort and complexity was to migrate to AWS, what a good infrastructure would look like and came up with milestones, JIRA tasks and take on some of that implementation. I felt like it was all on my shoulders.
I needed to grow my people skills
Although I liked working with people from other parts of the business, I had found this part exhausting, especially on the days where I had a lot more people interactions than I was used to (dealing with issues and demands for instance).
I was also in a place where I should be growing people around me. How was I going to influence and grow people? Did people think I was smart enough and inspiring enough to learn from? Did people trust me?
A colleague who had been in the industry much longer than I had, lent me a book The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt which helped me a lot here.
I also went to a couple of leadership training courses which helped too. I learnt about appreciating different personalities and how to leverage different strengths.
Imposter Syndrome
It was around this time that I learnt what the term Imposter Syndrome was. I was afraid of not being good enough or knowing enough. A colleague (the same person who lent me the book) sent me a couple of articles to read (I think he could see what was happening and how I was doubting myself).
However, some good things came out of this experience too.
Tech had a voice
I cared a lot about the platform and the direction of where we were going. It was a chance to focus on getting things right and balance delivery.
Some good things that happened:
Tackling Tech Debt
I would gather the team every fortnight to discuss any tech issues we had, any big initiatives we wanted to tackle and we as a group would determine how and when to do this. It was difficult to get this through the delivery team’s sprint though, and pondered on how to make this work — so I asked for a couple of tickets per sprint to be tech-only initiatives.
Tech Initiatives Had Visibility
This involved communicating the tech strategy to non-tech folks. It often happens that tech strategy is invisible and undocumented, so unless there is transparency it is difficult to build a solid platform and get support from other departments.
I found myself presenting to managers in different departments on topics like continuous deployment and general tech strategy (such as micro-services, using AWS and refactoring) and linking the reasons to business value, for example, if a server goes down in AWS, we can leverage auto-scaling to quickly recover and not lose revenue otherwise it could take hours before coming back online to the public.
Promoting a Learning Environment
I craved having that same environment where people were engaged, inspired, sharing tech and leveraging tools which would make our lives easier.
I once mentioned to my manager that we should have tech talks for the team and he responded, “why not all of tech”. I was shy and thought that it would be a big task, but I gave it a go and organised monthly tech talks on a Friday afternoon as an optional invite to whoever wanted to come along.
Here we shared live demos and talks that others were experimenting with and new tech at the time, such as Clojure and Scala. It didn’t matter to me if it was tech unrelated to our work, the point was to learn and be inspired, and by observing different technologies we could learn what the shortcomings were in the tools we had or see what good looked like. It was also an opportunity for people in the team to practise presenting in front of people.
A year later, I embarked on another leadership journey, where my focus turned to delivery and it was a learning curve again.
Being A Technical Delivery Lead
Something happened where the team was growing and growing and it was way too much for the Solution Lead to handle. He had something like 15 reporting to him with more people to join and many stakeholders to work with.
I was pretty happy being Tech Lead at the time, however the current Solution Lead talked me into trying the role.
As soon as I stepped into that role, I wondered how he managed. It was overwhelming (and I was taking half of his load).
There were a few hurdles that were present:
- In this environment there were many business owners to work with, all of them wanting delivery of something. We were a team of 10 (my half) and there were more stakeholders wanting work out of us.
- We were working in a new area of the business that needed to generate more revenue for the company.
- My team were also bombarded with reporting and data requests, which we were not equipped to handle, we didn’t have the expertise or the time to dedicate to this (I raised this with my manager and a Data/BI team arrived)
- There wasn’t enough transparency on delivery and it felt as though stakeholders distrusted us or didn’t think we were delivering.
- Due to being stretched, the team were not having 1–1s and getting the space to check in on how they were going.
I rolled up my sleeves and did my best to address these areas. Things I learnt:
- Transparency was important
- Dealing with adhoc requests
- Motivating a team
- Unblock others
- People matter
- Relationships matter
- Time and delegation
- Look around
- Develop a new routine
Transparency
When there is no transparency between different departments it’s difficult to get a sense of what is happening and understand the value of what each team is working on.
There were weekly catchups where we would walk through the wishlist from the business and update them on progress.
What I tweaked here was to provide an update on what was delivered and in progress and provide a sense of how large an initiative was to the stakeholders. I noticed the attitude changed and they worked amongst themselves within that meeting how to prioritise their requests and allowed us to work on more focused goals.
Dealing with lots of adhoc requests
It was probably part of the territory where many requests would come through, from support requests from customer service, bugs and requests forwarded from the CEO.
We trialled a few different things, such as
- Having a general support ticket to allocate a % of time spent in a sprint on support and small bugs.
- Providing documentation and tools for customer service
- I was triaging and dealing with urgent support requests, before seeking additional help from another team member.
- We hired a dedicated technical support team member
Motivating a team
In order to be focused and ensure we hit delivery targets, I wanted to keep the team motivated and have clear outcomes.
I was and still am shy, but I realised that techniques such as whiteboarding were effective in getting people on the same page and encourage discussion and problem solving. If the team understood the why for the initiative and were a part of solutioning, we all owned this initiative together, were clear on outcomes and gotchas and could drive this together.
I also tried to keep things upbeat and tried to provide a happy team atmosphere. Having a happy team is important in keeping people engaged and respectful of each other. I wanted an environment where we didn’t blame, where we helped each other and be a strong team together.
Side note — we were the only team at the time allowed to roll out our own deployments (a massive win back then when developers were not trusted to deploy code themselves)
Be the Unblocker
If there was blocker, I made sure I unblocked issues. Either me personally unblocking or collaborating with another team to help.
It’s important to “make things happen” and take the load off the team so they can concentrate and focus on the task they have on hand. If a team member feels that they can handle unblocking something, I let them handle it but I helped provide guidance and support where needed.
People Matter
I brought back 1–1s and wanted to ensure people had that space to grow. I felt weird at first having 1–1s (I wasn’t wise, what if I gave bad advice?). I learnt that listening was key and being able to provide feedback was important too.
I also used this opportunity to grow more junior members of the team who needed extra guidance and learning challenges to grow their problem solving skills.
Relationships Matter
I was working and interacting more and more with different types of people and I valued and cultivated the working relationships I had with various people, whether it was the scrum master, devops/infrastructure team, testers or product managers. Each person was different and understanding them was vital. To this day I have high regard for each of them.
Time and Delegation
Initially I felt like delegating was akin to not doing my job. In reality, it wasn’t that at all. If I stretched myself too thin, then I was no good to anyone and I needed to recognise when to delegate and how to delegate. Delegation techniques were different for different situations and people too.
As an Individual Contributor, I disliked being told how to problem solve, I enjoyed asking questions, researching and coming up with my own solutions. I liked owning the problem. However this doesn’t suit everyone and this may not be applicable to more junior members who need more specific details and a bit more guidance and support.
Develop a New Routine
I also learnt to block out chunks of time in my calendar so I could have some time to focus on my own deliverables and tasks.
I also spent the first part of the morning working away from my desk (out of sight, out of mind) to clear away emails and tasks before heading back for standup and meetings for the day.
Look Around
I looked around and tried to support my peers too. They were also under immense pressure and they were my team too. We don’t work in silos, we should do our best to support each other.
Taking a Break
After a while I realised I missed coding too much and wanted to focus on other aspects of my life.
I took a step back and went back to being an IC, lived abroad and travelled.
During this time, I realised I missed being a lead. In some instances, I saw team members were not being coached (I myself was not being mentored or coached for a long while), I wanted to create a collaborative environment, I wanted to create a learning environment and I felt I could make a positive impact.
During this time, I made great friendships and tried to drive some initiatives to make the environment a better place. We as a group achieved great things which I’m proud to being a part of — from teaching retirees to use tablets (empowering them and growing the team’s empathy), holding external tech talks, supporting the tech community, learning workshops in the company and trying to inspire kids to consider tech as a career.
I also found myself gravitating towards management-type books, articles, videos and following tech leaders on Twitter.
Leading Again
I decided to pick up where I left off and try leading again. This time I reflected on the experiences from the past, cringed at the mistakes (learnings!) and was more considered in my approach.
What I wanted to achieve
- Create an open, fun and happy environment for team members to thrive
- Help grow and coach team members
- Ensure peers were supported too
- Create a collaborative environment and involve the team in making decisions
- Empower my team to own solutions so they could grow and learn
- Create a motivated and engaged team, who understood why we’re working on initiatives (tech and non-tech).
What I kept in mind
- Everyone is at a different skill level and has different preference on how they like to be guided
- I can’t do it all. I need to work on what is needed and important. I will always be time poor and need to choose how to spend the available time I have wisely.
- I need to be technical and learn the platform (I stepped into a new tech stack and had to be pragmatic with whatever time I had to learn what was needed first. I also invested a lot of time outside of hours to skill up)
- Create great relationships and collaborate with other areas of the business.
- Communicate to the audience and to their preference.
- Be level headed and constant. The team needs me to be.
- Enable the team, unblock and resolve issues.
- Do all I can to ensure cohesion and alignment.
- Be the sh!t umbrella
- Don’t be a bottleneck by picking up work that will block others. Also if I was too focused on my task like an IC, what would I miss seeing?
- What do people expect, need or want from me?
It’s an ongoing journey where I will keep making mistakes and I keep learning.
One last thing
What really helps on this journey is having a support network and people who can mentor, coach and guide you.
I was lucky to have had good examples of what good leadership looked like and had a couple of good leaders who helped support me through the process.
I can’t say enough how much their guidance has really helped and how thankful I am to them.
