A Scientist’s Guide to Debugging Engineers
Too often, I see smart engineers making their own lives much harder than they need to be. Engineers are analytical people. They focus on actions, technical skills, and processes.
Feelings are for softies.
The reality is that your nervous system is part of your engineering tools, and is probably even more important than any other skill.
Nobody can operate at their best when their body thinks they are in danger. When your engineers are tense before a standup, exhausted after a sprint, or frustrated because of poor decisions, it has a huge impact on basically everything.
Feelings are signals.
The dashboard of your car has indicators to show when something is going on. Your body has feelings. Leaving them unaddressed can get very expensive.
In today’s guest post, I brought Marcel Tella to share his unique experience.
He spent almost a decade as a scientist, then a software engineer, and in the last couple of years shifted into coaching engineers and EMs.
He’s obsessed with figuring out why people do what they do and why they get stuck, and I love the fresh perspective he brings :)
One of your jobs as an EM is to actually listen to those feelings and help your engineers understand what needs to be changed.
When you ask someone, “How did you feel this week?” and give space for a meaningful answer (by staying silent), interesting things will come up.
Here are 3 common patterns I’ve encountered:
1. The super-responsive engineer
In almost every team there is an engineer who is known for being extremely responsive. Always quick to answer questions and jump in to help.
In my sessions with one such engineer, he kept coming back to the same thing:
“I’m tired all the time. I finish the day, and nothing really feels done.”
When we looked at his week together, it was quite easy to see that his days kept getting broken up. A bit of work, then an interruption, a quick reply, then back again.
When I asked him: “What do you feel if you don’t respond right away?”
His answer was: “It feels bad. Like I’m letting people down.”
Being constantly available was his way of being a good teammate, he felt that this was the way to be appreciated.
In the following weeks, he opened up about this dilemma with his EM. He is an important part of the team, and people depended on him, but it didn’t mean he needed to be available 24/7.
They started with a relatively small change - a two-hour focus block each day.
The engineer felt uncomfortable at first, as people were used to his instant availability (and he was afraid of the reaction), but everyone adapted quickly.
After a couple of weeks, he felt way more productive and also had more energy at the end of the day.
2. An always-late engineer
Every manager has dealt with well-intentioned and ambitious engineers who never finish what they plan.
One engineer I worked with was very frustrated about this behavior. He was sick as being the ‘late one’, but just couldn’t change it. After years with the same pattern, he actually saw himself as someone who never finishes. His whole system was prepared for failure.
When I asked him:
“When you think about feeling good about your work, how do you imagine it?”
He answered that feeling good was completing a meaningful amount of work, and proving he was a strong engineer. He was stuck in this loop of wanting to prove himself, feeling that ‘next week it’s going to work out!’
He was basically planning for the engineer he wished he was, not the one he actually was.
To actually change that, he needed to drop his ego and plan more conservatively. We created a simple plan: reduce the daily scope and add one rule:
“I plan precisely, and finish what I plan”.
It felt uncomfortable to plan so little, but when he continuously crossed every item on that list, his perception of himself started to shift. Slowly, he saw himself as “the one who finishes what he plans”.
Within weeks, he proved to himself that this could happen, and his reliability became something his manager could feel.
3. An engineer with Messy PRs
Another engineer I worked with had a different problem: her PRs were always messy, with lots of comments and re-reviews, despite a relatively stable workload. She wanted to improve, but felt stuck.
As we got to talking, I got the sense she was not very comfortable at her workplace. I asked her about that fear, and we realised that she felt judged all the time.
Even small errors triggered that subtle fear. She woke up tense, sat down already rushed, and described it as: “starting the day feeling behind”.
She had difficulty keeping attention, skipped checks, and reread lines without absorbing them. The stress of making mistakes made her make more of them. She had the skills, but it was her body going into protection mode before her mind even noticed.
In her next one-on-one, she shared some of her feelings with her manager. She had the luck of working with a good one - they appreciated her opening up, and it led to a very productive discussion.
Almost right after that, the fear dropped, and her PR quality improved. Instead of always being on the defensive, focusing on what others will say about her code, she felt more comfortable as part of the team.
Final words
Software engineering tools are getting more and more powerful, like Cursor and Claude Code. Still, the most important tool your engineers bring to work is their nervous system.
It’s easy when your engineers bring those topics to the table (as in the examples above), but in 90% of the cases, they won’t.
It’s your job to try to help them notice the patterns that hold them back.
Don’t shy away from talking about feeling, touching the softer part of their work. It can have much more impact than any skill improvement.
Marcel here, founder of Inspiring Personal Growth. I work with software engineers who are high-performing on paper but feel mentally overloaded, disconnected, or stuck despite doing everything right. If this resonates and you want to do excellent work without burning yourself out, feel free to message me.
Disclaimer: All cases in this article combine elements from real client situations. Details have been modified to protect anonymity while preserving the patterns and insights.