visit
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.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.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.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.