3 Things I Wish I Knew When I Was Still An Engineer

I loved being a software engineer, or so I thought. On my last project working as an engineer, I fondly recall spending my weekends writing code to finish any user stories in my queue. It got to the point that I completed my work so far in advance that I was running a few sprints ahead of my team. I started to use my newfound free time during the week to sit in as many application requirement gathering meetings as possible. I began to collaborate more with our design team and shadow interviews with customers about the product we were building. I shifted into more of a mentorship role for our engineering team. At times, I found myself explaining the rationale behind a feature design decision and bouncing ideas around for an architectural approach in the same conversation. It took me a while to reach this career-changing realization; I was more interested in shaping the product than building it. 

I’m coming up on two years since my transition from software engineer to product leader. Here are a few things I learned working on the other side.

There were times as an engineer where I thought the jobs of my product owners and scrum masters were simple, and that the engineering team performed the real heavy lifting of building the product. After all, how difficult could setting up meetings, writing user stories, running agile ceremonies, and talking to customers be?

I was wrong. Even at the most basic level, there are intricacies to performing the roles that I hadn’t considered. 

Let’s take running a stand-up as an example. As a product leader, stand-up is no longer an opportunity to wake up and remember what I was working on yesterday. On most days, by the time my 10 a.m. stand-up rolls around, I’ve already talked to stakeholders, checked product metrics, and finished my second cup of coffee. The dynamic completely changed from me being a passive participant to being an active leader. It is now my focus to inject energy into the team. I am motivated to encourage succinct updates, deal with awkward sleepy silences, and elicit reminders to add comments to sub-tasks or review pull requests. I think about ways to keep the touch-base fresh by changing up the location or sharing a fun fact. I was operating under the false assumption that participating in scrum ceremonies meant that I knew how to lead them. Even with an extroverted personality (which I don’t have), running a stand-up requires a certain finesse that takes a lot of practice and repetition.

The number of new ideas and skills that I learned on the job surprised me. In my first few days as a product leader, I remember trying to write a python program as a substitute for a complicated Excel function. It didn’t go well. My eyes were open to the world of product budgeting and financial forecasting, status reporting, people and stakeholder management, communication and facilitation, sales, marketing, design, customer empathy, and the power of choosing the right tool for the right job. I can go on, but this leads me to the next point.

When thinking about what makes great code, my engineer self always clung to whether it followed industry best practices. For example, my code had to be written using TDD, have high test coverage, and comply with the principles of SOLID and DRY. These were concepts I lived and breathed more than anything. I held myself to a high coding standard. I kept on revisiting my code logic before submitting for peer reviews so that it was as optimized as possible. I figured that if I completed the user stories assigned to me to the best of my ability, then we would reach our goals as a team.

I now place more significance on code that isn’t perfect but is tested and works to specification. I view code as great if a new teammate can understand what it is doing and contribute to it with limited guidance. I learned that there are so many variables that can cause a product to fail that have nothing to do with code. For example, the user experience could be too complicated, there may not be enough budget available, the architecture can’t scale to meet demand, or the customer may not have an interest in the product or even be aware that it exists. I’ve transitioned into taking a big-picture mindset, and I know that a well-coded product does not guarantee success.

All that said, I found myself falling into several traps because of my technical background. At the beginning of my transition, I had a difficult time working outside of my comfort zone. I spent time reviewing code and pull requests that could have been better used to gain buy-in from clients on the product decisions I was making. Aligning with our stakeholders to create a shared vision for our product could have eased some of the team’s tension. Some of the user stories I wrote had built-in biases for a solution I already envisioned. I’m ashamed to admit that there were times that I would judge others on their technical comprehension and delivery speed. I wanted to dive in and write the code myself.

I learned right away that my ethos needed to change to be an effective leader. I pushed myself not to think like an engineer. The best way I was able to change my frame of mind was to follow the example of other product leaders and seek out the advice of those around me. One of the more impactful techniques I learned that I still use today is to ask my engineering leads to call me out when I am crossing into their domain. I’ve started to apply this strategy to other areas of life, and I can’t recommend it enough.

With a lot of practice, I’ve learned to use my knowledge of the subject matter at hand to build meaningful connections with my team. I can simultaneously hold my engineers accountable for their work while being their greatest ally in interactions with clients or stakeholders. When we are in sprint planning or backlog grooming, I don’t shy away from getting into the weeds of technical implementation. This approach has resulted in better acceptance criteria on our user stories and has given the engineering team more confidence in what they are building and why.

I’ll be the first to admit that I am still learning how to maintain the proper balance between technical knowledge and business depth as a product leader. But, there’s one thing I know for sure. It takes more than a team of all-star engineers to build a successful product, and that’s what makes the next lesson so pertinent.

Looking back at my days as an engineer, I wish I was more considerate of my peers running the scrum process. There were times where backlog grooming felt like a battlefield. We would often spend the meeting tearing apart a single user story presented by our product owner, discrediting each assumption one-by-one. I remember overhearing a group of business stakeholders arguing about how long it would take to change our app’s color scheme and if it was worth prioritizing over other possible feature enhancements. While they were still debating, I walked back to my desk and updated everything to the color they wanted. All it took was one small code update.

It was easy to get frustrated that our stakeholders were making commitments without a real grasp of the underlying technology. Even though there was an overarching architect present at most feature scoping sessions, they did little to mitigate the feasibility disconnect. I knew that working on some low effort features could have benefitted our customers, while some high effort features would not be worth pursuing.

Instead of approaching the situation with a cavalier attitude, it would have been more impactful to seek out opportunities to bring the team together. Hosting a short overview session to review our tech stack and compare feature complexities could have been very beneficial. Including a lead engineer, who was intimately familiar with the codebase, in more feature conversations may have reduced a lot of back and forth. And while it may feel productive to work on other things during a sprint planning session, the value of a fully engaged team can’t be understated. Keeping an open mind and taking simple concrete actions could have bridged the gap between the business and engineering teams in a healthy way.

I’m fortunate that every team I’ve had the opportunity to work with was so passionate about the products they were building. They always had the best interests of our team and customers in mind. It was too easy to forget that in the daily grind. I’m appreciative of each experience and how they have shaped my point of view. I’ve also come to recognize that balancing a combination of more accountability and less control can be stressful. I used to be able to work harder and break down a problem to get by. As a product leader, I realize just how much a product’s success depends on every member of the team doing their part.

It boils down to this. We are all working towards the same thing: building a product to delight our customers and achieve our business goals.

If you’re a product leader on a team, involve your engineers in your decisions as much as possible. Explain why you’ve prioritized one piece of work over another. Encourage engineers to interact with your stakeholders and expose them to the business problems you’re facing. I’d be surprised if you don’t gain new insights into existing problems or develop new perspectives about the future.

If you’re an engineer, don’t be like I was. Respect the people and the process because, who knows, you may be in their shoes one day.