TL; DR:

• Higher pay does not erase startup risk

• Your risk tolerance changes over time

• Treat equity as uncertain upside

• Join me for the live stream (or watch the recording) on Monday, September 21 at 7:00 PM Pacific!

Should You Leave A Stable Job For An AI Startup?

A developer asked me about a decision that sounds exciting and uncomfortable at the same time.

They are already working for one of the top employers in their country. The role appears reasonably stable, the pay is fine, and they can generally log off around five. But recruiters are reaching out about AI startups offering 50% to 60% more money.

So what is the catch?

Maybe longer hours. Maybe on-call work. Maybe less stability. Maybe equity that becomes incredibly valuable, or maybe equity that never becomes worth anything at all.

This is exactly the kind of decision where I do not think there is one correct answer. The useful thing is not for me to tell you, “Take the startup job,” or, “Stay where you are.” The useful thing is to make the tradeoffs visible enough that you can decide whether the risk actually fits your life.

You can check out my full thoughts on this in the video below:

There Is No Universal Risk Profile

My younger self and my current self would evaluate this opportunity very differently.

Early in my career, I had fewer responsibilities. I was not married. I did not have pets. I had paid down most of my school debt through internships, and I had already spent six internships working at small companies. I knew I liked that environment.

My first full-time role was at a startup. I would love to tell you that I researched every variable and made the mathematically perfect choice. I did not. Some of it was judgment, and some of it was luck.

What mattered was that I had room to take the chance. If the job demanded a lot from me, I was prepared to work hard and see where it went.

My life is different now. I am married. We have pets. If we decide to have children, that changes the equation again. My choices do not affect only me anymore.

That does not make the startup good or bad. It means the same offer can be a smart risk for one version of you and the wrong risk for another.

I wrote recently about how career fulfillment changes as your life changes. Risk tolerance works the same way. You need to revisit it instead of assuming the answer you had five years ago still applies.

Actionable Tip: Before comparing jobs, write down what you are protecting right now.

• Time with your family

• Predictable income

• Health benefits

• Career acceleration

• Learning opportunities

• Flexibility

• A mission you care about

If you do not know what matters most, the largest salary number will make the decision for you.

Compare The Full Trade, Not Just The Salary

A 50% to 60% raise is meaningful. I am not going to pretend otherwise.

But salary is only one line in the offer. If you move from a predictable schedule to consistently working nights, weekends, or on-call rotations, you are trading more than one employer for another.

You are trading time. You are trading energy. You may be trading certainty. Depending on the company, you may also be trading a clear role for whatever problem is on fire that week.

That environment can be energizing. It can also be exhausting.

I have talked about what four years in big tech taught me after working at startups, and one of the biggest differences is not that one environment has problems and the other does not. It is that the problems often have a different shape.

At a large company, stability does not mean layoffs are impossible. We have all seen that. What it often means is that the company is not relying on one product, one small customer base, or the next funding round to make payroll.

At a startup, those business risks can be much closer to your day-to-day reality.

Actionable Tip: Translate the offer into the actual trade you expect to make.

1. What compensation is guaranteed?

2. What hours do people really work?

3. How often is the team on call?

4. How much runway does the company have?

5. What happens if the next funding round does not happen?

6. What would you lose by leaving your current role?

The goal is not to make the startup look scary. The goal is to stop comparing one complete job with one attractive number.

Equity Is Not The Same As Cash

Startup equity can be exciting. It can also make an offer feel much larger than it really is.

The important reality is simple: the company has to become valuable for that equity to become valuable.

That can happen. People join startups, work incredibly hard, and end up with a life-changing outcome. It is also not the most common outcome.

My mental model would be to make sure the guaranteed compensation works for me first. Then I would treat the equity as uncertain upside.

Ask about:

• The number and type of shares or options

• The current valuation

• The strike price

• The vesting schedule

• The exercise window if you leave

• Expected dilution

• Whether there is any realistic liquidity path

You do not need to become a venture-capital expert. You do need to understand enough to avoid mentally spending money that may never exist.

The same applies to the mission. If you strongly believe in what the company is building, that can absolutely matter. I have written about how much company alignment matters for developers, because believing in the work can make a difficult season feel worthwhile.

Just do not let belief in the mission replace basic due diligence.

Startup Learning Can Be Incredible

I think startups can be some of the best learning environments available to a software engineer.

Why? Because there is usually so much happening that it is almost impossible not to learn.

There may not be a specialist for every problem. The company may be solving something for the first time. You might need to move between architecture, implementation, operations, customer feedback, hiring, and planning much faster than you would in a more established organization.

That chaos is not automatically bad. It can force you to develop range, judgment, and comfort with ambiguity.

Of course, constant switching has a cost. The context-switching problem looks different across startups and large companies, but neither environment is magically free from it.

The question is whether the learning is worth the pace for you.

If your goal is to compress a huge amount of experience into a few years, a strong startup can be an incredible opportunity. If you are already near burnout, need predictability, or want to protect time outside work, the exact same environment may be a terrible fit.

Subscribe now

Interview The Startup Back

A company can tell you that it has excellent work-life balance. You will learn more by asking for concrete examples.

Try questions like:

• What did the team work on outside normal hours in the last month?

• How often are engineers paged while on call?

• What happens when a deadline slips?

• How many people have left the engineering team in the last year?

• What is the company’s current runway?

• Which assumptions must become true for the business to succeed?

• Why is this role open?

• What would make someone unsuccessful here?

Listen for specifics.

“We care deeply about balance” is a value statement. “The team had two after-hours incidents in the last quarter, and here is how we handled them” is evidence.

You may still join without perfect answers. Startups are uncertain by definition. But uncertainty you understand is different from uncertainty hidden behind recruiting language.

Run The Failure Scenario

Most people spend a lot of time imagining the upside.

What if the company takes off? What if the equity becomes valuable? What if you learn more in two years than you would learn in five somewhere else?

Those are fair questions. Now run the other scenario.

What if the startup runs out of money? What if the role is not what you expected? What if you leave after six months? What if the job market is difficult when that happens?

Can you absorb that outcome financially and emotionally?

If the answer is yes, the risk may be completely reasonable. If the answer is no, that does not make you timid. It means the downside has consequences you are not willing to accept right now.

Actionable Tip: Decide what failure would cost before you decide what success could pay.

Consider your savings, benefits, visa or residency constraints, family responsibilities, and how long a job search could realistically take. The more fragile the downside is, the more evidence you should demand before taking the bet.

My Answer Is Different Now

At this point in my life, I know how I work. I like working hard, sometimes to a fault. I can get deeply focused on making progress and do a poor job balancing everything else.

Because of that, if I joined a startup again, I would probably assume I was consciously giving up some work-life balance. Maybe the company would prove me wrong, but I would not build my decision around that hope.

I have also said that if I put startup-level energy into something again, it would most likely be my own company. There are a very small number of people who might convince me otherwise, but I know how much effort a successful startup can require. I do not think I have that effort available for somebody else’s vision right now.

That is part of why I still build side projects and think carefully about what I want to build next. They let me explore ideas and create things while keeping control over how much of my life I am willing to trade.

Your answer may be completely different, and that is the point.

Subscribe now

The Decision Is Big, But It Is Not Permanent

Changing jobs is a major decision. It is not a permanent identity.

You can join the startup and discover that it is not for you. You can stay in the stable role and reconsider when your circumstances change. You can interview, learn more, and decide the offer is not strong enough.

If a startup fails, that is not the end of your career. It may be inconvenient. It may be stressful. Finding another role may take time. But if you keep learning, working hard, and pursuing opportunities, one company failing does not erase what you gained.

So should you leave a stable job for an AI startup?

Maybe.

But do not make the decision because AI is exciting, the recruiter created urgency, or the salary number is large. Make it because you understand the workload, the business risk, the learning opportunity, the mission, and the downside, and you still believe the trade fits the life you have now.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Fulfillment changes as your life changes

• Career decisions are rarely permanent

• Meaningful impact is personal

• Join me for the live stream (or watch the recording) on Monday, September 14 at 7:00 PM Pacific!

Is Anyone Actually Fulfilled With A Software Engineering Career?

A developer asked a question that sounds simple but gets complicated very quickly: Is anyone actually fulfilled by a career in software engineering?

This was not really another conversation about AI taking jobs or changing how we write code. It was a much broader question about whether the career itself gives people what they hoped it would.

I have been thinking about this recently because I had an intern on my team, and we talked through some of the choices that show up early in a career. Do you go directly into the workforce? Do you continue school? What kinds of roles or industries might fit? Those decisions can feel enormous when you are making them.

The thing I wanted to make clear is that fulfillment does not have one permanent definition. It can look different from person to person, and it can look different for the same person as life changes.

You can check out my full thoughts on this in the video below:

Fulfillment Is Allowed To Change

I think most people have some core values that remain fairly stable. The way those values show up in your life, though, can absolutely shift.

At one point, career growth might be the thing you prioritize most heavily. At another point, family, flexibility, health, education, or time outside work might carry more weight. That does not mean you were wrong before. It means your situation changed.

This is why I do not think career fulfillment is something you answer once and then lock in forever.

If you never revisit it, five years can pass before you realize that four years and eleven months of a role have felt completely wrong. The first month was exciting because everything was new, and then the rest became something you tolerated.

That does not mean you need to conduct a dramatic career review every week. It means you should check in often enough to notice when the work no longer fits. I have written about building a career that fits how you operate, and the same idea applies even when burnout or ADHD is not part of the question. A career can look successful from the outside and still be a poor fit for the person living it.

Actionable Tip: Put a recurring career check-in on your calendar. Quarterly might work. Yearly might work. The exact cadence matters less than making sure the reflection actually happens.

Ask yourself:

• Which parts of my work give me energy?

• Which parts consistently drain me?

• Am I learning, contributing, or moving toward something I value?

• Has my answer changed since the last time I asked?

You do not need to make a giant change every time. Sometimes the answer is simply, “This still works for me.” That is useful information too.

Most Career Decisions Are Not Permanent

Early career decisions can feel like doors that close behind you.

If you start working after school, can you ever go back for a master’s degree? If you choose graduate school, are you falling behind everyone who entered the workforce? If you move into management, have you permanently left technical work behind?

These choices have tradeoffs. Going back to school while working full-time is not trivial. Changing roles may cost time, money, comfort, or momentum. But difficult is not the same as impossible.

I have known people who completed a master’s degree part-time while working. Plenty of engineers have moved from individual contributor roles into management and then returned to individual contributor roles. People change industries. They take time away. They discover that the path they selected was not what they expected.

That flexibility matters because what comes after senior software engineer is not one universal promotion ladder. Success might mean staff engineer, management, a different specialty, a smaller company, independent work, or staying exactly where you are because the work fits your life.

The goal is not to avoid making a choice. The goal is to stop treating every choice as a life sentence.

The Role And The Career Are Different Questions

Sometimes people decide they are no longer fulfilled by software engineering when the actual mismatch is narrower.

Maybe the domain does not interest you. Maybe you do not believe in the company’s mission. Maybe the team environment is unhealthy. Maybe the role asks you to spend your time in ways that no longer line up with what you enjoy.

That distinction is important.

An engineering manager who keeps reaching for coding tasks might not hate software engineering. They might miss building things. Someone who feels disconnected from a product might not need a new profession. They might need a domain where the outcome matters more to them.

This is why I think the management trap in software engineering is worth understanding before treating management as the automatic next step. Management is a different job. It can be incredibly fulfilling, but it does not become fulfilling merely because it comes with a promotion or better compensation.

I have been managing teams for roughly thirteen years, and I still genuinely love building software. In my primary role, spending more time coding would usually mean spending less time on the people and organizational work that I am actually responsible for. That is a real tradeoff.

AI tools have created a few more opportunities for me to build things without taking focus away from the team, which I appreciate. But the underlying question remains: Do I still value the work my role needs from me?

The same tension exists before management too. As senior engineers spend less time coding, their impact often shifts toward design, communication, mentoring, and helping other people move faster. If writing code is the only part that feels meaningful, that shift can be uncomfortable.

Impact Is More Than How Many People You Reach

When I think about fulfillment in my own career, I keep coming back to impact. Not performance-review impact. Not the biggest number I can put beside a project. I mean impact on an area of life that matters to me.

Earlier in my career, I worked on digital forensics software used by investigators, examiners, and law enforcement. The software helped people recover and understand evidence from digital devices. The total audience was much smaller than the audience touched by the work I do now, but the impact on an individual case could be enormous.

My current work can affect experiences for hundreds of millions of people. That is massive reach. At the same time, one request taking a little longer for one person does not feel as personally significant as helping uncover evidence that contributes to finding the truth in a case.

Neither form of impact is fake. They are simply different.

In my role now, much of the personal fulfillment comes from working directly with people. I get to help engineers grow, progress in their careers, and work through challenges. That gives me some of the individual impact that I value even when the product impact is broad and less personal.

This is also why company alignment matters for developers. If the organization’s mission is deeply connected to something you care about, the work itself may provide a strong sense of purpose. If it is not, fulfillment may need to come from the craft, the people you support, the flexibility the job provides, or the life the job enables outside work.

There is no rule that says your employer must be the source of all meaning in your life. Some people want work to be a reliable nine-to-five that funds everything they care about after five. That is completely valid.

That is not how I personally think about work. I enjoy working, and I spend too much of my life doing it to settle indefinitely for, “This feels okay.” But that is my answer. You need to understand yours.

Run The Smaller Experiment

If your honest answer is that the work is not fulfilling, resist the urge to jump immediately to the largest possible conclusion.

“I hate this project” does not automatically mean “I hate software engineering.”

“I miss coding” does not automatically mean “I failed as a manager.”

“I want a different kind of impact” does not automatically mean “Everything I built in this career was wasted.”

Actionable Tip: Identify the smallest change that could test what is actually missing.

• Try a different type of project

• Ask for more mentoring or design responsibility

• Explore another team or business domain

• Talk with an individual contributor who returned from management

• Take a course before committing to another degree

• Build something outside work to see whether creation is the missing piece

Small experiments give you evidence. They help separate dissatisfaction with one environment from dissatisfaction with the entire career.

Do Not Settle For “Fine” Without Checking

So, are software engineers actually fulfilled?

I hope many of us are. I enjoy what I do, and I can still say that I could be more fulfilled. Those statements are not contradictory.

Fulfillment is not a finish line you cross after getting the right title, salary, or employer. It is an ongoing alignment between what you value and how you spend your time. Because both sides can change, the conversation has to happen more than once every five years.

Check in with yourself. Separate the role from the industry. Think about the kind of impact that matters to you. Remember that most career decisions are not carved in stone.

You spend too much of your life working to never ask whether the work still fits.

Share

Leave a comment

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• A missed date is not a PIP

• Ownership means finding the next move

• Manager accountability covers people and outcomes

• No livestream... I am on vacation!

When A Developer Misses The Deadline, Who Owns It?

A question came up in the comments about what happens when an engineer does not deliver a project on time.

Does the developer get put on a performance improvement plan? If the manager cannot get the developer back on track, does the manager get put on one too?

It is a fair question, but it starts from a framing that I think is too simple. A project slipping does not automatically mean somebody failed at their job. Real projects have dependencies, changing constraints, technical surprises, and decisions that turn out differently than expected.

The more useful question is this: When the plan stops working, who takes ownership of figuring out what happens next?

You can check out my full thoughts on this in the video below:

A Missed Milestone Is Not An Automatic PIP

Let’s start with the most important distinction.

A performance improvement plan is not supposed to be the automatic consequence of one missed milestone. A project can slip for all kinds of reasons:

• Another team misses a dependency

• An external vendor falls behind

• The original technical approach does not work

• The scope was larger than anyone understood

• A higher-priority incident interrupts the plan

• The date was unrealistic from the beginning

None of those automatically means the engineer assigned to the project is performing poorly.

There is a difference between the outcome being off track and the person refusing or failing to engage with the problem. That distinction matters. I have written about when a struggling developer should be raised with their manager, and the same principle applies here: early communication creates room for coaching and correction. Silence removes options.

If you miss a date because a dependency moved, that is one problem. If you knew the dependency moved, said nothing, explored no alternatives, and let everyone discover the delay at the deadline, that is a different problem.

Ownership Starts When The Plan Breaks

When I talk about accountability, I am not saying that you must personally control every variable. You cannot.

What you can control is how you respond.

If the project is slipping, ownership means communicating that clearly. It means looking for alternatives instead of sitting back and hoping the problem fixes itself.

Maybe the date can move. Maybe the scope can shrink. Maybe there is a temporary implementation that meets the immediate need. Maybe your team can help the dependency team finish its work. Maybe you need to abandon the original design and choose something that is available now.

Actionable Tip: When you raise a delivery risk, bring the clearest options you have.

• What changed?

• What does it affect?

• What can still be delivered?

• What tradeoffs could protect the date?

• Who needs to make the decision?

You do not need to have every answer before speaking up. But “the project is late” is much less useful than “the project is at risk, here is why, and here are the three paths I see.”

This is where radical accountability differs from a blame culture. Accountability is about improving the situation. Blame is about finding the person who should absorb the discomfort.

Those are not the same thing.

Managers Own More Than Individual Performance

As an engineering manager, one of the most important parts of my job is helping people do their best work and grow in their careers.

But that is not my entire job.

I am also responsible for the charters of my teams. I currently have three sub-teams working in different areas of a routing plane for Microsoft 365. Those teams have different focus areas, including firewall technology, but they contribute to a larger mission.

If everyone is happy, growing, and producing excellent work that has nothing to do with our charter, I am still failing in my role.

On the other hand, if we deliver everything by grinding people down, ignoring their careers, and treating them like interchangeable output machines, I am also failing.

The job requires both. I need to support the people and help the organization get the outcomes those teams exist to produce. That balance is part of what is expected from an engineering manager.

So when a project slips, I cannot point at the engineer and say, “That was their project.” I might not be the person writing the code or coordinating every dependency, but I am accountable for whether the team has the clarity, support, coaching, and escalation paths needed to move forward.

Accountability Bubbles Up The Organization

This does not stop at the engineering manager.

If I repeatedly ignore my team’s charter, miss important outcomes, or fail to coach people who need support, my manager should notice. If that continues for months and nobody addresses it, accountability moves another level up.

Every layer has expectations of the layer below it.

That does not mean every missed delivery triggers a chain of performance plans. It means leaders should be able to explain what they own, how they know whether it is healthy, and what they are doing when it is not.

This is why measuring manager effectiveness is so difficult. You cannot reduce the role to one number. Technical direction, delivery, hiring, coaching, team health, and stakeholder trust all matter.

A manager might be strong at supporting people but weak at connecting their work to the team’s charter. Another might drive delivery while leaving a trail of burned-out engineers. Neither extreme is what I would call effective management.

Coaching Is Part Of The Manager’s Deliverable

The original question also called out hiring and coaching. Yes, managers should be accountable for both.

If I repeatedly make poor hiring decisions, someone should ask whether I need help improving how I assess candidates. If an employee needs performance support and I neglect them, that is not the employee’s failure alone. Coaching and mentoring are part of my job.

That does not mean every unsuccessful performance plan proves the manager failed. Sometimes a manager can provide clear expectations, frequent feedback, practical support, and reasonable opportunities to improve, and the employee still does not meet the role’s requirements.

The accountability is in doing the work properly.

Actionable Tip: If you manage people, do not wait for a formal process before providing useful feedback.

Use regular conversations to make expectations visible. Talk about what is going well, what needs to change, and what support would help. Effective one-on-ones should evolve around the person and the situation, not become a calendar ritual where neither person says anything meaningful.

If a formal performance process becomes necessary, it should not be the first time the employee hears that there is a problem.

Ask What Each Person Did Next

When something goes wrong, I would avoid jumping immediately to, “Who gets put on a PIP?”

Instead, ask:

• When did the risk become visible?

• Who communicated it?

• What alternatives were explored?

• What support did the engineer request?

• What coaching did the manager provide?

• What decisions did stakeholders make?

• Did this happen once, or is it a repeated pattern?

Those questions give you a much better picture of accountability than the missed date by itself.

Projects will slip. Dependencies will fail. Estimates will be wrong. That is software engineering in the real world.

Ownership is not pretending you can prevent every problem. Ownership is refusing to become passive when the problem appears.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• AI changes the work, not your interests

• Keep the parts that energize you

• Offload friction without surrendering judgment

• Join me for the live stream (or watch the recording) on Monday, August 24 at 7:00 PM Pacific!

AI Can Write The Code -- What Part Do You Keep?

There is a version of the AI conversation that is mostly about fear: Are software engineers getting replaced? The question that caught my attention from the ExperiencedDevs subreddit was different.

This developer was not primarily worried about losing their job. They were worried about losing the part of software development that made them care in the first place.

They can hand increasingly complex work to an LLM and get something useful back. That’s impressive, but it also leaves them wondering where they fit into the process. The building, the problem-solving, and the feeling of making something are starting to feel different.

I’ve talked before about how AI career fears are evolving, but this is not just another replacement-anxiety discussion. This is about engagement. If AI can perform more of the work, what part of the work do you actually want to keep?

