What I Wish I Knew At 35 About Building Wealth

The High-Income Trap

At 35, many tech professionals are earning more money than they ever expected. The income is there. The wealth is not. High income and high wealth are not the same thing, and the gap between them is where most tech professionals get stuck. They spend to their income level. They delay serious investment because they believe they have time. They optimize for lifestyle instead of capital. And then they look up at 45 and realize that the income was not doing the work that investment would have done.

Five Things I Wish Someone Had Told Me At 35

One: your company equity is not a retirement plan. It is a concentrated bet on a single asset. Diversify as soon as you can. The engineers who held all their equity in companies that fell by seventy percent learned this lesson expensively. Spread the risk as options vest and RSUs settle. 

Two: the most important investment decision is the asset allocation, not the stock picks. A boring index fund held for twenty years will outperform most active strategies. Stop trying to be clever. Start being consistent. 

Three: the house is not your primary wealth-building asset. It is where you live. Real estate can build wealth, but it requires active management and capital concentration. For most tech professionals, a diversified investment portfolio is more efficient. 

Four: compound interest needs time more than it needs money. Ten thousand dollars invested at 35 is worth four times as much at 65 as ten thousand invested at 45. Start early. More than amount, the variable that matters is time. 

Five: learn enough about taxes to make real decisions. At high tech salaries, tax optimization is worth thousands of dollars per year. Understand your equity tax events. Know the difference between short-term and long-term capital gains. This is not complicated. It is worth a weekend of learning.

The One Action From This List

If you do nothing else, read one book on personal finance. Education is your best investment. The rest builds from there.

The "AI Is Too Risky" Myth: What You Are Getting Wrong.

The Risk That Is Real

AI does make mistakes. This is true. AI generates confident errors. AI can produce plausible wrong answers. AI hallucination is a real problem in high-stakes domains. These are legitimate concerns. The risk team is not wrong to flag them. The question is not whether AI has risks. The question is whether the risk of not using AI is lower than the risk of using it.

The Risk You Are Not Counting

You are avoiding AI because of the risks you can name. The security risk. The accuracy risk. The compliance risk. You are not counting the risk of falling behind. Every quarter that you do not adopt AI tools that your competitors are adopting, the gap widens. The company that ships features faster, serves customers better, and operates more efficiently because of AI is pulling away from the company that is still asking whether it is safe to use a chatbot.

The Comparison You Are Not Making

The right comparison is not AI versus perfect. It is AI versus the status quo. Your current process has failure modes too. Humans make mistakes. Humans are slow. Humans get tired. Humans cost more. The question is not whether AI is risk-free. The question is whether the risk-adjusted value of AI exceeds the risk-adjusted value of the alternative.

The Approach That Manages Risk

Use AI for the decisions where the cost of a mistake is low and the speed benefit is high. Use AI for draft generation, for research synthesis, for the work that is slow and repetitive. Do not use AI for decisions where the cost of a mistake is catastrophic. That is not avoiding AI. That is using it responsibly. The companies that are winning with AI did not adopt everything immediately. They adopted the low-risk high-reward applications first and expanded from there.

The AI Adoption FAQ Nobody Is Answering Directly. Here Are the Real Answers.

"I Tried ChatGPT and It Gives Generic Output"

The problem is not ChatGPT. The problem is how you are using it. You are asking it to write something instead of asking it to think through something. Ask it to analyze your situation, identify the three biggest risks in your current workflow, and suggest specific interventions. Ask it to stress-test your current process. Ask it to argue the opposite position on a decision you are making. Generic output comes from generic input. The tool does not know your context. You are not giving it your context. Start with your specific situation, not a generic prompt.

"My Company Won't Approve AI Tools"

This is a workflow problem disguised as a policy problem. The tools do not need to be on the approved list to be useful. The approved list is for tools that touch company data. You can use AI on your own work, in your own environment, without any company data involved. Draft emails, analyze your personal productivity patterns, prepare for a presentation using public information, write first drafts of anything that does not contain confidential data. The constraint is not the policy. The constraint is your definition of where the work happens. Expand that definition.

"I'm Not Technical Enough"

You do not need to be technical to use AI tools effectively. You need to be able to describe what you want clearly. The barrier is language, not code. You do not need to understand how the model works. You need to understand your own work well enough to tell the difference between good output and bad output. That judgment is what you are being paid for. The AI handles the generation. You handle the evaluation. The people who use AI best are not the most technical. They are the best at knowing what they actually want.

"I Don't Have Time to Learn Another Thing"

You do not have time not to. The hours you spend on tasks that AI could handle are hours you are not spending on the tasks that require your actual judgment. Every week you delay is a week of compounding disadvantage. The learning curve for most AI tools is measured in hours, not weeks. The ROI is measured in recovered hours every week. This is not a time investment. It is a time reallocation. 

The Decision Stack: The Framework for Faster, Better Decisions at Every Level.

The Problem With Your Decisions

You are making decisions without a framework. Small decisions get escalated because nobody knows who should make them. Medium decisions take weeks because every stakeholder has a different criteria for evaluating them. Large decisions get made by the loudest person instead of the person with the best information. The result is slow, inconsistent decisions that the team does not trust.

Layer One: The Decision Map

Before any decision gets made, name the decision. Not the project. The specific decision. What are you actually choosing between? Who is the decision owner — the one person with authority to make it? Who needs to be consulted before it is made? Who needs to be informed after it is made? The decision map prevents the most common failure: the wrong people making the decision for the wrong reasons.

