DEV Community

Cover image for The Secret to Growing Your Career is Not Being a Better Engineer
Arctype Team for Arctype

Posted on

The Secret to Growing Your Career is Not Being a Better Engineer

Developers that rise through the ranks at tech companies to become directors, vice presidents, and even CTOs all have one thing in common that isn’t discussed often: a strong understanding of the company’s business objectives and how their product fits in.

A surprising number of engineers often feel that everything that isn’t related to the technical details of a project is someone else’s responsibility. I discovered this gap when I worked at a large company with tens of thousands of software developers. Last year, the incoming cohort of associate software engineers was nearly 1,000 people. In this post I will describe what I learned moving from software engineering to product management.

Table of Contents

  • Benefits of Thinking like a PM
  • A Smart Way to Level Up
  • 5 Things a PM Should Know
  • Conclusion

Benefits of Thinking like a PM

The side effect of trying to get more business and customer context was I actually became a substantially stronger engineer.
Your mindset could be a big reason why you might be having a hard time moving to the next level in your career. Putting in the time to understand the bigger picture from both a customer and business perspective can benefit you tremendously in many ways:

  • Your ideas address root level problems rather than surface-level issues
  • You have an easier time communicating with leadership because you can better articulate how the obstacles you face affect the org and not just your team
  • You have a higher level of appreciation for your work because you understand directly how it impacts the company Luckily, for most developers, getting business and customer context is fairly easy!

A Smart Way to Level Up

Strike up a conversation with the closest PM to your team and you’ll be amazed how much you can benefit from building a good relationship with them. The first thing to know is that a product manager’s main job is to make sure what you are building solves for customer needs in a way that also positively impacts the company’s bottom line.

Furthermore, they should inspire you to do your best work and empower you to create a great product. If you understand their role then you will be able to utilize their knowledge.

5 Things a PM Should Know

So with the goal of improving your output, gaining influence within your company, and improving your job satisfaction here is what you should learn from your product manager:

Key Company Objectives

A good starting conversation to have with your pm is about goals. Start broad and first make sure you truly understand your company’s business. Ask your PM what they think is the company’s long term goals and short term goals. Then work your way down the company hierarchy to better understand how your department’s long and short-term goals fit in. Once you have a good understanding of how the various company goals align with each other, your team’s own work should make more sense. Context is everything!

Macro Environmental Forces

Your company does not exist in a vacuum. Successful companies are constantly adapting to the macro environmental forces around them. This can range from interest rate changes and new government regulations to natural disasters. It is important to have an understanding of what external factors might affect your company and how your company might react. Engage in conversations with your leadership and product manager when you notice external trends and get a sense of how your team might be affected.

Speed vs Cost vs Quality

Generally, a team can only prioritize two out three between speed, cost, and quality at any given time. Product Managers often don’t directly articulate which two they are prioritizing at the moment. To further complicate things, priorities will shift over the product development cycle. Asking your PM what they think is most important periodically will give you clarity and advise you on how you should approach your work. Plus, having a conversation around this topic will also force your PM to think about what they value most at the time and articulate it.

Product Discovery

PMs are always looking for new opportunities for their teams. The process of understanding customer need and thinking of solutions for those needs is called product discovery. Many times the best ideas come from engineers and designers. Showing enthusiasm for helping your PM find the next big opportunity is an excellent way to build a strong relationship with them and gain influence. As an engineer, you will have a unique perspective on what problems your customer faces such as identifying problems through support tickets or noticing unique ways customers use your product that might not be obvious.

User Interviews

Product discovery leads to new ideas but before the team spends time building those ideas, it’s important to do user testing using prototypes and proofs of concepts. In fact, user testing is an ongoing activity as your team iterates on your product over time. As an engineer, it’s easy to get caught up in coding work and forget who you are building the products for in the first place. Seeing customers engage and potentially struggle with your product in real-time will give you a new sense of ownership and purpose. Many times you might notice small fixes you can make that will make the experience much better for the customer.

Conclusion

As you get a better understanding of the business context and empathy for your users, you can engage with your PM in more meaningful ways. Having a good relationship with your PM means your opinion will matter and carry weight. Use this to your advantage to directly influence what your team builds, not just how they build it.

Top comments (2)

Collapse
 
damjand profile image
Damjan Dimitrov • Edited

I totally agree! Once I also developed a mindset which includes a business perspective to development, I also feel like I became a better engineer myself.

I have one question: at the start of your post, you mentioned "I worked at a large company with tens of thousands of software developers"... For real? This can't be possible

Collapse
 
rettx profile image
Arctype Team

It was a large bank. At my old company, 40,000 people wrote SQL on a weekly basis.