How to Be a Technical Person

I have worked as a software engineer for the past decade, and for the last two years, I’ve run an IT retainer where I met several people who are very smart and capable, but who would never describe themselves as technical.

By sheer coincidence, I started this IT retainer just as generative AI tools started to get real adoption, so I got to see the resulting shift first-hand (and outside of an engineering team). People who once would have handed every technical problem to IT started solving things themselves; they built automations, untangled workflows, and started using software in a very different way.

As this happened, I noticed that my clients were getting stuck in ways that an experienced engineer rarely would. Not because engineers are smarter, but because a typical engineer has spent years developing certain instincts toward technical problems, which get drilled in through the work itself.

Nothing about these instincts is secret or hard to learn; what follows is my attempt to make them explicit. I’ve been keeping a list of “thought habits” that I’ve found useful to share with clients who want to do more technical work. Given that generative AI is letting everybody be a bit more technical, I want to publish this list so that it can be more widely useful.

1. Ask why before how

AI makes it incredibly easy to get answers and start building immediately; you can go from a vague idea to a prototype in an absurdly short amount of time. But speed makes it easier to build the wrong thing because the friction of building is now much less.

If a report is useless, generating it automatically doesn’t solve anything. If a team isn’t aligned on direction, putting AI on top of the confusion creates faster confusion.

Beginners rush to execution, but more technical people are willing to challenge the premise. They ask whether the problem is real and whether the process makes sense.

2. Expect the first version to be bad

Beginners often imagine that technical people get things right on the first try, while experienced people usually expect the first try to be incomplete and awkward.

If you think the first attempt should work perfectly, every flaw feels like failure. But if you expect iteration, then flaws become information. Your rough v1 gives you the material that you need for a better v2.

Technical people tend to be more comfortable with iteration. They do not treat refinement as embarrassment; they treat it as the normal path from vague idea to useful result.

3. Break the problem down

A lot of “technical ability” is really just the ability to make problems small enough to handle. One of the most common anti-patterns with AI is asking it to do too much at once.

“Build me a CRM” is a bad starting point because it is big, vague, and full of hidden decisions. “Build me a contact list where I can tag people and filter by tag” is much better. This is a specific and easily testable task.

Technical people decompose problems. They ask: What is the first useful version of this? What are the independent pieces?

This matters when you are writing a report, designing an automation, cleaning up a spreadsheet, or trying to improve an internal process. Large goals are hard to reason about; smaller sub-problems are much easier.

When working with AI, smaller asks produce better results. Every small piece gives you a checkpoint, and it is easier to solve a large problem via a series of small, comprehensible checkpoints.

4. Learn to move between levels of abstraction

Related to breaking down large problems, it is important to understand that every problem exists at multiple levels at once.

There is the big picture level, where you are asking what a system is supposed to do overall. Then there is the detailed level, where you might be asking what exact step is failing. Technical people are good at moving up and down between those levels.

Suppose you built a Zapier automation and it has stopped running. You could look at that as one problem, but it might actually be several different kinds of problems. Maybe the trigger isn’t firing. Maybe the connected account lost a necessary permission. Maybe a filter step is silently blocking records. Maybe the destination app changed its field names. Maybe the Zap is paused. Those are different layers of the same issue, and they each point you somewhere different.

People often get stuck because they stay at the wrong level. They either zoom too far out and stay vague, or zoom too far in and miss the broader system around the failure. An important skill is being able to ask, “What level am I looking at right now?” and then deliberately shift when needed.

This is one reason experienced people can look calm when something breaks. They are not necessarily smarter. They just have a better sense of what action to take next.

5. Build a mental map of what exists

You do not need to memorize everything. It is more reasonable to have a rough mental map of your domain, knowing that certain categories of things exist and when they might matter.

Google Drive is a good example. Suppose a colleague can’t open a file you shared with them. If you have never heard of Google Drive permissions, that is a mysterious failure with no obvious next step. But if you vaguely know that Drive controls access at the file and folder level, you know what question to ask and roughly where to look. You don’t need to know the details, you just need to know the category.

This is especially important when working with AI because AI is very good at filling in details once you know what to ask. But it cannot give you a useful answer if you do not yet have the concepts to form a good question.

Technical people do not know everything, but they do tend to have a better index of the landscape.

6. Think in systems

The most transferable skill that an engineer learns is the ability to look at an unfamiliar system and get traction on it quickly.

Everything is a system. A spreadsheet, a hiring process, a Zapier automation, a restaurant kitchen, and an AI workflow all have the same basic anatomy. They have input and outputs, data or work moves through them, and rules govern what happens at each step. Things can go wrong at the boundaries or anywhere in between.

Once that idea clicks, unfamiliar tools stop being intimidating. You may not be familiar with the software tool you want to use, but you know the questions that will help you make progress: What triggers this? What does it depend on? Where does the data live? What happens if this step fails?

These questions work everywhere, which means you are never starting from zero.

7. Accept that most systems are messy

There is a fantasy version of technology where everything is clean, elegant, and beautifully designed. Most real systems are not like that.

Most real systems are weird, have historical baggage, rely on half-documented workarounds, and are held together by old assumptions, manual patches, and the fact that nobody wants to touch the fragile part.

You should care about quality and improve rough systems when you can, but one of the biggest steps in becoming more technical is accepting that useful is better than perfect. Build something, use it and notice what is bad, then improve it and repeat.

8. Read the error

Inexperienced people see an error message and immediately freeze, but error messages are information, and they are very often the clearest information you get.

A technical person reads the error. Even when the message is imperfect, it usually narrows the troubleshooting dramatically.

The same applies when AI gives you a bad result. Do not just say it failed; ask why it failed. Was your request vague? Did the tool misunderstand the format? Did it assume the wrong thing? Did you ask for too much in one step? A useful thing about AI is that you can ask it these questions directly and usually get a good answer.

9. Ask what changed

When something stops working, one of the best first questions is: What changed?

Problems do not usually appear out of nowhere. Something changed in the environment, the configuration, the data, the prompt, the permissions, the expectations, or the sequence of steps.

Beginners tend to restart from scratch every time. They re-prompt the AI, rebuild the workflow, click random things, and hope the issue disappears. More technical people try to isolate variables. They look for the difference between the working state and the broken state.

Debugging is really just disciplined comparison. What state is the system in right now and what was different earlier? Thinking this way makes problems less mysterious.

10. Get comfortable with impermanence

Everything is provisional. Your first version will be replaced and the process you designed may only be right for six months. This is normal.

People often avoid starting because they want to choose the perfect structure and the perfect approach, but technical work does not reward perfectionism nearly as much as it rewards adaptability.

If things are going to change anyway, you do not need to freeze in search of perfection. Build the first useful thing, then let it be imperfect and improve it as reality teaches you more.