I was going to start as the best Engineering Manager (EM) ever!

Maybe 2 months later my manager goes “hey, so this team suddenly needs a new EM, what do you think?”

I’ll save the full tale, but I said yes and jumped in with both feet to take on a well-established team with 10+ engineers.

I would not recommend being dropped onto a team of more than ten engineers with two months of preparation. But I would recommend starting before you feel completely ready. Preparation can soften the landing; it cannot make management feel familiar.

It’s hard.

Many of the behaviours that made you successful as an engineer can become traps in management. New engineering managers keep using the behaviors that made them successful as engineers, even though management requires a different system.

Writing code, solving problems, supplying answers, and personally rescuing projects all produce immediate, visible results, but as a manager are a trap.

For me it was really hard to let go of the technical details. I loved writing very polished “tech specs” that explored a pragmatic list of options before touching code. Not all my engineers felt this way, and when they’d move forward without a spec or something as detailed as I liked, it was hard not to go and write one for them.

But management creates results indirectly. Using clarity, judgment, feedback, delegation, coordination, and the growth of other people. That work feels slower and less tangible, so new managers retreat toward the work that makes them feel competent.

I could have written the tech spec for them, and that may have produced a better document, but it would have denied my lead the opportunity to develop their judgment and taught the team that important technical decisions still belonged to me.

So instead I switched to coaching. Coaching wasn’t a covert way to steer them toward writing the spec I wanted. I had to share my concerns, give useful feedback, and accept that their judgment might produce a different answer from mine, which gave them all the tools they needed to do their best work.

Software Engineers are used to tight feedback loops, and often as a manager you need to make a decision where you may never know if it was the right call. Hiring makes this especially visible: you can make a thoughtful decision and still never know how the alternative would have unfolded.

It’s normal for new managers to feel bad at their jobs. It’s new, and you are just starting. This is more true the more senior an engineer was before making the move. You are used to a certain level of career proficiency, and it’s going to take time to get there again.

If you’ve made the transition or think you will soon, it may not feel amazing right away. Give it time. You didn’t get a promotion, you changed careers. You’re going to have some growing pains.

Feeling ineffective does not mean you are failing. You are still measuring yourself using the scorecard of your previous role. You’ll adjust and these feelings will fade with time.

Here’s a better scorecard when you’re just starting out:

• Did the team make meaningful progress on the right problems?

• Did I make the problem, priorities, or ownership clearer?

• Did I help someone exercise better judgment without taking the decision back?

• Did people receive timely, useful feedback and understand how they can grow?

• Is the team becoming more capable of succeeding without me?

A good week in management may produce very little you can point to and say, “I made that.” Your best work will often show up in someone else’s judgment, confidence, or results.

And you may discover, as I did, that you absolutely love it. I get so much joy from helping people grow, watching them solve bigger and bigger problems, protecting their focus from distractions, and supporting them when the work gets hard.

If you give management a real try and decide it isn’t for you, that time was not wasted. Some of the best staff and principal engineers I’ve worked with spent time as managers before returning to engineering. Understanding “the other side” made them better engineers.

Those extra ten months of preparation might have made me a stronger manager on day one. But they would not have given me ten months of management experience. Five years later, I’m very glad I said yes.

Your first few months are not a referendum on whether you can become a great manager. You didn’t get promoted. You changed careers. Give yourself permission to be new at it.

If you’re preparing to become an engineering manager, or you’re still figuring the role, what can I help you with? What is your current biggest struggle? I read every message :)

Leave a comment

The example they used is simple: one million tokens went from around $20.00 to around $0.07.

That is an absurd improvement.

It is the kind of number that makes me want to jump straight to the conclusion: “If tokens are getting this cheap, maybe we should stop worrying about token cost.”

Over a long time horizon I think this is true. The future of inference is probably cheap. However, the near future is expensive.

Tokens are becoming easy to spend

The first wave of AI usage was simple. Open a chat window, ask a model for help, and pay for the response.

That is no longer the whole story.

We now have “thinking” models that deliberately spend more tokens to reason through hard problems. We have coding agents that make it normal to fire off multiple requests while working through one task. We have tools that can parallelize work across several agents, then ask other agents to review the output for correctness, accessibility, security, legal risk, or style.

This is useful. It is also a fundamentally different spending pattern.

When a person sends one prompt, the cost is visible enough to reason about. When a system launches a small fleet of agents, each with its own context, tool calls, retries, validations, and review loops, the spend becomes…big.

The same thing is happening outside direct AI usage.

A developer might not use an LLM directly, but their pull request might trigger AI review comments. A product surface might summarize content, classify intent, rank options, rewrite text, extract structure from an image, or personalize an experience without the user ever knowing an LLM was involved.

You could be completely against AI, but will struggle to avoid accidentally using it.

Token spend is moving from explicit actions to infrastructure.

When something becomes infrastructure, leaders need an operating system for it.

The long-term trend does not remove the short-term responsibility

I believe local and open-source models will become much more attractive over the next 5 to 10 years.

You can already run useful models locally today. The tradeoffs are still real: speed, quality, memory, setup complexity, model choice, and operational support. For many teams and individuals, paying large model providers still makes sense if AI is part of the daily workflow.

But it is hard to imagine that staying true forever.

Hardware will improve. Models will get smaller and better. Open models will continue to close quality gaps. Inference stacks will become easier to operate. Eventually, many teams will have good-enough local or private options at approachable price points.

That future is important, but it should not become an excuse to ignore the present, even if you believe the time horizon is shorter.

For the next few years, token costs will still matter.

The point is not to make people afraid of using AI or spending money.

The point is that usage can scale faster than accountability.

A workflow that costs a few dollars in a prototype can become a serious budget line when it runs across every pull request, every support ticket, every sales call, every uploaded image, every user-generated review, or every internal document.

The cost of one action may be tiny.

The cost of making that action automatic, frequent, and invisible may not be. There is a large disconnect between how much an action costs. Even pre-AI, most engineers were not aware of how much their pull request costs in cloud tests. I spent years optimize test infrastructure for Android emulators so our engineers could quickly get results for tests, and it wasn’t cheap, but educating developers without discouraging them was a tricky line to watch.

The leadership problem is judgment

Something to ask is: “What kind of value do we expect this token spend to create, and how will we know if it is working?”

That is a leadership question.

Engineering leaders are used to this shape of problem. We make similar tradeoffs with cloud infrastructure, observability, test automation, build times, vendor tools, and platform investments. Is the cost is producing enough value to justify itself?

AI spend deserves the same treatment.

Some token spend will be obviously worth it. If an AI workflow saves engineers hours of toil, catches real defects, helps users complete high-value actions, or turns a manual operational process into a reliable system, the cost may be trivial compared with the value.

Some token spend will be exploration. That is fine too. Teams need room to learn. Today there are so many unknowns, and a billion assumptions to unravel.

When everyone is afraid of missing the AI wave, the default instruction becomes “spend more and find use cases.” That can be appropriate for a short exploratory window. It is not a permanent operating model.

You’re going to see more and more companies tightening the purse strings. Businesses will ask the reasonable question: what did we get for the money?

Engineering leaders should be ready before that question arrives as a budget panic.

A lightweight token spend review

Most teams don’t need a heavy approval process for AI usage. That would slow learning and push experimentation into corners. I won’t give out general advice because I think the needs are team / company specific, but here’s how I would think about it:

I would try to keep it simple and ask a bunch of questions.

1. What decision or action does this improve?

If the answer is vague, the workflow is probably vague too. More specific versions of these answers are in the right ballpark:

• It helps engineers find review risks earlier.

• It helps users write clearer content.

• It reduces manual classification work.

• It gives support teams a better first draft.

• It turns unstructured input into something the system can act on.

2. Who benefits, and how often?

A workflow used by ten people once a month can still be valuable, but it should be judged differently than one used by millions of users or every engineer every day.

3. What would we do without the model?

This question forces the comparison. A lot of people are stopping projects to ask “okay but how would AI solve this? Can we do it faster? More accurately?” and that’s great, but if you see an AI-first approach, you may need to flip that and ask what non-AI approaches would work here.

I see a lot of workflows where a simple python script is more deterministic, faster, and obviously cheaper.

The alternative might be manual work, a rules-based system, a smaller model, a cached response, a cheaper model tier, a narrower prompt, or no feature at all.

AI does not need to beat a perfect alternative. It needs to beat the real alternative.

4. What is the failure mode?

Some AI mistakes are mildly annoying. Others are expensive, risky, or trust-damaging.

The answer should influence how much validation you need, whether a human stays in the loop, and whether the workflow belongs in production yet.

The heroes will be the people who create leverage, not spend

The next phase of AI adoption will reward a different kind of behavior.

The early phase rewarded experimentation. Try tools. Build prototypes. Find surprising use cases. Learn quickly.

Your company/team may still be there, and if so, keep pushing. That phase is still valuable, but it’s just a step in a longer path.

As token spend becomes a normal part of software, the most useful leaders will be the ones who can create large gains with disciplined spend. They will know when to use the strongest model and when a smaller model is enough. They will measure whether agentic workflows are producing better outcomes or just producing more activity. They will find ways to replace agentic flows with deterministic methods.

They will also make this understandable to the people around them.

Good engineering leadership is not avoiding complexity. It is turning complexity into decisions people can make.

AI cost is going to become one of those decisions.

Not because tokens will always be expensive. But because cheap ingredients can still produce expensive systems when usage becomes automatic, invisible, and everywhere.

Seeing this coming down the line and figuring out efficient ways to spend tokens in a way that helps your teams thrive will be huge. It won’t last forever, but it will be important for a time. Just another step.

Any then what?

Along the way we will find dramatic drops in price for tokens.

Labs are literally growing diamonds to cool processors. Breakthroughs in material science, in processor manufacturing, algorithmic solutions, etc, can all translate to cheaper costs, and faster token generation.

The past doesn’t determine the future, and I am not a seer, but that is my prediction. I don’t think we are anywhere near the limits of what’s possible, and it’s too valuable to pass up.

Imagine a world where tokens are 100x faster and 1000x cheaper. What could you do? What problems might you run into? It’s fascinating. But at some point limiting spend may no longer be relevant.

Try this this week

Pick one recurring AI workflow in your team or personal workflow. Don’t ask whether it is too expensive. Ask whether it has a clear value story.

Write down:

• What action it improves

• Who benefits

• How often it runs

• What the non-AI alternative is

• What metric would make you change it

That is enough to start.

The future will be full of cheap inference. Our goal is to be leaders who handle it well by building judgment around it early.

What it means to be a programmer has changed many times, and LLMs will not be the last existential threat to what it means to be a programmer.

In the 1960s, “programmer” meant someone who understood hardware intimately. You thought in memory addresses, registers, and instruction sets. Abstractions were thin. Efficiency was survival. Hacks were often necessary just to get your product to market (I’m looking at you Pokemon on gameboy!)

In the 1990s, it meant mastering object-oriented design and navigating growing ecosystems. Frameworks emerged. Software scaled from single machines to networks. Architecture became a first-class concern. The internet exploded.

In the 2000s and 2010s, it meant shipping fast in a world of cloud platforms, open source, CI/CD, mobile devices, and global users. The bottleneck shifted from hardware to coordination. Engineers became systems thinkers: infrastructure, APIs, distributed systems, data pipelines.

Now we are entering another shift.

Large language models can generate code, refactor code, explain code, test code, and sometimes design code. They can scaffold a React app, write a migration, produce a Kubernetes manifest, or summarize a 5,000-line legacy file. Tasks that once took hours now take minutes. Didn’t work? Run it again from scratch. Vibe your way through.

