In today's fast-paced tech world, understanding the intricacies of software development and product management is key to success.

In this enlightening discussion, we speak with Erik Costlow, a Senior Director of Product Management at Azul, who shares valuable insights from his journey of transitioning from engineering to product management, current industry trends, challenges in software development, and advice for new programmers.

With a unique perspective and wealth of experience, Erik's insights are sure to be invaluable for anyone seeking to navigate the complex landscape of the software industry.

Profile:

LinkedIn: 📇 https://www.linkedin.com/in/costlow/
Twitter: 🐦 https://twitter.com/costlow
GitHub: 🐙 https://github.com/erikcostlow
Mastodon: 🐘 https://mastodon.social/@costlow

Key takeaways:

1. The transition from Engineering to Product Management: Erik highlighted the importance of communication skills and understanding of business needs for making this shift. Practicing presentations, teaching material alone, and focusing on understanding why and what about the product can help in this transition.
2. Challenges in Software Development: Erik pointed out two key challenges - prioritization and managing expectations. Both are key for an engineer to transition into a more senior role or into product management.
3. Career Advice for New Programmers: Erik recommended focusing on a specific domain one is interested in and becoming an expert in it. Choosing a technology with good market demand (Total Addressable Market) is key.
4. Software Security Trends: With the rise of cloud, microservices, and connected architectures, there's an increased need for skills to evaluate how data is used in these systems.
5. Importance of 'Why' in Product Management: Erik emphasized the need for product managers to focus on understanding 'why' a product is needed, 'what' it does, and 'who' needs it, and letting other teams deal with the 'how' and 'when'.
6. Learning Security Isn't Hard: Erik mentioned that understanding application security isn't hard and can be achieved by asking the questions “what are you defending and what are you defending it from.” A card game called Elevation or Privilege by Adam Shostack can help beginners grasp this concept.
   

---

Fun fact: Erik used to perform in a circus, riding a three-wheeled unicycle while juggling fire. The wheels were vertical.

---

Bazlur: Can you tell us about your background and how you got started in the software industry?

Erik: I used to write tiny little programs from books and things. When I was in college, I just did fun little interactive things for my own website: a blog, a custom fan club with birthday messages, etc. As I wrote software, I also liked breaking it, so I had a security niche as well. Not a major hacker, but someone who knew which corners would be cut.

After a few years of working, though, I noticed a lot of other people coming to the engineering group and telling us what to do. I could build things, but these people would come to me from the perspective of building the business that needed the software, which I felt was a stronger position.

---

Bazlur: That's an interesting background, Erik. I know you currently work at Azul as a Senior Director of Product Management. Can you share more about how you transitioned from being an engineer to focusing more on the business side of software development? What specific skills or experiences helped you successfully make that shift?

Erik: The switch is work, but mostly a mindset shift into understanding what's important and why. Generally, there are three paths into a product:

• From Engineering, understanding what’s built, knowing how it works, and being able to communicate externally.
• From Sales, understanding why customers are buying and when and how your offerings can fit into that slot.
• From Marketing, knowing how to position and drive attention toward the thing that you are building.

I came from the first path. Ultimately, I felt “left out” of the discussion about where requirements would come from and why we were building the software. I handled this and worked on communication skills by doing software security consulting. Since the consulting was helping development teams evaluate and understand their code, I had a strong foundation in the material but limited experience in the other skills of managing expectations, handling non-tech deliverables, and so on.

The consulting experience helped me because I was able to focus on communication skills, writing, speaking, handling expectations, and so on. Early on, I was nervous about presenting, so before some events, I would go home and practice teaching the consulting material alone in an apartment. Instead of doing things for the first time in a group, this let me figure out things in advance and learn timing control, what felt complex, where to pause, etc. It felt silly speaking my own material in an empty room, but it worked.

For anyone who’s interested in moving into product from engineering, there are two big things to learn. Firstly, you’re not an engineer anymore. Even if you know how to build something, you keep your hands off it. Your new job is to focus on the what and why and enable other teams deal with the how and when. The second is really to focus on that why/what/who trio and learn to listen and communicate. Your job isn’t to make requirements; you’re supposed to notice them from how people explain their problems. Learn to paraphrase what people tell you so that you can explain what matters.

For anyone who wants specific materials, I will recommend two: Simon Sinek’s Golden Circle talk, where he explains to “start with why,” and look over the Pragmatic Marketing Framework. This framework starts in the top-left with market problems: what are you trying to do, and why does it matter.

---

Bazlur: You mentioned practicing your consulting material alone in an apartment to improve your presentation skills. Can you provide more tips or techniques for developing effective communication and presentation skills, especially for those transitioning from an engineering background to a product management role? And when is the right time to make this transition as an engineer? 

Erik: Yes, I’ll admit it felt weird and unnatural at the time, but let’s break down why it worked. Things sound different in our heads versus when we verbalize and walk through them. For presentations or training materials, the first time you deliver them, you don’t know the difference; the parts you think are short may be long, and vice versa. By forcing myself to verbalize them, I learned those differences before going in front of people – in engineering terms, speaking your material alone is the local test before the public commit/code review.

For switching from engineering to product, some people want to; some don’t; it’s about your interests. If you find yourself becoming more interested in “Why are we doing this” than “How are we doing this,” then it’s worth exploring. The best way to start is by learning the why and pal-ing around with customer-facing roles: customer success, pre-sales engineering, solution architecture, and the like. Once you start explaining and perceiving your product from the outside in terms of “why do I want this, and what is the customer solving?” then go talk to the product teams about the next steps.