Layer Two: The Criteria

Every medium and large decision needs criteria before it is discussed. Not criteria that justify a decision already made. Criteria that define what a good decision looks like. The criteria should be written before the options are discussed. Priorities among the criteria should be explicit. This prevents the post-hoc rationalization problem: finding reasons to like the option you already preferred.

Layer Three: The Options

Generate three real options, not three variations of the same option. The worst decision processes produce two options: the preferred choice and the sacrifice. The best processes produce three genuinely different paths. If you cannot think of three real options, that is a signal that the decision space is narrower than you thought.

Layer Four: The Commitment

Every decision needs a commitment, not a recommendation. The decision owner commits to a specific action with a specific timeline. The commitment is recorded and shared with everyone who needs to know. The commitment includes what will be true in six months if the decision was right, and what will be true if it was wrong.

The 3 Mistakes Killing Your AI ROI. You Are Probably Making All Three.

Mistake One: Using AI for the Wrong Tasks

You are using AI for the tasks that do not take much time anyway. The emails. The short Slack messages. The LinkedIn post that takes twenty minutes. These are not where the ROI is. The ROI is in the work that takes hours. The project plan. The technical design doc. The analysis that requires reading forty pages of research. If you are only using AI for quick tasks, you are getting 10% of the value.

Mistake Two: Not Measuring

You did not measure before you started. You have no idea how long the task took before AI. You have no idea how long it takes now. You think AI is saving you time because it feels faster. But you have not checked. The tasks that feel faster and the tasks that are actually faster are not always the same. Without measurement, you are guessing.

Mistake Three: Not Changing the Workflow

You are using AI as a replacement for a human doing the same work in the same way. That is not where the leverage is. The leverage is in redesigning the workflow so the task that used to require a human now requires less of one. The email that used to take twenty minutes now takes five because AI drafted it. But if you still spend twenty minutes editing the draft, the workflow has not changed. The workflow has to change for the time savings to be real.

The Fix

Track time on three specific tasks for one week without AI. Then track the same tasks with AI for one week. The difference is your actual ROI. Then ask for each task: is the workflow the same as before? If yes, redesign it. The goal is not to do the same work faster. It is to redesign the work so less of it exists.

How to Actually Get Your Team to Use AI: The Step-by-Step Approach That Works.

Why Your AI Push Did Not Work

You pushed AI tools to your team six months ago. A few people are using them occasionally. Most are not. The ones who are not using them have reasons that sound reasonable. The real reason they are not using AI is not that they do not understand it. It is that you did not change the work, so the work did not change. AI adoption happens when the work changes to include it, not when tools are made available.

Step One: Find the One Task That Takes Too Long

Before you roll out AI to the team, find the one task that takes the most time that is also the most repetitive. Not the most important task. The most time-consuming and repetitive one. This is where AI will show the fastest return and face the least resistance. If you start with something complex or important, the learning curve will create pushback. Start with the task everyone dreads.

Step Two: Get One Person to Prove It Works

Find the person on the team who is most likely to try something new. Not the most senior. The one who is curious. Have them use AI for that task for two weeks and measure the time. If they save two hours in week one, the team will believe it. If they do not save time, you have the wrong task or the wrong tool. Fix the problem before you scale.

Step Three: Make It Part of the Process, Not an Option

Once you have proof it works, make AI use part of the standard process for that task. Not a suggestion. Part of the definition of done. If someone is not using AI for that task, they need to explain why in the same way they would explain why they skipped a required step. The process change is what makes adoption stick.

Step Four: Expand to the Next Task

After the first task is consistently using AI, expand to the next task that fits the criteria. Time-consuming and repetitive. Do not try to move AI into everything at once. The goal is not to use AI. The goal is to make the work better. AI is a tool that makes specific tasks faster. It is not a philosophy.

I Was the Guy Who Shipped Everything and Got Nothing. Then I Changed One Thing.

The Guy Nobody Noticed

I was the reliable one. Not the loud one. Not the political one. The reliable one. I shipped on time. I did not complain. I did not escalate unless it was necessary. I left meetings early when my work was done and did not insert myself into conversations where I had nothing to add. I figured the work would speak for itself. The work did not speak for itself. The work was invisible. The loud people in the meetings were visible. The person who escalated everything was visible. The person who took credit for other people's work was visible. I was not visible. I was just getting paid.

What I Was Doing Wrong

I was writing status reports. I was asking for approval before moving on anything ambiguous. I was waiting to be given direction. I was treating my manager's calendar as the gatekeeper for my productivity. The status report said we shipped the feature. The status report did not say the feature took three weeks of manual work that could have been automated. The status report did not say the same task used to take one week before the process was changed. I was reporting activity. I was not demonstrating judgment. There is a difference and nobody teaches you what it is until you get passed over for the third time in a row.

The One Change

I stopped writing status reports. I started presenting outcomes with data. Every week I sent a one-page summary: three things shipped, the impact on the metrics that mattered, and one thing I had automated that week that reduced future work. No requests for approval. No escalation. Just outcomes with evidence. The AI tool generated the data analysis part in twenty minutes. The judgment part was mine. Visibility is not luck. It is a system. The people who get hired are not the most competent. They are the most legible. Subscribe to get the exact one-page outcome format.