So are software engineers cooked?

No. But the center of gravity is moving.

The Pattern We’ve Seen Before

Every time abstraction increases, the job changes.

• Assembly → C: Engineers stopped managing every instruction.

• C → higher-level languages: Memory safety and productivity improved.

• On-prem → cloud: Infrastructure became programmable.

• Monoliths → distributed systems: Reliability and scale required new mental models.

• Handwritten code → AI-assisted code: Generation becomes commoditized.

Each transition sparked fear.

“If compilers get better, do we still need programmers?”
“If frameworks do everything, what’s left for engineers?”
“If no-code tools exist, will developers disappear?”

Instead of eliminating engineers, each wave raised the abstraction level and expanded the surface area of software. When building became easier, more software got built.

We can’t know if the same thing will happen here, but it seems likely to me.

What Actually Changes

The value shifts from typing to thinking.

When AI can write a CRUD endpoint in seconds, the competitive advantage is no longer “can you write CRUD?” It becomes:

• Do you understand the problem deeply?

• Can you design the right system boundaries?

• Can you evaluate tradeoffs?

• Can you detect when generated code is subtly wrong?

• Can you align technical decisions with business outcomes?

• Can you learn to use the tools efficiently?

In other words: engineering judgment becomes more valuable.

AI reduces the cost of execution. It does not remove the need for taste, constraint navigation, domain modeling, or long-term thinking.

If anything, it increases the premium on those skills.

The Bifurcation Risk

There is a real risk, though.

If engineers outsource too much cognition, they may atrophy. If you never debug, never reason about performance, never trace through memory or concurrency issues, your depth may wane.

There may be a bifurcation:

• Engineers who use AI as leverage to think bigger.

• Engineers who use AI as a crutch and gradually lose core understanding.

The former become architects of systems and orchestrators of capability.
The latter become prompt operators.

The tool is neutral. The trajectory is not.

And we don’t know the exact skills that will be valuable in the future, we’re only speculating. Things will change pretty rapidly at least for a few more years as the tooling around LLMs continues to improve.

The Real Constraint

The hardest parts of software have never been syntax, it’s been:

• Ambiguity in requirements.

• Human coordination.

• Organizational incentives.

• Tradeoffs under uncertainty.

• Long-term maintenance.

AI can generate code quickly. It cannot sit in your stakeholder meeting and resolve conflicting priorities. It cannot fully internalize your product’s lived context, political realities, or historical baggage.

It can help, but it currently cannot own these things.

What Survives

Curiosity survives.
Systems thinking survives.
Clear communication survives.
Technical taste survives.
The ability to debug reality survives.

The engineers who thrive will:

• Treat AI as a multiplier (whether that’s 1.1x or 5x or beyond).

• Double down on fundamentals.

• Learn faster with the tools.

• Move up the abstraction stack deliberately.

The skill is no longer “writing code.” It never was.

It is “building correct, resilient systems in messy human environments.”

That has always been rare, and is why most big tech companies reject so many candidates. They have all been told they are programmers, but not everyone has the right skills for the current version of what a programmer is today.

So… Cooked?

No.

But the entry-level path looks different. The skill ladder may compress, and definitely change. The floor may rise while the ceiling stretches.

The comfortable middle might shrink.

And that is uncomfortable.

Every major abstraction wave rewards those who adapt early and punishes those who cling to the old leverage point. When Android Studio came on the scene, I clung to it far longer than anyone else. I was the last engineer at Yelp to move over, and it cost me so much to do so. I’ve learned my lesson.

Software engineers are not cooked.

The question is not whether the profession survives.

The question is whether you evolve with it.

And while that would be a nice note to end with, here is one more thought: You don’t need to panic. It’s going to be alright. You don’t have to be on the latest and greatest to survive. These tools are easy to learn. Claude Code, Cursor, ChatGPT and whatever else comes your way are an afternoon of tinkering to get good. I can’t say that the same fundamentals I learned in Computer Science will be the same ones that serve the next generation of “programmers”, but I will say that understanding how to solve problems will help you face whatever is coming. So pick a hard problem and try to solve it. Try out different tools and strategies, because if you are someone who likes solving hard problems, “coding” was never your main pursuit anyway.

In my left pocket is always the notebook, and a pen I know works well. Whenever I have a thought, I write it down on the next available page. Before bed I review it, and I sort the notes as needed. Here are some examples from the past few days:

• Learn agentic coding by making a simple React Idle Game.

  • I actually did this! It was…interesting.

• What habits do I want? What do I want to lose?

• What quests do I want?

• Idea: A lockable cubby for each person in the house on each level so they can keep things safe.

  • I have a 7 year old with profound autism who has no sense of ownership, so she is constantly drinking everyones drinks, taking their things, dumping their cups, eating their snacks, etc. Most of my ideas are trying to outsmart her (and I usually lose).

• Idea: During talks with my partners, make sure everyone has something in their hands that isn’t a phone.

  • The thought here is that research shows that having something to do with your hands, helps you relax and focus better.

• Would a ring book be better? This one keeps wanting to fold closed. It’s hard to write in the air, I always need a solid surface to press it against… And maybe a smaller pen. And blank pages instead of lined!

This is just two pages, and I’ve filled out about 6 pages so far. I have a page where I just started brainstorming “What is a good life?” and I add to it when I have another thought on this subject.

I keep the notebook and pen on my bed next to me while I sleep, and if I wake up with a thought I write it down. My writing in the dark is as bad as it sounds, but I can make out what it says.

Why not just use a phone?

There are a lot of distractions in a phone, and to take a note it’s at least “enter password → find app → find correct place to take note → type note”. I hate typing on a phone, and most circumstances prevent a good voice note. A lot of my ideas occur during social interactions where my mind wanders. A notebook+pen are perfect tools for me, and slightly less rude than pulling out my phone (in my opinion).

The notebook is not a long term storage for notes, it’s meant to be the lowest friction way to get the idea down. It won’t take long before this is just a bunch of rambling notes from a madman without tending. Once the note has made it to something else (for example, writing this article was a note) I tear it out, crumple it up and throw it away.

This is a similar idea to all organization, but every system needs to be tended.

It doesn’t matter how well thought out your pantry organization is, it will become a mess. You need to tend to it the same way you would a garden. Life happens. And in this case, notes happen. The notebook is great for getting ideas down quickly, but you still need to do something with them to make them useful.

I won’t go into my whole system here, but for me this usually means Notion, but it can also go into the void (I do nothing with it, the act of writing it down was what I needed), I just do the action like “tell my brother I love him”, or I add something to the calendar. And as I mentioned, once it’s gone from the notebook, I remove the page and return it to oblivion.

The notebook cannot be the source of organization. It will become an unstructured mess. It is a fast inbox of thoughts, so it must be treated as such. At least for me, at least in this way.

Where did this idea come from?

I’ve heard many others talk about taking notes on paper, and this idea has sat in the back of my mind for years. It’s been nice to experiment with, and is the first thing that is setting up my 2026 up for success!

I cannot credit any singular source, and of course it’s an old idea to write down ones thoughts on paper.

Please let me know if this is something you’ve tried before, if you have any advice, or if you try it as a result of reading this please share how it goes!

The benefit this gives me is that the next time I get to work, I know exactly what I need to do. I have extreme clarity and high motivation to finish that task, so I start my next block off being very productive! I don’t need to spend any time figuring out what I need to do and I can get straight to it!

There are some tasks which may be hurt by context switching like this, but I’ve still found the benefits to outweigh this. Not only can I get right back into a productive headspace, but I had a chunk of time where my subconscious may have been working the problem and it’s common to start working with a new insight!

Now, “Flow state” is talked about a lot, and productivity gurus scream about protecting your time, and this is valid. I am not recommending you let meetings and other interruptions chop up your productive time in any way. But all work blocks eventually end, and what I am recommending is that you don’t push it to finish the task.

Your time becomes a lot more predictable. What I’ve found is that it becomes easier for me to get into the flow state, and I stay there longer. My hypothesis here is that I know I’m not going to just be able to grind another 30~ minutes after my work block to get it done, so I can’t skip over to Reddit or check Email or whatever other distractions might crop up in the middle of a work block. This is the time to get it done, use it or lose it!

I am now actually respecting my time.

I stumbled on this when I had kids. It’s now extremely punishing for me to stay 30 minutes late after work just to get things done, so my actual work time is way more productive. It has to be. I know I have to get it done in my working hours, and if I can’t, then it’s not getting done. Contrast this to my early career where I could work 16 hour days. To add insult to injury I am way more productive than I was back then (sorry past me, sending lots of hugs!)

To close things up, respect your work blocks. If you know you have 2 hours until your next interruption or end of day, then be firm with your brain that if you’re at the end of the 2 hours and you have maybe thirty minutes left to finish it, great! Leave it for your next work block where you know exactly where to start. I usually take 2-3 minutes to wrap up the task and make notes about where exactly I want to pick up so that context switching is a little easier. “Finish this API call, adjust the tests, and then make a prod build to test it out before putting up the PR”.

Good luck!

As with anything, each human brain is different. What works for me may not work for you. ADHD, Autism, OCD, etc, can all have major impacts on how we work and get things done. Productivity is not one size fits all, and will change for you over time! Experiment and try new things, see what works, and share with us all!

It’s in the middle of rendering, and while it does its thing I wanted to take the time to write about this experience.

If this is your first time learning about it, I am building a course for new and aspiring engineering managers to help transform them into confident leaders! I am building the exact course I wanted when I became a manager, to help people who like to learn with courses+videos.

I took 4 days off work this week to work on the course. I decided to produce an entire module and break up the course that way, rather than doing all the slides, all the filming, and then all the editing for the entire course.

It is nice to be in “filming mode” and there could be efficiency wins there, however I’ve never done this before. I didn’t want to film the entire thing only to realize in editing that I set myself up for failure.

I learned a lot going end-to-end with a module before committing to making ALL the slides or doing ALL the filming. I actually may do the next set of filming BEFORE I make the slides, and then make slides as I’m editing.

If I was screen recording that’s one thing, but I’m not, I’m adding the slides during editing, which makes it way easier to add different transitions and make adjustments to the slides depending on what is said.

So when will the course be done? I have no idea but here is some data!

• There are 24 slides, with some animations, resulting in 51 stills.

• I filmed this in 6 pieces, and there was 111 minutes of raw footage, and the final cut has 87 minutes (so we removed 24 minutes).

  • The resulting file is 28.44 GB. 4k baby.

• It was filmed in 2 sessions.

• The second sessions was SO much better, and the biggest impact besides quality is that the editing was about 5x faster. Many less things to cut out in post.

• My first round of editing was to remove all the “umms”, “ahhs”, the dead air where I read something, all the practices I did of a section where I then redid it, etc. This is where I made sure everything flowed together and made sense.

  • The next round was to insert all the slides in the appropriate places.

  • The next round was turning all the footage into “picture-in-picture”, and moving it around to where it made sense. I didn’t plan this in advance, so I had to make sure it didn’t cover up bits on the slide. This is something I can plan for, but didn’t take up too much time.

  • The last step was cutting up the footage into smaller chunks, and then transitioning between full screen and picture-in-picture. I didn’t plan to do this, but it works really well! I’m very happy with the result.

• This was recorded with a slow intentional speaking voice so that folks can speed it up if they prefer. I would probably listen to it on 2x, but I imagine 1.5x speed is good. I wanted to emphasize clarity.