You can check out my full thoughts on this in the video below:

I Would Start With Questions, Not A Prescription

If I were talking directly to this person, I would not jump straight to, “Here’s the best AI stack,” or, “Here’s the correct way to stay motivated.”

I would ask questions.

• What part of software development used to pull you in?

• Was it exploring a hard problem before the solution was obvious?

• Was it designing the system?

• Was it writing the implementation yourself?

• Was it learning an unfamiliar technology?

• Was it simply seeing an idea come to life?

Those answers matter because two developers can do the same job and love completely different parts of it.

I’ve had people tell me they genuinely enjoy working in legacy codebases. They like the constraints. They like figuring out how to move one piece without breaking five others. Someone else might look at the same situation, read about dealing with legacy code, and think, “Please let the AI handle all of this.”

Neither person is wrong. They are motivated by different challenges.

The Industry Is Optimizing For Throughput

My own experience with AI coding tools has changed quickly. Not that long ago, I could hand over a non-trivial feature and the result was somewhere between, “Cool, that worked,” and, “I just created more work for myself.”

There were tasks I would not even bother delegating because I expected the back-and-forth to cost more than doing the work myself.

That line keeps moving.

The models are more capable. The tools around them are better. Skills, instruction files, custom agents, and stronger development harnesses let us provide useful context without manually writing a 400-page specification for every task.

I do not think “one-shot everything” is a useful goal by itself. I also do not think the future of software development is engineers spending all day writing absurdly detailed specs. But the direction seems clear: AI is taking on more ambiguous work with less explicit supervision.

That means organizations will keep looking at throughput. If one person can move several workstreams forward with AI while another person insists on manually completing every step, there may be pressure on the second person to change.

That is not a moral judgment. It is a constraint worth acknowledging.

I’ve shared some of my real GitHub Copilot CLI workflows on a C# codebase, and the benefit is not that I can avoid thinking. The benefit is that I can spend more of my thinking time where it has the most value.

Find The Zoom Level You Actually Enjoy

I think about software development at different “zoom” levels. It’s actually something I apply when thinking about codebases, system architecture, workflows... and even careers!

At one level, you care about the exact loop, condition, and method. Zoom out, and you care about how the classes collaborate. Zoom out again, and you care about service boundaries, data movement, and the shape of the system.

Some people love the implementation details. Some love the architecture. Some love experimenting in the problem space before any architecture exists.

For the developer who raised this question on the original Reddit post, it sounded like the early problem-solving pass might be the part they want to preserve. They want to explore the difficult problem themselves and bring in AI afterward.

That can be a completely reasonable operating model. The important part is understanding the tradeoff. If that early pass becomes the bottleneck while everything around you is optimized for throughput, you may need to adjust how much of it you keep, how long you spend there, or what you hand off afterward.

Actionable Tip: For one week, keep two short lists:

• Work that gave you energy

• Work that drained your energy

Do not write broad labels like “coding” or “meetings.” Be specific. Was it shaping an API? Untangling a production issue? Writing repetitive mapping code? Reviewing a design? Learning a new domain?

Patterns will show up. That kind of reflection matters well beyond AI, and it is part of building a career that fits how you are wired.

Let AI Take The Friction

Once you know what you want to keep, look at the rest of the work.

Maybe you hate writing boilerplate. Maybe tests, observability, or security reviews are the tasks you procrastinate on. Maybe you love designing a feature but lose all momentum when the implementation becomes repetitive.

AI can help with those parts, but “give it to AI” is not the same as “stop being responsible for it.”

If I want an LLM to handle work that I do not enjoy, I still need to set it up to succeed:

1. Explain the outcome, not just the task label.

2. Provide the constraints and relevant context.

3. Define how the result will be checked.

4. Review high-risk decisions instead of trusting plausible output.

Otherwise, I have not removed the frustrating work. I have replaced it with babysitting an agent that keeps producing the wrong thing.

The goal is not to surrender judgment. The goal is to reduce the mechanical effort around the judgment.

What I Actually Love About Building Software

This thought exercise made me look at my own patterns.

Historically, I have loved building frameworks and reusable systems. Many many moons ago, I built UI framework experiments in XNA and Unity. I have spent time creating ridiculously overcomplicated libraries that almost nobody would use, sometimes including me.

Why? Because exploring the shape of those systems was fun.

The same pattern shows up in things like BrandGhost and Needlr. BrandGhost started because I needed a tool as a content creator and wanted to build it. Needlr grew out of the way I liked structuring C# applications. Both gave me a chance to take an idea, shape it, and watch it become real.

That is the key for me: I like seeing ideas come to life.

I care about technical direction. I care about architecture. I care about patterns that will create headaches if they spread across a codebase. I do not feel emotionally attached to writing every if statement or choosing between a for loop and a while loop.

For a long time, writing all of that code was simply the price of admission.

There was also an almost inevitable point in some side projects where the design ballooned, I realized I needed to undo earlier decisions, and the recovery work felt bigger than the fun part. Historically, that could be where I abandoned the project.

AI changes that balance. It can help me refactor, recover, and fill in the mechanical pieces while I stay involved in the direction. That’s a big reason I still build side projects. I can explore more ideas without every idea demanding the same amount of manual implementation.

AI Can Expand Your Range

There is another benefit here: AI can help you move into areas where you do not have deep experience.

I had an agent put together front-end work for a private dashboard. I could inspect whether the behavior made sense. I could check whether the tests exercised real code instead of a fake system under test. But I did not have years of front-end experience that let me confidently debate every pattern in the implementation.

Without AI, I might have needed to learn an entire stack just to build a dashboard I needed. Blazor has often been useful to me for a similar reason: I can bring my C# experience into web UI work. AI gives me another way to cross that gap.

That does not instantly make me a front-end expert. It lets me produce something useful while being honest about where my judgment is strong and where I need more help.

The same applies to learning. I love the feeling of having learned something, but I am often uncomfortable at the beginning of a new challenge. AI can launch research in parallel, summarize a domain, and give me enough footing to start asking better questions.

It lowers the barrier. I still have to engage with the result.

Build A Personal Operating Model

There is no universal percentage of software development that you should keep for yourself.

Instead, build an operating model that reflects your interests, your role, and the risk of the work:

• Keep the work that gives you energy and develops judgment you want to retain.

• Co-pilot the work you enjoy but can accelerate with feedback or parallel exploration.

• Delegate mechanical work where you can define a clear outcome and verify it.

• Review decisions involving architecture, security, data, and other expensive failure modes.

Then revisit the model. AI capabilities will change. Your role will change. The parts you enjoy may change too.

Actionable Tip: Pick one task you routinely dislike and improve the handoff to AI. Add the context, examples, constraints, and checks it was missing. Do not expand this to everything at once. Prove that the handoff actually saves time before you depend on it.

Humans Are Still In The Picture

I am not convinced the destination is, “People disappear and AI builds everything.”

My expectation is that people become much more amplified by AI and whatever tooling grows around it. I do not have a crystal ball, and I am not going to pretend that I know exactly how every software role changes.

But even in my own projects, the valuable part is not just code appearing faster. It is being able to explore more directions, recover from mistakes that previously killed momentum, and focus my attention on the parts where I have something meaningful to contribute.

That still requires a person deciding what should exist, what good looks like, and which tradeoffs are acceptable.

Wrapping Up

If AI could take over one part of your software development work tomorrow, what would you be relieved to lose?

Now flip it around: what part would you genuinely miss?

That second answer is the important one. It tells you where your interest lives. Keep enough of that work to stay engaged, get better at it because you care, and use AI to reduce the friction around it.

You do not need to reject AI to preserve what you love about software development. You need to be deliberate about where you fit into the process.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Better code does not guarantee efficiency

• Review loops need stopping conditions

• Scope control still belongs to you

• YouTube would not let me schedule a stream so... no stream 😦

GPT-5.6 Sol Impressed Me -- Then It Wouldn’t Stop

One of the weirdest parts of using a stronger coding model is that the failures can start looking useful.

I had been using the Opus models pretty heavily, especially because the large context window was genuinely impressive. Then I switched back to a GPT model with GPT-5.6 Sol, and my first reaction was basically: holy crap, this thing is good.

I have written before about how different models can change the shape of a Copilot workflow. This was one of the clearest examples I have felt in practice. Sol was not just producing code I liked. It was noticing things around the requested work that other models had missed.

That sounds great, right?

It was. Mostly.

You can check out my full thoughts on this in the video below:

Going Off The Rails Can Still Produce Gold

I was trying to explain model differences to my wife, who uses ChatGPT but does not spend her time comparing coding models like some of us do.

The example I gave her was scope drift.

You ask a coding model to change one thing. Then you review the diff and discover that it touched files you never mentioned. With some models, I have looked at those changes and thought, “What were you even doing over here?” The answer is usually some version of: yeah, that was unnecessary.

My early experience with Sol was different.

It touched unrelated tests, but the tests were actually wrong. It found behavior that technically passed the existing test while still being incorrect. It caught bugs in test code and bugs in underlying features that were outside the narrow task I had assigned.

That is a pretty incredible feeling. The model appears to wander, you prepare yourself for cleanup, and then you realize it found something real.

But there is an important distinction here: useful scope drift is still scope drift.

When I am using GitHub Copilot CLI on a real C# codebase, I need to understand what changed, why it changed, and whether that extra work belongs in the same delivery. Finding a bug is valuable. Quietly folding every discovered bug into one feature is not automatically the right move.

A Better Result Can Still Be A Bad Workflow

This is where my opinion became more divided.

I noticed some Copilot sessions taking a really long time. Work that I expected to take maybe thirty minutes would keep going for several hours. I would check the session assuming something had broken in the harness or a sub-agent had died.

Instead, it was still working.

It had run a review. Then it was fixing review findings. Then it was reviewing the fixes. Then another perspective found something else. On one feature, I saw the pull request appear after roughly five hours of agent work, even though the feature itself was not a monumental coding effort.

Was the output good? Often, yes.

Was five hours the right tradeoff? I am not convinced.

We talk a lot about model quality, but delivery has more dimensions than whether the final code passes tests:

• How long did the work take?

• How much unrelated code changed?

• How expensive was the review loop?

• How much attention did I need to spend supervising it?

• Could we have shipped the intended scope much earlier?

A model can produce better code and still create a worse overall workflow if nobody tells it when to stop.

The Review Loop Can Convince Itself

I like review agents. I like rubber-duck agents. I like asking for another perspective before I trust a change.

I also think they can create a nasty feedback loop.

AI is extremely good at sounding confident. Most of us have read an answer and thought, “That sounds believable,” even when we did not have the evidence to prove it. The same thing can happen between agents. A reviewer confidently proposes another improvement, the primary agent accepts the premise, and suddenly the task has a whole new branch of work.

This is not an argument against custom agents and skills in Copilot CLI. I use them constantly. It is an argument for making their boundaries explicit.

One of my sessions started with a few changes to an evaluation harness. When I checked it later, the agent was hand-writing a custom Markdown parser.

What?

That was the software equivalent of walking into your house and finding animals casually having a conversation in the living room. Nobody is acting like anything is wrong, but you know this is absolutely not where the evening was supposed to go.

The parser was not the assignment. The agent had reasoned its way into creating more work, and every additional change gave the next review pass more surface area to inspect.

Better review is not infinite review.

Prototype Mode And Hardening Mode Need Different Contracts

When I am building something, I am usually operating in one of two modes.

The first is prototyping. I want to know whether an idea is feasible. Can I connect these pieces? Does this service do what I need? Is the core experience even possible? The code may be throwaway, and that is fine.

The second is hardening. The feasibility question is already answered. Now I need regression tests, repeatable behavior, operational reliability, and confidence that I can keep changing the system without breaking it.

Those modes need different instructions.

If I am prototyping, an agent that spends hours polishing abstractions has missed the point. If I am hardening, an agent that proves the happy path once and declares victory has also missed the point.

Actionable Tip: tell the agent which mode it is in before describing the task.

For a prototype, define the question you need answered and explicitly deprioritize polish. For hardening work, name the behaviors that need regression coverage and define which adjacent changes are allowed. If the agent discovers something outside that boundary, have it report the finding instead of automatically implementing it.

That one distinction can prevent a lot of “How did we end up building this?” moments.

A Million Tokens Does Not Remove Context Management

The other issue I have seen is around the context window.

GPT-5.6 Sol gives me a huge amount of context to work with, but in some longer Copilot sessions I have still hit a point where the session effectively stops making progress. In my case, this has happened with plenty of context apparently remaining, often somewhere around the final quarter to third of the window.

The frustrating part is that compaction can fail at exactly the moment I need it.

The workaround that helped me during this time was restarting the Copilot process for the same session with /restart, then running /compact. That has let the work continue, but it is not behavior I have seen in quite the same way with other models.

Is that the model? The harness? The interaction between them? I had no idea -- but I do know that it was a pain in the butt.

That uncertainty matters. I am describing what I have observed in my sessions, not declaring a universal GPT-5.6 Sol limitation. And for what it’s worth, Copilot CLI seemed to have been patched for this since I initially was ranting about it on Code Commute.

The broader lesson still holds: session and context management remain part of agentic development. A larger context window delays some problems. It does not eliminate the need for checkpoints, compaction, and clean task boundaries.

What I Am Changing In My Workflow

I am still impressed with the model. I am not switching away because a few sessions ran too long.

But I am changing how I supervise the work.

Actionable Tip: give every agentic task a scope budget and a stopping rule.

Here is what that looks like for me:

1. Define the delivery boundary. Name the behavior, files, or subsystem that belongs in the task.

2. Separate discoveries from implementation. If the agent finds an unrelated bug, capture it unless it blocks the requested change.

3. Bound review loops. One useful review pass is not permission to keep reopening the design forever.

4. Create checkpoints. Ask for a status summary before a long-running session disappears into another branch of work.

5. Watch elapsed time. If a modest feature is still running hours later, inspect the current plan instead of assuming more time means more quality.

Permissions and tool restrictions are still important, and I have a full breakdown of what Copilot CLI can and cannot touch. But permissions only answer whether an agent can do something. They do not answer whether that work belongs in the current task.

That part still belongs to us.

The Model Can Be Impressive And Still Need Supervision

My first impression of GPT-5.6 Sol is still extremely positive.

It caught real problems that I did not ask it to find. It handled code with a level of awareness that surprised me. It made “going off the rails” look productive, which is not something I expected to say.

At the same time, I have watched it spend hours following review loops, expand a small task into a custom parser, and hit context problems before I expected them.

Both things can be true.

The model can be excellent, and the workflow around it can still need tuning. The output can be correct, and the process can still be too slow. The extra finding can be valuable, and it can still belong in a separate issue.

I do not want an agent that blindly stops the second it notices something outside the prompt. That would throw away one of the most valuable parts of a strong model. I want an agent that notices the problem, explains it, and lets the delivery boundary remain intentional.

That is the balance I am working toward: more capability without surrendering scope control.

If you are using GPT-5.6 Sol or another model for long-running coding work, pay attention to more than the final diff. Watch the route it took to get there. That is where the real workflow problems tend to show up.

Share

Leave a comment

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Senior is a successful career destination

• Higher levels require broader organizational scope

• Career progression is not a straight line

• Join me for the live stream (or watch the recording) on Monday, August 10 at 7:00 PM Pacific!

What Comes After Senior Software Engineer?

Have you ever looked at a software engineering career ladder and wondered why everything seems to move reasonably well until senior, and then suddenly the next step feels like a wall?

You’re not imagining that shift.

I have talked before about why engineers can feel stuck at senior, but I want to approach this from a slightly different angle. Sometimes the friction is about your growth, your manager, or unclear expectations. But sometimes the ladder itself genuinely changes shape after senior.

That does not mean you failed. It does not mean your company wants to hold you back. And despite how easy it is to blame every weird career problem on AI right now, I do not think AI created this one.

So what is actually going on?

You can check out my full thoughts on this in the video below:

The Ladder Changes Shape After Senior

The first complication is that software engineering titles are wildly inconsistent.

Junior, mid-level, and senior are common concepts, even if a company calls them Software Engineer I, Software Engineer II, SDE, SWE, or something else. Beyond senior? Things get messy fast.

One company might have staff, principal, senior principal, distinguished, fellow, or partner roles. Another company might skip staff entirely. A smaller company might have nothing beyond senior on the individual contributor track.

That was my experience before Microsoft. For most of my eight years there, the technical path was basically developer and senior developer. There was an architect role that never felt fully defined. Even as a technical manager, I eventually reached a point where there was no clearly established next role on that track.

Was I suddenly incapable of growing? Of course not. The organization simply had not created an endless sequence of titles.

That distinction matters. We often treat a career ladder like a universal map, but it is really a model of what one organization needs.

Title Inflation Makes The Wall Feel Worse

I want to be careful here because I do not have data to prove this. Treat it as an observation from roughly fifteen years in the industry, not a measured fact.

I suspect the expected time between early-career promotions has compressed. Companies use titles as recruiting tools. Employees move between organizations more often. Managers feel pressure to show progression. People understandably compare their timelines with everyone announcing promotions online.

The result is an expectation that every step should arrive on roughly the same schedule -- or at least that there should be very concrete steps in a prescribed amount of time to get there.

But careers are not linear. Going from level one to level two in a year does not mean every future level should take one more year. Follow that math far enough and everyone becomes a CTO before the end of the decade. Clearly, that is not how organizations work.

The higher you go, the larger the expected scope usually becomes. There are fewer roles with that scope, fewer opportunities to demonstrate it, and fewer people the organization actually needs operating there.

That curve was always going to get steeper. Title inflation just makes the change feel more abrupt.

Senior Can Be The Destination

The phrase people often use is terminal level. I don’t love it. It sounds dark, like your career has arrived at a dead end.

That’s not what it means.

A terminal level is a stable point where someone can perform successfully for the rest of their career. For many software engineering organizations, that point is somewhere in the senior band.

Think about what that says about you. You are trusted to solve difficult problems. You can deliver high-quality work consistently. Teams depend on you. You can guide other engineers, handle ambiguity, and operate without someone spelling out every step.

That is a successful career.

It can also be a demanding one. I have written about how senior engineers often spend less time coding because their impact increasingly includes design, mentoring, coordination, and helping others move faster. Staying at senior does not mean staying static.

Your skills can deepen. Your influence can grow. Your compensation can improve. You can take on new domains and become the person everyone relies on without collecting another title every eighteen months.

Compensation And Promotion Are Related, Not Identical

This is usually where someone asks: “Okay, but what happens to my compensation if I am not getting promoted?”

Fair question.

The exact answer depends on the company, but promotion should not be the only mechanism for recognizing strong performance. Salary growth, bonuses, stock, expanded ownership, and other rewards can continue while you remain in the same level.

A promotion usually comes with a larger adjustment because the expectations changed. But that does not mean every strong review must end with a new title.

You can be performing extremely well at senior, receive above-target rewards, and still not be operating at the next level. Those signals overlap, but they are not identical.

That can actually be a healthy balance. Maybe you are kicking ass at senior, being paid fairly, doing meaningful work, and preserving room for your family or everything else outside work. There is nothing lesser about that choice.

Organizations Cannot Be Made Entirely Of Principal Engineers

Now we get to the structural part.

Imagine an organization where every engineer is principal, staff, distinguished, or whatever the top levels are called. It sounds amazing if you picture a video game team where everyone has max stats. If you could build an NBA 2K team of max-stat players, or your RPG party was all max level, that’s what you’d want -- right?

In practice, what work are all of those people doing?

The next level after senior usually expects broader impact across teams, products, or an organization. If you are actively targeting that path, I have a separate breakdown of what principal-level scope actually looks like. The important point here is that cross-organization work is not infinite -- at least not infinitely done in parallel with all the other cross-organization work.

A company needs people setting technical direction across teams. It also needs many more people turning that direction into reliable products, systems, and customer outcomes.

You do not need hundreds of engineers independently trying to lead company-wide initiatives. At some point, everyone collides with everyone else.

This is not an argument for gatekeeping. It is an explanation of why the number of roles naturally narrows. The organization needs a different distribution of scope at each level.

Healthy Teams Need A Spread Of Experience

The same idea applies within a team.

You do not want a team made entirely of brand-new engineers because the coaching and operational overhead would overwhelm the few experienced people supporting them. But stacking a team entirely with the highest-level engineers does not make sense either.

A healthy team usually has a spread:

• Junior engineers building fundamentals and taking on well-scoped work

• Mid-level engineers carrying a large share of independent delivery

• Senior engineers handling complex work, mentoring, and creating leverage

• A smaller number of staff or principal engineers working across broader boundaries

That spread creates continuity. Junior engineers learn from people with more experience. Senior engineers develop coaching and delegation skills. The organization builds its next generation instead of hoping experienced hires appear forever.

This is where AI enters the conversation, but not as the cause of the senior-level wall. Companies deciding they no longer need junior engineers because AI can replace them are creating a different problem. I have shared my concerns about junior developers relying on AI without building fundamentals, and cutting off the junior pipeline removes mentoring opportunities and future senior talent too.

