Welcome to my monthly newsletter. I'm an experienced software engineer, a tech mentor to product managers, and the founder of Skiplevel. Every month I share:
- technical skills and knowledge you should know
- tips for working with and collaborating with dev teams
- tips for non-engineers struggling with confidence in technology
- tips for managers looking to build a more technically literate team
Ask me anything (yep, anything) and I'll cover it in an upcoming newsletter issue!
This month's Tech Term you should know:
For security reasons, browsers by default restrict cross-origin (two different domains) HTTP requests initiated from scripts. This is what's known on the internet as the same-origin policy.
CORS is a way to overcome the same-origin policy. CORS (short for Cross-Origin Resource Sharing) is an important security measure on the internet that allows owners control over who can access their domain resources. CORS allows a server to set which origins (domain, scheme, or port) other than its own that they will allow loading access from.
For example, if a developer who owns https://domain-a.com tries to load content from another website https://domain-b.com, the browser will restrict this access since they're two different domains.
In order to allow access, domain-b would need to set their API response header to allow all access (denoted by *) or allow access to your domain specifically.
What you need to know about CORS as a PM:
Building software is a complex process and unforeseen complications often arise during the process. As a PM, you should be aware of as many of these possible complications as possible, including the same-origin policy that may delay time to implement.
If a feature your engineering team is working on depends on a third-party, the development team may need to get permission from that third-party in order to gain access to their resources. As you can imagine, complications would arise if the third-party says no, or takes a long time to update their system configuration to allow access from your domain.
Tip: Anytime an engineer refers to "same-origin" or "cross-domain concerns" or "access control", it's likely they're referring to CORS.
Q: How do I build trust quickly as a product manager in an engineering-led organization (i.e. Engineering Directors have the final say)?
Asked by Product Manager @ Activision
Hi Product Manager @ Activision,
The quickest way to build trust in an engineering-led org is to show the engineering team that you’re both able and willing to empathize with, learn about and support their work. There’s a lot that goes into these that I’ll discuss in this article.
First, you should understand the difference in motivations behind product-led teams and engineering-led teams. While product-led teams make decisions based on product vision and how the product meets a set of customer and business objectives, engineering-led orgs place the decision-making emphasis on innovation and execution. This means solving technical problems with the least effort in the most scalable way. Your engineering manager is primarily concerned about the strength of the engineering team, solving technical challenges, and what is possible with technology.
With that in mind, do the following to build trust as a PM in an engineering-led org:
- Empathize with the engineering experience, concerns, and considerations
- Be curious and willing to learn technical skills
- Ask how you can support their work
Build trust through empathy.
Empathy can be a “crunchy” adjective that lacks specificity. We throw the word around often but less often talk about the how. What does empathizing with engineering actually look like?
While you’re not expected to know how to code, it’s important for the engineering team to feel you know what you’re talking about with at least the fundamentals in order to build trust.
Much more goes into creating software than just coding. To truly empathize with engineers is to possess an understanding of the software development lifecycle (SDLC) a.k.a the process of developing software and have some idea of what it takes to build reliable and maintainable software. Engineers must consider data design, architectural, and infrastructure decisions. To create maintainable and bug-free software, engineers must also consider and implement testing features, logging, alerting, performance monitoring, and more. There’s also decision making behind how to release software: deployment pipelines, staging environments, and rollback measures. These are just a few of the complexities that engineers must juggle while balancing technical trade-offs like scalability, fault tolerance, security, maintainability, ease-to-implementation, time-to-implement, and more.
You’ll need to have a moderate breadth of knowledge about all the above topics (and more) in order to develop your “engineering mindset”.
Possessing this level of empathy will help you engage with the engineering team that integrates the product <> engineering disciplines in a meaningful way.
Be curious and open to learning
The journey of learning technical skills and building a strong technical foundation is anything but quick. It takes time and lots of practice to build a strong level of empathy for engineering concerns and considerations.
But you don’t need to be a technical expert off the bat to gain engineering’s trust.
To build trust quickly with engineers, simply show interest and be willing to improve your technical skills and knowledge through self-learning and asking questions.
Being curious and openness to learning is an attractive trait period. When engineers see a product manager putting effort into learning technology, what they see is:
- Someone willing to understand and appreciate the complexity of their work
- A team player that’s willing to contribute to the ultimate goal of shipping awesome software
The majority of people want to help, so even if you’re struggling, the engineers on the team will be patient in teaching and explaining and this relationships inherently builds trust.
Ask how you can support their work
One of the easiest and most effective ways to gain the trust of engineers is by doing the following:
At the end of the every engineering meeting and discussion, ask “What is ONE thing that I can do that will make your job easier?”.
This simple addition shows you’re willing and ready to support them by taking superfluous tasks off their plate so they can spend more time on building.
Here are a few examples of tasks you can take off your engineer’s plates to enable them to do their best work:
Got a question? Ask me anything & I'll cover it in an upcoming issue!
Hot Twitter Takes 👀
Normalize👏 investing 👏 in👏 Tech👏 Health. This is such an awesome reminder to all of us (myself included) to focus on the positive rather than the negative.
What are some ways you and/or your tech team invests in tech health?
I asked the PM community on Twitter for their advice on working with engineering teams. Here are my fave responses:
I need your help! How can I improve this newsletter?
I put in a lot of time and effort providing you with the best technical literacy content, and I need your help. Tell me how I can improve this newsletter.
Want to feel more confident in your technical skills?
Missed the mid-month PM & Tech Jobs Newsletter?
Looking for a new PM role? My team and I decided to create a shorter newsletter issued twice a month with a list product role job listings from senior to entry-level roles.