| 11 minutes read

YouTube Plan

Channel direction

The channel does not need to become another maker channel or another generic career-advice channel. The strongest common theme is:

Honest lessons from an experienced engineer who tests ideas, reflects on what worked, and explains what he would do differently.

The subject can be software, communication, leadership, a keyboard, or training for a half marathon. Each video should contain:

  1. A specific problem or question
  2. Personal experience rather than generic advice
  3. Evidence, examples, or a real experiment
  4. A clear conclusion, including what did not work

Avoid promising a perfect productivity system. The more honest position is that most systems eventually fail, so the goal is to reduce friction and adapt.

1. I Tested the Modern Web on 3G. It Barely Works.

Priority: High

Why this fits: It combines a strong personal story, a technical argument, measurable evidence, and a broader point about engineering responsibility. It does not require building a new product; the existing outage page and test data provide the demonstration.

Possible titles:

  • I Tested the Modern Web on 3G. It Barely Works.
  • A Power Outage Showed Me How Broken the Web Is
  • The Modern Web Fails When You Need It Most

Thumbnail: A failed news page next to the lightweight outage page, with 3G: FAILED or THE WEB IS TOO BIG.

Core promise: Modern websites work well under ideal conditions, but many become unusable precisely when access to information matters most.

Opening:

During a week-long power outage, I still had a mobile signal. But I could not load the news or even the emergency information sent by the government. The connection was slow, but the bigger problem was the web we had built for it.

Structure:

  1. Tell the power-outage story and establish the stakes.
  2. Show what happened when opening normal news websites.
  3. Test several pages under the same throttled connection.
  4. Compare their size and loading time with the lightweight outage page.
  5. Explain how advertising, third-party scripts, images, and JavaScript add up.
  6. Discuss when rich applications are justified and when resilience matters more.
  7. End with practical principles: test slow networks, ship less, prioritize critical content, and do not assume ideal infrastructure.

Important: Keep the test fair and reproducible. This should not become another simplistic “JavaScript bad” argument. The conclusion is that engineers must design for the actual context and users.

Useful assets:

  • Screenshots and measurements already used in the blog article
  • Screen recordings with network throttling enabled
  • The outage aggregator and its architecture
  • The government message that linked to inaccessible information, with private details removed

2. Your Emails Are Backwards

Priority: High

Why this fits: It uses a skill learned at McKinsey that remains useful as a Principal Engineer. It is practical, broadly relevant, and can be demonstrated with concrete before-and-after examples instead of abstract advice.

Possible titles:

  • Your Emails Are Backwards
  • The McKinsey Writing Rule I Still Use Every Day
  • Stop Making People Search for Your Point

Thumbnail: Two messages side by side. One begins with a long explanation; the other begins with the answer. Text: ANSWER FIRST.

Core promise: Most technical communication hides the conclusion at the end. Putting the answer first makes emails, Slack messages, design documents, and presentations easier to understand.

Opening:

Most engineers communicate like they are writing a detective novel. They give you the setup, every clue, and finally the answer. At work, most people stop reading before the reveal.

Structure:

  1. Show a realistic engineering message written chronologically.
  2. Rewrite it with the conclusion first.
  3. Introduce the Pyramid Principle in one short explanation.
  4. Apply it to three situations:
    • A debugging or incident update
    • A decision request
    • A presentation slide
  5. Explain where answer-first communication can go wrong, such as removing necessary nuance or sounding overly certain.
  6. Give viewers the one-line test: can someone read only the first line and understand the point or requested action?

Important: Do not sell this only as a McKinsey technique. McKinsey provides the credibility and story; the value comes from seeing it applied to real engineering communication.

3. I Built My Dream Keyboard. Here Is Everything I Got Wrong.

Priority: High

Why this fits: The original keyboard series is proven channel content. A long-term retrospective is more interesting than another build and does not require creating a new keyboard. It also demonstrates mature engineering: evaluating decisions after living with their consequences.

Possible titles:

  • I Built My Dream Keyboard. Here Is Everything I Got Wrong.
  • My Dream Keyboard, Three Years Later
  • I Spent Years Building the Perfect Keyboard. Was It Worth It?