The whole system needs continuity. You cannot keep only the top of the pyramid and expect it to replenish itself.

What To Do When You Feel Stuck

Understanding the structure does not make vague promotion feedback any less frustrating.

If your manager keeps telling you, “Maybe next time,” while you spend another review cycle trying to prove yourself, you need more than encouragement. You need clarity.

Actionable Tip: ask questions that separate your performance from the organization’s available opportunities:

1. What specific evidence is missing? Ask for observable examples, not “more impact.”

2. Am I consistently operating at the next level? A strong year at your current level is not automatically the same thing.

3. Does this team have work with the required scope? You cannot demonstrate cross-team leadership if every meaningful decision is already owned elsewhere.

4. Is a role realistically available? Sometimes the organizational shape creates more back pressure than anyone wants to say directly.

5. What would make the next review materially different? If nobody can answer, that is useful information.

You may discover that you have real gaps to close. Great. Now you can work on something concrete.

You may discover that you are ready, but the organization has no room. That does not automatically mean you should leave, but it gives you an honest tradeoff to consider. An internal move or another company may offer the scope that your current team cannot.

And please protect your energy. There is a difference between stretching into bigger responsibility and running yourself into the ground chasing a label. My advice on pursuing promotions without burning yourself out still applies here.

Your Title Is Not Your Entire Career

I understand why titles matter. They affect compensation, opportunity, how recruiters find you, and how many of us measure whether we are moving forward.

But the ladder cannot be the only scoreboard.

Senior software engineer is not a waiting room where you sit until your real career begins. It is a high-skill, high-trust role that many people work very hard to reach. If you stay there and continue doing excellent work, that is not failure.

If you want principal, staff, management, or another path, go after it with clear eyes. Learn what the role actually requires. Find out whether your organization has the right opportunities. Build the evidence. Decide whether the tradeoffs fit the life you want.

Don’t let the absence of another title erase everything you have already accomplished.

Careers are not straight lines. Organizations are not infinite ladders. And success is much bigger than the word printed beside your name.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Build the thing for yourself first

• A thin paid layer beats abandonment

• Free tools are still worth shipping

• No livestream this week. Sorry!

Why I Still Build Side Projects (And What I’m Building Next)

I’m twenty-plus years into programming and about fifteen years into my career, and I am still building side projects. That is not an accident, and it is not nostalgia. Building things is still the fastest way I learn, and it is still the advice I give to almost everyone who tells me their resume feels thin.

But something has shifted for me lately. I’ve gotten to the point where if I am going to sink my limited free time into building something, I should at least be open to the idea of charging a couple bucks for it. Not building a business. Not quitting my job. Just putting a very thin layer on the front of something I was going to build for myself anyway.

That small mental shift turns out to be a surprisingly good cure for the “ooh, shiny” problem that kills most side projects.

You can check out my full thoughts on this in the video below:

Twenty Years In And I Am Still Building

Whenever someone tells me their resume feels weak -- they’re not employed yet, or they’re junior and applications keep going nowhere -- my answer is almost always the same. Go build something.

It works for two reasons. The obvious one is that it gives you something concrete to talk about instead of a list of technologies you have “familiarity with.” The less obvious one, and honestly the more important one, is that building things is how you actually learn. Reading about a pattern and shipping something that depends on that pattern are completely different experiences.

I have written about this before in the context of why side projects and soft skills keep coming up in interviews, and I stand by all of it. But I want to be clear that this is not advice I give from a distance. I am still doing it.

Most of my side project time goes into BrandGhost, which is my main thing outside of work. It takes up enough of my attention that I have pushed other things aside for it -- including making videos on my main YouTube channel for a stretch. There are only so many hours, and something has to lose.

But there is always a pile of other stuff I want to poke at.

The Free Things I Have Already Shipped

Before I get into what I want to build, here is what is already out there for free, because some of you might actually find these useful.

Needlr is a dependency injection and assembly-scanning library I put together. It is extremely opinionated. I am not planning to sell it, and I am not trying to convince anyone it’s the one true way. I build basically all of my C# stuff with plugin frameworks, and that pattern kept showing up over and over, so I extracted it. If you want to use it, great. If not, that’s completely fine. If you want to see the shape of it, I have walked through building modular .NET applications with Needlr’s plugin architecture.

Homebase came directly out of frustration. If you spend any time on social media, you have clicked a hundred “link in bio” links that drop you on a landing page full of other links. Linktree is one of the platforms that does this, and I was a paying customer for a while. Then I hit a problem where video previews were rendering as black thumbnails. There is no good reason a YouTube thumbnail should just fail to show up. I opened a support ticket, got the runaround for about a month, and eventually thought: I pay for this, and I could just build it myself.

So I did, in roughly a weekend. Homebase is on GitHub, it is free, you can clone it or fork it, and it is optimized for SEO, AEO, and GEO. You can add product links and a bunch of other things. And if you’re wondering how to configure it -- you point Claude or Copilot at the repo, tell it where your stuff goes, and it handles the config files.

A few MCP servers for Google Search Console, Google Keyword Planner, and Google Analytics. Google did not have official MCP servers for these, which still surprises me. Mine are vibe coded, and I believe I have versions in both C# and Go because I wanted to mess around. They’re on my GitHub. I genuinely hope Google ships their own and makes mine obsolete. If you want to understand what is actually happening under the hood in one of these, I have a full walkthrough on building MCP servers and clients in C#.

None of those are businesses. They’re scratch-your-own-itch projects that happened to be useful enough to publish.

The Thin Paid Layer

Here is where my thinking has changed.

I have a problem that I suspect a lot of you share: I could go build this, or I could go build that, and then something shinier appears and I drift toward it. The half-finished graveyard is real. Most side projects don’t die because they were bad ideas -- they die because nothing forces them across the line from “sort of works on my machine” to “actually usable.”

A thin paid layer is the forcing function.

The idea is simple. Build the thing for yourself, because you actually want it. Get it to the point where you would use it. Then put a very thin layer on the front -- pay a couple bucks, here’s a license key, done. If people pay, awesome. If nobody pays, I still have the tool I wanted.

What I am explicitly not doing is turning every idea into a full-fledged business with a marketing site, a support org, and a roadmap. That is a completely different commitment and it is the thing that makes people avoid starting at all.

Actionable Tip: pick the side project you have abandoned closest to “done.” Define the smallest version you would personally use every week. Ship that, and only that. Whether you put a paywall in front of it is secondary -- the point is having a definition of finished that isn’t “everything I imagined.”

What I Actually Want To Build Next

These are all deeply opinionated, and you might read them and think “why would anyone pay for that?” That’s kind of the point. I am building them for me.

A modern MySQL Workbench with an LLM attached. Workbench is being retired, and from what I have read the plan is a lighter-weight experience inside VS Code. That’s neat, but personally I want the actual Workbench form factor -- just less dated. And the thing I really want is to give a read-only connection to an LLM and have it optimize queries with me. Connect with whatever access level you want (admin, write, read-only), poke at your data, and then have an agentic back-and-forth about query plans. I already do a version of this by giving Copilot read-only database access and letting it run EXPLAIN and look for optimizations. I just want it to be a real tool instead of a workflow I re-assemble every time.

A personal finance planner built for two people. My wife and I keep separate accounts but operate with full transparency -- the only exception being gifts we’re trying to keep a surprise. If she asks what’s in my 401k, the answer is just the number. We treat that stuff as ours. So I want something that pulls in financial data read-only across accounts and gives us a shared view plus a shared agentic session. She has really taken to using ChatGPT, so the idea is being able to ask questions like “where is most of our spend going?” or “how do the investments look?” against a central brain that can actually see across everything. If I build it, it will be configurable -- bring your own provider, or run a local LLM if you would rather your financial data never leave the house. I have no idea what the right form factor is yet.

A voice companion for GitHub. This is the one I’m poking at most actively. I feel like the GitHub app should do this and probably will eventually, but it doesn’t today. A big chunk of how I get work done now is creating issues and assigning them to agents. What I want is a push-to-talk companion -- the same interaction model you get in ChatGPT -- that lets me navigate all of that by voice. “What new issues came in today?” I have automation that scans BrandGhost error logs and files issues automatically, so there’s usually something. “Give me more detail on issue 123.” “Cool, assign that to an agent.” And then later: “Check in on that agent session -- did the PR land? Did it add proper tests?” The goal is being able to have that conversation without reading code. Maybe the answer isn’t even a dedicated app -- maybe it’s just wiring an existing assistant to my repositories through an MCP server. I need to play with it. If it does end up being a mobile app, it goes on the app stores.

A photo recovery tool. I used to work in digital forensics, and I spent about a decade building tools for exactly this. Since leaving, people still occasionally come to me with “I think these files are deleted, can you help?” -- and the funny part is I no longer have access to any of the tooling I helped build. I know how to build it again. Is that market saturated? Absolutely. But I have example code, it solves a real problem people bring to me, and there is no reason it can’t live on a website for a couple bucks.

Websites for non-technical friends. This one isn’t a product, it’s a favor I keep repeating. I have a close friend in the trades doing drywall and restoration work who is reasonably technical but would never spend the time to learn web development. He would get real value out of a proper site. I did the same thing for my video editor when he started a business on the side -- he has been fantastic about turning videos around when I hand them over late, so building him a site was an easy yes. The key detail is that I structure them so the owner can maintain them: copy a config file into ChatGPT, ask for the change, paste it back, done. I might start advertising that.

Why I Trust Agents With Some Of This And Not All Of It

The voice companion idea probably sounds sketchy to some people. “You’re just going to let AI do your work?”

Sort of. Here’s the honest breakdown.

There is a category of work where I trust an agent to go end-to-end, and it’s not blind trust -- it’s because I have built a lot of guardrails. File-based instructions that encode how the codebase works. Roslyn analyzers that enforce naming, null checks, and log validation so bad patterns fail at compile time rather than in review. Scoped custom agents and skills in Copilot CLI so each task runs with a narrow, well-defined job. The gates are what make the trust reasonable.

Then there is the other end of the spectrum. Big feature work, architectural changes, large refactors -- I’m not handing those over and walking away. I will still assign them to an agent and let it crank, but my expectation is not that it gets it right. My expectation is that I learn something from watching how it approaches the problem.

Sometimes there are genuine gold nuggets in there. Other times I look at the approach and immediately think “oh, that’s definitely not what I want” -- and that’s still valuable, because I often didn’t have a strong opinion until I saw a concrete option. Getting to “no, not that” without spending my own hours on it is a legitimately good trade.

Yes, it costs tokens. Yes, it costs someone’s compute. But it didn’t cost my evening.

My Best Ideas Show Up When I Can’t Act On Them

I don’t know if this is universal, but it is extremely consistent for me: my best ideas arrive precisely when I am nowhere near a computer.

Not at my desk. Not in a planning session. Walking, driving, at the gym -- suddenly I know exactly how to solve the thing I was stuck on last week, or a feature idea shows up fully formed. And then by the time I’m back at a keyboard, it has faded into something much blurrier.

That is honestly a big part of why the voice companion idea appeals to me so much. Not just “assign this issue to an agent,” but being able to talk through a half-formed idea out loud, argue with it a bit, and then say “open a GitHub issue on this repo with what we just worked out.” I have done exactly that with ChatGPT before, and the friction of translating it into the real repo is the only annoying part left.

Actionable Tip: whatever your capture mechanism is, make it require zero setup. Voice memo, a note that’s one tap away, a text to yourself -- it doesn’t matter which. The ideas you lose aren’t the ones you rejected, they’re the ones you never wrote down.

Might As Well Turn The Fun Into Something

The through-line for me is that I am going to keep building this stuff regardless. That was true before there was any chance of making a dollar from it, and it will be true after.

But I’m at a point in my career and my life where if I’m already spending the time, and the thing I built is genuinely useful, it seems a little silly not to put it somewhere people can find it. Worst case, nobody buys it and I still have the tool. Best case, a few extra dollars show up and I get a nudge to actually finish the next one.

That’s the trade I’m making. Build for yourself first. Ship the smallest usable version. Let the thin paid layer be the reason you cross the finish line instead of drifting to the next shiny thing.

So -- what are you building? I’d genuinely like to hear, especially if you’re leaning on AI to crank out something interesting. Let me know.

Subscribe now

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Learn before changing the system

• Clarify your authority and expectations

• Automate recurring release pain incrementally

Tech Lead in a Broken Team? What You Need to Do First

Imagine stepping into your first tech lead role and discovering that every release needs four to six hours of manual testing. Old bugs keep coming back. Delivery dates seem disconnected from the engineering effort. The team is overloaded, and overtime is starting to feel like part of the plan.

Where do you even start?

My answer is not, “Walk in and fix everything.” You do not have enough context yet, and trying to change the whole system immediately is a great way to burn trust before you understand why the system behaves this way.

You need to learn, align, build relationships, and then create momentum with one measurable improvement at a time.

You can check out my full thoughts on this in the video below:

Do Not Start By Rewriting The Team

When you inherit a struggling project, the problems are usually obvious before the causes are.

You can see the long manual test cycle. You can see the regressions. You can see the exhausted engineers and the aggressive delivery dates. What you cannot see yet is how the team arrived there, which constraints are real, and which previous attempts have already failed.

So the first move is observation.

Map out:

• How work enters the team.

• Who decides what gets prioritized.

• What “done” currently means.

• Where releases slow down.

• Which defects keep returning.

• What engineers believe is causing the pain.

• What product and management believe is causing the pain.

That does not mean you sit quietly for six months while everything burns. It means you avoid prescribing a solution before you can explain the system.

Your other immediate job is clarifying the role itself. “Tech lead” means wildly different things at different companies. Are you expected to make technical decisions? Can you push back on scope? Are you accountable for delivery? Are you coaching engineers? When should your manager step in?

Ask your manager directly. Keep asking as new situations come up. This is not a one-time onboarding question.

I also think your manager should not be surprised by the problems you are seeing. Share the observations, explain what you are trying, and be clear about where you need support.

Actionable Tip: bring your manager a short list of current risks, the evidence behind each one, and the first experiment you want to run. Ask which decisions you own and where they want to be involved.

Build A Working Relationship With Product

It is easy to walk into this situation and decide the product manager is the problem.

They keep pushing dates. Engineering keeps taking shortcuts. Quality drops. Therefore, product must not care about quality.

Maybe. But that conclusion is not especially useful, and you probably do not have enough information to make it anyway.

The product manager may be responding to customer commitments, revenue pressure, executive expectations, or information the engineering team does not have. At the same time, engineering may be carrying risks that product cannot see clearly.

That is exactly why you need the relationship.

There should be healthy tension between product and engineering. Product pushes for customer value and delivery. Engineering pushes for feasibility, sustainability, and quality. I have written about what happens when that healthy tension between product and engineering disappears.

Your goal is not to defeat the product manager. Your goal is to help both sides make better tradeoffs.

I have had working relationships change when schedules and responsibilities shifted. Even when I already knew the product manager, I still needed to make time to understand what they needed from me and how I could support them better. It is mutual. I want them helping engineering, and I need to help them succeed too.

Actionable Tip: set up a recurring conversation with your product partner. Ask what outcomes matter most, which dates are truly fixed, what risks they are carrying, and what engineering information would help them make better decisions.

Make Release Pain Visible

Four to six hours of manual testing before every release is a giant warning sign to me.

But you cannot simply delete that testing. The team is doing it because it catches defects. If you remove it without replacing the protection, you have not improved the process. You have just hidden the risk.

This is where the team needs to slow down enough to speed up.

Start by documenting every manual release check:

1. What behavior is being verified?

2. How long does the check take?

3. What defects has it caught?

4. Can that behavior be covered at a lower test level?

5. What is the smallest useful slice you can automate?

Do not wait for the perfect test architecture. If the code is tightly coupled and the only practical first step is a clunky behavioral test, write the clunky behavioral test. You can improve it later. The immediate goal is to stop the same regression from surprising you again.

Unit, integration, functional, and end-to-end tests all protect different boundaries. Understanding how unit testing and functional testing complement each other helps you avoid trying to solve every problem with one giant UI test suite.

I have lived this at a startup. We had enough technical debt that we needed UI-level behavioral tests before we could safely refactor parts of the application. A big chunk of that debt was mine, so I am not blaming anyone else. Those tests were not the final destination, but they gave us enough confidence to start changing the code underneath.

The manual release checklist should only get smaller. New regressions should produce new automated coverage, not another permanent item for a human to click through at release time.

Exploratory testing can still be valuable. Just do not make the hour before release the only time anyone explores the product. If you only look for surprises at the release gate, you will keep finding surprises at the release gate.

Dates And Engineering Effort Need An Honest Tradeoff

There is nothing inherently wrong with a fixed release date.

There is also nothing wrong with estimating a body of work and letting the date move.

The problem starts when scope and date are both treated as fixed while quality is expected to remain unchanged. Something has to move.

If a feature needs a month of engineering effort and somebody wants it in a week, you have a few honest choices:

1. Reduce the scope.

2. Move the date.

3. Take a deliberate shortcut and document the debt.

4. Do not build it.

What you cannot do is pretend that a month of work somehow became one week because everyone agreed the date was important.

This is where I strongly prefer smaller vertical slices. Ship one thin, working path through the feature. Let customers use it. Learn from the feedback. Then decide what deserves the next investment. Vertical slice development can help teams deliver useful value sooner without pretending the entire feature fits inside an impossible deadline.

Sometimes you will still choose debt. That can be a valid business decision, but only if everybody understands the cost. If you rush a feature into a shape that cannot support the next iteration, say that clearly. The next change must include paying down the shortcut.

Otherwise, “we will clean it up later” becomes the permanent operating model. That is why technical debt has to be balanced deliberately, not treated like invisible work engineering will somehow absorb.

Actionable Tip: when somebody asks for a fixed date, respond with the smallest scope the team can confidently deliver by that date. Make the excluded scope and any accepted debt explicit.

Overtime Cannot Be The Capacity Plan

If the plan only works when engineers repeatedly work extra hours, the plan does not work.

That does not mean overtime can never happen. Production incidents happen. Unexpected customer problems happen. Teams sometimes make short-term pushes.

But sustained overtime is not additional capacity. It is borrowing energy from future delivery, quality, and retention.

As the tech lead, do not quietly absorb the gap. Make capacity visible:

• Here is what the team can complete safely.

• Here is the work that does not fit.

• Here is the quality risk if we force it in.

• Here is the decision we need from product and management.

If the pressure is already affecting people, talking to your manager about burnout should happen before somebody reaches the point where they cannot keep going.

Pushing back is not refusing to deliver. Good pushback gives decision-makers a realistic set of tradeoffs.

Ownership Means Following Through

One of the most important parts of this role transition is realizing that agreement is not action.

You can explain the testing problem to the product manager. They can nod and say it sounds reasonable. Then everyone returns to the same priorities, and nothing changes.

That does not automatically mean they do not care. It probably means this improvement matters more to you than it does to them, so you need to drive it.

Pick one change. Give it an owner. Put time against it. Define what better looks like. Report the result.

For example:

1. Choose the ten most expensive manual release checks.

2. Automate one of them this iteration.

3. Require a regression test for every recurring defect.

4. Measure the release time and escaped defects.

5. Share the result with engineering, product, and your manager.

6. Repeat.

That first win matters. People support changes more easily when they can see that the change saved time, reduced risk, or made delivery more predictable.

You do not need to repair the entire organization in your first month. You need to understand the system, clarify your authority, build the relationships, and prove that one better way of working is possible.

Then do it again.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Raise concerns early, without jumping to termination

• Coaching needs observations, support, and follow-through

• Managers remain accountable for the whole team

• Join me for the live stream (or watch the recording) on Monday, July 20 at 7:00 PM Pacific!

When Should You Tell Your Manager A Developer Is Struggling?

I came across a question from a team lead who had been coaching a junior developer for roughly 20 months. Progress had been difficult, and from the team lead’s perspective, the developer had actually started moving backward. They were less proactive, still needed a lot of direction, and did not seem to be responding to the coaching.

The question was basically: When should I tell my manager this is not working?

My immediate reaction was that this conversation should have started much earlier. But I want to be extremely clear about what I mean by that.

Raising awareness early does not mean asking your manager to terminate someone early. It means sharing what you are observing while there is still time to understand the problem, adjust the support, and give the person a fair opportunity to improve.

You can check out my full thoughts on this in the video below:

Raising Awareness Is Not A Verdict

Some people hear “I need to tell the manager” and immediately translate that into “I am trying to get this person fired.”

Those are not the same thing.

A useful conversation with your manager is not:

• “This developer sucks.”

• “They are never going to make it.”

• “We need to get rid of them.”

Those are conclusions. They skip over all the information your manager actually needs.

A better conversation sounds more like this:

• Here is the work the developer has been trying to complete.

• Here is where they are consistently getting stuck.

• Here is the coaching or support I have already tried.

• Here is the progress I expected to see.

• Here is the trajectory I am seeing instead.

• Here is where I need help.

