Widen your impact as an engineer

Tara Ojo
6 min readFeb 27, 2020


Over the years, my understanding of what it takes to grow as an engineer and climb my career ladder has changed dramatically. When I started out, I was confident all I needed to do was to become an amazing coder. I thought I just needed to know how to build complicated features.

Though, when I looked at the careers of more senior people in technology, this didn’t really add up. Most CTOs and Technical Directors aren’t spending their time in the codebase and worrying about code quality in their day to day roles. Even technical architects and leads don’t always spend lots of their time writing code. While it’s still important, writing code isn’t their highest priority.

Now, my thoughts on growing as an engineer are pretty different. Seniority develops as your impact grows. Particularly as your work starts to impact and influence larger groups of people. When you think of a CTO, their job isn’t about the details. It’s more about the wider questions that impact the team they look after. When you think of a principal or an architect they’re all about defining technical strategy for the future, and making sure engineers have everything they need to do their jobs and do it well.

Groups of impact: me, my team, tech team, company, community
Where is your level of impact?

I’ve grown most as an engineer when I was doing things that were unexpectedly widening my impact. Firstly, I started developing my specialism. This meant people would start to come to me for support as someone experienced in a specific area. And secondly, I made things happen, thinking less about what could be better and instead taking action to make things better.

Develop your specialism

When you’re confused about a concept and can’t figure it out, who do you go to for help? For me it depends on the subject. If it’s a weird React thing then I know just the person for that, if it’s infrastructure related then I know the girl for that too. If it’s an accessibility question, I know a guy.

While there are lots of great full-stack developers out there, I generally go to specific people for more specialised questions. Lara Hogan has this great concept of developing a manager Voltron and I like to give it a technical spin. The idea is to have a diverse group of people that you can reach out to for support for different things. In my case, React, Accessibility, Infrastructure, CSS, etc. To flip this idea around, what could you help with in someone else’s Voltron?

Maybe people already come to you with certain questions because you have a bunch of domain knowledge in that area. Otherwise, think about what you would want that area to be. While it’s still important to develop a foundation in different areas, picking one or two as your “specialism” will help you focus your learning. The next step is making sure people know you’re the person to ask if they have questions. Be vocal about that topic and share your opinions in discussions, pull requests and essentially at any opportunity you get!

T-shape: The top of the T is your base knowledge and skills and the main part of the T is the depth of you knowledge

Having base knowledge in a wide variety of areas, and developing depth in some specific areas is commonly known as having T-shaped skills. As a new engineer, you’re generally feeling different areas out, but as your skills develop you’ll start to find areas to develop technical depth and as people come to you with questions, you’ll start to widen your impact.

Make things happen

I’ve met so many people in life with great ideas but lack the motivation to actually make them happen. I refuse to be one of those people! You’ve probably had ideas yourself of things that could be improved or potential solutions to problems. Act. On. Them. I had to force myself to push through the “I don’t know what I’m talking about barriers” and I still need to on a regular basis. So, even if you aren’t the person to do the actual change, make your thoughts known and make things better.

I’m essentially talking about being proactive.

proactive - adjective

  1. (of a person or action) creating or controlling a situation rather than just responding to it after it has happened.

I found this a pretty big mental shift, especially as a technical lead. As an engineer you can spend time picking off a to do list of tasks that someone somewhere in the company has decided is important. When you become more senior, people look to you to make those decisions!

You can only really prepare yourself for this is by doing it. Keep an eye out for opportunities that support the growth of your colleagues and see if you can work on it on the side of your normal role.

As an example, I did a 12 month graduate scheme at Marks and Spencer. I was one of nine engineers hired as a graduate software engineer, and we were distributed around the company. Some of the teams were iOS, Android, APIs and I worked on the front-end team. I was super nosey and wanted to know what others were working on around the business. I also wanted to learn a bit more about how the other teams in the business worked. I organised what I called a “Grad show and tell” where the nine of us would get together and share what we’d been working on. It was super low pressure because there were no senior people in the room and I got to see how my fellow grads were building things in Java, Swift and Python. We learned from each other and went away with wider knowledge about what was happening in other parts of the business. This is a small-scale example, but I saw an opportunity and then I made it happen.

You can apply this idea to lots of things. Generally, it’s about influence. You need to show that the thing you want to do is a good idea so you’ll need to consider how you’ll get people on board.

When I was offered an internal role outside of my grad scheme, I really put this into practice when asked for a pay increase. I gathered a bunch of data about current salaries in London for an engineer and asked for feedback from my team, so I could prove that I was at the mid-level I hoped I was. My influencing tactic was completely data-driven so when I walked into the meeting I booked with the director of the department, I only had to show him all my evidence and he agreed to the salary I wanted! This also had the benefit of bumping up salaries of my colleagues that would also be starting in similar roles.

Public speaking is another great way to widen your impact in the external tech community. You’re sharing your opinion in a very visible way with people from other companies. Not only is speaking great advertisement for the company you work for, but it can be great exposure for you personally. If you have a topic idea that not many people speak about or have a unique perspective on a popular topic, conferences and meetups will always want you.

When I say “Make it happen” I mean take the lead and do the work to improve things for your team, your department, your company and even the wider tech community. Whether that is making a refactor to make building features easier or giving an external talk to help with hiring, it’s all worth it 😊.

Focusing on these areas generally makes work life better for everyone you work with, as well as helping you build those skills that will help you to climb the so-called “career ladder.”

This post is a written and updated version of a section from my talk Junior.next(). Over the upcoming weeks I also plan to write about the other parts of the talk too :)



Tara Ojo

Software engineer @ Google. She speaks and writes about career progression and front-end development. @tara_ojo