How technical do you have to be? (Engineering)

Joseph Akoni — Tue, 28 Jul 2020 11:55:22 +0000

You’ve probably heard rumors that only technical Product Managers survive and as a novice PM who studied Art History, you’re probably thinking “Why TF did they hire me?”

Well, besides your being available to give insight into the exact age and cost of the paintings that Bobby Axelrod just purchased in Billions, they probably also think you’ll be a fine PM without the “formal training” of an engineer…and they’re right!

Are you required to have written an API from scratch to be a solid PM? No

Are you required to know how to properly define a function to be a solid PM? No

Do you have to understand the concepts of polymorphism or object instantiation? No

Are you required to have spent 80 hours coding the Tomasulo algorithm from scratch using Verilog when you never actually coded Verilog a day in your life and your teachers barely spent any time teaching you Verilog in class and even less time teaching you what the Tomasulo algorithm even was?! No (sorry, having flashbacks to my Computer Architecture class)

The short answer to the question “Do you have to be technical?” is no. I know PLENTY of AMAZING PMs who don’t have engineering degrees.

Another question could be “Does having formal technical training help?”

Of course it does. Anyone who has told you that having a technical background does not help in any way, shape, or form is not being honest with you. ANY related skill or knowledge you have prior to starting a job can help you. Alternatively, you must take into account that simply having a skill does not necessarily mean that you know how and when to apply that skill to ensure your success at your job.

Having a certain skill or knowledge does not guarantee that you will be successful. Being a technical PM does not guarantee your success. Which means that, yes you the journalism major, can be a successful PM too.

Being a technical PM does not guarantee your success. Which means that, yes you the journalism major, can be a successful PM too

The P-Zero PM Tweet This

Here’s an example for my sports fans out there:

Take former NFL Wide Receiver Darrius Heyward-Bey for example. He ran the 40-yard dash in the 2009 NFL combine in a whopping 4.3 seconds. That man was fast! In his 10-year career, he caught 202 passes. To put this in perspective, Michael Thomas, one of the NFL’s premiere receivers, caught 149 passes THIS PAST YEAR ALONE! Michael Thomas had a 40-yard time of 4.57 at his NFL Combine which is considered “slow” for a wide receiver. The skill (speed) did not automatically generate results on the field (catches).

Another example is Paul Pierce, the self-proclaimed top 5 greatest players to ever play in a Celtics uniform. I’m in better shape now than Paul PIerce was in his prime. Despite this, Paul Pierce was a 2008 NBA Finals Champion and NBA Finals MVP. His lack of skill (athleticism) did not deter him from being an NBA champion. He amplified his other talents effectively and efficiently and he was athletic enough to get the job done.

So don’t let not having significant technical skill deter you! You can still be an MVP PM. Focus on the other PM skills that make you stand out (Relationship building, creative idea generation, excellent communication, data analytics, the keen ability to turn user research into a viable solution, the list goes on…)

When it comes to any area that is outside your knowledge zone, leverage the expertise around you as I mentioned in the Prod Squad article. In this case, you’ll be leveraging your team’s technical expertise.

Let’s think of this another way…

Your goal should not be to focus on whether you should “be technical” as in having some form of a formal technical training through a bootcamp or degree program. Some of your engineers have been honing their crafts for literally over a decade. It will take you a long time to catch up. You must focus on being technical enough. You have to balance Knowledge Attained and Time Spent Attaining That Knowledge. You can take a 6-month engineering bootcamp which takes you deep into the abyss of engineering concepts or a couple 3 hour courses on Udemy that give you a good overview of software development. Every PM will not have formal engineering training but any PM can be “technical enough” to be an amazing PM.

Every PM will not have formal engineering training, but any PM can be technical enough to be an amazing PM.

The P-Zero PM Tweet This

Tips for being technical enough

1 . Focus on the WHY not the HOW.

How your engineer must update code is honestly none of your business, lol (but really, it’s not). You are not being paid to understand the intricacies in coding standards. You should trust that your engineer will implement the solution in the most efficient way. If you don’t trust your engineer, well that’s an entirely different story…