• From here my plan is to film the rest of the course in order, so the next thing I’ll do is the course intro. I think this will make the module on Building Trust (the one I produced already) jump out as a bit of an odd duck, but that’s alright. I would much rather the first video people see is high quality, and the trust module is the 4th (of 8).

I’m not promising any sort of release date for this because I can’t estimate it, but this best place to hear about progress is on this newsletter. If you’re interested you can always reach out to me on Substack or LinkedIn. My plan is “as soon as possible”.

History does not necessarily predict the future, but every exponential improvement in software engineering has only made the field more expansive and lucrative.

Giving software engineers the ability to write higher level code because of compilers instead of assembly was a game changer, and it not only enabled more people to become engineers, but it made them all way more efficient.

We got Rollar Coaster Tycoon written in pure assembly, but now folks who are not quite as legendary can make games too. And that’s not a bad thing! More games meant more competition, which meant more engineers.

It is my prediction that the need for Software Engineers will increase as the economy recovers. Now, I am not an economist so I have no idea when that will happen, I am only relying on the fact that it will eventually. Interest rates continue to slowly come back down, and while were are in the middle of the dumbest trade war of my lifetime, I am bullish on a bright future.

It is also worth mentioning that the day we can replace software engineers with AI, means that the AI can improve its own code. That is the path to the AI Singularity, which means none of us will need to work. The machines will be capable of anything, and their rate of growth will be limited only by the energy we can consume. I’m not AI (or so I will have you believe), but my goal would immediately be Dyson Sphere (a megastructure that absorbs all the suns energy).

That doesn’t mean we won’t start to replace some engineers with less efficient LLMs, but it’s a big leap to say we’ll replace many or most engineers. If LLMs are cost effective, even if they aren’t as good we will see shifts, but folks wanting to move fast and build great things will continue to need skilled engineers until an AI Singularity.

So today is a great day to learn software engineering, don’t let any hypster tell you otherwise without real proof.

I love AI tools, and they can enable incredible things, but as someone exposed to very large code bases, I have not seen any signal that indicates software engineers are going anywhere. The role simply evolves as it so far always has.

The market is hard because the economy changed. The AI hype and people screaming about the "end of the engineering world" certainly hasn't helped, but we have a doomsday culture, it is ingrained in us to look at how bad things are.

The amount of world ending events I've lived through is stupid. Smart people get tricked all the time by people yelling that the sky is falling. During Y2K, planes were supposed to literally fall out of the sky.

Remember the Mayan Calendar 2012 world ending? I knew some very smart people saying some very dumb things simply because the Mayans didn't make an infinite calendar.

Life Updates

My focus remains ever present on the course! For anyone new, I am working on a course to help new and aspiring engineering managers who are uncertain, overwhelmed, and stressed become confident leaders so that they can successfully guide their teams and drive results.

To that end, I have been filming and uploading some content to YouTube to practice making videos and become more comfortable putting myself out there. I shot all of this on my phone and my Sony a6000, and just today I unboxed my new Sony FX30! I am absolutely in love with this camera, and I am learning all about it so I can start filming.

My next step is to film Module 5 on building trust. I’ve made all the slides and content, now I need to film and edit and figure out the process. I don’t have a strong reason for filming this module first, other than I didn’t want to do the intro first so I just picked one to trial out.

Once I’ve done that and I’m happy with it, I will go film everything else. I have a lot of course content and extras to make, but my primary focus is on the core course content. I may start selling the course before all the extras are done, and then add the ones I have planned over time. This will mean I can help people sooner. I will release all that extra content for free for everyone who purchased the course. My goal is to keep making it more valuable over time!

A huge thank you to everyone who has offered to help with the course! I super appreciate you, and I may take some of you up on that offer, but I need to make it first :)

I am an introvert who was always anxious to have 1:1s with anyone. Just having them on my calendar for the end of the day made me miserable leading up to it and it killed my productivity. So I became a manager to conquer my fears! On that journey I spent considerable effort learning everything I could, and now I fear 1:1s with nobody.

Over the next few minutes I'll share everything I've learned and I hope it helps you be a more confident leader who has more joyful 1:1s. I genuinely look forward to every single 1:1 on my calendar every week, even if the week is crazy busy (which they usually are). Let’s get going!

Prep for your meetings

I do this in two ways.

The first is adding things that come up throughout the week to the agenda. This could be a piece of feedback for your report, useful (but not urgent) information, a thought or insight about their career, an opportunity you want to discuss with them, etc. The more you get to know your report, the more things will pop up during the work week.

The second is taking some time to do 2 minutes of reviewing the agenda. You can take longer, but I find 120 seconds gives a lot of clarity to the meeting, and because I’ve been adding things throughout the week longer doesn’t help much. If I am meeting with someone right after another meeting, I’ll take time in the morning to review the agenda, but usually it’s right before we meet.

This helps prevent me from being surprised by something they added, but it gives me a sense of the flow the conversation will most likely have. I can think about how much time we might need to spend in certain areas. It lets me go “we have a really full agenda today, what is most useful for us to tackle today”.

Listen Actively

This advice is thrown around a lot, so I’ll give you my unique twist here.

I close slack. I close my email tab. I have my phone on silent, out of reach, with the screen down. I have a teleprompter which sits on the end of my camera where I fullscreen the video call (I mostly manage remotely), and I minimize my own face (most of the time).

The teleprompter is nice because when I look at my report, on their end it looks like I am staring at them. On my end, it’s a distraction free screen. No notifications, no nothing. I also place the camera to the left of my desk, so I physically have to turn to face them.

This means if I do go on my screens, I have to turn my body, and it’s very obvious I am “distracted”. In practice I do this because I am taking notes, or I am looking into something that came up in the call, and I tell them this. When I physically turn back to the camera, they can literally see me returning my full focus to them and the conversation.

I think this comes across as extreme, but for me I would get distracted during calls. I’d think of a camera lens I was interested in and search for how expensive it is. It always felt innocent, but then I would realize I hadn’t really been listening for a minute, even though it felt like I had been.

For slack, I found if my manager messaged me, I’d respond in the middle of a 1:1. Here it felt like I was optimizing my time, but in reality I was wasting my direct reports time.

This 30 minute meeting may be the 10th one I’ve had this week, but it’s the only minutes my engineer will get with me that week. They deserve my full attention.

Do what you say

I had a problem in my 1:1s where my direct reports would ask me something, and I would always say yes because I am just so helpful, and 10% of the time something would come up and I could no longer complete the request. Worse, a majority of these I would get so busy their task would simply get bumped lower and lower on my todo list, that by the time we met next, I had forgotten they even asked!

This erodes trust. It feels bad. Don’t be me.

Instead if something comes up, let them know. Don’t wait for the 1:1, just tell them. I also review my task list every single morning and anything that is for my direct reports gets bumped back to the top of the list.

This is not a status report

I covered this in the other article, but it bears repeating. A status report is generally a waste of time. Your direct reports want to get things done, if they are only meeting with you to tell you how things are going, you’re failing as a manager.

You can get status in Github, Jira, Slack, project pages, standups, project meetings, etc. Whatever tools and mechnisms you have, get status of things there. And if you can’t, make that a conversation in your 1:1:

“Hey, I would like to make sure our 1:1 time is as valuable for you as possible, let’s talk about the best way I can stay up to date without using our 1:1 time for it”.

Some of my engineers love to include status in our 1:1s. They like to talk about what they did that week. That’s okay, but I direct the topics to challenges they encountered, how they worked with other teams, how this impacts their goals, etc. I still want them to drive the agenda, but I’m going to poke around and look for areas to give them feedback on (positive or constructive), I’m going to look for areas to coach on.

Be upfront about your topics

If you have something you want to talk about, let this be known at the start of the meeting. I usually say “Hey, I need to steal 5 minutes for our agenda today to give some org updates” or “I have a few non-urgent things I’d like to talk about, but if we can’t get to it today that’s alright, we can focus on your topics/agenda first”.

Some things are time sensitive, such as letting them know about a team member who is leaving, and some are just nice to haves if we have time.

What I try to emphasize here is that this is still their meeting. I may have things to contribute, but unless it’s time sensitive, we may not get to my agenda items and that’s okay.

Check in before delivering feedback

If you need to give constructive criticism, check in first.

“Hey, I wanted to give some constructive feedback on your presentation yesterday, are you in a good spot for that?”

This takes very little time, and it prevents awkward situations. “Actually, I am giving my 2 week notice” or “Oh, I just found out my mom is very sick, can we talk about that another day? I don’t think I’m really going to be able to hear what you have to say”.

This happens very rarely of course, but it does happen. It’s a respectful way to kick off giving feedback in a 1:1, and it helps you align to their headspace. They may not care about getting feedback on their presentation, just because it’s something you want to give.

Better in person 1:1’s

If you are meeting in person, mix it up.

If you normally grab a stuffy office room, go for a walk. If you always walk, go play a game of pool while you chat.

Always check in first as they may have something more sensitive that requires privacy, and you don’t want them to just not talk about it. Remember, you are the manager, a lot of people struggle to push back and communicate effectively because of the power dynamic. They may internally think “well, we’re in this public space, I guess we won’t get to talk about how I’m unhappy right now”.

If you’ve never had a walking 1:1, I highly recommend it! And if mobility is hard for you, just getting out of the office or trying a different spot can still be very nice.

That’s it! Those are the tips. I hope they are helpful, but if I missed something please let us know!

Leave a comment

My main drive has been to niche down and focus on an area I feel is not readily covered, and to force myself to grow as a leader by covering only topics related to leadership whenever possible. This is why I have articles where I help you Improve Your Audio because I force myself to think: How can I be a more effective leader? How can I help others be more effective leaders? Improving your audio may not seem useful, so I felt like that one, while not huge, was a big win.

This is why my focus has been on building a course, to help new and aspiring managers. I wanted something I could give to someone who was feeling nervous/anxious about stepping into the role, and they would have everything they need to become a confident leader. Not someone who has all the answers, nobody has those, but someone who’s able to say “I don’t know the answer, but we’ll figure it out”.

But in the back of my mind is the nagging question, am I too focused? I will always cover leadership topics in this newsletter, but I feel very limited in my brand. I spend almost my entire week in 1:1s with Software Engineers, helping them grow, unblocking them, keeping them happy, etc. I do meet with other leaders, and I mentor them as well, but an order of magnitude less. The team I’m responsible for is all engineers.

I also love software engineering as a craft. Most people on LinkedIn rage against algorithms and data structures, and complain about pull requests and AI tools, but I love everything related to software. It’s something I would do full time if I had unlimited money.

So here I sit, blinking cursor staring me in the face, wondering, do I un-niche? What would that look like? Should I write multiple newsletters? Should I constrain those thoughts and ideas to YouTube instead, and keep the newsletter focused?

The sun is coming up and the kids are starting to wake up, and I don’t have an answer, but I think I need to make a change somewhere. I’ve always had a YouTube itch, so that may be where I expand my brand. For now Lead Kindly will remain a resource for leadership growth in Software Engineering. If you have any thoughts, please share them with me :)

Hello to you all, and especially all the new subscribers, welcome! Updates about the course and life at the end if that’s your thing. If you haven’t said hello, get in the comments and introduce yourself! :)

Remote work is no longer a novelty—it’s the norm. When I went remote in 2015, I was told I would miss out on most opportunities afforded to real employees. It was phrased much nicer, but the message was clear: Remote workers are less than.

I proved everyone wrong, and in 2020 the world was forced to accept what I had been preaching: Not only is remote work possible, but for millions of people it’s a better option. Productivity is higher, costs are lower, and work-life balance is much improved.

