Advice for Engineers on Effective Career Development

We recently had a visit with Erick Tai, Co-Founder and Head of Engineering for Reflektive (a performance management platform for the workplace) to talk about career development for engineers and some of the mistakes made along the path. Erick is not only Head of Engineering at Reflektive, but also an expert in management and mentorship.

Tai: When you stay in one position too long, you can become complacent and dull your sharpness. You will also likely be working with the same people, and eventually, you will learn all you can from them. It’s important to work on new projects in order to maintain your passion and sharpness. When the time is right, changing positions offers new vantage points you can learn from. Changing positions doesn’t necessarily mean leaving your company. The natural thing for people to do is look outside their current organization. However, you can also gain new opportunities by asking. When I was in a role earlier in my career, I wanted more leadership experience and asked if I could lead a team. They eventually gave me a team lead position. Before you leave a role, ask yourself if there are opportunities in your current position where you can still learn and grow. If the answer is no, then you have your answer.

Tai: It is absolutely a mistake to switch jobs too often. Being a developer is as much about learning as it is building.  But coding is a social thing. It’s why GitHub has taken off, as we give each other feedback in pull requests all the time.  People may think developing is all about people and their machines, but a huge factor to growing as a developer is the team we build with. It’s how we learn.  As with any team, you want to build trust, and with that will come honest, great feedback from teammates that will make you - and the team -stronger.  If you keep changing jobs, you’ll be that free agent that never gels with the team.  You’d be cutting yourself out of a lot of opportunities.

It takes time to build trust. Some of the best opportunities are presented when your manager has seen your work, understands your contributions and wants to invest in you. This happens all the time. Many engineers have stories about a great boss that gave them even greater opportunities because they’ve built up that trust together.

Tai: Not every engineer should become a manager, and it’s ok if you’re not ready to move into management even if that’s your long term career goal. Whether you want to become a manager or a senior architect, there are certain skills that set you up for success later in your career. Leading is knowing when to follow. It’s about making decisions on what short cuts to take that won’t hurt the product or end user experience, and which to avoid because while it might work now, you’re setting your team and company up for problems later down the road. I think sometimes people need to spend more time building out projects to better understand the variables that go into making the right choices. As an engineer, you have to understand how it all happens at lower level coding to understand how to make the right judgment calls.

Tai: Mentoring junior developers should be seen as an opportunity.  They’re your team members and your future aid.  Challenge them, grow them.  Your value as a developer isn’t just based on making code run efficiently on a machine with limited resources - it’s also based on how you can help your team build more with your limited human resources. Who wouldn’t want an amazing engineer who can make those around him/her better?  I’d want that person on my team and make sure they’re given the opportunity to fully leverage their influence.

Tai: Fifteen years ago, Java was hot.  Five years ago, Scala and Ruby.  Nowadays, it’s Go.  And how about all the Javascript frontend frameworks nowadays? And yet, they all work well and get the job done.  But as the world’s needs evolve, so do the tools.  Stick with one stack if it helps you get the job done, but don’t be afraid of new stacks if they’ll get the job done even better.  You don’t hire a great hammer-er to come fix things broken in your home.  You find a great contractor who’s willing to learn and use the right tools for the job.

Tai: Whether you want to be on a management track or a development track, you should first identify what you define as “success.” You don’t need to know exactly where you want your career to end up, but you can look to senior leaders in your company and ask yourself if you want to be in their role down the line. I’ve always focused on being able to help other people accomplish their goals; this is why I’m drawn to management. I set goals for myself along the way to obtain more leadership opportunities, and when the time was right I asked for them. For any engineer, it’s important to set a goal to write clear code that can be understood by other engineers long after you’ve left the project. A great engineer is someone who writes code in a way that is easy to understand, so that someone else can leverage and reuse. Think about what skills you need to develop to become the senior architect or manager you want to be, and then set goals to achieve those in realistic timeframes throughout your career. Never stop learning and growing.

Tai: Very early on in my career, I was sitting in on a “mind opening” brainstorm session: “Let’s come up with several usages of RFIDs and how it would change the food industry in five years.”  The group encompassed those with engineering backgrounds as well as those who lived in the world of business. Well of course, RFIDs would make a huge impact on logistics.

Other engineers and I started brainstorming about RFIDs in warehouses, then on trucks for shipping.  You could then figure out where things are headed and potentially route things better and to what supermarkets. It was perfect.  It made incredible sense.  What a great brainstorm.

Meanwhile, another team with non engineering backgrounds came up with their ideas. Let’s use it for logistics in warehouses and shipping.  How about RFIDs in the supermarket aisles for coupons?  What about RFIDs that work with a reader at home to let you auto-scan groceries you already have in your home so that restocking shipments are automatically ordered for you?

The breadth of the non-engineering brainstorm vs the tunnel vision of the engineering approach reminded me of how problem-solving oriented we are as engineers.  We have to remind ourselves at different stages of engineering to zoom in or zoom out to make sure we’re solving the right problem – or that we’ve even identified the right one.  A lot of this has to do with working with the right people and, listening to others’ ideas.  Our job as engineers is not only isn’t just to come up with solutions, but also rather to identify the opportunities for solutions.  To do that, you need to work as a team, communicate well, listen, and be flexible.