Thumbnail: The finished keyboard with several mistakes circled. Text: 3 YEARS LATER or NOT SO PERFECT.

Core promise: After designing the PCB, adding a TrackPoint, and making the keyboard wireless, which decisions were genuinely useful and which were only interesting engineering?

Opening:

Three years ago, I designed my dream keyboard from scratch. It had a custom PCB, a split layout, wireless support, and a TrackPoint. I called it the ultimate keyboard. After actually living with it, I would not build the same keyboard again.

Structure:

  1. Recap the original goal and constraints quickly.
  2. Explain which parts survived daily use.
  3. Show what became annoying, unreliable, or unnecessary.
  4. Separate mistakes in requirements from mistakes in implementation.
  5. Explain whether the project improved typing, comfort, or productivity.
  6. Show what the ideal version would look like today without building it.
  7. End with the larger lesson: dream projects reveal what you value, but “ultimate” requirements change after real use.

Questions to answer:

  • Do you still use it regularly?
  • Was the TrackPoint worth the complexity?
  • Did wireless improve the experience?
  • Which layout choices lasted?
  • How difficult is maintenance?
  • What would you buy instead of building today?
  • Was the project worth doing even if the result was not perfect?

Important: Lead with mistakes and changed opinions, not a chronological summary of the old videos. Existing footage can carry much of the visual story.

4. I Stopped Using To-Do Lists

Priority: Medium

Why this fits: This is not another productivity-system video. It is the honest conclusion after trying Notion, Obsidian, PARA, paper, Apple Notes, and other systems. It can continue the current video without repeating its calendar instructions.

Possible titles:

  • I Stopped Using To-Do Lists
  • Productivity Systems Keep Failing Me
  • Why Every Productivity System Eventually Stops Working

Thumbnail: Several abandoned tools crossed out. Text: I GIVE UP.

Core promise: Productivity systems often become another task to maintain. The useful question is not which system is best, but how little structure is needed to start the next important thing.

Opening:

I have repeatedly found the perfect productivity system. Then, a few weeks or months later, I stopped using it. For a long time I thought I lacked discipline. Now I think maintaining the system was part of the problem.

Structure:

  1. Show the graveyard of previous systems.
  2. Explain the excitement and temporary feeling of control each created.
  3. Identify the recurring failure: maintenance and retrieval friction.
  4. Explain the difference between recording work and doing work.
  5. Describe the limited role the calendar currently plays without calling it a universal solution.
  6. Explain what still fails and what you do when the calendar is ignored.
  7. End with permission to abandon a system that costs more than it returns.

Important: Do not repeat “timeboxing solved everything.” The interesting and credible argument is that no system works permanently or perfectly.

5. What Changes When You Become a Principal Engineer?

Priority: High

Why this fits: More than ten years across startups, scale-ups, consulting, SAP, and engineering leadership provide credible experience. The useful angle is not a list of career tips; it is the transition from producing code personally to improving the decisions and output of a wider organization.

Possible titles:

  • What Changes When You Become a Principal Engineer?
  • I Became a Principal Engineer. Coding Was Not the Hard Part.
  • Senior vs Staff vs Principal Engineer: What Actually Changes?

Thumbnail: CODE -> IMPACT or three columns labeled SENIOR, STAFF, PRINCIPAL.

Core promise: Advancement beyond Senior Engineer is less about knowing more frameworks and more about scope, leverage, judgment, communication, and ownership.

Opening:

I used to think the best engineer was the person who solved the hardest technical problems. As a Principal Engineer, solving the problem yourself is often the least valuable thing you can do.

Structure:

  1. Explain your earlier definition of a strong engineer.
  2. Describe what changed at Senior, Staff, Tech Lead, and Principal level.
  3. Use concrete examples:
    • Reducing a workflow by 50%
    • Owning an OKR cycle close to company leadership
    • Training and mentoring engineers
    • Improving engineering practices across teams
    • Turning ambiguous business needs into technical direction
  4. Explain what remains technical about the role.
  5. Discuss the danger of becoming a meeting-only engineer.
  6. Give advice for an engineer considering the individual-contributor path.