This isn’t true for everyone, and there are new challenges that arise. For many leaders the question arises: If I can’t physically see my employee work, how can I build trust with them to do good work? While we are seeing some thrashing with RTO (Return to Office), remote will continue to be a large part of the work force. So let’s talk shop about how to improve trust, with an emphasis on software engineering teams.

The Crucial Role of Trust in Remote Teams

Trust forms the foundation of any high-performing team. It ensures that members can rely on each other to meet deadlines, communicate transparently, and collaborate effectively. In virtual environments, where cues like body language or casual hallway conversations are missing, trust must be built intentionally.

Research by Jarvenpaa and Leidner shows that in remote teams, frequent and clear communication is key to overcoming uncertainty and fostering trust. Their study in Organization Science highlights that trust in virtual settings develops when team members have repeated, reliable interactions—even if those interactions occur through screens rather than in person.

Similarly, Purvanova (2014) emphasizes that the quality of communication, rather than its frequency alone, plays a significant role in establishing trust within remote teams. For software engineering teams, where complex problem-solving and creativity are daily demands, establishing trust is a prerequisite for collaborative success.

As a manager, I build trust with my team by meeting with each person 30-60 minutes every single week. I aim to be as present as possible, not checking slack or email during our meetings, and making it about them as much as possible. I am happy to share about myself, but I am there to serve them. I help answer their questions, unblock them, and try to get them the resources they need.

Without trust, a manager can’t know if an estimate provided by an engineer is accurate. Are they padding time to slack off? Are they over-promising and we’ll be late? Mistakes can always happen, but without trust our thoughts can lead to paranoia, and we’ll be unable to give our stakeholders (relatively) accurate estimates.

Without trust, an engineer can’t know if they can share crucial information with their manager. What if the manager uses that information to fire them or hold them back? Or keep them from getting a project? I’ve worked on teams where someone was fired for getting pregnant! That did not instill trust in everyone else to share information with management.

My engineers need to be able to trust me with sensitive information, and I need to trust them to work hard and bring their best.

Challenges to Remote Software Engineering Teams

• Limited Nonverbal Communication: Without face-to-face interactions, managers and team members miss out on nonverbal cues that often help gauge sincerity and build rapport.

  • This can be a good thing, as a lot of these non-verbal signs are misunderstood, especially for neurodivergent individuals. I have heard “well they didn’t make eye contact” in interview feeedback as a way to signal lack of intelligence or confidence in a candidate, which is not accurate.

• Geographical and Cultural Diversity: Distributed teams may span multiple time zones and cultural backgrounds, which can lead to miscommunications or varying expectations regarding work habits.

  • This extends into holidays, where when region may be off while the other is working. These can be worked around, but diligence with a calendar is required.

• Reliance on Digital Tools: While tools like Slack, Zoom, or Microsoft Teams facilitate communication, they can also create silos or information overload if not managed properly.

Research Insights on Trust in Virtual Teams

Academic research offers valuable insights into overcoming these challenges. For example:

• Communication as a Trust Builder:
  Jarvenpaa and Leidner’s (1999) seminal work found that regular, transparent communication is critical for building trust in virtual teams. Their research suggests that timely feedback and consistent updates help reduce uncertainty and reinforce a shared commitment to team goals.

• Quality Over Quantity:
  Purvanova (2014) argues that while communication frequency is important, the depth and clarity of interactions are what truly build trust. In software engineering, where technical nuances require precise understanding, clear and thoughtful communication is paramount.

• Leadership’s Role:
  Research by Gilson et al. (2015) indicates that effective virtual team leadership—characterized by empathy, clarity, and accountability—can significantly influence team trust. Managers who foster an environment of psychological safety empower team members to share ideas and admit mistakes without fear of undue criticism.

Strategies for Building Trust in Remote Software Engineering Teams

Drawing on research and practical experience, here are 5 actionable strategies for engineering managers:

1. Enhance Communication Practices

• Regular and Structured Meetings:
  Implement daily standups, weekly reviews, and one-on-one check-ins. These meetings not only keep everyone aligned but also create regular touchpoints for relationship building.

  • Be careful with meeting fatique. I am not recommending a constant stream of meetings, your team needs time to do work! But these are some options available to you.

• Clear, Written Communication:
  Encourage the use of detailed written updates, whether through emails, project management tools, or dedicated communication channels. Clarity in documentation can prevent misunderstandings and ensure that everyone is on the same page.

  • A follow up email after a meeting summarizing the key takeaways is a way for someone to go “oh, I didn’t actually agree on that”, which can save time, and help eliminate classes of problems.

  • Bonus tip here, have someone who is heading towards staff/management do meeting summarization and be a note taker for meetings. It’s a great way to improve communication skills.

• Video Conferencing:
  Video calls help humanize remote interactions by allowing team members to see facial expressions and body language. Whenever possible, opt for video over voice-only calls to foster connection.

  • Not everyone is comfortable with having their video on. I don’t require this for everyone, but I do encourage it. Find the balance that works well for your team.

2. Establish and Communicate Clear Expectations

• Define Roles and Responsibilities:
  Clearly delineate what is expected of each team member. When everyone understands their responsibilities and the broader team goals, trust increases.

• Set Milestones and Checkpoints:
  Break down projects into smaller, manageable tasks with regular progress reviews. This not only keeps projects on track but also provides opportunities to celebrate achievements and address issues early.

3. Foster Informal Interactions

• Virtual Water Coolers:
  Create digital spaces—such as chat channels or virtual coffee breaks—where team members can discuss non-work topics. These informal interactions build personal connections and can help bridge the gap created by physical distance.

  • I’ve struggled with this one with my teams, but if you can pull it off it can be very effective. My struggles are that my engineers are not that interested in having a weekly time set aside. We’re still working to find “virtual water cooler” moments.

• Team-Building Activities:
  Organize virtual team-building exercises or online games that encourage collaboration and help team members learn about each other beyond work tasks.

  • We have a quarterly “offsite” where we get together for half a day to do something fun together. We did team cooking led by a professional chef, virtual escape rooms, “DIY” where you bring your own project and we work separately—together, origami, etc.

4. Empower and Support Your Team

• Encourage Autonomy:
  Trust is a two-way street. Empower your team members with the autonomy to make decisions and manage their workloads. Autonomy fosters ownership and, in turn, reinforces mutual trust.

  • You can go too far towards autonomy, or too micro-managy. You need to find the balance for each person on your team, and what you’re comfortable with. I lean towards too much autonomy, and need to check in to make sure my team isn’t floundering with too many options/freedom.

• Provide Constructive Feedback:
  Regularly acknowledge achievements and offer supportive, constructive feedback. Creating an environment where team members feel safe to experiment and even fail can lead to greater innovation and trust.

  • If you are only giving constructive feedback, you will lose trust. You need to give positive feedback as well. That way when you give constructive feedback, it doesn’t come off as too-critical. Your report knows you call out the good stuff too, and so you’re saying something because it’s impactful.

5. Leverage the Right Technology

• Use Collaboration Tools Effectively:
  Adopt tools that facilitate both project tracking and informal interactions. Integrated platforms can help ensure that information flows smoothly and that every team member has access to the resources they need.

• Monitor and Adapt:
  Continuously evaluate the effectiveness of your communication and collaboration tools. Solicit feedback from your team and be prepared to adapt your strategy as the team’s needs evolve.

  • It’s okay to not know the right thing to do, so try something out, and see how it works. Even if something has been working, things and people change, so keep an eye on everything. Or if you’re past the basics, delegate these things to your team! Empower them to improve the processes and monitor the success of the team. They are the ones doing the work, they know best what’s working and what isn’t.

Looking Ahead

As remote work continues to define the modern workplace, the strategies for building trust will evolve. Future research is expected to delve deeper into the nuances of virtual collaboration, further illuminating how technology, leadership, and communication intersect to foster trust. Engineering managers must remain agile, continuously adapting their approaches to meet the dynamic needs of distributed teams.

Conclusion

Building trust in remote software engineering teams is a complex, ongoing process. It requires a deliberate mix of clear communication, structured interactions, and genuine human connection. By leveraging research insights and adopting best practices, engineering managers can create an environment where remote teams not only function effectively but also innovate and excel. The journey to building trust may be challenging, but its rewards—increased collaboration, higher productivity, and sustained team morale—are well worth the effort.

References

• Gilson, L. L., Maynard, M. T., Young, N. C. J., Vartiainen, M., & Hakonen, M. (2015). Virtual Teams Research: 10 Years, 10 Themes, and 10 Opportunities. Journal of Management, 41(5), 1313–1337.

• Jarvenpaa, S. L., & Leidner, D. E. (1999). Communication and Trust in Global Virtual Teams. Organization Science, 10(6), 791–815.

• Purvanova, R. K. (2014). Face-to-Face Versus Virtual Teams: What Have We Really Learned? The Psychologist-Manager Journal, 17(1), 2–29.

Life Updates

For the new folks, hello! I am building a course for new or aspiring engineering managers, taking you from nervous/anxious to confident leaders!

Even though I am still writing the content for the course (I passed 13,000 words! That’s more than the “The Curious Case of Benjamin Button”), I’ve started recording. To de-risk the process, I am going to do a full module end-to-end to see what I can learn from the process. I would hate to write all the content for every module, only to realize I need to redo a lot of it once I got through the first video.

One thing that I found truly interesting was how easy it was to sync up multiple audio sources.

I record video on a standalone mirrorless camera which has a built in microphone. I also recorded audio on my Audio-Technica AT4040 microphone, which has a very deep and rich sound, directly to my PC.

In DaVinci Resolve I just pressed a button to sync them together, and it was perfect. I could mute one track while it was playing and unmute the other and it was perfectly aligned with my lips. Playing them both at the same time was weird, but fun I guess?

In life I remain very busy, so while progress on the course is slow, it marches forward, and I am very excited about what I am building. I am very happy that after almost a year of starting to go to the gym, I am still going! I have changed the cadence from 3 times a week down to 2. I am still seeing great progress, and this works better for all the other things I want to do in my life, like build a course for new engineering managers!

I named my newsletter “Lead Kindly”, and I keep telling myself that I am kind, but it’s not true.

I can think of many moments where I choose the safe option (just being “nice”) instead of the kind option. Where I don’t give feedback because I don’t want to upset someone, even if my data could be helpful for them to grow.

It’s hard.

I want to be so good for everyone, and yet I find that I don’t always do the kind thing. It makes me feel like a fraud, because I also want people to like me. I want there to be no awkward moments or hurt feelings.

However, I want to challenge my belief that this is a lie.

While I have taken the safe—nice—option many times, this has become less and less true over time. I remind myself that it might be nice to spare someones feelings, but I also don’t get to decide how they feel, and the information/context I have could help them, and I deliver the hard feedback.

There are LinkedIn posts I don’t make because I’m afraid it will upset some people, but my most viral post with millions of impressions was because I didn’t listen to that voice. I took a stance and I said something many people didn’t agree with and that’s okay. They can handle hearing something they don’t like, and maybe they will learn something (or in many cases, leave a nasty comment, but that’s the internet for you I suppose).

I have been speaking up more in my personal relationships and giving people feedback when they ask for it. If you want me to tell you how you look in something, I will give you my opinion, and it’s not always going to be positive. But now you can trust me to give my true honest thoughts, if that’s what you want.

