Skills No Degree Covers

What My Grandmother and Mother Actually Taught Me

No university course prepared me for the moment a senior engineer quit on a Thursday afternoon, three weeks before a major product launch, and the entire team looked to me for what to do next. What prepared me was a woman who woke up at 5am every day to run a small business out of her kitchen, and another who never once cut a corner even when no one was watching. My grandmother and my mother were my first engineering mentors — they just didn't know it.

My grandmother ran a tailoring shop in a small town where reputation was the only currency that mattered. She had a saying she repeated so often it became ambient noise: 'If your name is on it, it has to be right.' She wasn't talking about clothes. She was talking about integrity as a professional operating system — the kind that doesn't require a manager to activate.

My mother worked in administration for twenty years and was passed over for promotions more times than I can count. But she never delivered a document with a typo, never missed a deadline, never let a bad week become someone else's problem. I watched her and internalized something that no MBA program teaches explicitly: consistency is a form of leadership, even when no one gives you the title.

These two women handed me a framework before I had the vocabulary to name it. What I later recognized — after years of leading engineering teams, making hiring decisions, and watching talented people derail — is that they were teaching me character architecture. The structural stuff. The load-bearing walls of a professional identity that could actually hold weight under pressure.

Done Right — If You Do It, Do It

The most dangerous engineer on any team is not the one who lacks skill. It is the one who treats quality as conditional — who does good work when it is visible and cuts corners when it is not. I have seen this pattern destroy codebases, erode team trust, and quietly poison engineering cultures that took years to build. The damage is rarely dramatic. It accumulates in the dark.

Early in my career, I was asked to write a data migration script for a system that 'nobody really uses anymore.' I could have written something quick and dirty. Instead, I treated it like it was going into the core product. I documented it, tested edge cases, added logging. Two years later, that system turned out to be the foundation for a compliance audit that the company desperately needed to pass. The script I wrote was the only clean artifact in the entire data layer.

This is what 'done right' actually means in engineering leadership: you build the habit before you know the stakes. You cannot decide in the moment to care about quality — by the time the stakes are clear, the decision has already been made by the version of you who was working alone at 11pm with no one watching. That version of you is who you actually are.

As a CTO, I started screening for this pattern in interviews by asking candidates to describe the last time they refactored something that was already 'good enough.' The answers were extraordinarily revealing. Engineers who had internalized quality as identity would light up and go deep. Engineers who treated quality as a performance would give vague answers about team standards and code reviews — external validators, not internal ones. The difference between those two types of engineers, compounded over three years on a team, is the difference between a codebase you can scale and one you have to rewrite.

The principle my grandmother gave me — your name is on it — translates directly into engineering culture. When a team believes that every commit, every PR, every architecture decision carries personal weight, the quality floor rises without anyone having to police it. That is not a process problem. That is a character problem. And character, unlike process, does not require enforcement.

Courage — Action First, Explanation Later

There is a particular kind of paralysis that strikes technically excellent engineers when they step into leadership. They have spent years in a domain where the right answer can be derived, proven, and defended before execution. Leadership does not work that way. Leadership requires you to move before the information is complete, before consensus is formed, before you are certain you are right. Most people are not trained for this. Most people freeze.

I learned courage not from a leadership seminar but from watching my mother handle a situation where the organization she worked for was about to make a decision that would hurt a lot of people. She did not have authority. She did not have a title. She walked into the director's office and said what needed to be said, clearly and without hedging, and then she walked back out and waited. She was right. And even if she had been wrong, the act of speaking was the right move. That distinction — between the outcome being right and the action being right — is one of the most important things I have ever learned.

In engineering leadership, courage looks like calling out a bad architectural decision in a room full of people who have already emotionally committed to it. It looks like telling your VP that the roadmap is not achievable without trade-offs they have not accounted for. It looks like having a performance conversation with a senior engineer three weeks earlier than feels comfortable, because waiting will cost the team more than the awkwardness costs you.

Action-first courage is not recklessness. It is the recognition that delay is also a decision, and usually a worse one. Every week I waited to have a hard conversation with an underperforming team member was a week the rest of the team watched me not act, and adjusted their own behavior accordingly. Teams read their leaders constantly. When you hesitate on a hard call, they do not see caution — they see avoidance. And avoidance is contagious.

The most effective engineering leaders I have worked with share one behavioral pattern: they compress the gap between recognizing a problem and acting on it. They do not wait for perfect information. They do not wait for the right moment. They move, they communicate, they adjust. That compression is not a personality trait you are born with. It is a muscle you build by practicing action in small, low-stakes situations until it becomes your default response to discomfort.

Why These Skills Do Not Appear in Job Descriptions

Job descriptions are written to filter for competencies that can be verified in a 45-minute technical interview. You can assess algorithmic thinking. You can assess system design. You can even get a rough signal on communication. What you cannot assess in a standard interview loop is whether someone does their best work when no one is watching, or whether they will act with courage when the room is uncomfortable. These are the variables that actually determine team outcomes over a 12-month horizon.

The engineering industry has a long history of promoting people based on technical excellence and then being surprised when they fail as leaders. The assumption embedded in that practice is that leadership is a layer you add on top of engineering skill — a set of techniques you can train in a workshop. It is not. Leadership is an expression of character, and character was formed long before the person walked into your org. What you are hiring is the accumulated result of thousands of small decisions that person made when they had no audience.

I have watched brilliant engineers fail as tech leads not because they lacked knowledge but because they lacked the structural soft skills — the internal standards, the courage to act, the consistency under pressure — that make technical knowledge actually useful to an organization. And I have watched engineers with average technical profiles become exceptional leaders because those structural qualities were load-bearing in everything they did.

The industry is slowly waking up to this. Behavioral interviewing has improved. Reference checks have gotten more serious. But the fundamental problem remains: we are trying to assess character with tools designed to assess competency. The signal-to-noise ratio is terrible, and the cost of a wrong hire at the senior level is measured in team years, not quarters.

How Personality Science Changes What You Can See

This is exactly why HEXACO-based personality science is not a soft HR tool — it is a structural engineering instrument. The HEXACO model captures dimensions of personality that are directly predictive of the behaviors that make or break engineering teams: Honesty-Humility, which maps almost perfectly to the 'done right' principle my grandmother embodied; Conscientiousness, which predicts whether someone will maintain quality standards without external enforcement; and Emotionality and Agreeableness, which shape how a person handles conflict and pressure in collaborative environments.

What LU Teams does with this framework is give CTOs and VPs of Engineering the ability to see team dynamics before they become team problems. When you understand the HEXACO profiles of the people on your team, you can predict where friction will emerge — not because you are labeling people, but because you are understanding the structural properties of the system you have built. A team with three high-Conscientiousness engineers and one very low-Conscientiousness engineer has a specific, predictable tension point. Knowing that in advance is not surveillance. It is engineering.

The soft skills my grandmother and mother gave me were, in HEXACO terms, high Honesty-Humility and high Conscientiousness expressed as lived behavior. They did not have the vocabulary. But the pattern was clear and consistent and it shaped everything I did as a leader. Personality science gives organizations the ability to identify those patterns early, before three years of team damage makes them obvious in retrospect.

The leaders who will build the best engineering organizations in the next decade will be the ones who treat team composition as a design problem — with the same rigor, the same intentionality, and the same evidence-based discipline that they bring to system architecture. Soft skills are not soft. They are structural. And like all structural elements, they need to be understood before the building goes up, not diagnosed after it starts to crack.