Important: Do not frame the video as a universal leveling guide. Titles and expectations vary significantly between companies. State that this is what the role means in your experience.

Potential follow-up career videos:

  • The Skills That Took Me From Senior to Principal Engineer
  • Why Writing Matters More as You Become a Senior Engineer
  • Stop Measuring Senior Engineers by How Much Code They Write
  • What McKinsey Taught Me That Software Engineering Did Not
  • How to Lead Engineers Without Becoming Their Manager
  • The Difference Between Ownership and Working More
  • How I Make Technical Decisions When There Is No Right Answer
  • What I Look For When Mentoring Senior Engineers
  • Ten Years as a Software Engineer: What I Would Learn Differently

6. I Am Training for a Half Marathon, So I Built a CLI

Priority: Medium to high

Why this fits: This is a current, authentic goal and a natural intersection of software with life outside work. The CLI should support the story rather than becoming a long coding tutorial.

Possible titles depend on the result:

  • I Am Training for a Half Marathon, So I Built a CLI
  • Can a Terminal App Get Me Through a Half Marathon?
  • I Let My Terminal Plan My Half-Marathon Training
  • I Built a CLI to Keep Me Running

Thumbnail: Terminal output beside a running shoe or race route. Text: 21.1 KM.

Core promise: Can a small tool built around your actual behavior help you prepare consistently for a half marathon?

The CLI needs a clear job before filming. Possible functions:

  • Show today’s planned run
  • Import completed runs from a provider or file
  • Compare planned and completed distance
  • Track weekly mileage and long-run progression
  • Warn about abrupt increases in training load
  • Show the remaining weeks until race day
  • Generate a simple post-run reflection

Choose only the functions that solve a problem you genuinely have. A focused CLI is a better story than a feature-rich training platform.

Structure:

  1. Establish the half-marathon goal, current ability, race date, and concern.
  2. Explain why existing running applications do not provide the view or trigger you want.
  3. Define the smallest useful version of the CLI.
  4. Show selected implementation decisions without turning the video into a line-by-line tutorial.
  5. Use it during several weeks of real training.
  6. Show where its recommendations or assumptions failed.
  7. Finish after the race with the result and whether the tool helped.

Best format: Capture footage throughout training and publish the main video after the race. Smaller development or training updates can become Shorts, but the long video needs the complete question and result.

Important: Avoid medical or prescriptive training claims. Make clear that the tool organizes or visualizes your plan; it is not a substitute for professional coaching or healthcare.

  1. Your Emails Are Backwards — fast to produce and establishes the engineering/communication direction.
  2. I Tested the Modern Web on 3G — strongest story-led technical video.
  3. My Dream Keyboard, Three Years Later — reconnects with the proven keyboard audience without requiring a new build.
  4. What Changes When You Become a Principal Engineer? — establishes the career pillar with earned credibility.
  5. I Stopped Using To-Do Lists — an honest conclusion rather than another system recommendation.
  6. Half-Marathon CLI — film over time and publish when the experiment has a real ending.

The half-marathon video should be recorded in parallel from the beginning. Do not wait until the race is over and then try to recreate the uncertainty, training, failures, and progress.

Career-video principles

Career content is a good fit, but generic advice has historically performed poorly on the channel. Use these rules:

  1. Teach from a decision, mistake, or transformation you personally experienced.
  2. Use actual examples and outcomes, with confidential details removed.
  3. Challenge a common assumption instead of offering a broad list of tips.
  4. Make the advice useful to one identifiable audience and career stage.
  5. Acknowledge where company context changes the answer.

Strong framing:

I thought ownership meant saying yes and working more. That made me less effective. Here is what ownership means to me now.

Weak framing:

Here are seven ways to take more ownership at work.

Ideas to avoid for now

  • Building another productivity system only for the sake of content
  • Generic videos about motivation, success, or becoming a better developer
  • Broad framework or language introductions without a personal question
  • Product reviews without long-term experience or a distinctive test
  • Advice based only on authority rather than a concrete example
  • Calling any tool, keyboard, or workflow “ultimate” without revisiting the tradeoffs