I have told my partners things that make them feel upset, or mad at me, and create an awkward atmosphere, but they always come back and we get to talk about it when the emotions have subsided. It wasn’t nice, but it was kind. It built trust. They understood where I stand, and we were able to move forward in a positive direction. Had I been nice and said nothing, they wouldn’t have known what I actually thought, potentially leading to conflict later, or increasing resentment.

Can I do better? For sure. I will always be working towards being more kind. That’s why I made Lead Kindly, because I want to be a kind leader first, even if it means dropping niceness. I still strive to be nice, but kind first.

So while writing for a publication that champions kindness can feel like a lie, I don’t think it’s actually a lie. I strive for kindness, and I work towards it every single day. What do you think?

Leave a comment

So that is my journey, the transformation I strive for.

I want to be kind.

I want to tell you what I really think.

I want us to have an authentic relationship based on trust.

I don’t want to mask or pretend that I am someone I’m not so that you will like me.

I want to build a personal brand that is a true reflection of me, and who I want to be.

I am all about growth. I am all about kindness, even if I’m still learning.

Thank you for learning with me, and I hope I can continue to offer you insights into being a kind, empathetic, and confident leader.

When we meet with people, it’s all about the value we bring. Today I’m going to focus on the manager to direct report 1:1, because oh boy do I have some opinions about this topic!

Who’s Meeting Is It?

This was surprising for me to learn, but the 1:1 belongs to the direct report!

As a Software Engineer, I met with my manager because my manager said that’s what we were going to do every week. It wasn’t explained to me why, and I just sort of assumed it was to give a weekly status report, so that’s what I did.

Every week, status report.

This is what I worked on, this is what I didn’t work on, this is what I am planning to work on.

Over and over. It felt like a huge waste of my time, and honestly I wasn’t sure why my manager wanted these meetings. You could just look at my github or Jira to see what I was doing, did you really need me to tell you the same information week after week?

Well eventually I learned that the meeting was for ME. It was supposed to be my time!

And I also learned that my managers job was the SERVE ME. His job wasn’t to make sure I was working. His job was to help me be better. To elevate my game. Help me grow. Unblock me. Get me breakfast!

Well not breakfast, but the rest is true.

Once I learned this, it changed everything.

Who Runs the Agenda

Since the direct report owns the meeting, they run the agenda.

If the manager has things they want to say or bring up, that’s possible, but the primary purpose of the meeting is to make it easy for the direct report to get access to the manager. To ask hard questions. To share context and gain context.

You don’t know how RSU’s (Restricted Stock Units) work? Ask your manager.

You want to get promoted? Talk to your manager. Grill them. Find out what your missing. Do you need a mindset shift? Bigger projects under your belt?

The 1:1 is your space to connect with the rest of the business, to understand how you can deliver value, to build a rapport with someone who may one day have to advocate on your behalf to leadership.

Oh you’re suddenly going to be a parent, you’re freaking out, ahhh! Talk to your manager. When I became a dad many years ago, I learned that Yelp covered 8 weeks full pay! I had no idea, but I asked, and then I did.

Advice on Running the Agenda

The single most effective method I have developed to having great 1:1s is to have a written down agenda each week.

This feels heavy and a lot of work if it’s not the norm, but trust me that it’s easy and saves you a lot of time. It also just works super well.

In practice this can be a fresh sheet of paper that sits on your desk each week, or in my case it’s a Google Doc. I like to share it with my manager so they can read ahead if needed, but I don’t think this is required.

During the course of the week, add your thoughts to the doc. These can be raw unfiltered thoughts, or they can be more thoughtful questions. I am reviewing my manager levels, so whenever I make time to work on them, I write down some of my thoughts. Some of them are questions I have for my manager, and some of it is context I would like to share with them.

If someone brings up something in one of my 1:1s that require my managers attention, I’ll pop over and make that not in the middle of the 1:1 (I let my report know I’m doing this so I don’t appear distracted).

This helps me from needing to remember things.

I’ve been to two many 1:1s with my manager where I went “I know on Tuesday I had something I wanted to talk to you about…but it’s Thursday now and my mind is an empty vessel, maybe I’ll remember”.

I didn’t.

This practice of taking notes over time means I can just roll into 1:1s with my manager and I have a lot to talk about. The week is busy, I don’t always want to take 15 intentional minutes to sit down before we meet to prepare some topics. No, I do this whenever a topic comes to mind.

I might include interesting articles I read for us to chat about, or insights from a meeting.

How to Help Engineers

Okay if you are a manager and you’re thinking “this is great, but how do I help my engineers have better 1:1s with me! They aren’t going to read this long article”.

I suppose if they are willing to read an article just send them the link, but otherwise here is what I do.

When I first meet my engineers, I share with them my managing philosophy. This includes the views I expressed here about 1:1s. “These are your meetings. I may bring topics to them, but I expect you each week to have your topics. Whatever you want to talk about. We can spend the entire time talking about your cat, or your projects, or your career, or ideas you have, it’s up to you. It can be valuable or it can be a waste of time, but it’s yours”.

It may not be a big rant like that, but you get the idea. I set expectations.

And then after 3 months or will refresh. I will remind them that this is their meeting. This is especially true for folks who I find are just giving me status reports each week. The nudge/reminder is generally pretty helpful to get them back on track.

And don’t push how they run the meeting. You can offer suggestions like a shared doc, but leave it up to them. You can keep your own doc for the engineer if you want (I have a private Notion page for everyone that links to various other databases, but we won’t cover that today). If they want a shared doc, great. If they don’t, that’s just as good.

As their manager, go with their flow. It’s easier for you if everyone does what works best for you, but being a manager is about helping your team, not pushing them into practices that don’t work for them.

Mini Question Bank

I am building a massive question bank as a PDF resource for my course for new and aspiring engineering managers, but here are some off the top of my head.

• How does compensation work? How do I make more money here?

• Am I ready for a promotion? If not, how do we get me there? If so, what can I do to help get that going? What is the promotion process here?

• I am unhappy with my job, help me fix that.

• Who do I talk to about X?

• Y thing made me feel uncomfortable, help.

• I am having trouble communicating with someone, how can I do better here?

• I am struggling with <this> aspect of my job, who would be a good mentor to help me grow here?

• Could we pair program on Z thing?

• I’m interested in becoming a tech lead / interviewer / manager /etc one day, how do I do that? Am I close?

• Recently you said we are doing <project>, but I don’t see how that’s a good use of our time, can we talk about that?

• I’m thinking about interviewing at other companies and wanted to give you a heads up. I’m not necessarily planning to leave, but I am considering it.

• I received offer X from a company. They said I have 2 days to respond, could you help me review the offer? How does it compare to my current compensation at our company?

• I am thinking of joining a startup / mid level / big co, how do they compare to our company? What would be different or similar?

Outro

And that’s it. I hope that was helpful and that you will now have more effective 1:1s. I have not worked on the 1:1 section of my upcoming course for new/aspiring managers yet, but I’m sure that will spur future articles on the topic for this substack. If you have questions feel free to comment or reach out to me on LinkedIn.

Hey there good looking, you made it to the end! The article is over, but in this section I’ll share more about myself, the newsletter, and the state of the world.

The Course

First up, the course I’m working on to transform you into a confident engineering leader! It’s meant for new and aspiring managers to help them transform from “I have no idea what I am doing…” to “I can figure it out now!”

When we last spoke on Jan 21st we were at 3,800 words for the main content only, and today I breezed past 8,000. I’ve done a ton of research and editing, and I’ve found a flow that works really well for me!

When I make time to work on the course (in the evenings after the kids are in bed), I pick a module and work on its outline. What am I trying to say here? What is important to get across?

Usually this necessitates some research which could be reading books, reading articles, going back and fourth with an LLM, watching videos, etc. I actually learn a lot from this, and sometimes I will stop working on that section to let my subconscious process the new information and switch to something else.

Done is better than perfect, but I also want to make sure the quality of information is top notch. I am not going to heavily edit the videos and add lots of fun animations, for that aspect I could tinker forever, but for the content, the good stuff, I want that to be top notch.

When the research is done and the outline is solid, I’ve broken it up into a bunch of bite sized chunks with the main “what I want to say”, I then use speech-to-text combined with typing on a keyboard to get the rest down.

I estimate that the course will be around 20,000 to 30,000 words when it’s done! Let’s see how accurate that is. To put that in perspective, I looked up business books, and they are roughly 50,000 to 80,000, so that’s pretty cool! I have no intention of turning this into a book, I think there are pretty good books on how to become a manager, but we’ll see! Some people like to learn via books, some like to learn by course. I am focusing on the course crowd for now!

The Newsletter

I started a LinkedIn newsletter called “Lead Kindly Bites”. The mission is “value in under a minute” for the same topics as we cover in this substack newsletter. The next one will include some gems from this article.

The plan in general is to write my substack newsletter (like this one!), and then pull out the most interesting and valuable piece to share in the LinkedIn Bites version. This fits the LinkedIn audience a bit more who are looking for quick value, but I will also link to this substack for anyone interested in reading/learning more.

Why? One I think it would be useful, but I also want to grow this substack more. Today I have 3,700 followers on LinkedIn, which is 37x more than this substack! LinkedIn followers are a lot more casual than substack subscribers, so that’s fine, but I think a lot of those folks would enjoy this newsletter.

To help route them here, I am going to deliver value on their platform (Lead Kindly Bites) and give them an optional call to action to checkout a more detailed version of the bite they just read. We’ll see if that works! :)

I will also drive folks who found my substack back to LinkedIn. That could be you! Did you know I’m active on LinkedIn? Dropping wisdom bombs on my followers? I post between 3-5 times a week there, but because of how LinkedIn works, your unlikely to see all the posts I make. This is why I will always love substack more. You get every email I post here! It’s completely up to you to engage or not on your own time.

Setting the Stage

Feedback is data. By giving it, you are potentially giving someone new context or perspective.

Trying to change someones mind or behavior with feedback can lead to a lot of unnecessary work or frustration. You may want someone to change, but they have to make that decision. All you can do is give them data.

If you can let go of the desire to change someone else, you can give more effective feedback and save yourself a lot of work. Less emotions, less work, more impact.

When you offer feedback, you’re sharing how you see things. You don’t have perfect information, and that’s okay. The other person might disagree or have knowledge you don’t. Feedback isn’t a debate you must “win.” It’s just valuable data they can use or ignore. This shift in mindset will free you from the pressure of needing to be “right” and help you focus on clarity and helpfulness.

Focus

Send one message.

Don’t give feedback and try to tell the person two things. Tell them one. Don’t cloud your message with extra information. Make it clear and concise.

One message.

If you have more than one thing to say, pick one. Deliver that single piece of information clearly and concisely.

This ensures that you do not cloud your actual message and get off course. It is very easy to get lost once the conversation gets going and for the other person to get stuck on one minor detail and miss the bigger picture.

Now you can run it through an LLM and ask if this feedback is clear/concise and focused. Give it a try.

Ask Permission

You need to make sure now is a good time for the other person to receive feedback.

It doesn’t matter if you’re the big CEO, if the other person is in the wrong headspace your going to waste everyones time.

At the very least check in. “Hey, I had some feedback I wanted to share on your presentation from yesterday, is now a good time?”

You open up the floor for the other person to say “actually my cat is very sick, I don’t think I’d be very receptive to that today. How about in a few days?”

If you ignore this bit, you might be fine, but the cost is low, and the mitigations great.

Situation and Behavior

Focus on the subject, not the person. You aren’t assessing this persons character, or who they are. You are giving data on a thing they did or said.