That distinction matters because feedback is deeper than a single verdict. If all you provide is a label, your manager cannot tell whether the issue is skill, unclear expectations, poor coaching, team fit, missing context, or something else entirely.

Actionable Tip: bring observations, not character judgments. Describe what happened, what support was attempted, what changed, and what you need from your manager next.

There Is No Magic Ramp-Up Number

The Reddit discussion had people at both extremes.

Some people claimed they could tell within a week whether a developer was going to work out. Other people pushed back and said new hires need months before anyone should be concerned.

Honestly? I do not believe there is one magic number.

A junior developer learning their first professional codebase is in a different situation from a senior developer joining a familiar domain. A new graduate may need help learning how work moves through the team. A transfer may know the company but not the product. Someone may be technically capable but completely lost in the domain.

The important signal is not whether they reached full productivity by an arbitrary date. It is whether you can see a reasonable trajectory.

Are they asking better questions? Are they retaining what they learned? Are they taking on slightly more responsibility? Are the same blockers repeating without any change? Does the support they need seem to be increasing instead of decreasing?

You may not know the answer after one week. But if you have worked closely with someone for a few weeks or a couple of months and the trajectory concerns you, that is enough reason to share what you are seeing.

You do not need certainty before you communicate.

Your Manager Should Not Be Surprised

If I pair a new developer with a team lead, technical lead, intern buddy, or another engineer, I still expect to check in.

How is the new person doing? Where are they getting stuck? What is going well? Does the person helping them need anything from me?

I do not need a formal performance report every few days. I do want enough communication that the next conversation makes sense.

If a team lead tells me after several months, “This person is not working out,” and that is the first concern I have heard, my response is going to be: Wait, what happened?

The concern may be completely valid. But now we have lost months where we could have changed the coaching, clarified expectations, or added support.

Regular check-ins are one reason I care so much about helping people make the most of their one-on-ones. These conversations should surface small signals before they become enormous surprises.

Actionable Tip: give your manager lightweight progress updates. “Going well,” “still learning this area,” “we are trying a different approach,” and “I need help” are all useful signals.

Clarify What Your Lead Role Actually Owns

“Team lead” and “technical lead” can mean completely different things from one company to another.

In one organization, a lead may be expected to actively coach developers, adjust how work is delegated, and drive onboarding. Somewhere else, the lead may own technical direction while the manager handles nearly every people-related concern.

This ambiguity is one of the mistakes new managers and leads can make. Everyone assumes they understand the role, nobody states the boundaries, and important work falls into the gap.

If you are the lead, ask your manager:

1. What coaching do you expect me to handle directly?

2. What kinds of concerns should I raise immediately?

3. How often do you want onboarding updates?

4. What decisions can I make without checking first?

5. What support can I ask you to provide?

You should feel empowered to help. You should not quietly inherit full responsibility for another employee’s performance without the authority, context, or support to handle it.

Do Not Just Drop The Problem And Walk Away

There is another failure mode here.

You tell your manager, “Bob is not ramping up very well.”

Then... nothing happens.

Did you expect the manager to take over? Did the manager expect you to keep coaching? Is someone changing the plan? Does the developer even know what they need to improve?

Raising awareness without agreeing on a next action is not enough.

Depending on the situation, the next step might be:

• Pairing the developer with someone else for a different perspective.

• Giving them a smaller, better-defined area to own.

• Spending more time on domain context instead of only code.

• Setting clearer expectations for initiative and communication.

• Having the manager join a coaching conversation.

• Identifying training, documentation, or tools that are missing.

• Checking whether the team or role is simply a poor fit.

The point is not that every struggling employee can be turned around. Sometimes the role will not work out. But if the only action is repeatedly saying “they are struggling,” nobody is actually helping.

Make Sure The Coaching Is Not Part Of The Problem

Managers often hear different versions of the same situation.

The junior developer says, “Things are going well. I hit a few blockers, but I am working through them with the senior developer.”

The senior developer says, “This person takes no initiative. I have shown them this five times and they still cannot do it.”

So what is actually happening?

Maybe the junior developer is disengaged. Maybe they are not retaining information. Maybe they are afraid to ask questions. Those are all possible.

But maybe the senior developer’s idea of coaching is screen sharing, clicking every button, writing all the code, and saying, “Watch what I do.” Then they are frustrated when the other person cannot reproduce the process alone.

I have written about how senior developers can accidentally make learning harder, especially when expertise makes the difficult parts feel obvious. Watching an expert move quickly is not the same as practicing the skill.

Actionable Tip: let the learner drive. Have them share their screen, choose the next step, explain what they think is happening, and ask for guidance when they get stuck. It may feel slower, but you can finally see how they reason.

Technical Aptitude Might Not Be The Whole Story

When someone seems unmotivated or passive, it is easy to jump straight to a personality judgment.

Sometimes that judgment is wrong.

Maybe they do not understand the domain well enough to know why the work matters. Maybe every task feels like an isolated technical request with no connection to a user or business outcome. Maybe they are overwhelmed by the codebase and trying not to expose how lost they feel.

Managers and leads often say, “There are no stupid questions. Ask anything.”

I genuinely mean that when I say it. But I also understand that new employees may still worry about looking unqualified in front of their manager. Pairing them with another engineer can create a safer place to ask those questions and build confidence.

That is part of why a manager needs multiple perspectives. Talk to the developer. Talk to the person coaching them. Look at the work. Ask what each person has tried. Do not assume one story gives you the complete picture.

Accountability Still Belongs To The Manager

As a manager, I can delegate pieces of onboarding. I can ask a senior engineer to be an intern buddy. I can give a team lead room to coach someone and adjust the day-to-day approach.

I cannot delegate away my accountability for the team as the manager for the team.

At the end of the day, the manager is responsible for making sure employees have clear expectations, appropriate support, useful feedback, and a fair process when performance concerns exist.

That does not mean the manager personally performs every coaching session. It means the manager remains engaged enough to understand what is happening and act when the team needs help.

This is where accountability without sliding into blame matters. The goal is not to decide which person deserves to be attacked. The goal is to understand the system, clarify ownership, support improvement, and make a responsible decision.

A Practical Way To Escalate The Concern

If you are a lead and you are worried about someone’s progress, you do not need a dramatic speech.

You can use a simple structure:

1. State the observation. What specific behavior or outcome concerns you?

2. Describe the trajectory. Is it improving, flat, inconsistent, or getting worse?

3. Explain the support. What coaching, pairing, documentation, or context have you tried?

4. Share the impact. How is this affecting the developer, the work, or the rest of the team?

5. Ask for help. What do you need the manager to clarify, provide, or decide?

6. Set a checkpoint. When will you compare notes again?

That might sound like:

I have been pairing with this developer on the deployment workflow. They can complete the steps with direct guidance, but they are still unable to complete the same workflow independently, and the same questions are repeating. I have tried written steps and two driver sessions. I would like your help understanding whether we should change the coaching plan or clarify the role expectations. Can we check in again after the next two tasks?

That is specific. It leaves room for investigation. It creates an action. And it does not pretend you know the final outcome before the manager has even joined the conversation.

Earlier Communication Can Be Kinder

Waiting can feel compassionate because you do not want to get someone in trouble.

But silence is not always kind.

If the developer needs different coaching, earlier communication helps them get it. If expectations are unclear, earlier communication gives the manager time to clarify them. If the team is a poor fit, earlier communication creates more options. If a formal performance process eventually becomes necessary, the concern should not appear out of nowhere after nearly two years.

The time horizon for raising awareness is much shorter than the time horizon for giving someone a fair opportunity to improve.

Those ideas are not in conflict.

You can communicate early, coach patiently, gather better information, and avoid rushing to a conclusion. In fact, early communication is what makes that patience more responsible.

The Question Is Not “When Do I Give Up?”

The better question is: When do I create enough visibility for the right support to happen?

My answer is early and regularly.

Do not wait until you are completely frustrated. Do not turn one difficult week into a permanent label. Do not hide the concern for 20 months and then hand your manager a final verdict.

Share the signal. Ask for help. Agree on the next step. Keep checking the trajectory.

Maybe the developer turns things around with better coaching. Maybe they thrive on a different team. Maybe the role ultimately does not work out. You cannot know that from the first concern.

What you can do is make sure the concern is handled with clarity, accountability, and enough time for people to respond.

If you have a software engineering or career question, leave it in the video comments or submit it anonymously at codecommute.com. I would love to hear how your organization divides coaching responsibilities between leads and managers.

Subscribe now

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Principal impact crosses team boundaries

• Sustained ownership beats one heroic project

• Visibility should follow meaningful impact

• Join me for the live stream (or watch the recording) on Monday, July 13 at 7:00 PM Pacific!

What It Actually Takes To Become A Principal Engineer

I came across a question from someone trying to understand what getting promoted to principal engineer actually looks like. Not the generic career-ladder language. Not “increase your impact” and “show more visibility.” They wanted specifics, because the advice they had heard felt inconsistent and the target kept moving.

Honestly? I think that criticism is fair.

Before I get into my take, there is an important caveat: my perspective comes from working at Microsoft, and I am an engineering manager. Titles, levels, and expectations vary dramatically between companies. Some organizations go from senior directly to principal. Others have staff between them. Some swap the staff and principal labels entirely. So I am not claiming this is the universal definition.

What I can do is explain the pattern I have seen, the path I took, and what seems to separate someone doing excellent senior-level work from someone operating at principal scope.

You can check out my full thoughts on this in the video below:

Principal Is A Scope Change, Not A Coding Upgrade

The simplest framing I have is this: becoming principal is usually not about being a senior engineer who types code even faster.

By the time you are being considered for principal, the expectation is already that you are technically strong. If you interview at a big tech company, coding questions may still be part of the process. System design will probably matter even more. But being excellent at those things is the baseline, not the entire case.

The bigger change is the surface area of your responsibility.

A senior engineer can have a huge impact within a team. A principal engineer is usually expected to influence work across teams, products, or an organization. That does not mean you personally write every line of code or dictate every design. In fact, I have written before about why senior developers often end up coding less, and principal scope pushes that shift even further.

You are increasingly responsible for questions like:

• Can several teams align around a technical direction?

• Can this platform support an entirely new class of customers or partner teams?

• Can a risky initiative move from an idea to a durable, supported capability?

• Can stakeholders trust that you will drive the work without chasing you for updates?

• Can other engineers lead meaningful pieces of the mission and succeed because of the structure you created?

That is a very different job from being the person who solves the hardest ticket in the sprint.

You Can Be Promoted In Or Hired In

The person asking the question wanted to know what it took to get promoted into principal. My path was different: I was hired into Microsoft at the principal level.

That distinction matters because changing companies can be one route into the next level. Maybe you are already operating near that level, but your current team has limited opportunities. Maybe there are already several principal engineers and the organization cannot create enough principal-scope work for everyone. Maybe you have been close to promotion multiple times and now have a strong collection of examples to take into interviews elsewhere.

None of that means the interview is easy or that you get to skip demonstrating the scope. You still need the evidence.

When I joined Microsoft, I did not have another big tech company on my resume to provide a neat level-to-level comparison. I came from a much smaller digital forensics company, and I had never worked on globally distributed deployment systems at anything close to Microsoft’s scale. I go deeper into that transition in my journey from a startup into Microsoft.

What I did have were concrete stories about operating across an organization.

One example was taking a product idea that had been outsourced, bringing the work in-house, building the team around it, and leading that area successfully for years. I could explain the business outcome, the technical ownership, the team growth, and the sustained responsibility. The domain was different, but the leadership and engineering skills transferred.

That is the key. You do not need to have solved the exact same problem at the exact same scale. You need to show that you have repeatedly handled comparable complexity, ambiguity, and organizational reach.

Make “Organizational Impact” Concrete

“You need more impact” is frustrating feedback because it sounds important while telling you almost nothing.

So what does organizational impact actually look like?

Imagine you work on a platform that supports three kinds of internal services. You lead an initiative that lets the platform support entirely new classes of services. Now you are not just improving one feature for your immediate team. You are expanding the value of everything your team already built and making it available to whole new groups across the company.

But even that outcome is not enough if your involvement was just proposing the idea or making a couple of code changes.

At principal scope, you might:

1. Help shape the original idea and clarify the business value.

2. Lead the design and architecture across several teams.

3. Get partner teams bought into a shared direction.

4. Break the work into areas other engineers can own.

5. Navigate risks, dependencies, and changing requirements.

6. Keep stakeholders informed without turning communication into theater.

7. Carry the initiative through delivery and into sustained operation.

That combination is what turns “I worked on a large project” into “I led an organizationally important outcome.”

And yes, influence is part of it. The technically best proposal does not automatically win. If you are struggling to build support across teams, the same dynamics I discussed in why good ideas keep getting shut down absolutely show up here too.

Visibility Should Be A Consequence Of Impact

I have mixed feelings about the word visibility.

I have personally been put forward for promotion and received feedback that I did not have enough visibility. That was incredibly frustrating. My reaction was basically: what do you mean? I am doing the work my leadership asked me to do. Am I supposed to replace useful engineering work with a bunch of artificial self-promotion?

Communication matters. Project updates, stakeholder notes, demos, and reaching out to groups that might benefit from the work can all help. You should not hide important work and then be shocked when nobody knows it happened.

But I heard a framing from a VP that changed how I think about this: the impact should be large enough that the relevant parts of the organization naturally have some visibility into it.

Not every person needs every implementation detail. The point is that the work touches a broad enough surface area that leaders and partner teams can say, “Yes, I know that initiative. I understand why it matters, and I know this person is driving it.”

That is different from doing small-scope work and trying to amplify it until it sounds organizational.

Actionable Tip: treat communication as a multiplier for real impact, not a substitute for it. Learn to explain the mission, risks, tradeoffs, and outcomes in language each audience understands. That skill is a big part of why I think communication separates good developers from great ones.

Ownership Is The Signal Behind The Title

When I think about the strongest principal promotion cases I have seen, two words keep coming up: ownership and accountability.

People trust this person with an important initiative. They are not waiting for someone else to define every next step. They are not being chased down to see whether anything is moving. They create clarity, pull the right people together, surface risks, and keep driving toward the outcome.

Usually this is not someone who suddenly appeared, completed one enormous project, and immediately became principal. The pattern is more often:

• They have already been contributing at a high level on important work.

• They consistently make the teams around them more effective.

• They take on ambiguous problems without waiting for a perfect plan.

• They build trust across technical and non-technical groups.

• Then they lead one or two especially visible, high-impact initiatives that make the existing pattern undeniable.

That last project may become the cleanest promotion story, but it is not the entire story. It is evidence that confirms sustained behavior.

This is also why principal scope cannot be reduced to a checklist of code contributions. If your project requires coordination across teams, the difficult parts may be alignment, decision-making, sequencing, communication, and creating ownership for other engineers. Those are not distractions from the technical work. At that scale, they are part of the engineering work.

The Goalposts Can Move

Here is the part nobody loves hearing: sometimes the target really does move.

Organizations change. They grow, contract, reorganize, and end up with different distributions of engineers at each level. A company may decide it has too many people at a certain level and quietly raise the bar. The work that earned a promotion several years ago may not be enough under the current expectations.

That does not make the process feel any less unfair when you are on the receiving end.

You can do strong work, get told you were close, receive vague feedback, and then wait another six months while wondering whether anything you are doing matters. I have experienced the disappointment of being put forward and not getting the result. I have also experienced this on behalf of my employees when I am working for putting them forward for promotion. It is demotivating, especially when you thought you were following the guidance you had been given.

If that happens, try to get specific:

• What evidence was missing from the promotion discussion?

• Who needed to see a broader scope of impact?

• Was the concern about the work itself or how it was represented?

• What would make the next review materially different?

• Are principal-level opportunities actually available on your current team?

If your manager cannot turn the feedback into something concrete, that is useful information too.

And protect your energy. There is a real difference between stretching into bigger responsibility and running yourself into the ground chasing a title. I have shared more thoughts on pursuing promotions without burning yourself out, because no level is worth destroying yourself over.

Principal Impact Is Shared, Not Hoarded

One of the projects that helped demonstrate my own impact within the principal band was a multi-month resiliency initiative across an entire platform. It had visibility well beyond my immediate team, and I was responsible for coordinating work across a much larger group.

But I did not personally do all of that work. Not even close.

The engineers leading individual parts of the initiative did the work. My role was to help create the direction, coordination, accountability, and conditions for those pieces to succeed together.

This is important because large impact is not a fixed pie where the principal engineer takes the biggest slice and everyone else gets less credit. Done well, it is closer to one plus one equaling three. The overall initiative becomes a strong impact story, and the engineers leading its different areas get meaningful stories of their own.

If your version of principal leadership requires absorbing all the credit, you are doing it wrong.

The best evidence of principal-level leadership is not that everything depended on you personally. It is that the organization could take on a larger mission because you helped many people move effectively in the same direction.

A Practical Plan If You Are Targeting Principal

So what can you actually do with all of this?

Actionable Tip: stop asking only, “What task gets me promoted?” Start asking, “What important outcome is too large for one team, and how can I help the organization deliver it?”

Then work through this:

1. Learn your company’s definition. Get examples of people who were recently promoted and the evidence that mattered.

2. Inventory your real scope. Write down the teams, systems, stakeholders, and business outcomes your work already touches.

3. Find the missing dimension. Maybe you need broader technical ownership. Maybe you need cross-team influence. Maybe you need sustained delivery instead of another short project.

4. Choose work that serves the mission. Do not manufacture a vanity project for promotion. Find an actual organizational problem worth solving.

5. Practice telling difficult stories. Be ready to explain projects that went off track, how you built buy-in, where you changed direction, and what you learned.

6. Create opportunities for other engineers. Principal impact should multiply the people around you, not turn you into a bottleneck.

7. Consider the external path honestly. If your organization cannot offer the scope, another company may evaluate the experience you already have differently.

None of this guarantees a promotion. That uncertainty is part of why the process feels so nebulous.

But it does move the conversation away from “do more stuff and be more visible” toward evidence you can actually reason about: scope, ownership, trust, organizational outcomes, and sustained impact.

Do Not Let The Level Become The Mission

I understand why people focus on titles and levels. They are the clearest quantitative signal we have for career progression. Compensation follows them. Responsibility follows them. It is natural to care.

The part I do not love is when the entire incentive becomes: what do I need to do so I personally get promoted?

That framing can make a group of talented people optimize as individuals while the company hopes useful business outcomes appear as a side effect. It feels backwards.

The healthier question is: how do we work together more effectively on the mission, and how do I grow my ability to contribute at a larger scale?

If you keep expanding the complexity you can navigate, the people you can align, the outcomes you can own, and the success you can create for others, you are building principal-level evidence. The title may still depend on timing, organizational shape, and a process you do not fully control.

But the capability is yours.

If you have questions about software engineering or career development, drop them in the comments or submit them anonymously at codecommute.com. I would love to hear how principal expectations differ where you work too, because there absolutely is not one universal path.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Ralph loops make failed AI attempts cheap

• My template library is the real unlock

• First real end-to-end AI build succeeded

• Join me for the live stream (or watch the recording) on Monday, July 6 at 7:00 PM Pacific!

Feeding My AI Workers Templates

I like doing these AI recaps after I’ve had a real stretch of time to sit down and actually build, and this one’s a good one. I recently had a week off work -- my wife was back in Canada visiting friends for her birthday, so I had the house (and the animals) to myself. I still ended up doing some work every day in some capacity, but I also had the flexibility to focus on what I actually wanted to build. Fair warning up front: this is an extension of the stuff I’ve been talking about recently with building things using AI.

You can check out my full thoughts on this in the video below:

Too Many Copilot Tabs, Not Enough Brain

For context: I lean on Copilot CLI for basically everything these days. I keep telling myself I should try other tools more -- I’ve poked at a few this year -- but the flow is working so well that pulling myself away feels actively disruptive. Add in the fact that I’ve got my token limits lifted, and there’s a lot of incentive to just stay put.

My day-to-day looks like juggling a handful of different repositories at once. There’s BrandGhost, the side business I run for automating social media posting and SEO work for other businesses. There’s Needlr, my dependency injection framework for .NET. There’s a consumer app I’m helping a friend build. And then a handful of smaller supporting projects on top of that. In practice, that means I’ve got a PowerShell window open with something like twelve tabs, and I’m just bouncing between them -- prompting Copilot in one, checking on another, prompting a third.

I saw someone online recently put a name to the mental toll of doing this -- and that’s really pointing to the significance of this way of working. Constantly juggling too many AI sessions is a real cognitive cost, and it’s messing with people’s heads a little. I’ve written about the context-switching problem before, but this is a new flavor of it -- it’s not just switching between tasks, it’s switching between agents, each with its own context, its own state, its own thing it’s in the middle of.

Ralph Loops, Orchestration, Spec Kit, and Templates

The system I’ve been building has multiple layers, and the important part is that every layer is optional on its own.