Why your engineer is making a code change is completely your business and you should ask Why because this could impact product decisions and timelines. For example, if your engineer says she’s delayed because she has to update code to enable a user to receive a text confirmation immediately after editing a setting, but you have not prioritized text confirmations, your engineer could be wasting engineering cycles on something that’s currently unnecessary. Wasted engineering cycles will affect your launch date, and pushed back launch dates are no bueno.

Note: There is an exception to this rule which I will cover in a future article that I’ll call “When data is your product” because if the “feature” that you are developing is data (i.e. displaying a new type of information to a specific audience), then you may have to dip into these if-else statements. Fun stuff!

2. Understand all of the naming schemes related to processes, databases/storage, deployment environments, etc within your company – Your engineers will casually throw around terms like “The Envoy B1 Omaha Omaha Blue 42 system” referring to the test environment in which they develop products in. If they have to explain what “The Envoy B1 Omaha Omaha Blue 42 system” is to you EVERY single time they speak to you, they will hate you, lol (no but really they will).

3. Understand basic engineering terms and how they work in practice. You may hear your engineers use terms like “client-side, API,databases, backend, server, codebase, machine learning, data structures, page load time”. You should know at a high-level what these mean so you can communicate efficiently with your development team. This site, Top Programming Terms and Definitions for Beginners, has a good list of engineering terms to familiarize yourself with.

4. Learn how the core architectural components that your engineers work with are connected to each other – You won’t know how to write to a database, but after completing steps 2 and 3 you will know a database stores information and a codebase is where your engineers’ code is stored. What databases are written to when a user enters in information on your website? What codebase gets updated when your iOS engineer makes a code change? These are the types of high level architectural questions you should know the answer to.

5. Ask questions when you hear an engineering term you don’t know! The only way you can learn is by asking questions! If you hear an engineering term you don’t know, ask immediately what it is. If you wait and assume you know what it means because you don’t want to come off as “unknowledgeable,” then you will for sure look “unknowledgeable” when you attempt to use the term incorrectly in the future. My main mantra is “The only stupid question is the one that is unasked”. Trust me, I ask A LOT of questions.

Benefits of being technical enough:

1. Communicate technical details more broadly more easily – You will be better equipped to explain to anyone why certain technical decisions were made. For instance, if you are asked why the engineering timeline was set a certain way by an executive, you’ll be able to answer with confidence.

2. Communicate with your engineers more easily – It will allow you to have smoother communication with your engineers. When your engineers use terms you don’t know like “The Envoy B1 Omaha Omaha Blue 42” you’ll know exactly what they’re talking about without missing a beat.

3. Make faster and better future decisions – If you have a good high level understanding of your technical architecture, you can prioritize future features more quickly based on the technical requirements they require.

4. You’ll feel cool – It will make you feel cool that you spoke with an engineer about something related to software/hardware architecture (because engineering is cool, ya dig?)

5. Your engineers are doing things that an HTML/CSS course won’t help you grasp. Things your engineers are doing may be wayyyy more complicated than anything you learn in a CSS/HTML course. You may say, “Great! Then I’ll spend the next 6 weeks learning the difference between instantiation and initializing, threads and processes, stacks vs queues, and protected vs private variables.” Remember, you were not hired for your engineering expertise. You can’t code, it’s okay. Put the C++ book down. You were hired for your ability to unearth and analyze a problem, create viable solutions, and (most importantly) your ability to work with technical experts to deliver these solutions.

6. More efficient use of time. You will spend more time strategizing on how to build the next great product and less time trying to learn to code the Tomasulo algorithm from scratch to impress your engineering manager. They’ll think it’s cool for like 5 seconds and then ask what feature are you prioritizing for them to build next quarter (because shipping products > your new website you coded from scratch).

Whew! That was a lot.

In Summary

If you don’t have a technical background, don’t sweat it!

Amplify your non-technical strengths
Be technical enough and leverage the engineering expertise around you
Smile and be great.

I believe in you.

The post How technical do you have to be? (Engineering) appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

Engineering Archives - The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career

How technical do you have to be? (Engineering)

Tips for being technical enough

Benefits of being technical enough:

In Summary