“You are lazy” is not useful feedback. It’s a judgement call. Nobody ever heard that and went “you’re right, I’m going to change my act and I’ll never be lazy again! If only someone had told me this 15 years ago it would have saved my marriage”.

Keep the feedback focused on your observation and be specific.

“Yesterday during our team planning meeting, you interrupted Carol 3 times when she tried to speak, as a result she stopped trying to contribute, and we never got to hear her viewpoint.”

Be specific. We didn’t say “you usually interrupt Carol”. It was about that specific meeting. Even if it had happened in the past, focus on specific most recent example. This prevents us from wasting time arguing about details. We can argue about “usually”, but we can’t argue about what actually happened.

Timing

In the ideal case, you want to give feedback as close to the event as possible.

If you feel confident to give your feedback in the moment, and you lean on your other great feedback skills like asking permission, go for it. It is however okay to sleep on it and reflect.

In most cases you should give whatever feedback you have the next time you meet.

Feedback that is about someones performance, may require you to consult with others. This is also fine, but keep in mind that the longer you wait, the more problems you invite.

If you sit on feedback for too long, it will become harder to be specific, and the persons memory of the event will start to get foggy. You risk your version of events drifting further from what they believe happened, which makes it harder for everyone to be on the same page.

The value of the data degrades over time. Your feedback on my presentation the same or next day is super helpful for me to reflect. If you give it to me 5 years from now, I probably forgot I even gave a presentation, and that’s 5 years where I could have used that feedback to have refined many presentations.

In Summary:

1. Feedback is data - Not a tool for behavior change.

2. One Message.

3. Ask First: Ensure the other person is ready to hear what you have to say.

4. Be Specific and Objective: Describe the situation and behavior, not the person’s character.

5. Be Timely: Provide feedback while the details are still fresh.

What looks like success today, is not what you need to do tomorrow.

Every day you should be updating the set of things you should be working on. Things can change fast—even in relatively stable environments—because we are dealing with people.

You might think updating your roadmap is the best use of your time. You spend the day on it and make good progress, choosing to not do a whole list of other lower priority things. The next day begins and you still think it deserves your time, and one of your engineers lets you know they are quitting.

Do you still work on your roadmap or do you deal with this new situation?

There are some important nuances here to discuss:

• Delegate as much as you can.

  • To the future

  • To other people

  • To the garbage can—because you won’t do it.

• Communicate to your stakeholders, team, and manager as much as you can about what you’re doing, and most importantly, what you’re not doing. This lets them reset expectations and plan accordingly. If that roadmap isn’t getting done when you said it was, let people know asap.

If success looks like completing the todo list to you then you need to change that mindset. The todo list doesn’t matter. What matters is being able to work on the most important things, communicating well about it, and being able to let everything else fall to the floor.

What follows is about Lead Kindly as a newsletter, and the Course I’m working on to help transform new or aspiring managers into confident leaders. If you don’t care about this you can jump here (or leave me a comment, what did you think about the article? I tried something a bit shorter today).

The Course

The raw writing for the course is 3,800 words so far, which excludes the many pages of planning, research, references, links, etc. That’s just 3,800 words I’m going to translate into videos and other course content. I’m very curious about what it will be like at the end! I haven’t fully completed a module yet, I’m chicken pecking around, writing on each of them in little chunks of effort. It’s very fun!

Teaching has always been my favorite way to learn, and putting together something where my goal is to transform new/aspiring leaders into confident leaders is no small feat! I want to make sure the course is packed with value, so it occupies a lot of my brain-space.

One of the first things I do each morning after waking up is work on the course. It’s quite fun! I am looking forward to recording the lessons, but I’m trying to nail the content first so I don’t have to re-record.

I’ve gone ahead and stubbed out all the 30~ resources I want to make for the course, and some of them I’ve started!

The one I am most excited for is the Question Bank which can be a resource you use as a manager to help 1:1s be more effective, or something you can give to the engineers on your team to help them figure out what insightful questions they can bring to 1:1s.

This is paired with the module on having the most effective 1:1s, and I think it will be helpful for most management styles.

The Newsletter

As of a little while ago we crossed the 100 subscriber threshold!!! Thank you so much to everyone tuning in. This has been a very fun adventure. I started this newsletter to help improve my writing, and now I feel it’s how I share what I’ve learned with others to help them grow as leaders!

I hope this newsletter continues to be valuable, and I will keep on working hard to make great use of your time. Thank you for helping me reach 100 people! That blows my mind.

My focus for the next while—besides the course—is to continue delivering value here for free. I will not be putting the articles behind a pay wall, and paid subs will always be an optional thing for people to show their support.

If there is something you want to see more of, feel free to reach out! I am always happy to chat, whether it’s in the comments or DMs. I respect that this relationship is mostly one way—I write and you read—but you are always invited to turn that around and get involved.

And if you are an EM, this is extra important to learn so that you can coach your direct reports into being managed easier. How meta is that!?

So whether you’re a software engineer, an engineering manager, or someone else I tricked into reading this, pull up a chair, this is going to be good!

Managers Are People

Your manager is a person, and understanding that is important to being managed well.

They will not always be their best self. They may come to work stressed or be dealing with hard problems. They may have just heard bad news right before they meet with you. They may not always be as present as they would like to be for your meeting, or will mess up and say the wrong thing.

If you can give your manager grace, while still holding them accountable, it will go a long way to having a good relationship.

In a perfect world they would never be late, keep their personal problems at home, never be stressed, always know the right answer, etc etc. But you’re never going to find this manager, so work with the human one you have, and hopefully they give you the same grace in return.

Managers Have Different Styles

Not all managers operate the same way.

Some are hands-on, some are laid back, and others may be extremely process-oriented. Once you learn these things about your manager, you can anticipate their needs and help them help you.

You also have your own style, and understanding how you like to work will go a long way to finding a compromise that you and your manager can be comfortable with.

For example, I like to have a shared doc with my direct reports to make it easier to manage our conversations. Some like to use Google Docs, some like to use Slack, and some don’t want a shared space at all (won’t look at it, won’t write in it). For the ones who don’t want a shared space, I maintain one myself and take notes there just for me. This allows me to operate the way I want, but I’m still flexible for how each individual prefers to operate.

Not All Managers Are Good

You might get stuck with a bad manager and I’m sorry. Bad managers were one of the big motivators for why I joined the ranks, to make it less likely that you’d get a bad one. I figured if I was good, and I could help others be good managers, we’d save you the headache. We’ll keep working at it!

A bad manager is someone who doesn’t want to get good at being a manager, or maybe they are a bad fit for you. They could be someone obsessed with power, can’t stop micromanaging, or are too much about themselves to be good for others.

Don’t stay with a bad manager for too long, you deserve a good manager, but I respect that leaving is not always an option. Especially today where the market is hard, and switching teams or companies isn’t feasible for everyone.

In these situations, try your best to manage your manager. In whatever way they are bad, try to limit their options. Hold them accountable for doing right by you. I recommend the book Crucial Accountability here, but it’s difficult to give a nuanced answer for such a wide topic: There are so many ways a manager can be bad.

I won’t cover managing up in this post, but don’t give up hope, you have options! And you are welcome to reach out and if I can help I’ll do what I can.

You are Responsible for You

Understand what success looks like for you.

This is a job you need to do. Your manager cannot do it for you. They can help, but ultimately you need to figure it out. Does success for you mean:

• Get promoted by a certain date?

• Taking on a certain type of project? Certain size?

• Getting your total compensation to a certain level?

• Technical mastery?

• Impacts on users?

• Peer recognition?

• Giving talks?

You cannot be managed to success if you yourself don’t understand what that looks like. There are thousands of things you could consider as your personal success, and it doesn’t have to be just one thing.

For me to be successful, I want to be make enough money to provide for my family, be able to help my team thrive, and be able to help other managers be better. I have a detailed understanding of what each of these means, so that I can always be working towards them.

If you’re feeling upset with your manager for not making you more successful, first ask if you know what success looks like. From there you can communicate this to your manager, and they can help you work on it together.

Pursue Your Desire Relentlessly

Once you know what success looks like, go get it!

Bring an agenda to every 1:1 with your manager. Fill it up during the week, and go through all your items. You want to do interviews? Awesome, add it to your agenda doc, and in your next meeting ask your manager how you get trained to do interviews.

Advocate for yourself and learn to be heard.

Don’t let a no from your manager stop you. If I did, I never would have become a remote engineer.

My manager told me no, and so I researched. I learned. I really wanted to be remote full time. After a few months, I asked if I could go remote for a week while I visited family.

I worked my butt off, and the remote stint went well, my manager was happy. A few months later I did two weeks. And then we did three. Eventually I moved back to Canada, and I asked to go remote. We had so much evidence that it worked, they were willing to give it a try.

I advocated for what I want, and I worked tirelessly to get it. If I just asked my manager to be able to go remote, got a no, and kept asking, no progress would be made. Instead I made it happened, and kept my manager in the loop so they could help me when it made sense. This made it very easy to manage me, and I got what I wanted.

If your manager is not helpful, look for other places. This is super true if you have a bad manager. Want to interview and your manager is useless? Talk to one of the recruiters yourself, talk to other interviewers who do training. I am not advocating for defying your manager, but if they are lazy or unwilling to put in the effort, don’t let that stop you.

Don’t Wait For Feedback

This is another area that could be a book.

Everyone says they do not get enough feedback. As a manager, no matter how much we give it’s never enough. Good software engineers relentlessly want to improve, and they love having all that glorious feedback data.

As a person being managed, make it easier to get feedback by telling your manager what feedback you are looking for.

When I was giving a talk at the company, I asked my manager to give me feedback on my presentation and how confident I appeared. My manager was able to give very specific feedback on how my umms and uuhhhs and body language helped or didn’t help me appear confident. I was able to work on these things and when I gave the real presentation, it went so much smoother.

If I had not asked at all, or just said “give me feedback”, it’s very unlikely I would have gotten much. Maybe my manager would have said the same things, but the chance is slim.

This obviously works for people who are not your manager, but your manager is always looking for ways to give you feedback, and this is not true of everyone else you encounter. So if you give them notes on where you’d like feedback, you’re going to see a huge improvement, and your manager will be happy at how much easier it is to manage you than your peers.

Learn To Accept Feedback Well

I have received a document that went on for pages about how I was not doing my job properly, and it outlined all the places I was failing as a manager.

This document was sent to my manager, and my skip level manager. I didn’t agree with the wild claims in the document, but do you know what I responded with?

I thanked the person who put it together.

I have no doubt this document was meant to discredit me and get me fired, but still it was feedback. Even if the content was ludicrous, somebody still thought these things. Knowing they think it, even if I disagree, was incredibly useful.

Getting criticism can be hard, especially if it’s from your manager. If you’re struggling with a piece of feedback, even if you disagree with it, thank the person for giving it. Knowing that your manager thinks some untrue thing about you is a gift.

Accepting feedback and being grateful does not mean you agree with the feedback. At the end of the day, gaining someone elses feedback is a tool you can use or not use.

In my case, I was able to understand that the person was very unhappy with how I was operating as an engineering manager. This enabled me to sit down with them in a 1:1 and explain my role to them. They were not an engineer, and so the way I managed was different. They wanted me to micromanage my team, and tell the engineers what to do. This is not how the team operates, and while this is upsetting for them, that wasn’t the issue.

The underlying issue was that they wanted something done and it wasn’t getting done, and they went after my management style as the culprit. After we level set on the role of an EM, and how engineering teams operate, we were able to discuss their actual concerns, and find a solution together.