At the bottom is what’s known as a Ralph loop -- a pattern named after Geoffrey Huntley’s tongue-in-cheek nod to Ralph Wiggum, and it’s dead simple: a worker picks up a task, iterates on it inside some constraints, and if it doesn’t meet those constraints in the time it’s given, the work gets thrown away. No wasted human time arguing with an agent that’s gone sideways -- you just scrap the attempt.

On top of that sits an orchestration layer, which follows an open-source specification from OpenAI called Symphony. I’ve got my own C# implementation of it. This is the piece that schedules work across however many Ralph-loop workers are running.

And the third layer is an integration with Spec Kit -- GitHub’s open-source toolkit for spec-driven development. This is what lets you start the whole thing off just by handing it a spec. And I don’t know if I would call this a layer above or below the spec kit integration, but I have a template library that I am building for scaffolding. So it’s not exactly the same as spec kit, but it’s a a solo (or complementary) part of what the spec could include -- all up to my own standards and expectations for how I want something started.

Here’s the part I actually like: none of these layers are required. You can use the inner Ralph loop by itself. You can use the orchestration layer without ever touching a spec. Or -- and this is the version I’ve been testing -- you can hand the whole system a single one-shot prompt and let it use Spec Kit to build out the spec, then use the orchestration layer to schedule the work, then let the agents go execute it.

The One-Shot Calculator Test

To actually test this, I’ve been feeding it about as simple a prompt as I could come up with: “I want a desktop-based calculator app in C#.” That’s it. That’s the entire prompt, on purpose -- I wanted to see whether, given almost nothing, the system would actually finish.

Given how trivial that ask is, my bar was low: I expected spec documents to get created, and I expected a simple app with some buttons that does calculations -- the same basic calculator UI you’ve got on your phone. Tech stack didn’t matter to me -- WinForms, WPF, whatever, I wasn’t specifying it in the prompt. And since it’s such a simple app, I gave it a budget of an hour to get it done.

The early attempts weren’t failures exactly, but I wasn’t happy with them either. The problem was mostly glue -- the connective tissue between all the pieces. I’d come back and find it had burned 30 minutes retrying a single step because a worker session had literally frozen, or gotten stuck in a loop trying to build something it was missing a dependency for. That’s half an hour of a 60-minute budget gone to something completely silly, not to the actual work.

Eventually, though, I got a real end-to-end success. First one. And that felt like a genuine milestone, even for a calculator app -- because it meant the scaffolding, the orchestration, and the loop logic were all finally working together instead of fighting each other.

Why Templates Are the Real Unlock

If you take away one thing from this issue, I’d want it to be this: the real unlock isn’t the fancy orchestration layer. It’s the template library.

I’ve been building up a set of templates -- somewhere north of 10, under 20 -- that represent the foundation I’d expect for any codebase, depending on what I’m building. Want a desktop app in C#? I’ve got an Avalonia template that’s great for getting a cross-platform desktop app off the ground fast, which is exactly what kicked off the calculator build. Every one of these templates already reflects how I like to build things with a plugin architecture, and how I like to wire up dependency injection.

But a template isn’t just a starting solution file and a couple of projects. That’s part of it, sure. The bigger part is that every template ships with my coding standards already turned on -- analyzers and linters configured the way I want them by default. It also ships with my agent instructions: a library of shared instructions that match against file paths. So if an agent is working in a file that ends in test.cs, it automatically gets my standards for what a good test file looks like in C#. And because those instruction files are themselves templated, I can swap in different pieces depending on the stack -- xUnit instructions versus TUnit instructions, for example.

Actionable Tip: if you’re experimenting with anything like this yourself, don’t start with the orchestration layer. Start with a small library of your own project templates and coding standards. That’s the piece I use every single day, regardless of whether the fancier orchestration experiment ever fully pans out.

Put it together and the goal is simple: when I kick off a brand-new project, it’s scaffolded well from the very first commit, fully on autopilot -- instead of me getting an agent to reinvent my standards from scratch every single time.

This Isn’t Just For New Projects

The other half of this system isn’t about kicking off brand-new projects -- it’s about ongoing work. There’s a small web server sitting there listening, and I can just queue work items up to it. It schedules agents against that queue, and if a backlog builds up, an orchestrator looks at priority and dependencies and figures out how to work through it.

Some pieces of this I use constantly, some are still very much an experiment. The templating library and the reusable instruction files -- I’m in those every single day. Because I’m running across so many different Copilot sessions and repos, I keep spotting the same small pattern show up more than once: “oh, this is clearly a recurring problem, let’s get it into the instructions” -- and that feeds straight back into the template library. The same thing happens when I’m building a new feature: sometimes I realize I need a template for this shape of work, sometimes I realize I just need better instruction coverage.

That’s honestly why I’m not worried if the fancier orchestration experiment doesn’t pan out. The templating system is something I get value from regardless -- and it also syncs just the instruction files (not the whole template) across my different projects, so if I improve a standard in one repo, it can propagate to the others.

... Besides, people smarter than me I am sure are already lightyears ahead on the orchestration part!

Teaching the Agent to Ask About UX

After that first successful run, I went and looked at the actual calculator -- and it looked terrible. So I asked Copilot directly: based on the spec, was there anything in there about UX? Nope. Nothing.

So for the next attempt, I changed the one-shot prompt -- and I mean changed it barely at all, because I wanted to keep it close to a true “give it nothing” test. I just added one line: I want a consistently styled user interface that looks modern. That goes in right at the start, and then the same pipeline runs: Spec Kit turns it into a spec, orchestration schedules the work, agents execute.

The part that still catches me off guard, even though I built it: there’s an agent driving the entire Spec Kit conversation on my behalf. I didn’t invent that pattern -- it’s not novel -- but actually watching an agent have that back-and-forth about what I want built, fully hands-off, still feels a little nuts. When we’re this hands-off, we either need to expect things to be done in odd ways or provide significant enough guard rails to keep things on track.

Worth saying too: none of this requires Spec Kit at all. If I want to bring my own spec, or my own prompt, or skip that step entirely, I can just start a new repo and start sending work items straight to the queue. Those work items can just as easily be GitHub issues -- the system integrates with GitHub directly.

Turning This Into Real Eval Scenarios

Once I’ve got this working end-to-end reliably, the next step is turning scenarios like the calculator app into actual eval scenarios. The idea: define requirements that apply across every scenario -- has to finish within a given time window, has to stay under a token budget, has to actually deliver on the spec. That last one needs an LLM judge that reviews the spec against the output and decides whether it actually delivered. I’ve written before about building LLM-as-judge evaluation harnesses in C#, and this is exactly the kind of system that needs one -- I don’t have a ton of eval experience yet, so I’m actively building that muscle.

Why bother? Because it gives me a way to tune the system honestly. If I change how conflict resolution works, or how retries behave, or how work gets scheduled across multiple parallel workers, I want to be able to run it against a handful of eval scenarios and say “yep, this still meets my bar” -- instead of just eyeballing one run and hoping.

One optimization idea that came out of watching this calculator run: it only used a single worker because there wasn’t enough parallel work to justify more. But for anything more complex -- multiple workers, potential conflicts, retry logic -- there’s a real efficiency question buried in here. Instead of spinning up a brand-new working session for every single work item, what if a worker just kept reusing the working directory it’s already sitting in? If a build takes a minute, and you’re chewing through 10 work items, that’s a minimum of 10 minutes out of your budget spent purely on rebuilding from scratch every time. On a 60-minute budget, that’s not a rounding error -- that’s a huge chunk of it.

Why I’m Actually Doing This

Zooming out, I think about all of this in two ways.

The first is that I’m trying to build things, and using AI well, so I need to get better at building the scaffolding that makes AI effective -- that’s my templating library, that’s my instruction file library, and I’m actively working on both.

The second is that I’m experimenting because that’s genuinely how I learn best. Long before AI was part of the picture, this looked like me building a role-playing game as a side project -- not because I ever expected to ship a finished game, but because building it forced me to learn different corners of software engineering I wouldn’t have touched otherwise. Playing around with agent orchestration right now is the same instinct. I’m not sitting here thinking I’ve invented agent orchestration -- I haven’t, and there are people and companies way further ahead of me on this, which is completely fine. I’m happy to go use their stuff when it makes sense. This is just me playing around so I can learn, because that’s how learning has always worked for me.

If you’ve got questions about software engineering, AI, or your career, drop them in the comments, or head to codecommute.com and submit them anonymously -- I’ll make a video response for you and everyone else watching.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Healthy conflict between product and engineering matters

• A non-technical boss isn’t an automatic dealbreaker

• Surface tech debt before it gets ignored

• Join me for the live stream (or watch the recording) on Monday, June 29 at 7:00 PM Pacific!

When Your Product Manager Becomes Your Boss

This week’s topic comes from a post over on the ExperiencedDevs subreddit, and it’s a good one: is it normal for the product owner or product manager to be your boss? The person who posted it had their engineering manager leave -- and instead of backfilling that role, leadership made the product manager who already worked with the team the new manager of the engineers. So now the engineers report into a product manager, and as far as I can tell there’s no engineering manager replacement coming. That’s just the path forward. They were asking the obvious question: is this normal, and what should I make of it?

You can check out my full thoughts on this in the video below:

One Detail Changes the Whole Picture

Right at the end of the post, they dropped in a piece of context that I think matters a lot: this is a company that’s primarily a marketing company. Software is an aspect of what they do, not the whole business. And they wondered if maybe that was a factor.

I think it’s a huge factor, and I want to call out why I love that they included it. We talk about a ton of different software engineering topics, and the right answer almost always depends on the situation. A tiny startup is not a giant enterprise. A company that’s effectively 100% a software business is not the same as a company where software supports some other product or service. When I read something like this and feel a strong gut reaction -- wait, what the heck is that? -- the most useful thing I can do is check whether the context is just very different from what I’m used to. It usually is. So keep that in mind as I share my take: your situation might not map cleanly onto mine, and that’s exactly the point.

Why You Actually Want Conflict Between Product and Engineering

Here’s the meta point I really want to land, because everything else hangs off of it. I think it’s genuinely important for a team or an organization to have healthy conflict between engineering and product. “Conflict” is almost too strong a word -- think of it as healthy tension between two groups motivated by different priorities.

If you only have product representation, you get pulled toward what I’d only half-jokingly call feature factory hell -- crank out features, crank out more features, and never make space for the work that keeps the foundation from getting brittle. Flip it around: if you only have engineering representation, you exaggerate the other way into tech-debt-and-architecture hell, endlessly refactoring and re-architecting while shipping very little customer value. Both extremes are caricatures, obviously. But that’s the whole reason you want both voices in the room. They pull against each other, and that tension is what keeps you focused on what actually matters: shipping real value without quietly rotting the codebase.

So when a team loses its engineering manager and folds entirely under product, my first concern isn’t “a PM can’t manage people.” It’s “who’s representing the engineering side of that tension now?”

The Traditional Setup, and What’s Really Shifting

In a more traditional org, engineers report up to an engineering manager, and the product manager works with the team. Those are two different things, and it’s worth separating them. The product manager absolutely helps understand and set priorities -- they’re translating what customers and the broader industry are asking for, figuring out which direction the product should go, and often bridging into sales and marketing. But the engineers aren’t reporting to that person for career development. They report to an engineering manager, and the engineering manager partners with the product manager on what to actually go focus on. If you want my full breakdown of that role, I wrote about what’s actually expected of an engineering manager.

What’s changing in this Redditor’s case is that the reporting line and the engineering representation are both collapsing into the product manager. The partnership tension I just described doesn’t have an obvious counterweight anymore.

Ownership Moves Around -- a Lot

I want to paint a picture from my own career, because the balance between product and engineering is not fixed. It moves.

Back when I worked at a digital forensics company before I landed at Microsoft, most of the time product management set the direction of the product and made it very clear what we needed to deliver -- they sat between engineering, sales, marketing, and customers. We shipped monthly, and we’d prep hard for some big conferences, so product would shape a lot of the roadmap around those. From the engineering side, as an engineering manager and a software engineer, our job was to make it real -- and to push back in a healthy way. “You want these things, but you may not see all the detail that goes into doing them well, so let us represent that side.” Then we’d meet in the middle. Funny thing is, even though a lot was set by product, I never felt like I lacked input or control. We just had a genuinely good working relationship.

Then I came to Microsoft, onto a deployment platform team in Microsoft 365. Early on, it felt almost the opposite -- engineering managers were quite literally defining the roadmap, and the product managers were there to facilitate that vision, jumping into cross-team dependencies and smoothing things out. Then there was a reorg, and it flipped dramatically. Product went from facilitating to owning every priority, work stream, and deliverable -- to the point where it sometimes felt like I barely had a say. A complete 180, on the same org, in the span of a few years.

On the team I’m on now, it’s more of a hybrid. I feel like I have a lot of say in what we work on, and the product managers do a great job bridging the business needs down -- “here’s the initiative, here’s the spend or performance goal we need to hit” -- and then leaving the how to engineering. Three very different balances, all in one career. So when someone asks “is it normal for product to run things?” -- honestly, the ratio swings all over the place depending on where you are.

The Two Things That Get Weird

So what actually gets harder when a product manager is directly managing engineers? I see two big ones.

Career development. In this case the poster said their PM isn’t technical at all. That can make career growth genuinely tricky. Not impossible -- I want to be careful here, because I’ve had non-technical managers I thought were fantastic, and plenty of people will disagree with me on that. There are real strengths a non-technical manager can bring. The hard version is when someone is non-technical and struggles to communicate effectively with technical people. That’s when it gets rough -- it’s hard to feel relatable to a manager when you don’t think they can follow what you’re working on or understand what career progression looks like for an engineer. Even if they actually do get it, that gap erodes the trust and respect that make the relationship work. I went deeper on how you even evaluate this in measuring manager effectiveness.

Delivery and representation. This is the thread running through everything above. When you drop the engineering voice out of priority-setting, you lose the person who’s supposed to argue for the foundation. You’re left with a product focus -- and like a bunch of the Reddit commenters warned, get ready for the feature factory: more and more features, less and less room for the work that keeps your base from getting brittle. It’s not that it can’t work. It’s that the structure quietly removes the counterweight. Getting non-feature work onto the roadmap is already hard enough with an engineering manager in the room -- I broke down that whole battle in how to get tech debt prioritized.

Subscribe now

How You Actually Make It Work

Here’s the part I care about most, because it’s the part you can control. If you’re in this spot and you’re not immediately heading for the door, do two things.

First, invest early in communication. Figure out how to talk to this manager so they actually get it. If you start going on about classes and code structure, a non-technical PM may have no idea what you mean and no interest in it. So learn -- quickly -- the level you need to communicate at, and ideally help them learn how to communicate effectively back to you. You don’t control their half of that, but you fully control yours, and getting this right is what lets you set clear expectations when you’re not seeing eye to eye. This, by the way, is the exact skill I’d argue separates good developers from great ones -- being able to translate technical reality for a non-technical audience.

Second, be proactive about surfacing the engineering side. A non-technical product manager probably isn’t going to ask, “hey, where’s our tech debt, do we need to re-architect anything?” -- not out of malice, but because it’s genuinely not on their radar. So you’ve got two options. You can sit and sulk -- “well, I guess we’re a feature factory forever, no tech debt work, no improving our test infrastructure, no re-architecting.” Or you can say: they’re not going to ask because they don’t know to ask, so we’ll bring it up. Lay out the pros, cons, and risks for the areas they don’t have exposure to. Whether they act on it is a separate story -- but the part you control is making sure it gets raised. And if they consistently won’t factor it in when prioritizing? That itself is a useful signal about whether this is a good long-term fit.

My Best Boss Was a Product Leader Running Engineering

I’ll leave you with a story that complicates the whole “product running engineering is bad” narrative. At that same digital forensics company, there was a stretch where our VP of engineering left, and the interim VP of engineering was our product management leader. So product was, quite literally, in charge of all of engineering -- a different level in the hierarchy than this Reddit situation, but the same basic shape.

And honestly? In my eight years there, that person was the best engineering leader I worked with at that level. Which sounds wild given the framing of “oh no, product is in charge, there’s no engineering voice.” So what made it work? He wasn’t writing code and wasn’t a software engineer, but he was technical enough in how he communicated. He listened to the engineering side. He clearly understood that you need that healthy conflict between product and engineering to prioritize well. And when he didn’t follow a technical detail, he’d just say so -- “I don’t get it, can you explain it a different way?” -- no bluffing, never frustrating to work with. A lot of it came down to his willingness to genuinely take in engineering concerns instead of just handing down “product decided, go ship it by next week, figure it out.” Even reporting into him, I always felt well supported in my own growth.

So, Is It Normal -- and Should You Worry?

My honest read: it’s not an absolute dealbreaker, but I’d also be lying if I said I’d love being in this exact situation. I think statistically I got pretty lucky with that interim VP, and more often than not, I suspect this setup doesn’t pan out quite as well. But the outcome isn’t fully out of your hands. If you’re aware of the parts you can influence -- communicating in a way your manager actually understands, and proactively making sure engineering concerns reach the prioritization table -- you can tilt the odds. And if you give that a real shot and it still doesn’t work? Then yeah, it’s probably time to go find a place where engineering gets a seat at the table.

If you’ve got a situation like this you’re wrestling with, you can submit it anonymously over at codecommute.com and I’ll do my best to make a video response. Hope this one helps.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Not knowing everything is completely normal

• Prove or disprove every hypothesis, then write it down

• Disproving is just as valuable as proving

• Join me for the live stream (or watch the recording) on Monday, June 22 at 7:00 PM Pacific!

Debugging When You Have No Idea What’s Going On

Something is on fire. A live service is doing something it absolutely should not be doing, the metrics look wrong, and you’re sitting there staring at it thinking: I genuinely have no idea what’s going on. If you’ve ever felt that creeping sense of shame in that moment -- like a “real” engineer would already know the answer -- I want to talk to you. Because that feeling is incredibly common, and it’s almost entirely self-inflicted.

You can check out my full thoughts on this in the video below:

The Shame of Not Knowing Is Almost Entirely Self-Inflicted

This whole topic came out of a post on the ExperiencedDevs subreddit. Someone framed it really honestly: it feels shameful as a software engineer when something is happening that you don’t understand, and you genuinely don’t know what’s going on or how to make progress on it. And I get it. I really do. But I want to say this as clearly as I can: that is completely okay, and it’s completely normal.

No one in the world expects you to know everything. They shouldn’t expect it, and honestly, they can’t expect it -- it’s not possible. Part of being an engineer isn’t having every answer in your back pocket. It’s being curious and working toward a better understanding when you don’t have the answer yet. A lot of this pressure is self-inflicted, and a lot of it is just software engineering culture. We tend to be a group of strong problem-solvers, so hitting a wall where we just don’t know is wildly uncomfortable. That discomfort is normal. It does not make you a bad engineer.

This is also one of the big reasons we build software in teams. If everyone on your team thought exactly the way you do, then the moment you got stuck, the entire team would be stuck right alongside you. Diversity of skill, experience, and perspective is a feature, not a nicety. A lot of the things I wish I understood earlier in my career come right back to exactly this.

Even Multiple Levels Up, We Don’t Always Have the Answer

I was recently talking with one of my engineers who was deep in a live site investigation. For context, the service area my team is responsible for in Microsoft 365 is... a bit outrageous. The sheer amount of traffic flowing through our systems makes it genuinely impossible for any single person to know every detail about everything. Should people on the team get better and better at investigating and understanding it over time? Absolutely -- that’s the whole game. But no single person knows everything all the time. The surface area is just too big.

So there we were, talking it through. A very sharp engineer, and me, several levels up -- and between the two of us, there was no obvious answer. In that moment, as a manager, part of me felt that same pull: man, I wish I just had the answer in my head. But my boss doesn’t expect me to know everything. My skip level doesn’t expect me to know everything. We have to make space for that. If your goal is to never be in a situation where you don’t know the next step, you’re going to fail at that goal. You will end up there. And that’s fine, because what actually matters is that you try to make progress.

If you’ve ever been on the receiving end of someone expecting you to instantly understand everything, this rant about “junior developers who just don’t get it” digs into that expectations mismatch between experience levels.

My Framework: If You Can Prove It or Disprove It, Write It Down

Okay, so with all of that out of the way -- how do I actually approach a problem when I have no idea what’s going on?

Here’s the core of it: most people treat problem-solving as proving a hypothesis right. I treat it as building a matrix of what’s known fact versus what’s still assumption.

When most people debug, they form a hypothesis, go chase it, and if it turns out to be right, great -- they keep progressing. But if it turns out to be wrong, it gets quietly dismissed as wasted effort. “We thought it might be this, we looked into it, it wasn’t, so we got nowhere.” I want to push back on that hard. Disproving something is just as valuable as proving it.

So whenever I can prove a statement true or false -- by reproducing something, by reading through the code, by finding a log that contradicts the theory -- I write it down. On a whiteboard, in a shared doc, wherever the team can see it. Back when we worked more in person, I used to fill entire whiteboards with assumptions, each one marked as proven or disproven. The magic of this is that none of the investigation is wasted. Every hypothesis you resolve, in either direction, shrinks the unknown. While something stays an assumption, it’s a live question hanging over the whole investigation. The goal is to keep converting assumptions into facts.