I also want to be clear about what product management isn't because people with the wrong expectations will just churn with frustration. If you’re looking at the role because “I want to implement my own ideas,” then I suggest not doing that. You need to source ideas from or at least move ideas through people who want to solve your particular problem. You do this by listening, not convincing them why they want whatever ideas you have. You could have a great idea, but maybe it’s not the right problem to deal with right now. Teams that focus on the right thing often outperform even the best teams that do excellent work on the wrong things.

---

Bazlur: Let’s shift gears and talk about the current state of software development. In your opinion, what are some of the biggest challenges that developers face today? Additionally, do you have any advice on how to overcome these challenges?

Erik: There can be a lot of challenges, but I’m going to address some things that I think aren’t covered often enough: prioritization and managing expectations.

Prioritization is understanding and deciding what to work on. Early on, you sometimes don’t control your own priorities, but over time, you become more trusted in choosing what to work on and how. The difference between a junior and senior engineer isn’t just skill level; often, senior engineers are better at choosing what to work on because it addresses a more urgent or bigger priority.

Second, managing expectations isn’t just a technical problem. There are other stakeholders who don’t build software but are impacted by the decisions you make. These are questions like when will we have a certain feature, how will we understand it, how much is it going to cost operationally, and other things that matter. The positions of engineering manager, VP of engineering, and such deal with these questions more. As you work on the code, consider what information other stakeholders on the project are wondering about and help them shed some light on what’s going on.

---

Bazlur: Based on your experience, what advice would you give to new programmers who are uncertain about the prospects of their careers and are unsure of the steps they should take to ensure their careers are on the right track? With so much noise on the internet, it can be difficult for newcomers to navigate the field and determine which technologies to focus on.

Erik: I’d recommend choosing something you’re interested in and figuring out how to become one of the best people in that domain. The way VCs and product managers make decisions like this is by looking at TAM and SAM. TAM stands for the total addressable market, and SAM stands for the service addressable market.

When you pick a technology or vertical, find one you enjoy that has a good-sized market where the skill is needed. For the service addressable part, the advice I received was, “If you want to be valued at a company, do what that company does.” Generally, this means developers will do better in companies that view themselves as software companies or where software is an absolutely critical part of their business. If you want to work in a vertical like finance, that’s great, but you also need domain skills in finance beyond just the software.

When choosing your tech stack, pick a stack that has some staying power or is at the front of a market. Periodically learn new things and recognize that learning something new sometimes involves intentionally saying goodbye to knowledge that’s no longer useful.

An example for me is that, at one point, I learned Flex and ActionScript for making web apps. It was neat to try, but I realized there wasn’t much demand (TAM) for that skill set, so I said goodbye shortly after.

---

Bazlur: As someone with a strong passion for software security and expertise in the field, what are your thoughts on the current industry trends? With the growing need for software security, many new opportunities are emerging in this area. What advice would you offer to newcomers who may view it as a potential career path?

Erik: Software security is really broad, so I want to scope it a little. The specific niche of security that I’m interested in is application security, which is about how we build and manage applications in a way that can detect and stop attacks. With the role of the cloud, microservices, and connected architectures, there’s ample opportunity for people who know how the software works and is built. Unlike the last decade or so, when you just threw a web application firewall (WAF) in front and called it a day, now you need skills to evaluate how data is used behind the scenes. WAF is now like a mullet: security in front, software in the back, and it has no idea what’s going on back there.

On the job market, there’s a really good need for people who can understand risk and threats and map them up to architecture diagrams to figure out the right defense.

---

Bazlur: Thank you, Erik, for sharing your insights. I’m sure our readers will find them immensely beneficial. On a different note, do you have any enjoyable or memorable stories from your time in the software industry that you would be willing to share with us?

Erik: There are quite a few, but I can’t really get into the details of them. Those in the industry know exactly what I’m talking about, and those who want to guess what the stories are, you’ll probably be right.

One story where I can be a little vague is that a while ago, I had a service where I thought the bills were a little high. By logging in to my account and hitting F12, I was able to open other people's bills and compare the prices we were getting on similar things. Whether that’s hacking or not depends on who you ask, but I didn’t do a lot of it, and it was clear nothing could be changed, so the company wasn’t actually harmed.

---

Bazlur: Thank you so much for sharing your insights with us. We really appreciate your time. If we have any further questions, we will be sure to reach out to you. Before we end, is there any parting advice or resources you would like to share with our readers, such as a list of recommended books or any other helpful information?

Erik: On the security side, I think the goal of a lot of experts is to make it seem hard. It’s not hard, and you can get a foot into application security fairly quickly. The main questions are just, “What are you defending, and what are you defending it from.” If you’re brainstorming defences that don’t address either question, then don’t do that. The easiest thing to look at is a card game by Adam Shostack called Elevation or Privilege. You take cards that list a threat (what are you defending it from?) and figure out if/where in your software it applies. Some cards fit, and some don’t. Most importantly, you don’t need to be an expert to try it, and it’s really easy.

---

Conclusion:

From our enriching conversation with Erik, we glean that the software industry is as exciting as it is complex. Whether it's mastering the transition from engineering to product management, understanding the challenges and trends in software development, or getting to grips with the nuances of software security, the right approach and mindset can make all the difference. As technology continues to evolve and shape our world, it's essential to keep learning, remain adaptable, and always remember to view our work from the perspective of 'why', 'what', and 'who'. With these insights in hand, we can all navigate the software industry with a little more confidence and clarity.

Note: This comprehensive and insightful interview was conducted through various digital platforms, including Google Docs, email, and Slack. We are continuously working on improving our processes. So, if you have any feedback or suggestions regarding our interview method, please feel free to share them. Your input is invaluable in helping us provide an even better experience in the future.