Had I rejected the feedback or gone to arms, we would have become combatants. As someone who leads with empathy and kindness, I certainly had some words for their management style, but that would have cost us both.

And something tells me they probably wouldn’t have thanked me for my context :)

Closing Thoughts

I’ll be honest, I am choosing to end this article before I feel like I’ve covered everything, because I wanted to spend this evening working on the course, but I got this idea of “how to be managed” stuck in my head, and I have not stopped writing about it. SO, we are going to put a pin in it. Here are a quick few thoughts to tie us off for now, and I will probably revisit this topic sometime in the future:

• You will not get everything you ask for, but ask anyway.

  • Even a no has value, and now your manager knows what you want. I got a no for remote, but asking helped make it eventually happen.

• If you are unhappy, say something. Don’t be silent. Don’t let it fester. Even if you don’t think there is a solution (you’ll be surprised).

• If you want to get promoted, ask how that happens.

• If you get stuck and you genuinely tried to solve the problem, ask for help.

  • This is a goldilocks problem, don’t ask too early, don’t ask too late. If you’re unsure, let your manager know you’re unsure and work together on what timing is appropriate.

• If you want more money, ask for more money. Be open to hearing a no, but more likely you will learn how to get more money.

• Work life balance is important, don’t wait for your manager to make it happen.

  • More hours does not mean more output. It can in small doses for short periods, but burnout is real, more hours is never the way to get more done as a software engineer or manager.

• Asking for advice is gold. Don’t always bring problems, bring solutions, but problems can be fun too. Your manager likely likes solving problems.

• Remember that your managers job is to be a force multiplier for you, not to do the work. You do the work, they help you do the work better.

• Sometimes your managers best move is to do nothing. To not give you the answer. To not solve the problem. To not give you the resource. This can be frustrating, but it is sometimes what leads to the most growth and innovation.

I hope this helps!

So a month in, I was still figuring out how things worked, I asked my manager how I could be a mentor. I was thinking long term, but he said “actually we have an Android intern joining, are you interested?”

I said yes.

About a month later, we hired another full time Android engineer, and I said yes to mentoring them as well.

So me, this pretty inexperienced engineer (in my opinion at the time) had 2 mentees. I met with them weekly, helped them navigate a company I was learning to navigate, and helped them gain new perspective in different areas of software engineering and Android development.

My relationship with my intern was more involved because I had to help them find projects, and guide them a lot more, but both were great relationships that taught me a lot. I actually ended up becoming lifelong friends with the full time engineer, and attended his wedding years later.

I would go on to mentor dozens of software engineers in my career.

Each time I felt I was able to make a huge difference and help them see things in a few 1:1s that took me years and years to learn. It felt like giving people the shortcuts I wish I had learned! It was pretty intoxicating, and I learned to really love helping others level up.

I had one mentee who let me know early on in our relationship that they were planning to quit. We talked about this a lot, and they revealed a lot of issues they were having that ultimately could be solved if they had open and honest conversations with their manager. They would go on to stay for a few more years, getting a promotion, and being a lot happier with their job. They expressed looking forward to coming to work now, instead of dreading it and counting down the days until they would leave.

I consistently signed up for the mentorship program and every time I was matched with someone it felt like a new opportunity to make a big difference and learn a lot.

I’ve talked about why I became a manager before, but I actually forgot about the mentorship angle as a strong motivation. It was how I validated that being a manager was something I felt like I could be good at.

It’s not the only aspect of being a manager, and coaching+mentoring can be quite a bit different when its your team, but it was a good signal.

As a manager you are responsible for the success of the team, and by that nature your incentives are different. Being a truly great coach and mentor as a manager requires you to separate yourself from that fact, so that you can focus on what’s best for the individual, even if it hurts the overall teams success. Ideally you can align what’s best for them and the team, but sometimes there is a choice.

Most people have had a manager who would easily throw you under the bus for the team/business. Not only do I find this reprehensible in most situations, it’s just bad business. The best choice is to focus on the individual and what’s best for them, which will collectively be good for everyone. This is not a rule that always works, but it has been a very successful policy for me as a leader.

Everything I wrote in the previous article is true, I wanted to be a manager after reading High Output Management, and permanent remote led to me pulling the trigger on talking to my manager about becoming a manager, it was my mentorship experience that made me go “yes, I really think this is a good idea”.

If you’re considering engineering leadership, whether that’s as a manager or a tech lead, lean into mentoring opportunities more. Create opportunities to help others. How does that make you feel? If you feel like it’s a waste of time, then the individual contributor track may be a bitter fit for you.

If you find fulfillment in helping guide others, than it’s a strong signal that leadership may be something you enjoy.

When I think about being people-first, I want to make sure I defend the business. Without the business, we don’t have jobs, and thus we don’t have a team, so the business is still important and necessary.

However, when I say people first, it does mean putting the business second. I think counter-intuitively though, this is what’s best for the business.

If you only care about short term gains, you can always sacrifice people to boost short term productivity. This does increase risk, particularly for bugs and crashes, but forcing people to work long hours and burn out can serve you in the short term. I think this is horrible and lazy, but we would be dishonest to deny short term gains.

It will however always cost you in the long term. Always.

Investing in people and supporting their well-being is the only viable long term strategy. If you take care of your people, they will take care of you.

I can hear the skeptics and the pessimists screaming, and perhaps sometimes they are correct, but outliers aside I believe if you support your people with everything you have, it will always come back in higher returns for you and for them.

As a concrete example, I have had engineers on my team tell me they are interviewing elsewhere. They risked potential backlash from their manager by telling me this, but they chose to trust me. And in doing so, I was able to help them vet companies based on their career goals, help make space for them to interview (instead of them randomly taking time off) which was less awkward for them, and have someone to talk to about the job hunt.

In some cases, this helped them realize they want to stay and they are still with me, and in other cases we found them their next opportunity and we said our good bye on good terms.

Without this information early, I may find out when they have accepted an offer elsewhere, and I am unable to help them. That’s a choice they get to make, but by building trust I hope they can take the risk with me, because I am here to support them even if that means walking them out the door (and the business is sad about it).

This is a more extreme example of where I put people first. Perhaps I could have kept them longer and squeezed some productivity out of them by sabotaging their job hunt, or filling their head with pessimism about changing companies. I certainly wanted them to stay, so shouldn’t I use my influence to keep them?

I think you can try, and most managers do, but I don’t think it’s serving either of you, and is one of the biggest reasons management is a dirty word in some peoples mouths. People are not resources.

Your people need to feel supported by you. That they can trust you, and that they know you have their back, no matter what. In that world, you are going to get their best work out of them. You are going to have a strong relationship you both can lean on during hard times.

I have walked my team through tremendous challenges, both privately and as a team, and having that trust made the unexpected way more manageable for all of us.

So not only do I believe that being a people-first leader is the most productive way to lead, I think it’s the most kind way to lead.

Your people are giving up their time to work for this company. They don’t ever get that time back. In the reality where we need to trade time-for money, we could all use kindness. We could all use a leader who supports us in the best way they can.

Let me know what you think about people-first leadership! I love to be wrong, it’s the best way to learn.

1. ☑️ Concept, identify transformation

2. ☑️ Outline of Modules and shape of course

3. ☑️ Brainstorm supporting materials to create

4. ☐ Write for each module ← We’re here!

5. ☐ Create slides

6. ☐ Record lectures and edit them

7. ☐ Review course, and reshoot+edit anything that isn’t high enough quality.

8. ☐ Create remaining supporting materials not created along the way

9. ☐ Upload to a platform and start selling!

There are a lot of other steps, but those are the main “creation” steps. For example I’ll need to research different course platforms, work on marketing, creating buzz, etc.

Inside of “Write for each module” is a lot of research, that’s where we actually put things together. Making slides, recording videos, etc are more mechanical and those stages will go faster. The most valuable step is the current one!

Price

I had the thought today to start pre-selling the course before it’s done. I’ve had quite a few people reach out saying they want to take the course, which gives a very false sense of how well the course will do, because a sale isn’t a sale until money is exchanged.

This is where a pre-sale is valuable. If people are willing to put down money for it, there is no question. People not buying during the pre-sale does not mean your product can’t be successful. There is no way better to test the appetite than to sell it early.

However, in order to sell something you have to figure how much to charge, so between writing the modules, this is something I am going to work on.

Let’s dive into the thought process!

Kajabi gives three price points for courses as an example:

• Sell a mini course for about $47 to $147

• A shorter online course from $197 to $497

• A longer flagship course is around $1,000 to $3,000

They go on to say that every course varies, and these are just examples. And this makes sense. A course to edit photos that takes you two hours to go through, is competing against thousands of other courses offering something similar, and will be priced very low.

You could boost the value of the course by tackling something more advanced and niche, that might have less students who are interested in that niche, but they may be willing to pay more for your expertise, and there is less competition.

A speech coach for car sales will make much less than a speech coach for executives even though they are teaching very similar things, the niche is different.

My niche is new or aspiring engineering managers who want to self teach via a course they can do at their own pace. Not a massive audience of billions, and very specific knowledge I’ve spent years learning.

Cost and Profit Approach

One way to think about pricing the course is to consider the cost to produce it, and divide that by the expected number of people who might take it over the next 2~ years, and then add the profit.

Cost of course = (cost to produce + profit) / number of students

This requires understanding all the costs up front. The biggest factor here is labour, where I am the primary person putting the course together. If I were teaching this material 1:1, I would charge at least $500/hour, so if I figure out how long it will take me to finish the course, I can multiply the number by that to get an idea of cost.

I also need to add in hosting costs, fees taken along the way, licensing any assets, etc.

The challenge here is that at this stage with this approach is that I’m not sure how many people I will actually enroll in the course, or how much time it will take me to do the writing. I estimated around 400 hours of effort to produce the course given the current outline, which is pretty expensive at $500/hour. Perhaps there are ways to cut this down by hiring an editor and such, but we’re still stuck with the problem of knowing how many people might enroll.

Part of figuring out the price now, is that I would be able to pre-sell the course, which would give me some estimates on actual hunger for the course. Chicken meet egg.

Value Approach

Another way to think about this is to understand the value we will provide with the course.

Looking at the content of the course, how much extra money might this have made me as a manager if I had been able to take it? If I could have taken it as an engineer, how much sooner would I have become an EM, and how much further along my career would I have been?

Looking at each of the 20+ resources, how much time would each of those saved me? How much better and more professional of a leader would I have looked to my team, my peers, and my leadership chain?

I am also going to pack a lot of templates, and check lists, quick guides, etc into the course, which are all a tremendous value on their own. These each should save a new EM/leader lots of time if they otherwise didn’t have it. Even an hour~ each adds up considering the high salary that engineering managers hold. And each of these are well crafted, they aren’t randomly created. I’m making them an experienced manager.

I am also committed to adding more value to the course over time, and anyone who purchases the course will get the updated templates or additional resources even 5 or 10 years from now.

Lastly, we can also bring all the alumni together so that new managers can have a network of empathetic leaders who all took the course and have a shared jumping off point to connect and start their network strong. A lot of EMs struggle to build an internal network in their company, and we can use the course to help springboard EMs to already have an external network of leaders they can lean on or help.

While I don’t have a dollar amount of all that value as of now, calculating that can help determine how to price the course.

Philosophy on Price and Closing Thoughts

I want buying this course to hurt.

I don’t want people to pay for a course that sits on a shelf.

I don’t want people to pay for a course and poke around once in awhile and get nothing out of it.

I have an entire steam library full of games I bought on deals I will likely never play. I don’t want you to give me your money and then get nothing out of it.

