Want to become more technical in just 5 weeks? Find out how the Skiplevel program can help.

I’ve worked with lots of product managers as a software engineer. Most of them don’t have an engineering background and they realize having some level of technical acumen is extremely valuable for their career in both the short and long-run. So when product managers ask me whether they should take a Python coding class to become more technical, my response is always, “That’s probably not the best idea.”

Don’t get me wrong–it’s not that learning how to code isn’t useful. It’s just that taking a coding class once won’t make you technical. Let me explain why.

Why taking a coding class won’t make you more technical

Think of it this way: just because you learned how to use a hammer and a screwdriver once, doesn’t mean you now know how to build a house. In a coding class, you learn basics like how to assign a variable, or iterate through a list of items using the syntax of a specific programming language, but learning how to build an app that’s capable of real functionality takes lots of trial and error and years of practice.

If your goal is to become a developer and build apps, then you should take a coding class and set upon the long and arduous (but hopefully fruitful) journey of learning how to build real functionality using the programming language you just learned. But if you’re a non-engineering tech professional that wants to become more technical quickly, then learning how to code is the least effective path for you.

So if taking a coding class won’t help you become more technical, what will? Well first, let’s break down what it really means to be technical.

What does it really mean to be technical?

“Being technical” is a phrase that’s thrown around a lot, but it’s not very specific. What exactly does being technical mean? Despite the term’s prevalence, most people have trouble defining it.

That’s because we often view being technical as a single skill that we correlate strongly with the ability to code (which in itself is also very vague–does taking a coding class mean you now know how to code?).

In reality, being technical is not just a single skill–it’s a bunch of interconnected skills. Specifically, there are four of them.

1. Knowledge of Available Technologies

The first is having a broad knowledge of the available technologies at your disposal. Here’s an example: If you wanted to make an application faster, you can use Cloud Delivery Networks, client-side caching, application caching, concurrent processing, server-side rendering, single page applications, and much more. You get the idea.

There are lots of tools and techniques (available technologies) engineers use to achieve desired functionality and traits in software. The more technical you are, the more tools and techniques you’re exposed to and know how to use in both common and creative ways to solve problems and deliver on product specs.

This leads us to our second skill: the ability to think through technical trade-offs.

2. Ability to think through Technical Trade-offs

When engineers make decisions about how to build a product given its specs, they’re constantly evaluating the trade-offs of using different technologies (or at least they should be!)

I’ll give you an example using our previous use case of making an application faster for users. To achieve this, engineers may consider building the UI as a Single Page Application (SPA) or implementing server-side rendering (SSR). In deciding which technique to implement, it’s very helpful to know the pros and cons of each. If your app sees a lot of user interactions, SPAs provide a faster and more dynamic user experience. But if SEO is an important part of your marketing strategy, and shorter implementation time is more important, then SSR is a surer bet.

In reality, there are still more options like browser and server-side caching–each with their own strengths and weaknesses. So a big part of being technical is not only being aware these available technologies exist, but also being able to evaluate their trade-offs in order to balance product and technical requirements.

3. Ability to Communicate Technical Concepts while using Technical Jargon

The third skill is being able to communicate technical concepts while using jargon. Many product managers I talk to confide in me how difficult it is to communicate with engineers. And I totally get it! Technical jargon can be intimidating for many professionals working with engineers. This is understandable. But unfortunately, jargon is a necessary evil and it’s here to stay. Here’s why:

Every field or area of activity has their own specialized terminology. That’s because each field has its own unique context, and it’s quicker to use specialized terms or lingo to express an idea within that context. For example: It’s quicker to say “microservices”, instead of “small applications organized around a specific business capability, deployed onto its own servers, that communicate over a network”. See what I mean? This is why having the ability to communicate technical concepts using specialized jargon is a crucial part of being technical.

4. Knowledge of the SDLC (Process of Building Software)

Here’s something that’s not always talked about: building software is hard. Like really hard.

Building software doesn’t allow room for interpretation–the computer executes commands exactly as they are written. Unfortunately, humans are prone to mistakes and we make errors all the time, including while building software. This means bugs will inevitably make their way into our systems. And it’s not just the coding part that’s hard, it’s the designing of the system that’s also hard. We tend to forget the internet is a physical thing, and a large part of creating software is trying to finagle physical machines to serve and scale our apps reliably and quickly.

This is where the process of building software, also known as the software development lifecycle (SDLC), comes in. The goal of the SDLC is to mitigate human errors, and provide structure to an otherwise complicated and unruly endeavor. So if you want to know what it takes to build thoughtful and resilient software, learning the SDLC will be an important part in your technical education.

Become more technical by targeting the four technical skills above

Now that we’ve broken down the specific skills for what it means to be technical, it’s easy to see why taking a coding class won’t get you there.

The good news is the four skills you just learned are interconnected, meaning as you’re being exposed to new available technologies, you’re also learning new related terms, and their strengths and weaknesses. You can use the four technical skills to help organize the information you’re exposed to while on the job, through online content and books, or through an on-demand course like the Skiplevel program.

The Skiplevel program helps professionals become more technical without learning how to code by teaching students the four technical skills above. Students learn the fundamentals of technology while being exposed to a wide range of technical terms and available technologies. If you’re a non-technical professional, this program was created to help you feel confident about your technical skills during interviews and while on the job!

Positive feedback is feedback too!

We often think of feedback as “critical feedback”, but positive feedback is just as important! Team cohesive and effective teamwork ultimately comes from a place of positivity and a sense of forward/upward momentum. It’s difficult to have these when just focusing on critical feedback. You want to know what you’re doing right along with ways you can improve. So as much as possible, ask for positive feedback like “What did you like about [x] that you’d like to see me continue doing?” and “What was your favorite part about [x]?”

If you want to level up your technical skills and your ability to communicate and collaborate with engineers, enroll in the Skiplevel program. The Skiplevel program is a comprehensive, on-demand course + community that helps you become more technical without learning how to code.