For the C# side of actually getting useful signal out of failures, I’ve got a guide on handling exceptions in a way that streamlines debugging. For everything else: Build out your matrix of assumptions. Validate them.

There Are No Stupid Hypotheses

One of my favorite side effects of this approach: there are no dumb ideas. When nobody knows what’s going on, someone will eventually say, “This is going to sound kind of crazy, but... could it be something with the operating system?” And the room groans -- “come on, the OS is the last thing that’s going to have a problem.”

But... maybe it is? If you can’t state as a matter of fact that it isn’t, then it’s an assumption, and it’s completely valid to go prove or disprove. Across thousands of machines, could there be something off with a specific OS version in a specific scenario? One hundred percent. Is it common? Nope. Is it possible? Absolutely. So write it down and go check. Often the “crazy” hypothesis is exactly the one worth checking, because it’s the last thing anyone would have looked at -- and you already admitted you don’t know what’s going on.

Watch the Correlations Emerge

Here’s where it gets genuinely satisfying. Once you start turning assumptions into proven facts, patterns start to surface that you couldn’t see before.

You check the OS angle: “Nope, we see it across versions X and Y, so it’s not the operating system.” Fine, that’s a fact now. What about hardware? “We see it on configurations A and B, but not C... so C is still open, but A and B definitely reproduce it.” Now you’re not holding a pile of vague guesses in your head -- you’re drawing a map. And when you lay those proven facts side by side, you might suddenly notice: wait, we only ever see this on these specific combinations. Only this software version. Only this region. Only this traffic pattern.

That’s the moment the investigation stops being vibes and starts being data-driven. You go from “I don’t know, so let’s just guess” into actual experimentation, and then into higher-level correlations between signals you’ve proven are real. For live systems, this is also where good observability and telemetry earns its keep -- the more real signal you’ve instrumented, the faster those correlations show up.

And a bonus point here: get comfortable with AI and MCP servers. Being able to rely on an LLM to pull data and help you correlate it is SIGNIFICANTLY more effective than you being in the weeds just trying to pull the actual data. Let it do the boring work so you can use your brain for what’s more valuable.

Where This Came From: Debugging With Almost No Information

This framework actually goes back to my digital forensics days. The software we built essentially scanned devices -- mostly hard drives at the time -- and turned the data into a structured report so an investigator looking for digital evidence had something readable to work through. Think of it as a giant search engine plus an interactive dashboard.

Here’s the brutal part for debugging: because this was forensics, the data on those devices was highly sensitive material tied to active criminal cases, and a lot of it legally could not be copied or reproduced. So the usual “just send me a repro” was frequently off the table. On top of that, many of these workstations were often air-gapped by design. So when something broke, you might get a terse “it doesn’t work” and maybe a log file -- and you’d better hope there was something obvious in the stack trace, because a lot of the time there wasn’t.

When you’re debugging with limited information and no ability to reproduce the problem, you cannot afford to waste effort chasing hypotheses you’ve already implicitly ruled out. That constraint is exactly what forged this prove-or-disprove habit. It’s the same energy as untangling a gnarly dependency injection debugging nightmare -- you methodically eliminate possibilities until the real cause has nowhere left to hide.

And yes -- afterward, always reflect: if this happened again, could we add better logging, telemetry, or monitoring to catch it faster next time? That follow-up is worth doing every single time. It just usually doesn’t help you in the heat of the moment, so treat it as a separate step.

The Keys Are in Your Hand

One last thing. Sometimes the reason you’re stuck is an assumption you never bothered to prove because it seemed too obvious to check. “Why would I look at that? It’s obviously not the problem.” But did you actually prove it?

It’s like tearing the house apart looking for your keys while they’re in your hand the whole time. I did this constantly as a kid building LEGO -- convinced they forgot to include the one piece I needed, when it was the next piece in the instructions, sitting right in my hand. Investigations have the exact same trap. The thing you “know” is fine is sometimes the very thing that’s broken.

You’re Not a Bad Engineer for Not Knowing

So if you take one thing from this issue, let it be this: you are not a bad engineer because you don’t know the next step. Don’t let the shame paralyze you. Accept that not knowing everything is completely normal -- it has to be, because no one can possibly know everything. The point isn’t to have the answer instantly. The point is to get curious, start writing down hypotheses, and start proving or disproving them one at a time. If you stay curious and keep exploring the problem space, you’ll keep making progress. And that’s all any of us can really ask for.

If you’ve got questions about software engineering or career development, drop them in the comments or head over to CodeCommute.com and write in anonymously. I’m always happy to make a response and share a perspective if it helps.

Leave a comment

Share

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Decision-makers are detached from your code

• “The code is a mess” never wins

• Reframe tech debt as future velocity

• Join me for the live stream (or watch the recording) on Monday, June 15 at 7:00 PM Pacific!

How to Get Tech Debt Prioritized

This week’s topic comes from a post on the ExperiencedDevs subreddit. A developer was asking for perspective on getting their manager to prioritize tech debt. It used to get prioritized, they said, but lately their manager keeps pushing back because the team needs to deliver features. If you’ve been writing software for any length of time, you know this one -- the age-old battle between shipping more things and making the code better. And if you haven’t hit it yet, it’s probably just about to happen.

You can check out my full thoughts on this in the video below:

This Is a Prioritization Problem, Not a Code Problem

The first thing I want to get out of the way is that this is genuinely tricky, and it’s tricky because it isn’t really one problem. It’s a prioritization problem, a communication problem, and a perspective problem all bundled together. If you’re more junior and this is happening to you for the first time, it’s easy to feel confused and frustrated by it -- like you’re clearly right and nobody will listen. So it’s worth slowing down and understanding what’s actually going on underneath.

Tech debt almost always accumulates the same way: a few things stack up, and whoever owns prioritization -- a product owner, an engineering manager, some combination of those roles -- has to make a call. And the more removed those people are from the code, the less direct understanding they have of how specific areas of the codebase affect your ability to ship. I don’t mean that conceptually. I mean very specifically: they are not going to know that this class or that module is the thing slowing you down, because they’re not spending time in there.

I’ll be honest about my own seat here, because it’s relevant. I’m an engineering manager at Microsoft -- I’ve been there just under six years, and I’ve been programming for over 20 years. But in my role, I don’t write code. It’s not that I’m not allowed to; it’s that there are enough other things I’m responsible for that it doesn’t make sense for me to spend my time there. So there are absolutely situations where I am simply not aware of where the tech debt is. I have to rely on and trust my team to bring it up. And when they do, I expect them to be able to articulate why it matters. That last part is the whole ballgame, and we’ll come back to it.

The Two Forces Working Against You

When you zoom out, there are two big forces shaping these conversations from the prioritizer’s side.

The first is constant pressure to deliver more, often with less. Before Microsoft, I was at a startup, and there it was a never-ending stream of “how do we get more things done?” There’s truly an infinite amount of work, and a lot of it feels like strategic bets -- things you’re not certain about but believe you have to try. At a big company, it’s a different flavor of the same thing: less uncertainty per bet, but a massive surface area of teams all pushing their own initiatives. Either way, the pressure is “more, faster.” I went deep on how that infinite pile grows as you get more senior in More Experience, More Overwhelmed.

Layer on the current climate -- hiring slowing down, teams shrinking, and the “we made a strategic pivot to AI, so where’s the 10x productivity?” expectation -- and the “do more with fewer people” drumbeat gets even louder. I hear this constantly: leadership bet on AI, and they’re relying on the people building things to show the return.

The second force is detachment from specific areas of the code, which we already talked about. Put those two together -- relentless delivery pressure plus distance from the codebase -- and you have the exact conditions where tech debt loses. Not because anyone is stupid or malicious, but because the people deciding are focused on shipping value to customers, and you’re handing them an argument about classes and methods.

Subscribe now

How the Debt Actually Piles Up

Let me walk through the mechanism, because it’s so common it’s almost mechanical.

Say you want to build feature A in a one or two week window. The north star design is “do X, then Y, then Z.” If you did all of it properly, it might take a month or two. But you look at the window and go: we can definitely get X done, we’ll get partway into Y, maybe finish it with a tweak, and we will not get to Z. But that’s fine -- we’ll ship A on time and come back for Z next sprint.

So you ship. You got X, part of Y, and no Z. The feature works. You’re now in an intermediate state with a bit of debt baked in -- and then the question comes: what’s more important, the next batch of customer value, or going back to finish Z? If the feature already shipped and already works, finishing Z is almost never the higher-value option. If Z had been truly necessary, it would have blocked the release in the first place.

Now multiply that by every feature your team ships -- two, three, five, six of these at once -- and you can see how you just keep bleeding debt. I genuinely believe nearly every line of code we write is debt to some degree, but here I mean the specific, visible gaps you know you left because you took a shortcut to hit a date. And I don’t mean “shortcut” as an insult -- it’s often not “oh my god I can’t believe I wrote that.” It’s just “we didn’t get the full thing done, the feature works, and what’s left isn’t visible to the customer.” The frustration is that it keeps happening, sprint after sprint, and that constant churn is its own kind of tax -- closely related to the productivity drain I covered in The Context Switching Problem Every Dev Faces.

Why “The Code Is a Mess” Never Wins

Here’s where most engineers shoot themselves in the foot. The argument they bring sounds like: “As a software engineer, I think we should focus on this. Here’s why.” And every reason is about the code -- this class is convoluted, we hate touching this module, we want to refactor for cleanliness.

Now put yourself in the prioritizer’s chair. They’re weighing “spend a week rewriting some classes” against “fix these three critical customer-reported bugs and ship these two features the sales team can use to chase five new customers.” Why would they pick the cleanup? The framing was lost before the conversation even started, because it was built entirely around things they don’t focus on and can’t easily evaluate.

It’s almost like you’re set up to automatically lose. And that’s a genuinely lousy spot -- being forced to pit your tech debt against visible customer value, using the one language the other side doesn’t speak.

Actionable Tip -- Before you pitch tech debt, run it through this filter: strip out every reason that’s about the code itself, and see what’s left. If there’s nothing left, you don’t have a business case yet -- you have a preference. Keep digging until you can express the cost in terms of delivery, bugs, or time.

Reframe It in the Language of the Business

The move is to translate. Instead of “this code is a mess,” make it about speed, risk, and waste on the work they already care about.

Concretely, it sounds more like this: “This isn’t some legacy file we haven’t touched in four years and never will. We are actively in here right now. Two of the bugs this sprint are in this exact code, and we keep breaking it because it’s convoluted and we can’t test it effectively. If we slow down for a week and clean it up, the two features you want next -- which we already know live in this same area -- get easier. They’ll take half the time going forward, and we’ll stop bleeding these recurring bugs.”

See the difference? You’ve connected the cleanup to future velocity, reduced bugs, and less wasted time -- and you’ve anchored it to specific upcoming work the prioritizer has already hinted at. You’re not asking them to value clean code. You’re showing them how the debt is actively taxing the roadmap they care about. That’s the same spirit as deciding to talk to your manager about burnout -- don’t lead with the vent, lead with the pattern, the impact, and what would actually help.

The more you can express tech debt as “this will speed us up on related work” or “this will stop these bugs that are clearly hurting our velocity,” the better your odds. “The code is a mess” is a feeling. “This is costing us two bugs a sprint and doubling the time on the next three features in this area” is a business case.

The Manager’s Side of the Table

I want to address the manager dynamic too, because the original poster felt their manager was the obstacle. From where I sit, an engineering manager carries real responsibility not to turn the business’s delivery pressure into a crippling weight on the team. A good manager absorbs a lot of that and provides some shelter -- not by hiding it entirely (the team should understand the context), but by refusing to amplify it. Amplifying pressure isn’t productive and it isn’t helpful.

That shielding role is exactly what I dug into in The Management Trap in Software Engineering -- a lot of management is absorbing chaos so your team can stay focused. But there’s a real risk in being the person who soaks up everything, which I broke down in The Hidden Cost of Being the Team Hero. The point for you as the engineer: your manager is very likely getting this pressure from above, and your job in that conversation is to make it easy for them to advocate for the cleanup to their stakeholders. Hand them the business case, not the complaint.

The Hard Truth: Some of It Will Never Get Done

I’ll close with the uncomfortable part, because pretending otherwise doesn’t help anyone. My entire job is prioritizing things, and at the end of the day you have to accept that some things simply will not get done. There is an infinite amount of work -- I have business-critical features to ship for my teams before you even get to tech debt or bug fixes -- and it is quite literally impossible to do all of it.

That means some of the stuff you talked about, planned, and said “oh, we’ll get to it” about may genuinely never happen. And honestly? That can be completely fine in the end. The skill isn’t getting everything done; it’s relentlessly ordering things by value and working through them, accepting that the bottom of the list might never come up. If that constant triage is wearing you down, you’re not alone -- I wrote about that exact feeling in ADHD, Burnout, and Building a Career That Fits Your Wiring.

So find the opportunities to bring tech debt up, and organize them from the perspective of the person doing the prioritization. What will make it clear to them why it’s valuable? That means framing it around value to them -- not value to you. It’s a frustrating thing to navigate, but reframing your perspective makes it a whole lot easier.

If you’ve got a specific situation you’re wrestling with, you can submit it anonymously over at codecommute.com and I’ll try to make a video response.

Leave a comment

Share

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Management is a different job, not a promotion

• Not all context switching drains you equally

• Absorb your team’s chaos -- but keep it temporary

• Join me for the live stream (or watch the recording) on Monday, June 8 at 7:00 PM Pacific!

The Management Trap in Software Engineering

This week’s topic comes from a post on the ExperiencedDevs subreddit titled “the management trap.” An engineering manager was reflecting on their career progression and how they’d arrived at a particular realization: they’re missing a lot of the joy -- that deep, hyperfocused, heads-down work they used to get as an individual contributor. As someone who has been a frontline engineering manager for over thirteen years, this one hit close to home, and I want to walk through my honest take on it.

You can check out my full thoughts on this in the video below:

Where This One Is Coming From

I want to set the stage a bit, because context matters here. This isn’t a tiny startup with ten people on a single team -- it sounds like this person is in a larger organization. A lot of what they describe about how their time gets spent is the side effect of scale: cross-team coordination, headcount planning, all of that. That stuff exists in small companies too, but the amount of time, effort, and focus it demands varies dramatically based on the size and the stage of the company.

The other detail that stood out to me is that this person is a frontline manager. They mentioned that a senior manager promotion has been talked about but never quite materializes. That resonates with me, because I’ve been a frontline manager for about thirteen and a half years now. Before Microsoft, I was at a smaller company where a director role was on the table -- but that was five and a half years ago. So when someone says they’ve been sitting in the frontline manager seat for a long stretch, watching the “next step” stay perpetually one conversation away, I get it.

And here’s the honest tension in their post: it’s not that they hate management. They explicitly said they get genuine enjoyment out of helping people with career progression, promotions, and growth. That part lights them up. But when they zoom out and look at their day-to-day, it feels chaotic -- scattered, sporadic, a lot of context switching -- and they miss the ability to just sink into one hard problem and feel like they’re making real progress on it.

Management Is a Different Job -- Not a Better or Worse One

If there’s one thing I want you to take from this issue, it’s this: a management role is not the same as an IC role, and that difference does not make it better or worse. It’s just different.

That sounds obvious written down, but I don’t think it actually lands for most people until they’ve lived both sides. Engineering management is its own discipline within software engineering -- the same way a product manager or a project manager is something distinct within software engineering. It’s not “senior engineer, but with more authority.” The work itself changes shape.

A lot of people hit a point in their career where the promotion that’s offered to them is a management position. And that can be fantastic -- you might love it, it might fit you perfectly. But I’d urge you to understand what managers should actually be spending their time and focus on before you assume it’s just the natural next rung on the ladder. I went deep on this in I Wish I Knew THESE Before Becoming A Manager, and a lot of it comes down to expectations nobody sets for you up front.

Not All Context Switching Costs the Same

Here’s a nuance I don’t think gets talked about enough. The Reddit thread frames the chaos as the problem -- too much context switching, not enough hyperfocus. And I get that. But when I reflect on my own experience, it’s not the context switching itself that wrecks me. It’s context switching into work that doesn’t engage me.

Let me give you a concrete contrast. When I’m working on security-related problems, there’s often a ton of context switching, and it can get genuinely chaotic. But I don’t walk away from it feeling burnt out, because that work excites me. Jumping in to help one of my engineers work through a gnarly technical challenge? That can be energizing, even though it’s an interruption. On the flip side, sitting down with focused, prepared time to work through interpersonal challenges or career progression with someone -- that feels good. But being rapidly context-switched into that same kind of work, with no runway, is incredibly taxing for me.

So it’s often not even the nature of the task that determines the cost. It’s how much context and preparation I have going into it. I talked about a closely related version of this in last week’s issue on ADHD, burnout, and building a career that fits your wiring, and the mechanics of why switching is so expensive in the first place in The Context Switching Problem Every Dev Faces.

Actionable Tip -- If you feel perpetually drained by your week, don’t just count your context switches. Audit what you’re switching into:

• Which interruptions leave you energized, and which leave you hollow?

• How much of the draining stuff is draining because of the task itself vs because you had zero preparation for it?

• Can you batch the low-context, high-cost work into a window where you’re actually braced for it, instead of letting it ambush your focus blocks?

The Part of Management I Actually Believe In

This is the piece of the conversation I have the most conviction about. I genuinely believe that to be effective as an engineering manager, my job is to enable my team to do their best possible work.

In the short-to-medium term, that often means I have to be the one who gets randomized so that they don’t. When chaos comes in -- an urgent org-wide ask, an incident, a security fire -- I’d rather absorb the initial hit myself than yank three engineers out of their flow. I sometimes describe this as shielding or sheltering the team, and I want to be clear about what I mean: not hiding things from them, but removing distractions so they can stay locked on the work that actually moves us forward.

But absorbing chaos is only a good strategy if it’s accruing to something. Here’s my litmus test: from a pure operations standpoint, I feel successful in my role if I could walk away and my team could keep running entirely on their own. That sounds almost paradoxical -- like I’m saying my goal is to not be needed. From a career-growth standpoint that’s obviously not the whole picture, because I’m here to help every one of them grow. But operationally, the target is a team that doesn’t depend on me to function. I dug into this idea of self-sufficient, autonomous teams in Effective Software Teams: Islands and Autonomy.

The real trap -- and in my opinion this is the actual trap, more than the “I miss being an IC” framing -- is when the chaos I’m absorbing isn’t moving us toward that self-sufficiency. If I’m just perpetually soaking up randomization with no end state where the team gets more autonomous, that’s not sustainable. It’s supposed to be temporary. Take the chaos, let the team build the processes, services, and tools that make us stronger, and then we don’t need me in that spot anymore -- and we move on to the next frontier together. The flip side of this is a real risk worth naming: if you become the only person who ever absorbs the chaos, you’ve built a fragile system around your own bandwidth, which is exactly the failure mode I broke down in The Hidden Cost of Being the Team Hero.

Fan-Out Work Is the Most Unscalable Thing I’ve Seen

Let me give you the specific pattern that’s been on my mind, because it’s the clearest example of chaos that doesn’t accrue to anything good. I’ve been trying to make more noise about it lately: fan-out work.

We’re a platform team in a large organization. Because the surface area is enormous, what happens constantly is that some team owns a thing, a change lands, and the message goes out: “everyone needs to go make this change.” The work fans out to dozens of teams. And it’s not one team doing this -- it’s multiple teams all fanning work out to each other simultaneously.

In my opinion, this is one of the most inefficient, productivity-destroying patterns you can possibly have. And I want to be careful here -- I’m not saying the work isn’t important. I’m not saying we shouldn’t help. I’m saying it is, by a wide margin, the most disruptive kind of work I’ve encountered in my software engineering career. The randomization it injects across an entire org is brutal.

This is where being a manager means more than just personally absorbing hits. If I notice that fan-out work is a recurring theme, I owe it to my team to push back to the broader organization and say, “something has to change here.” That doesn’t mean I’ll have the solution in hand. But if I’m going to make noise about a problem, I need to volunteer to be part of building the fix -- not just complain about it.

Systematize the Interruptions Instead of Just Absorbing Them

There’s an older example I come back to a lot. Back in my startup days, the CTO and founder would come by and say, “this is urgent, we have to do it now.” Especially in the early days, we’d drop everything and get completely randomized. I’d try to step in and shelter the team from it, but over time we landed on something better -- a kind of unwritten contract.

When we got approached that way, the new default became: we don’t just drop everything. We talk about it. We’d explain what we were currently working on, give visibility into the tradeoff, and then if the answer was still “yes, I genuinely think you should drop that other thing,” at least it was a conscious decision made with full context -- not a reflex.

That shift, from reflexive interruption to a deliberate, systematized filter, was hugely important. The team was almost always working on things that made us more effective in the long run, so being able to push back and force the interruption to justify itself protected the work that mattered.

Actionable Tip -- If your team is constantly randomized by “urgent” asks, build a lightweight filter instead of absorbing each one in the moment:

• Make the current priorities visible, so any new ask has to be weighed against something concrete.

• Push the interruption to be an explicit decision: “we can do that, but it displaces X -- is that the call you want to make?”

• Capture recurring interruption types (like fan-out work) and treat the pattern itself as a problem to solve, not just each instance.

Firefighting vs Getting Ahead of the Fire

The other balance I’m constantly trying to strike: how much energy goes into firefighting for the team, versus getting ahead of the fires so they don’t start? When I’m spending all my time absorbing the chaos of the moment, I have nothing left to invest in preventing the next wave of it. And the fires my team isn’t directly working to put out -- those are exactly the ones I need to find capacity to address myself.

I’ll be honest about a compounding factor here, too. When I’m running multiple teams and I don’t feel like I have enough capacity on each one, that’s a huge contributor to exactly the scattered, randomized feeling the Reddit poster described. Fewer people to rely on means I have to context-switch even more. I have genuinely amazing people on my teams -- just fewer of them than I’d want to sustain everything without me jumping into the gaps. That’s nobody’s fault. It’s mostly the side effect of organizational growth, and it’s something I covered from the IC angle in More Experience, More Overwhelmed.

If Management Is the Promotion In Front of You

So let me bring this back to where the Reddit poster started. They framed it as a trap for managers -- losing the ability to hyperfocus the way they could as an IC. And honestly? I do miss some of that. But I’ve also found that I get a lot of that deep-focus satisfaction outside of work, and I genuinely enjoy it there.

The answer is going to be different for everyone, and that’s exactly the point. As you move up, the hands-on, heads-down portion of the job tends to shrink -- I talked about that reality in Senior Engineers Spend Less Time Coding. Management accelerates that shift even further. So if a management promotion is the thing being offered to you, don’t take it just because it’s labeled “the next level.” Understand that you’re signing up for a fundamentally different job -- one with friction coming at you from multiple directions, where success looks less like “I shipped this” and more like “my team shipped this without needing me.”

If that trade excites you, management can be incredibly rewarding. If the thing you love most is the deep technical flow, go in with your eyes open that you’re trading away a lot of it -- and know that there may be other ways to grow that keep you closer to it.

Final Thought

I’ll admit this one is a bit all over the place, because the topic genuinely is. The “management trap” isn’t really a trap in the sense of a mistake you fall into. It’s just the reality that management is a different role, with different rewards and different costs, and a lot of people step into it without anyone being honest with them about that tradeoff.

If you’re weighing this in your own career -- or you’re already in the seat and feeling the scatter -- I hope this gave you a more useful frame than “management good” or “management bad.”

And if you’ve got a specific situation you’re navigating, you can submit it anonymously over at codecommute.com, and I’ll try to make a video response.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• The list is infinite -- accept it and prioritize accordingly

• Lean into the work that actually energizes how you’re wired

• Pick the easiest task to break paralysis when overwhelmed

• Join me for the live stream (or watch the recording) on Monday, June 1 at 7:00 PM Pacific!

ADHD, Burnout, and Building a Career That Fits Your Wiring

This week’s Reddit thread is from the ExperiencedDevs subreddit, and it asks a question that I think a lot of people quietly wonder about: if you have ADHD, anxiety, depression, or some combination of those things, do you feel “nerfed” compared to your colleagues?

I want to be careful with this one. I’m not lumping these together because I think they’re correlated. They’re not. They’re distinct things that show up very differently in different people. But the question is real, and I have my own answer for parts of it, so I want to walk through what I’ve actually learned -- specifically as it applies to engineering work -- rather than offer abstract reflections.

I’m also going to be upfront: I’ve been diagnosed with ADHD. I’ve gone through periods of depression at earlier points in my career. I don’t have an anxiety diagnosis. I’m not a doctor, I’m not telling you what to do, and the words I use here come from my lived experience as an engineer and engineering manager. Take what’s useful and leave the rest.

You can check out my full thoughts on this in the video below:

Where This Is Coming From

When I made my video response to this Reddit thread, I just wrapped a two-week on-call rotation. On paper, my on-call shift is only six hours a day, Sundays off. In practice, between the team I manage and some adjacent security work that doesn’t really respect rotation boundaries, I ended up putting in 12-hour days for stretches of it. I’d wake up at 5:30 AM, dismiss the notifications on my phone, realize a few of them were actual things I needed to deal with, and effectively start work right there in bed. By the time my actual on-call shift kicked in at noon, I’d already been at it for hours.

By the time it ended, I was cooked. Sunday night I’m sitting at my desk -- the time I’m supposed to be working on the things I genuinely enjoy -- and I’m just holding my head in my hands. Nothing left. My wife walks in and asks what’s going on, because she can see it.

That conversation is what kicked off the reflection that this article is built on. So fair warning: a lot of this is from the freshly-burnt-out version of me. But honestly, that version of me probably has more useful things to say about this than the rested version.

The Infinite List Problem

Here’s the thing I keep crashing into: my life is lists. Whether it’s a whiteboard, a notes app, a backlog, or just in my head, that’s how I keep track of what needs to happen. And the lists never stop growing.

For most engineers, this is just reality. There’s no shortage of work. AI hasn’t shrunk the list -- it has expanded what’s possible to ship, which means more things go on the list, not fewer. The total work to do is effectively indefinite. I’ve made this point in the broader context before, in the More Experience, More Overwhelmed issue. The more senior you get, the more the list grows and the less of it you can personally close out.

This becomes a specific kind of problem if you’re wired the way I am. My natural posture is “get through the list.” And when the list is mathematically impossible to ever finish, you’re essentially walking around in a perpetual low-grade state of failure. My wife actually surfaced this one and it landed hard: she said the reason I struggle with this is that I take a lot of pride in my work. So an infinite, never-empty list becomes a constant admission that something is incomplete. It’s a treadmill that doesn’t stop.

I don’t know if there’s a clean fix for that. I haven’t found one. But what I have found are tactics that take the edge off.

Actionable Tip -- A few things that have actually helped me operate inside the infinite-list reality:

• Stop measuring success as “list empty.” Measure it as “right things done this week.” The shift is from completion to prioritization.

• Have a visible “top 3 today” outside the master list. When the master list is overwhelming, working only off the top-3 view for the next few hours is sometimes the only way to start.

• Pick the smallest task on the list when paralyzed. Yes, it’s the wrong task by priority. But the worst outcome when you’re frozen is doing nothing, and three small wins in 30 minutes often build the momentum to take on the big one.

• Audit the list itself periodically. Things on the list for 90+ days that you’ve never started are probably never going to get started. They’re noise. Move them to a “maybe-later” file and stop letting them haunt the active backlog.

The Paralysis Trap

The thing nobody warned me about with an overflowing list is that the most intuitive response -- “I have so much to do, I better get moving” -- is actually the opposite of what often happens. The brain can flip in the other direction and just freeze. You sit there, totally aware of how much there is, completely unable to start any one specific thing.

This is the part that feels backwards. If you have ten things you need to do today, doing zero of them should be the absolute worst outcome. And yet, when the overwhelm hits, zero is exactly where you can end up.

My only reliable counter to this is going small. Not “the most important thing.” Not “the highest-leverage thing.” The easiest, fastest, get-it-off-the-list thing. Even if it’s tiny. Even if it doesn’t matter much. Once one item is checked off, the next one feels possible. Once a few are done, sometimes the big one suddenly stops feeling like a wall.

This is related to the broader context-switching pain I talked about in The Context Switching Problem Every Dev Faces. The same thing that makes context switching expensive for everyone is what makes the “start small to build momentum” trick work for me -- once my brain is engaged on something, the cost of starting the next thing drops.

The Chaos-Is-A-Superpower Thing

Reading through the Reddit thread, the comment pattern I found most interesting was people with ADHD saying, basically, “put me in the firefighting role. Don’t put me in the planning meetings. I want the chaos because chaos engages me.” And then a wave of replies going “this is me, this is exactly me.”

I read that and went, really? But the more I thought about it, the more it tracks for me too. Security incidents and on-call escalations are exhausting, but they’re not boring. There’s urgency, something concrete to chase, a problem with a real shape. I find that engaging in a way that long quiet planning blocks aren’t. That’s not a moral statement. It’s just how my brain reacts.

The actionable version of this is: pay attention to which kinds of engineering work actually energize you vs drain you, and don’t assume the conventional wisdom about “good work” matches your wiring. Some examples of pairs I’ve noticed for myself and people I’ve managed:

• Deep architectural design vs. incident response -- both legitimate engineering. Some people light up at one, some at the other.

• Greenfield builds vs. complex production debugging -- some engineers go after these very differently.

• Long planning meetings vs. short focused syncs -- same content, different cognitive cost.

• Solo deep work vs. mob/pair programming -- some people get energized by one and depleted by the other.

None of those are wrong. None of them mean you’re a worse engineer if one drains you. But if you ignore the pattern and structure your week around the work that depletes you, you’re going to burn out faster -- and you’re going to do it while assuming the burnout is your fault, when really it’s just a workload mismatched to your wiring.

Don’t Confuse Burnout With “Just Tired”

One of the things I had to learn the hard way is that burnout doesn’t always feel like sadness. Earlier in my career, before I really had vocabulary for any of this, I thought depression looked like obvious sadness. It doesn’t always. Sometimes it’s just emptiness, or paralysis, or the feeling of having nothing left to give to the things you normally love.

Right now I’m not depressed, but I’d be lying if I said I’m not carrying some of the same flavor of that from the on-call burnout. The signal I look for: am I sitting down to do the work I genuinely enjoy and still feeling like I can’t engage with it? When the answer is yes for more than a couple of days, that’s not “I’m tired.” That’s something I have to actually address with rest, not push through.

This is where the Should You Talk To Your Manager About Burnout? issue becomes relevant. The short version of my answer there is: yes, but with framing. Don’t go in with vague “I’m tired.” Go in with “here’s the pattern I’m seeing, here’s the impact, here’s what I think might help.” That conversation goes very differently from the vent.

The same point applies for promotion timing, by the way. I covered that in Promotions Without Burnout -- the pattern of grinding yourself into the ground to earn a promotion and then arriving at the new level with no fuel left is one of the most common career failure modes I see. If your wiring is already prone to overwhelm, that path is even more dangerous.

The Randomization-Absorption Move (Manager Perspective)

This one is specific to engineering managers, and I think it’s the part of this conversation I have the most conviction about.

I want my team focused. I want them not getting randomized constantly. I want them clear on priorities so they can make their own decisions without me being in the middle of every call. That’s just good engineering management, and I talk to my team about minimizing context switching for them all the time.

But here’s the part that took me a while to admit: for me to protect them from randomization, somebody has to absorb it. And often, that somebody is me. When a security incident hits during their focus time, I’d rather take the initial triage hit myself than yank three engineers off what they were doing. When a request comes in from another team that’s going to derail an afternoon, I’d rather have the meeting myself than route it to someone who’s mid-flow.

This isn’t scalable forever, and it’s not the only tactic. But when push comes to shove, if my job is to protect their focus, then absorbing some of the chaos is part of that job. Which means I have to be honest with myself about my own energy budget -- the same things I tell my engineers about not running themselves into the ground apply to me too.

The related caution here, and this one is for both ICs and managers, is the Hidden Cost of Being the Team Hero. Volunteering to absorb chaos is a service to the team -- but if you become the only one who absorbs it, you’re building a fragile system around your own bandwidth. That’s a separate problem worth being honest about. By absorbing the chaos, you’re ideally creating more opportunity for the rest of the team to move past situations where you need to be absorbing that kind of chaos -- that’s how you scale out of it.

So Are You Nerfed?

Back to the original Reddit question.

My honest answer: not nerfed, but mismatched in certain contexts. Engineering work is wildly varied. Some of it lines up with how my brain operates and some of it actively fights against it. The job is not to fix my brain to match the work. The job is to understand the wiring, lean into the work that energizes it, build coping mechanisms for the work that doesn’t, and -- as a manager -- design roles where the people I work with get to do more of the former and less of the latter.

Actionable Tip -- A short reflection exercise. Spend 10 minutes thinking through this:

• Which two or three types of engineering work in the last 30 days made me lose track of time?

• Which two or three left me drained even though they were short?

• Is my current week structured more like the first list or the second?

• If it’s the second, what’s one thing I could shift this week to get closer to the first?

You won’t be able to fully optimize this -- the job has what it has. But even a 20% shift toward work that fits your wiring tends to compound over months.

Final Thought

I don’t have a clean wrap-up for this one. I’m sharing because the Reddit thread was honest and I think it deserves honest engagement back. If you’re someone in this space -- whether that’s ADHD, anxiety, depression, or just chronic burnout that you haven’t named yet -- I’d rather you know that the patterns I’ve described are real, you’re not making them up, and there are tactics that help. They’re not magic. They take attention. But they might help you out in your situation.

And if you want to send me a more specific scenario you’re navigating, you can submit anonymously over at codecommute.com and I’ll try to make a video response. I find these conversations a lot more useful than the abstract “advice for software engineers” stuff -- so the more specific, the better.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• When your ideas always get shut down, it’s rarely the ideas

• How you pitch them is the lever you actually control

• Genuine curiosity beats trying to win the argument

• Join me for the live stream (or watch the recording) on Monday, May 25 at 7:00 PM Pacific!

Why Your Ideas Keep Getting Shut Down

Another week, another ExperiencedDevs Reddit post that hit me a little harder than most. This time it was from someone who’s just exhausted from speaking up. They keep proposing ideas, the team keeps ignoring them, and they’ve reached the “why am I even bothering” stage. You can feel the defeat coming through the screen. That’s a pretty rough place to be in your job -- and it’s the kind of thing I think about a lot from the manager side too, because I genuinely need the people on my teams to feel like they can speak up.

But after digging through their post and the comments, I think most of the advice flying around misses the real lever. So let me walk through how I’d actually approach this if it were happening to me.

You can check out my full thoughts on this in the video below:

The Reddit Post That Got Me Thinking

The post itself doesn’t give a ton of context. The poster says they’re experienced on the team but not the tech lead, and they keep getting shut down when they propose ideas -- particularly around scoping and design. They feel like people are over-engineering or building things that don’t need to exist. The main concrete example they gave: their team wants to support multiple file formats when, in their view, the system only needs CSV.

That’s basically all we get. So I’m going to do what I usually have to do with these threads -- make some assumptions, walk through the most likely scenarios, and try to be useful even with incomplete information. If you’ve been here before, this is similar to how I worked through the post from someone telling their manager they were burnt out -- there’s only ever one side of the story, and you have to read between the lines a bit.

It’s Probably Not Your Ideas

Here’s the assumption I’m going to start with: statistically, this person doesn’t always have bad ideas. Nobody has only bad ideas. Some are going to be good, some are going to be okay, some are going to be off-base. That’s true for me, that’s true for you, and that’s true for the Reddit poster.

So if their ideas are being consistently rejected -- not occasionally, not in specific scenarios, but constantly -- the most likely explanation isn’t that the ideas themselves are uniformly bad. It’s much more likely that the way the ideas are being pitched is the problem.

I’ll use the file format example to walk through this. Imagine you’re in a design discussion and someone proposes supporting five file formats. You think it’s wasteful and unnecessary. You speak up:

“We don’t need that. That’s a waste of time.”

Now, you might be completely right. Maybe the team really doesn’t need it. But how does that land on the person who proposed it? They’ve now had their idea bluntly shut down with no engagement and no follow-up. They’re going to defend their position. The room is going to side with whoever feels more reasonable and can make a better case for their perspective. And you just lost a conversation you were trying to win.

I see this pattern a lot, and it shows up the worst in technical design debates where the answer genuinely isn’t clear-cut. I wrote about a perfect example of that recently in the Feature Slicing vs Clean Architecture comparison -- both are defensible, both have tradeoffs, and the “right” answer is contextual. If you come into that kind of debate with your mind already made up, you’re going to get rolled by whoever is willing to actually engage with the tradeoffs.

Try Genuine Curiosity Instead

The single biggest change I’d suggest if you keep getting shut down: lead with genuine curiosity, not your conclusion.

Same file format scenario. Someone proposes five formats. Instead of “we don’t need that,” try:

“Interesting -- what’s driving the need for the extra formats? Is this coming from customer requests, or is it more anticipatory?”

What does that buy you? Information you didn’t have before. Maybe they had a conversation with the product owner that you weren’t in. Maybe they’ve seen customer support tickets you haven’t seen. Maybe they’re just optimizing for “we’ll need flexibility later” with no real data behind it. You don’t know until you ask.

Actionable Tip -- A genuinely curious question has a few properties:

• It assumes the other person has a reason that makes sense from their seat

• It is asked before you’ve reached a verdict, not after

• It is phrased as a question, not a leading statement (”Why do we need this?” is leading. “What’s driving the need?” is curious.)

• You actually listen to the answer and let it change your position if the new information warrants it

And this last point is the one most people skip. If you ask a curious question, get new information, and still don’t even reconsider your position -- you weren’t being curious. You were performing curiosity to look open-minded before reasserting your original take. People can feel the difference.

The Goal Isn’t To Be Right

This sounds funny to say but, it’s the part that flips everything: the goal isn’t to win the argument. The goal is to deliver more value to your customers. Those are very different goals, and they pull you in very different directions.

If you’re optimizing to win the argument, you go in hard, shut things down, and protect your position. If you’re optimizing to deliver value, you go in curious, learn what the other side is actually optimizing for, and look for compromises.

In the file format example, that might look like:

“Personally, I don’t think shipping five formats is worth the time right now -- but I hear that flexibility matters to you. What if we shipped with the main format, but we put a thin abstraction over the file I/O so adding a second format later is a small change instead of a rewrite?”

Now you’re proposing a middle path that addresses both concerns. You’re optimizing for time. They’re optimizing for flexibility. The abstraction layer gives you both -- maybe. Now, my contrived solution might absolutely be the wrong move in some real scenarios. Sometimes the abstraction is more cost than the optionality is worth. The point isn’t that I cracked the technical answer in two paragraphs. The point is that the conversation is now productive instead of adversarial.

And from a team-dynamics perspective, this is the kind of behavior that builds trust over time. I wrote about this dynamic in the Effective Software Teams: Islands and Autonomy issue -- teams that work well aren’t the ones where one person is always right. They’re the ones where people actually engage with each other’s ideas.

When You Always Feel Unheard

If you keep walking out of meetings feeling like nobody listens to you, there are two scenarios I generally see:

1. Most of the time, you’re communicating in a way that’s getting in your own way. Your ideas might be great, but they’re landing as attacks, as shutdowns, or as “I’ve already decided and I’m now just informing you.” Fix the delivery and a lot of this changes.

2. Sometimes, the team really isn’t a fit. You can have the cleanest communication style in the world and still be on a team where people genuinely don’t want to listen. I covered the version of this where it’s specifically your manager who won’t engage in the issue on managers who refuse to give feedback -- that one has a different solution path.

The honest answer is that it’s almost always some mix of both. Some of it is on you, some of it is on the environment. The part you control is your delivery. Start there.

Actionable Tip -- Before you bring something up next time, ask yourself:

• Am I going in trying to be heard, or trying to be right? Those produce very different conversations.

• Have I actually asked the other side why they want what they want? Or am I just waiting for my turn to argue?

• If I’m wrong, am I prepared to actually update my view? If not, the curiosity isn’t real.

• Is there a middle path I haven’t proposed yet? Most “either/or” debates have a “both” answer hiding in them.

Don’t Give Up On Speaking Up

The thing I really don’t want anyone to take away from a Reddit thread like this is “well, I guess I’ll just stop speaking up.” That’s the worst possible outcome. As a manager, the people who quietly disengage are the hardest to help -- I can’t address what I can’t see. And as a teammate, that voice going silent makes the whole team worse.

There’s also a flavor of this where the person who keeps speaking up ends up shouldering everything because nobody else volunteers. That has its own downstream cost, and I dug into it in The Hidden Cost of Being the Team Hero. The fix isn’t “speak up less.” The fix is “speak up smarter, and don’t carry the team on your back while you do it.”

If you’re in this spot right now, please don’t give up on it. Try the curiosity angle for a few weeks. Try the middle-path framing. Pay attention to whether the conversations start landing differently. If they do, that’s your answer about what was actually going on. And if they don’t -- after you’ve genuinely changed your approach -- then yeah, you might be on a team that’s never going to hear you, and that’s a different conversation entirely.

Share

Leave a comment

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Reddit’s “just quit your manager” advice misses the nuance

• The real question is how much you actually care

• Level-set expectations in your 1:1s or stay frustrated

• Join me for the live stream (or watch the recording) on Monday, May 18 at 7:00 PM Pacific!

When Reddit Says Quit Your Manager

I came across a post over on the ExperiencedDevs subreddit where someone was venting about their manager. The usual stuff: incompetent, doesn’t really understand basic software things (the poster mentioned the manager doesn’t seem to know what Git is or what it’s used for), pulls people into endless pointless meetings where nothing gets decided, and ignores everything that comes up in 1:1s. The poster also mentioned this isn’t a one-off -- there are apparently three managers like this on their team. They wrapped it up by saying they’ve started interviewing and asked what else they could do.