I want you to love this course so much, every time you encounter someone who’s thinking about getting into engineering leadership, you recommend they take this course. “Use your development budget on this, it’s so worth it!”

I want to take uncertain, overwhelmed, potentially stressed out engineers/manager, and transform them into confident leaders.

That’s what I want from the course.

And one last thought: The price analysis is not looking at other courses. Why? Because there isn’t another course like this. I’ve looked. Nothing compares to what I am trying to build. I’ve looked at hundreds of courses, and everything falls short of my vision and what I’m going to offer. And that’s okay, they are doing their own thing, but when I think of price, I can’t compare it to anything else, so it needs to stand on its own. The price has to be right for the audience who will benefit from it the most.

I had just over 10 years experience as a Software Engineer when I took this career reset and something like 20~ years of programming experience. While I was able to bring a lot my skills along for the ride, it was starting over.

The First Day

The manager I was stepping in for had put together a 12 page document. I would refer to this document for the next 2~ years. It was kind of intimidating to receive it, as it provided the following information:

• A very heart warming welcome message. Thank you for this!

• General info about the team.

• Big list of projects, what’s in flight and upcoming work.

• Planning and staffing needs.

• Team processes and how things operate.

• People - where the risks are, how folks are doing, who needs what, who might struggle with the transition the most, etc. Also details about each engineer, she knew her people well.

I also had the chance to interview her before she left, and when I would ask her questions like “Where do you see the Design Systems team going in the future” she gave me a very detailed answer, and then 6 different links which had a ton of information. Entire roadmaps.

The notes I made from this meeting were 4 pages long.

I also received a 7 page “ramp up” doc from my mentor.

I was intimidated, to say the least.

These were already so much information, but of course the team had a Google Drive filled with hundreds of documents. Tech specs, project proposals, etc. They had a massive wiki filled with a ton of runbooks and descriptions of things. Github repos, a ton of them! All doing stuff, all important. There were Jenkins jobs and infrastructure built. The team owned internal websites. They had meetings with lots of different teams I didn’t know. This team also worked with Design, who had their own entire set of areas with their own documents and complicated inner workings.

So on my first day I took a deep breath, and I created a doc.

Everything went into that doc.

All the links, into the doc. Any new information? Into the doc. A task I needed to do? Into the doc.

It became massive very quickly. Before I abandoned it for a more robust system a few months later, it became 18 pages.

The first day came and went, and I survived. All the fears I had about it were unfounded. I met the team, I got to speak with me mentor, my manager, and I was off from there.

The First Month

I quickly realized that the organizational methods I had learned as an engineer were not going to serve me as a manager. There was just so much more information than when I was an engineer. There was in fact now 10 engineers worth of information, and like when I first learned to drive, it was so hard to know what to pay attention to.

1:1s began in earnest in week 2, and I was officially meeting with all 10 of my reports. One of the engineers had handed in her resignation before I started. To this day I’m not sure why, but I know that egotistically I assumed it was because I was leading the team. I was new, I had no idea what I was doing, and she was jumping ship before I crashed it. Very unlikely, but that was the story I wrote for myself in the early days.

As an extreme introvert who was afraid to do meetings with people — odd choice to become a manager I know — 1:1s ended up being the best part of the job.

I was very opinionated about 1:1s between managers and engineers, which gave me a great place to start: Here is how I view our relationship, what do you think?

As is common as a manager, everyone said that was great. And as is common as a manager, I had no idea if they were being truthful or sucking up. It was my first dip into the changes that come with leading a team.

The first month was hard, but not for the reasons I thought. It was the information overload that I struggled with, not the meetings. Even as an introvert who was very drained from meetings, the meetings were easy.

The First Quarter

I had my first hard lesson in ownership and stakeholder management when meeting with some executive stakeholders (VPs), who were reviewing our teams roadmap. I actually didn’t know what the teams roadmap was yet, but the design manager who managed the designers on the team had worked with the previous manager on it, and lead the meeting. One of my ethos of becoming a manager was not to change anything initially coming in. I didn’t have enough context to really own anything yet, I was here to learn and understand.

The executives were not happy with the roadmap.

I remember one part of that meeting where I was told by an executive that it’s my roadmap, so I have to have ownership of it. I had tried to give context that it was my first month~ on the team, and they were having no excuses.

I don’t fault them, but years later I don’t think I would have changed anything leading up to that meeting. I wasn’t going to evaluate and make a whole new roadmap in my first month, so I thanked them for the feedback and we moved on.

By the end of the first quarter, I had a chance to have my butt handed to me by execs, we got through an entire project cycle for projects I mostly understood, I had 2 people leave, and 1 more transfer to another team (we still chat!), I got to work through an annual compensation cycle and help with that, I got to run and do quarterly planning (for the upcoming quarter) with the team, and have some hard 1:1 conversations.

I got to meet and get to know my management group, and have interesting conversations about hard problems other managers were working through. I also got to share some of mine with the group, and get help and their perspectives on things.

I got to work through level calibrations, and learn about the other side of career planning and progression.

It was a hell of a first quarter.

And then my 5th child was born on Christmas Eve.

Paternity Leave As a Manager

At Yelp we get 8 weeks fully paid for paternity leave, at least in Canada. We can take longer, but you only get paid by employment insurance. I won’t go into how much that is, but it’s peanuts. I am the sole income for my family, so I only did the 8 weeks.

That is a long time to be away from your team, especially when you have only been managing them for 12 weeks. But that was part of the deal. My manager (ie director) knew going into this that at some point I would be out for leave. My team also knew and I talked to them about it.

This transparency was super helpful in planning for while I was gone.

We arranged for another manager to cover while I was out, and it went very well.

I came back more tired than ever (did you know babies are hard??) but it was nice to be in routine. On my 21st week as — but only having 12 weeks of experience — I was back home, leading my team, and taking ownership of that roadmap.

The first inkling to becoming a manager happened over a vacation.

I was working on the Core Android team at Yelp as a Software Engineer. I was good at what I did, I had peoples respect, I was very helpful, I got stuff done, etc etc. Nothing too exciting.

As far as a career though I was still kind of coasting. I had no real career aspirations, other than keep doing well? I didn’t know much about much, including why I was meeting with my manager every week. Does he just want to make sure I’m doing my work? Can’t he just look at my Jira for that?

So I go on this 2 week vacation to Scotland and Ireland. Beauty everywhere. Castle after castle after castle. Everwhere we went we’d find a nice spot to read. I read quite a few books in those 2 weeks.

One of them was “High Output Management” by Andy Grove. I can’t guarantee the same epiphany for you or anyone else, but it blew my mind.

I finally understand why I had been meeting with a manager every week for my entire dang career and I had been wasting it.

When I returned to work, I created a new Google Doc and shared it with my manager. I added a heading that was the date of our next 1:1, and during the week I wrote all my thoughts and questions in that doc. Our next 1:1 was so packed we got to maybe 5% of the things I wanted to talk about.

I created a new heading with the date of our next 1:1. I rolled over things I wanted to talk about, added things that came up during our 1:1 we didn’t have time to talk about, and during the week continued to add more topics.

I’d be working on build timings, and wonder why we couldn’t just get Android engineers better hardware, so I’d add “Can we get Android engineers better hardware? What’s that process like at Yelp? How do I build a case? Who would I need to talk to to get approval?”

What I learned reading that book, was that my managers job was to make me more effective. To ensure I was happy and wanted to keep working here. That my ambitions were met. His role was to remove blockers in my path.

Until I read High Output Management, I had no idea why I even had a manager. Nobody explained it to me, so I made my own assumptions and never even thought to challenge them and as a result I wasted so much potential in my first five years.

Don’t be me.

Use your manager. Build a relationship with them. Let them help you. HELP THEM help you. Give them data. Let them know what is getting in your way, dragging you down, and keeping you from doing your best. It doesn’t mean rely on them for things you can do yourself, you need to take ownership and responsibility, but there are so many things a manager can do to help you, especially early in your career.

They are a force multiplier for your career, if you let them. If you do the work.

As a result of creating that doc and putting in the effort to be thoughtful of what I wanted to talk about each week, I became the tech lead of the team. I got to run standups for the team. I got to do quarterly and annual planning. I was the one who put the roadmap together. I got to represent Yelp at Hack the North. I got to go on recruiting trips. I created opportunities to give talks, and write for Yelps external engineering blog.

These were things I wanted to do, and I made them happen by talking about them.

My manager was thrilled with this change, and would talk about how going on vacation was the biggest productivity boost I ever had (and I can’t disagree with that!). He asked me how he can get the other engineers to also have similar docs! ;p

So much and more sprouted from this idea that my career was in my hands, and my manager was here to support me. Some of those gains were because I was rubber ducking to my manager about my career, and some of them were from our now insightful conversations.

So About Becoming an EM?

Right!

So that book helped me realize the role of an engineering manger (EM) is to help support and bolster engineers, and I loved that idea. It was the first time I considered that as a career.

It wouldn’t be another 5 years until I actually made the leap.

I won’t run through the full 5 years, but the gist of the delay was because I became a full time remote engineer and moved to Canada. I wanted to be fully remote more than I wanted to be a manager.

When the COVID-19 Pandemic changed the landscape, and I realized that remote was here to stay, I let my manager know immediately that my intentions were to become an EM.

While I might have been able to pull it off before that — I can be very persuasive (and persistent!) — it would make it really hard to change companies. I didn’t want to become a remote EM at Yelp only to be unable to change companies because everyone else required EMs to work in office.

The pandemic changed that, and so I started to pursue the path.

Now, I wasn’t fully locked in when I told my manager. I had a 1.5 year plan to interview other EMs to understand the role and everything that came with it, I was going to read books, listen to podcasts, and take courses (I learned these don’t exist or are insanely rare).

A month — maybe two — later, there is an opening on the Design Systems team. Sort of a dream team for me. 10 engineers, ambitious projects, they help other internal engineers and designers be more efficient and productive. They had awesome products already. The engineers themselves were very respected and sought after.

But it didn’t fit the plan! It was a hard choice.

I interviewed the manager who was leaving, and she only made the decision harder. She spoke so highly of the team and made it even more exciting of an opportunity for me. I expressed my fears+concerns and she said she think I’d do great. Thanks for nothing! ;)

How I made the decision was this:

I pictured two scenarios, and asked which one would make me a better manager after 4-5 years.

The first was I say no thank you to the Design Systems team, I stay the course and continue with my interviews, reading books, listening to podcasts, and failing to find any courses because why would anyone make such a niche course helping other EMs be successful (hint ME, I’m doing this, but don’t tell anyone), and in 8-16~ months I become an EM (for another team).

The second option, I say yes and do the job. I read books when I can, I learn from my mistakes, and I embrace the terror.

The answer was so clearly the second one to me, so I said yes without any more deliberation. 4-5 years of doing the job is going to decimate 16~ months of study and then 3~ years of on the job.

In Closing

I will write another article some day on my experience becoming an EM and what that experience was like, but this was what lead to me becoming an EM, from the initial spark to my decision making criteria.

I don’t think becoming an engineering manager is for everyone, but after 3.5 years it was the correct role for me. I love this job, and I get to learn so much more than when I was an engineer. I am very lucky to have the team I have, and I feel I am in a position to help so many more people grow than when I was an individual contributor.

If you made it all the way through, thank you! I hope it was interesting or helpful to you in some way. Feel free to message me or comment, I’d love to chat! :) Also if that kind of course sounds interesting, let me know! I’ll add you to the list :)