Software is becoming a bigger and bigger part of our lives, but do we actually understand how it works?
We might be the tech savants in our families, and know our way around a smartphone or laptop. But that’s just the surface; the reality is that most of us don’t actually understand how most of the technology we use works under the hood. If you had to explain to me how the internet works, could you do it?
Obviously we don’t need to understand everything we use, in the same sense that we don’t need to know why boiling potatoes in water with baking soda makes them taste better when roasted, or why ice reduces swelling. But technology is a lot more practical than that, because a lot of people work at companies that sell software. And everybody works at companies that use software.
These are important things to remember, because although we hear a lot about how we’re in the golden age of software engineering — nobody can hire developers fast enough — an underappreciated reality is that inside startups and tech companies, most roles aren’t technical. Every organization employs marketers, salespeople, recruiters, and executives whose job descriptions don’t involve any meaningful knowledge of computer science or even basic HTML, but whose professional lives and workflows are dominated by software nonetheless.
If you match this description, ask yourself: Do I understand the basic concepts underpinning the software I use to do my job or what it is that my company actually builds and sells? These questions aren’t rhetorical. Becoming more technically literate will help you work better with engineers, identify chances to automate or improve your workflows, and become a whiz in the tools you use to get your job done and help the business grow. In short, technical literacy provides a path to excel as a non-engineer in a field dominated by engineers.
Technical literacy does not mean learning to code
People think about “being technical” in a binary way — there are software developers who know how to code, and there’s everyone else. But learning how to code is a hefty undertaking: you’re looking at hundreds or even thousands of hours of precious time. Plus, there are sizable financial and time investments if you want a degree or even just to graduate from a bootcamp. While in some ways building apps has never been easier, today’s developers need to understand vastly more domain-specific tools than in the past (e.g. how to use npm or storybook).
If you don’t want to be a software engineer, what’s the point? If this is what being “technical” means, then for most it is completely inaccessible.
This binary view of technical literacy is memorialized in the classic meme about how movies comically misrepresent what software engineers actually do. In any given film, you can expect to see “coders” doing something like this:
This “code” is actually an SVG file from Wikipedia, which is basically a representation of an image (like a rectangle); in other words, it’s not really something you’d ever see a software engineer “coding” in real life. The point the movie is trying to make is clear: whatever these coders are doing is complete magic, we have no chance of understanding it, and we might as well just brush over it since nobody will notice. (Credit to The Social Network for at least trying to be accurate.)
As you’ll see, though, things are way more nuanced than that! Being technical is a spectrum — it’s not one size fits all — and there are lots of different places you can settle. You don’t need to be a developer to understand the differences between file types, and to know that an SVG is a type of graphic used for design. And if you’ve been in a startup office, you probably know that developers don’t write code on see-through holographic screens.
You can think of it just like playing an instrument. There’s a big difference between being able to strum a few chords on guitar and being able to rip out a gnarly solo. Both are great, and utility purely depends on what you’re trying to accomplish. Technical literacy is no different. You don’t have to learn how to code to benefit from knowing what code is and how it gets written.
Being technically literate simply means that you’re comfortable with the basics of how technology works, and critically, you understand the area you work in with more depth. Useful and practical technical literacy has two layers:
- The base: The basics of software and hardware.
- What’s a computer?
- What’s the internet?
- What’s a database?
- The domain: Deeper knowledge that’s relevant to your job.
- What products are we building, selling, and using?
- How do they work? What problems do they solve?
- How do our engineers build and use them?
- How do your team’s tools work?
If you’ve read this far, you’re hopefully convinced that there’s a place for you on the technical literacy spectrum, and that you don’t need to be a developer to be someone who understands the basics. But what’s the point of being technically literate? There are two big ones for folks at startups and tech companies — understanding and working with developers, and being an expert at the tools you need to get your job done.
The importance of working with and understanding software engineers
If you work at a startup, chances are you’re going to need to collaborate with developers. That work could be internal — on internal tools, integrations, providing expertise, etc. — or it could be external — marketing to, selling to, and recruiting developers. Either way, being able to communicate with them is a hugely valuable skill.
In my experience, developers can be some of the most curious, thoughtful, and creative people to work with. But from afar, they can appear intimidating at best and downright scary at worst. Developers have reputations — earned or otherwise — for being a tough group with high standards and particular tastes. But like any other audience, most of that perception stems from them being different. Understanding the basics of what code is, how it works, and what developers are doing every day will help break down that barrier and engender collaborative relationships.
For some roles, working with developers is part and parcel of the job description. Imagine you’re a product manager at a consumer startup working on a big new feature launch. You want to understand what it takes to build the architecture for your spec. Is this a two-day thing or a 20-day thing? How do you interpret and allocate time for delays? How difficult would it be to adjust a piece of the user experience right before launch? In many ways, product management is about setting expectations, and it’s hard to do that with no understanding whatsoever of how the sausage is made.
But developers aren’t only internal stakeholders. Imagine you’re on a marketing team at a B2B startup that’s launching a new product line for developers. How do you articulate what makes the product interesting? What kind of content should you write that developers might find interesting? Where should you distribute and promote it? Marketers need to understand their audience to create and distribute compelling content.
In situations like these — and many others you’ve probably already been thinking of — understanding developers and the basics of what they do will take you a long way. Here are a few ways technical literacy matters for common roles:
This one is simple: the entire job of a product manager is predicated on working well with software engineers! Without understanding how they work — and the basics of what code they’re writing to build your spec — you’ll be looking at a black box. Effectively prioritizing feature work, keeping tight timelines, and aligning stakeholders is all predicated on understanding the work your developers are doing. And as a developer, wouldn’t you prefer to work hand-in-hand with someone who has taken the time to understand your craft?
You don’t want to step on your developers’ toes and get too involved; there’s definitely a balance to strike. But as a general rule, for product managers technical literacy is non-negotiable.
Technical recruiting is widely considered one of the most frustrating hiring bottlenecks at startups today. Recruiters are tasked with finding qualified developers, understanding which types of roles are relevant to them, and being able to explain why a particular role is a compelling and interesting challenge. Technical literacy can help recruiters more quickly identify strong candidates, speak intelligently about internal engineering organization, and articulate what kinds of interesting engineering problems candidates will get to work on.
Ten years ago, few considered developers an audience worth selling to; they simply didn’t have the buying power. Today there are hundreds of companies that have proven that wrong, many already public. As a marketer, developers are an audience you can’t ignore. Even if your product isn’t explicitly focused on them, every startup eventually needs to build a developer program (see Slack and Twitter). Without technical literacy, marketers will be in the dark on how to effectively speak to and engage with this potentially lucrative audience.
Like marketers, sales reps are now tasked with dealing with increasingly technical organizations. Developers are notorious for disliking being sold to, so the process requires a specific approach: one focused on no frills, quick time to value, and allowing developers to work with the product themselves. It goes without saying that you need to understand typical developer workflows — especially as they relate to the product you’re selling — as well as what makes your company’s product compelling to this technical audience. Technical literacy is a must to be able to speak intelligently here.
Technical literacy on the job: working with tools
Understanding and working with developers is only a piece of the puzzle. Software is becoming a larger and larger part of how all teams operate (duh). Sales has built its backbone on Salesforce for a decade, and that same paradigm is increasingly true for other teams.
It goes without saying that the better you understand the software your team relies on, the more proficient you’ll be in it. This already happens naturally: teams that are large enough will usually have one “power user” who seems to know the ins and outs of Salesforce, Lever, or whatever your team runs on. You want to be that person.
While technical literacy will help you understand these tools and where they fit into the broader ecosystem, the work doesn’t end there. Becoming a true power user requires hours of reading documentation, finding tutorials online, and engaging with the community around whichever tool you’re focused on. For example, Hubspot has a vibrant set of forums for asking product questions and learning more about how other companies use the tool. But for all of this, technical literacy is the foundation.
There’s one more area in the realm of tools where technical literacy can help: integrations. The tools you use day-to-day integrate with other parts of your company’s stack. Lever job postings might be displayed on your marketing website with Lever acting as the CMS; Intercom might be pulling user-level data from your data warehouse. And with integrations come problems. With basic technical literacy — and a little scrappiness — you can go from:
“This job posting isn’t showing up on the site — can someone on engineering help me?”
“I checked and it looks like our most recent Netlify build failed because there’s a Contentful entry missing a tag. I archived it to fix the problem but can whoever created it fix it when you have a chance?”
The latter doesn’t require knowing how to code — just a decent understanding of how a website works and how a CMS works with it — but it can mean the difference between something getting fixed immediately and something getting fixed in a couple of weeks. There are countless more of these kinds of situations, including:
- Debugging mismatches between data in Salesforce and data in your warehouse
- Making copy changes on your marketing site without needing engineering help
- Sending data from Segment to a new customer activation tool
The more technically literate you get, the more of these small opportunities you’ll find in between the cracks of your company’s toolchain — and the more impactful you’ll be.
Finally, any discussion about technical literacy needs to consider the so-called “advent” of low-code and no-code tools. They enable non-engineers to do more than ever on their own, like build landing pages, internal tools, or data pipelines. Though it’s part of a longer discussion, building something that really works in these tools will usually require interfacing with something technical — be it an API endpoint or a simple database — and being technically literate can often mean the difference between being self-sufficient and getting delayed by engineering resources.
Some tips for becoming more technically literate
This is, unfortunately, the hard part. One of the main reasons that people aren’t as technically literate as they’d like to be is that it’s really difficult to do: there’s no bootcamp, no degree, no book, and no one-stop shop that covers everything you might need to know in your specific situation. Learning about the basics of software usually consists of an odd cobbling together of blog posts, YouTube videos, coffee chats, and slideshows from 2011.
But there’s good news! If you’re working at a startup or tech company, you’re in a prime environment to get more technical via good, old-fashioned experience. You’re surrounded by actual developers, your tools are using actual data, and your teammates are stuck with workflows that could be meaningfully improved. As edge cases and bugs arise, you’re in a prime position to put your technical literacy to work and solve them.
Here are a few tips to get started on your journey.
Make a plan
Learning “guitar” is hard, but learning a song on guitar is a lot easier. Similarly, if you’re trying to learn everything there is to know about software, you’ll get overwhelmed quickly (and you may already have). There are still basics that everyone should know — like how to play a chord and strum — but the magic is in how you apply it.
Start by taking a look at your company and your role, and where you think being more technical could give you an edge. Earlier we identified a couple of areas where technical literacy can level up your performance:
- Understanding and working with developers
- Being an expert at your toolchain
For each of these, startup employees and leaders should think about how they relate to their particular function. If you’re a marketer, you’ll want to focus on cultivating a sophisticated understanding of the developer persona, as well as diving into specific topics like email deliverability or how data moves between systems. Be specific about what you want to learn (or at least start with learning). A useful question to ask is: “Where have I lost out by not being technical?”
Find a developer friend or two
If you’re working in startups, you’re already surrounded by people who spend their entire days doing what you’re trying to learn a little bit about: software. And if you play your cards right, they can be a valuable resource on your technical literacy journey. If you don’t have an engineering team (or if you really don’t like them), you probably have a friend or two who can fill this role.
In this arena, you’ll want to come prepared. Structured conversations with questions you’ve thought of in advance are a much better use of a developer’s time than aimless curiosity. Try focusing on the areas you’re weakest in, and do research in advance so you’re not putting the entire learning burden on someone else.
Consider you’re an account executive working at a startup that sells a NoSQL database, like MongoDB. The more you understand about how developers work with databases, the better seller you’ll be; but asking a developer to explain this entire landscape to you is an ask destined for failure. Instead, do your research in advance and write down specific points that have you stuck. “I was reading up on the difference between SQL and NoSQL, and the one thing I don’t understand is how you query a NoSQL database” is much better than “Can you explain NoSQL to me?”
And, of course, if someone has been really helpful to you, buy them a coffee or something!
Get good at Google
This tip would be at home in any article about learning. Save for getting up to speed on a specific tool, there aren’t many places on the web with curated resources you can just read through; you’re going to need to be scrappy. In my experience, the best content for explaining tech concepts sits in two places:
- YouTube. It has a lot of garbage, but it can be a goldmine for visual explanations of technical concepts. The most useful videos are not always the flashiest or best-produced ones.
- Company-specific blogs. These are harder to find, but generally the best content for any individual concept comes from a company that makes money off said concept. My favorite examples are this Duo Security post about SAML, and Cloudflare’s guides for understanding their company.
Like anything, you’ll need to refine your search skills and develop an intuition for whether a piece of content is worth your time or not.
Consider basic coding
I’ve said multiple times already that you don’t need to learn how to code to be technically literate. But it sure does help! Understanding how programming works, what a language is, and basic patterns like packages and version control will help you across the board:
- You’ll have a concrete understanding of what developers actually do
- You’ll be able to write simple scripts and work with tools to automate your work
- You’ll get a first-person view of the tools developers use today (React, Redux, etc.)
You don’t need to end up as a full-fledged programmer; think of it more as exploratory learning.
If you’re just looking to get your feet wet, there are lots of incredible free resources on the web. I first got started with Codecademy’s Python class back in the day. A useful tip someone gave me is to think about something cool you’d want to build or automate — maybe a tip calculator or something to send emails — and try focusing on learning what you need to build that specific thing.
Find influencers and experts in your space
Once you’ve built your plan and started looking around the web for helpful content, you’ll likely come across some usual suspects in your particular field who are creating useful stuff. Follow these people on social media, subscribe to their newsletters, and check up on their YouTube channels for updates. A few examples:
- Benn Stancil’s Substack on data strategy and tools
- Corey Quinn’s newsletter about AWS (and his entertaining Twitter)
- Vicki Boykis’s newsletter about tech and tech culture
- My Technically newsletter on getting more technical
You might not understand everything you read, but diffusion is powerful and you’ll be surprised how quickly you improve.
What companies can do to help
We’ve talked a lot about what individual employees can do, but leaders at startups and tech companies should also view technical literacy as a pressing problem. If you’re an employer, think about how you can help your employees become technically literate with programs such as:
- Education stipends for continued learning, conferences, books, and online classes
- Company events that bridge the gap with engineering and focus on enabling non-technical teams
- Dedicated time offered to employees to learn coding basics and technical foundations
- Buddy programs with company engineers for interested employees to get up to speed with internal infrastructure and contributions
Giving employees the resources and time to uplevel their technical literacy will pay dividends to the company in the long term. You’ll be building a team that understands developers and their toolset better than the competition — one that is more equipped to handle whatever curveballs the hectic startup experience might throw at them.
Join the Newsletter
Technology, innovation, and the future, as told by those building it.
Views expressed in “posts” (including articles, podcasts, videos, and social media) are those of the individuals quoted therein and are not necessarily the views of AH Capital Management, L.L.C. (“a16z”) or its respective affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.