The overwhelming response in the comments was exactly what you’d expect: “You don’t quit companies, you quit managers. Get out. Stop wasting your time.” And honestly, I don’t disagree with that as a general principle. But I also don’t love how black-and-white it ends up being when that’s the only advice anyone offers. So I want to walk through where I agree, where I push back, and the questions I think actually matter when you’re in this situation.

You can check out my full thoughts on this in the video below:

Where Reddit Is Probably Right

Let me get this out of the way first: a manager’s influence on your career is significant. I’ve been doing this long enough to see the inverse play out plenty of times. There are places I’ve worked where the company was great, the product was great, the people were great -- and a single manager change either elevated the experience or absolutely tanked it. I’ve never personally worked somewhere I thought, “Man, this company is garbage, but thank god I have a great manager.” That just doesn’t happen for me. But I’ve absolutely worked somewhere good and had a manager pull the whole thing down.

So the Reddit answer -- “your manager matters more than the company brand on your business card” -- I actually believe that. And for most people, in most situations, the “start interviewing” advice is probably the right move. Especially if you’re already burnt out and resentful, the amount of energy needed to drive change is energy you probably don’t have. That’s not a moral failing. That’s just reality.

Where I Start To Push Back

What bugs me is the binary on/off framing. Always jump ship. Never try to fix it. If everyone in a thread is piling on with the same advice, my instinct is to share the other angle -- because someone reading that thread might actually be in a different scenario where the right answer isn’t “leave.”

Let me exaggerate to make the point. Imagine you genuinely love the company. You believe in the product, you love your peers, you’ve been there long enough to have helped build the thing, and the opportunity in front of you is real. Then a new manager gets dropped above you and they’re just... not good. You can have bad hires at every level -- engineers, product managers, EMs, VPs, C-suite. People who interviewed great and turn out to be a disaster in practice. The decision-makers above don’t always see it, because the chaos doesn’t bubble up the way the interview signal did.

In that scenario, “just leave” is leaving a lot of value on the table. I’ve had moments in my career where a bad manager situation would have been the easiest excuse to jump, and I’m glad I didn’t. I worked through it, found ways around it, escalated where it made sense, and the long-term outcome was better than running. That’s not me saying I made the perfect choice every time -- I’m just saying that if “leave at the first sign of friction” had been my default, I wouldn’t be where I am today.

For more on the manager-perspective side of this, I dug into what new managers and leads typically get wrong in a previous issue -- worth a read if you want to understand what might actually be going on above you before you decide.

The Real Question: How Much Do You Care?

Here’s the question I’d ask instead of “should I quit?” -- how much do you actually care about this specific job, at this specific company?

Because the honest answer to that question changes everything that follows. If you genuinely care, then you probably do have the energy and motivation to try things first. If you don’t really care or don’t care enough for the amount of effort that goes into driving change, then sure -- the “start interviewing” advice is probably the right call.

And there’s no judgment in that. You’re allowed to not care or not care enough to pour more time and energy into something. People conflate “I should fight for this” with “I’m a good engineer,” and that’s not how it works.

The corollary: if you’re already burnt out and resentful, the amount of energy you have left to drive change is probably zero. I get into this in more depth in the issue on whether you should even talk to your manager about burnout, but the short version is: trying to fix a bad situation when you’re already cooked is a recipe for being even more frustrated. Be honest with yourself about which side of that line you’re on.

Build A Case Before You Burn It Down

If the answer to “do I care enough?” is yes, then the next move isn’t a heroic confrontation. It’s two things in parallel: support systems and evidence.

Actionable Tip -- Check your support systems in both directions:

• Up the chain. Who’s your skip-level manager? Do you have any working relationship with them? Are they someone who would back you up if you brought this to them with substance? Or are they the type to immediately tell your manager you complained?

• Across your peers. Are other people seeing the same things? You don’t want to get into “Bob sucks, let’s hate Bob” territory, but you can ask carefully -- “Hey, I ran into this situation, how have you been navigating it?” -- and see what comes back. If everyone else thinks things are fine and you’re the only one frustrated, that’s actual signal too. That’s not a fun signal, but it’s worth knowing.

The other half is evidence. When you go talk to your skip-level or HR or whoever, you want to be able to move past “I just don’t like working with this person” to “here are specific instances, here are the impacts, and here’s what I’ve already tried.” That’s the difference between a venting session and a conversation that can lead to action.

And just to set expectations: even with great evidence, your skip-level probably isn’t going to fire your manager on the spot. There’s usually a longer, slower process for things like this -- something closer to a performance plan than a phone call -- and often there’s still more observation, investigation, and understanding that goes into things. That’s not a reason to skip the conversation. It just means: don’t expect overnight magic.

There Are Always Two Sides To This

The Reddit post is one side of the story. The manager has the other side. And we have no way of getting that side, ever.

I’m not saying the original poster is wrong or making it up. I’d actually bet they’re doing a fine job and have a manager they genuinely don’t align with. But here’s the uncomfortable thing -- if we could call up that manager right now and ask “tell me about so-and-so and how the 1:1s are going,” we’d almost certainly hear a different story. Maybe a wildly different story. Maybe one where they think they are following up on things and the communication just isn’t landing the way the report thinks it is.

This is exactly why I wrote a whole issue on whether you can even measure manager effectiveness in any meaningful way -- because “this manager is bad” is a much harder claim to substantiate than people assume. And the things you’d use as evidence often look different depending on which seat you’re sitting in.

I’ve also been the person on the other side of “my manager won’t give me feedback” complaints. I unpacked the manager-side of that one in the issue on managers who supposedly refuse to give feedback -- there’s a lot of nuance that gets flattened when only one side gets to narrate the story.

None of this means your frustration is invalid. It just means: be careful about building a complete narrative when you only have half the inputs.

The 1:1 Problem Nobody Talks About

This is the part I think gets overlooked most often. The Reddit post says, “I bring stuff up in 1:1s and nothing happens.” Fair complaint on the surface. But let me walk through what might actually be happening.

You bring up a problem in a 1:1. Your manager listens, acknowledges how you feel, and you move on. Two weeks later, you bring up a similar problem. They acknowledge it again. Move on. You leave the second 1:1 thinking, “Okay, this is the second time and they’ve done nothing.” Meanwhile, your manager might be leaving the exact same 1:1 thinking, “Cool, they raised an issue and we talked about it. Glad they got it off their chest.”

You’re operating on totally different expectations. You think “raising it” means “they will go fix it.” They think “raising it” means “the person needed to vent and now we’ve vented.” Neither of you is technically wrong. You just never agreed on what was supposed to happen next.

Actionable Tip -- Stop ending 1:1s without explicit agreements. Try things like:

• “Can we talk about a plan for how we’re going to address this?”

• “What does the next step look like, and who owns it?”

• “By when should we expect to see movement on this?”

• “If nothing has changed in two weeks, what’s our follow-up?”

I went deep on this in a previous issue on getting the most out of your 1:1s, because honestly -- this is one of those things I see talented engineers under-leverage their whole careers. The 1:1 is your most direct, structured channel to your manager. If you’re walking out of every one of them with a vague sense of “well that didn’t go anywhere,” that’s a problem worth fixing before you start interviewing.

Wrap-Up

If your manager is genuinely bad, has no interest in changing, and your skip-level won’t back you up -- yeah, go interview. That’s a valid call and probably the right one for most people in that scenario.

But before you get there, ask the harder questions: How much do you care about this job? What does your support system actually look like? Have you built a real case with evidence? And most importantly -- are you and your manager actually operating on the same expectations in your 1:1s, or are you just both leaving with different stories about what happened?

Level-setting expectations and clean communication is, honestly, one of the biggest factors I’ve seen play out in software engineering careers. Everyone wants to argue about which language is best or whether AI is taking over. Meanwhile, the people who keep getting stuck are usually stuck on this. Get that right and a lot of the rest sorts itself out.

Leave a comment

Share

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Your start time isn’t the signal you think it is

• People will model whatever hours you actually keep

• Overcommunicate the expectation -- silence sets it for you

• Skipping the live stream one more week here... But I’ll be back!

What Your Working Hours Signal To Your Team

Someone over on the experienced devs subreddit asked a question that I think a lot of people quietly worry about: when managers or senior people see you coming in late and staying late, or coming in early and leaving early, what do they actually take from that? Is your start time saying something about your work ethic? And honestly -- I don’t think it’s saying what you think it’s saying. But there’s a different signal you’re sending (or that your manager is sending to you) that does matter, and most people miss it entirely.

You can check out my full thoughts on this in the video below:

What I Actually Care About As A Manager

I’ll just lead with this and get it out of the way: I genuinely don’t care what time you start or what time you finish. I care that you’re putting in honest effort, that you’re engaged in the work, that you’re asking for help when you need it, and that the output of you in your role is something we can work on together to optimize. That’s it. The clock-in/clock-out timestamps are not the thing.

The one thing I care about that is time-related is overlap. If you’re on a team of eight and seven of them have a sync at a certain hour, can you find a way to make that work? Maybe you literally can. Maybe you can’t and you partner with someone to represent you. Maybe you lean on async tools to catch the parts you missed. The answer almost always exists -- you just have to be an adult about it and figure it out with your team.

I’ve worked with people who needed to shift their schedule because they were taking a class, or visiting family on a different coast, or their parents were in town for two weeks. The answer is always the same from me: how can I help make this work? Because I want flexibility for my team. I think you get more out of people when they have flexibility, and I think they’re more engaged. The opposite -- being rigid about time -- creates resentment, fear, or quiet quitting. Pick your poison. None of those are good outcomes.

So if you’re sitting there worried that your manager is going to judge you because you walk in at 10:30 instead of 9:00, I would tell you: most decent managers don’t care, and the ones who do are usually using time as a proxy for something else they should just be measuring directly (which is its own conversation -- I went into that more in Measuring Manager Effectiveness on a recent issue).

Where The Perception Actually Comes From

Here’s where it gets more interesting, and where I think most people miss the real signal.

The perception around working hours doesn’t usually come from someone’s start time. It comes from the people they look up to. If your senior engineer is online at 10pm, or your manager is firing off Slack messages at 6am, you start to build a quiet model in your head: this is what success looks like here. Maybe nobody ever said it out loud. Maybe the manager would tell you with full sincerity that they don’t expect you to be online at 10pm. Doesn’t matter. The behavior is the message. People emulate what they see, especially from people they respect.

So you start asking yourself questions. They’re getting an extra two hours a day. They’re more senior. They’re probably smarter than me. How am I supposed to keep up? And whether or not that calculation is conscious, it shapes how you work, how you feel about your work, and how long you stick around before you burn out.

This is one of the most common patterns I see in newer leaders too -- they don’t realize the modeling effect their own habits have on the team. I wrote about this in Top Mistakes of New Managers and Leads and again in I Wish I Knew THESE Before Becoming A Manager. The same theme keeps showing up: the things you do without thinking about them become the rules your team thinks they have to follow.

My Own Trap (And What I Got Told)

I’ll be honest -- I’ve been on the wrong side of this. Going back to my startup days before Microsoft, I worked as much as I possibly could. Not because anyone made me. That’s just how I operated. And at some point I got told, more or less, “Hey Nick -- you shouldn’t work that much.” And the part I was hearing was “it’s not healthy” and that part I appreciated.

But there was a second part to it that took me longer to absorb: you’re setting an example, and people will model it whether you tell them to or not. The unspoken expectation on the team becomes the hours the most visible person is working. If you’re modeling 14-hour days and weekends, that becomes the standard people think they have to hit to be considered effective.

My initial reaction, embarrassingly, was “well that’s not my problem -- people are adults, they can make their own decisions.” Which is technically true and operationally useless. As a leader, it is my problem, because I do understand that people emulate behavior they look up to. I do understand that they form expectations I never said out loud. So pretending otherwise is just me being defensive about my own habits.

Actionable Tip: If you find yourself working long or unusual hours, don’t just hope your team interprets it correctly. Tell them, plainly, that your hours are not their expectation. Then back it up by reminding people to disconnect when they’re going outside the norm -- don’t force naything, just make space for them. The combination of explicit words and visible action is what actually shifts the perception. If you have a manager doing this and you’ve never asked them about it, that’s exactly the kind of thing to bring into your next one-on-one -- ask them directly what they expect of your hours and whether they’d actually prefer you sign off when your work for the day is done.

The Manager Who Got It Right

The cleanest example I’ve seen of this done well was from a manager I joined under. He had something in his email signature -- I’m paraphrasing -- along the lines of “my working hours are not a reflection of what your working hours should be” and another note about working with teams in different time zones. If you read that without context, you might think it’s a weird thing to put in a signature. The reason it’s there is exactly the perception problem I’m describing.

He was being very explicit about the unspoken expectation. Every email he ever sent carried that disclaimer. He was overcommunicating because the alternative -- staying silent and letting people draw their own conclusions -- always loses. People will fill the vacuum with assumptions, and the assumptions will skew toward “I should probably be doing what they’re doing.” So you fill the vacuum yourself, on purpose, with the message you actually want them to take.

This connects to a bigger truth I keep coming back to about the people side of this work: the soft skills that move you up are usually about being explicit about things other people leave implicit. Communication, expectation-setting, calling out the obvious that nobody else wants to call out. The stuff that feels almost over-the-top is usually exactly right.

A Funny Coincidence

This whole topic was on my mind because earlier the same day I recorded the video, I happened to be in the office on a Friday -- which not many usually do because, well, it’s Friday. I was making up for a day earlier in the week I couldn’t get in. Someone on my team was on a call with a colleague, and the person on the other end asked who was in the office. My teammate listed a few people, including me, and -- in a way they knew I’d hear -- said something along the lines of “yeah, because he’s a workaholic.”

It’s harmless. They were joking around. But it’s a really clean piece of evidence that the perception is real, regardless of how many hours I actually work (no one is timing me with a stopwatch). And it’s a useful reminder that if I don’t want my team to assume “this is the expectation,” I have to be even more deliberate about saying out loud what the actual expectation is. Otherwise the joke stops being a joke and starts being the standard -- and that’s what you’re trying to avoid.

Wrapping It Up

So if you take one thing from this issue, take this: your start time isn’t the signal. The hours you actually work, especially if you’re senior or in a leadership role, are the signal -- and they will set the bar for your team whether you intend them to or not. The best thing you can do is overcommunicate. Tell people what you actually expect. Send them offline when they’ve put their time in. Put the disclaimer in the signature if that’s what it takes.

And if you’re on the other side -- if you’re the person worried about how your hours look -- then have the conversation. Ask. Don’t carry around a perception in your head that nobody actually holds. The cost of asking is one slightly awkward minute. The cost of not asking is years of working to a bar that doesn’t actually exist.

Subscribe now

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Manager effectiveness is multidimensional -- technical, project, and people

• You can’t perfectly quantify it, but you can measure signals that matter

• Balancing delivery with people management is the real challenge

• I’m on-call this week -- no live stream. Sorry!

Can You Actually Quantify How Good a Manager Is?

A viewer recently asked me about how quantifiable manager skills are, and I think it’s a genuinely fascinating question. We can all think of managers we’ve worked with and immediately categorize them -- “that person was incredible” or “that person was a nightmare.” But putting numbers on why is a completely different challenge.

I wanted to break this down because I think it matters -- not just for evaluating managers, but for managers themselves who want to understand where they’re doing well and where they need to invest more time.

You can check out my full thoughts on this in the video below:

First, Set the Expectations

Before we can measure anything, we need to level-set on what’s actually expected of a manager. And this varies massively -- across companies, team sizes, and seniority levels.

My advice for level-setting expectations applies to managers too. If you’re thinking of moving into management or you’re a new manager, work with your own manager to understand what’s expected of you. That baseline matters because without it, you’re measuring against a target you can’t even see.

The biggest variance I see comes down to how much time you spend as a hybrid IC. At smaller companies or on smaller teams, there’s often more of an expectation that you’re hands-on in the code. It almost wouldn’t make sense to sit back and wait if you have a small surface area of people and technology. But as your scope grows -- more people, more product areas -- the balance shifts. You stop being the person fixing bugs and start being the person planning how work gets delivered and making sure the right skills are applied to the right problems.

I’ve lived this shift personally. Early in my career I managed a bunch of people at a startup on a single product, and I could code in any area because I’d been there since the beginning. Then at Microsoft, I moved into a deployment team -- a more focused scope, a codebase older than some team members -- and many of my hands-on strengths just didn’t apply the same way. The same thing happened when I moved over to the M365 routine plane -- and that’s not a failure. It’s what happens when your role gets more strategic.

The Three Dimensions of Manager Effectiveness

I think about manager effectiveness across three major areas, and the measurability of each is very different.

1. Technical Ability

This one is nuanced. It’s different to have domain knowledge of the codebase versus having system design expertise. I can tell you from experience -- there are potentially junior engineers on my current team who can find and fix a specific bug faster than I can, because they’re working in that code every day. But if you need help designing a system from scratch? That’s where broader engineering experience kicks in.

The measure isn’t “can you out-code your team.” It’s more like: can you take on ambiguous, complex technical challenges and deliver at a level comparable to senior ICs on your team? For some managers, the answer is yes. For others -- especially those managing larger or more diverse surface areas -- the answer is no, and that’s completely okay if other dimensions are covered.

Actionable Tip: If you’re a manager who’s lost touch with hands-on code, lean into AI tools. I’ve found that AI makes it much faster to get up to speed on unfamiliar codebases when you need to jump in. It doesn’t replace daily hands-on experience, but it dramatically shortens the ramp-up time.

2. Project Management

This covers prioritization, tracking progress, managing roadblocks, handling dependencies with partner teams, and making sure work is properly staffed. And not “staffed” in the gross “people as resources” sense -- I mean making sure you have the right mix of skills and experience applied to each problem.

Can you measure this? Sort of. You could look at whether deadlines are consistently hit, missed by a little, or missed by a lot. If you’re always off by 2x on a six-month project, something’s wrong. If you’re off by a week or two? That might be totally reasonable.

But the real signal is less about hitting exact dates and more about what you do when things are off track. The best managers I’ve seen raise awareness at the right time, engage the right stakeholders, and either adjust scope or adjust timelines -- so things still get delivered on an agreed-upon plan even if it’s been shifted. That’s incredibly hard to put a number on.

3. People Management

This is the one most engineers underestimate when they move into management. And honestly, from my experience working with other engineering managers, many still don’t realize this is fundamentally a people management job. That’s alarming to me.

Here’s what falls under this:

• Career growth -- are you helping people advance? Is there a reasonable promotion cadence on your team? Not everyone promoted every cycle, but also not nobody ever.

• Team composition -- do you have the right balance of levels, backgrounds, and strengths? You can’t build a team where everyone has maxed-out stats. That’s not real.

• Single points of failure -- if only one person knows a critical system, you need a plan. That’s the lottery effect (or if you prefer the darker version, the bus effect).

• Engagement -- are people actually interested in their work? Do they feel supported?

That last point is critical. If you’re hyper-optimizing for delivery by always slotting your best person into the next highest-priority task, you’re probably ignoring whether your team is burning out. That person keeps getting siloed. Maybe they don’t even want to do that work anymore. Maybe other people on the team want the opportunity. You can’t ignore the people side just because the delivery side looks efficient on paper.

Actionable Tip: If you think supporting your employees detracts from delivery, you’ve got it backwards. A team full of people thinking “screw this place, no one cares about me” is not going to deliver great work regardless of how cleverly you assign tasks.

So How Do You Actually Measure This?

Here’s my honest answer: there is no single tool or system that gives you a clean numeric value across all of this. But there are signals you can look at.

• Promotion cadence -- are people progressing at a reasonable rate? If it’s zero or 100%, something’s off.

• Employee satisfaction surveys -- at Microsoft we have a signals survey with a “thriving score.” It’s not perfect science, but it gives you a quantitative read on whether your team is engaged.

• Deadline accuracy -- not whether you hit every deadline perfectly, but whether the variance is reasonable and whether you course-correct effectively.

• Technical contribution -- if you’re still expected to be hands-on, can you handle complex work at a level that matches your most senior ICs?

• Team resilience -- do you have the right mix of experience levels and no single points of failure?

The important thing is that you’re not measuring to game a target. You’re measuring to understand where you need to invest time. If nobody’s getting promoted, that’s a signal. If everyone is but your delivery is suffering, that’s also a signal.

It’s Going to Look Different for Everyone

Is it possible to come up with some type of assessment for manager effectiveness? Sure, I think so. But it’s going to look different depending on your seniority, your team composition, the lifecycle of your product, and a dozen other factors.

And that’s actually fine. The point isn’t to come up with a universal manager score. The point is to be aware of the different dimensions, check your signals, and course-correct where things are off.

These are my opinions from 13+ years of frontline engineering management. Your experience might tell you something different, and I think that’s a valuable perspective -- so leave me a comment to let me know!

Share

Leave a comment

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!