I've had the privilege of working with seven startups and have interviewed hundreds of engineers. I've hired many and promoted less. The truly exceptional engineer is differentiated not by their technical prowess but by a broader set of skills. Sure, you may need an exceptionally talented ML engineer to build a foundational AI model. To build truly great products you need an engineer with what I like to call The Spark. In the age of AI, your ability to transcend code and collaborate with your wider team is going to be far more important.
Coding Spark
AI facilitates quality and productivity and reduces the chores involved to deliver value. These levers are typically sacrificed to meet time-boxed customer deadlines. I need a quick script to migrate a database, AI done. I need to set up a local DevEx environment, AI done. I need to write a bunch of tests, AI done. With increased efficiency and with the removal of the coding bottleneck, there is less room for excuses when it comes to these key value-adds.
The top 1% of engineers treat every pull request like a published paper — it tells a journey of discovery. It should read like prose with all the usual clean-code guidelines. Commits tell a story, not "WIP blah." AI enables this behavior. The code you write shapes the team around you, inspires junior engineers, and sets the team up for success. Your code is your reputation. Every function you write is your signature. The standard should be: would I stake my name on this? I personally have two high-level directives when writing code: make it readable, support the future reader; and leave it in a better state than you found it.
Team Spark
I prefer to golf, do martial arts, snowboard, and work with people who are exceptional. These people inspire me to do better. If I can surround myself with excellence, it's infectious. The converse is also true — mediocrity breeds mediocrity, fast. The moment a senior engineer starts cutting corners on code reviews, the whole team's quality drops within weeks. Conversely, when a tech lead insists on thoughtful architecture discussions before writing code, the entire team starts thinking more deeply about design.
The personal standard of surrounding yourself with people who challenge you translates directly to engineering teams. The best teams I've built shared these characteristics:
- Psychological safety to say "I don't know" or "I was wrong." The smartest person in the room isn't the one with all the answers — it's the one willing to ask the hardest questions.
- A culture of constructive dissent. If everyone agrees immediately, someone isn't thinking hard enough.
- Celebration of craft, not just output. Shipping fast matters, but shipping well matters more in the long run. There are some interesting caveats here when it comes to unknown features and company stage.
- Mentorship as a core value, not a side project. The best engineers multiply themselves by elevating others.
As a leader, your job isn't to enforce standards through process. It's to embody them so consistently that they become the water your team swims in.
Wellness Spark
Here's something I rarely see discussed in engineering circles: personal discipline is the bedrock of professional excellence. How you show up in your life is how you show up in your code. The engineer who consistently exercises, sleeps well, and manages their energy isn't just healthier — they're sharper. They make better architectural decisions at 4 PM because they're not running on Monster energy drinks. They handle production incidents with calm precision because they've trained their nervous system through discipline in other areas of life.
Sacrificing your physical health and work-life balance has long-term life-debt consequences which can be withdrawn from in the short-term, but like technical debt will eventually require repayment. I work hard, very hard. In every company, when I am there, I am working, focused, aligned on the mission. But I also ensure I am sleeping and exercising well and feeding my body with a balanced nutritious diet. Without this sounding hokey or new-agey, the advice is simple: it keeps my mind balanced and enables me to think and work in high-pressure environments. It fuels my best technical and leadership decisions. The standard is simple: take care of the machine that writes the code. Your brain is your most valuable tool. Treat it like one.
Learning Spark
Technology moves fast. The framework you mastered two years ago might be legacy today. The architecture pattern everyone swore by is now considered an anti-pattern. This is the reality we work in, and the top 1% of engineers don't just accept it — they thrive in it. Adopting every Red Hat, Microsoft, Google, or AWS technology blindly doesn't cut it. Without continuous learning we aren't sharpening our technical chops. Continuous learning isn't about chasing every new JavaScript framework. It's about developing a deep understanding of fundamentals while staying curious about what's emerging.
AI enables this by allowing you to research technical concepts and easily ask questions; you can validate those decisions with industry trends. Then you can validate them quickly with PoCs to try before you buy. I can do things in hours and days that used to take weeks and months. The standard: dedicate time every week to learning something new. And as I tell my kids, if you aren't doing something that makes you uncomfortable, you're always in your comfort zone and therefore you're not growing.
Ownership Spark
This might be the most important standard of all, and it's the one I see failing most often in engineering organizations. Accountability means owning outcomes, not just tasks. It means when the deployment fails at 2 AM, you don't point at the infrastructure team — you ask what you could have done differently. What can you drive to improve the process? How can you enable others to do what was missed? When the project misses its deadline, you don't blame the PM for changing requirements — you ask why you didn't flag the risk earlier.
The top 1% of engineers practice radical accountability. They don't hide behind process, hierarchy, or ambiguity. They say:
- "I made a mistake. Here's what I learned, and here's how I'll prevent it next time."
- "That's not in my job description, but it needs to get done, so I'll handle it."
- "I don't have enough context to make this decision well. Let me go find out before I guess."
- "The system I built has a flaw. Let me be the one to fix it."
Accountability isn't about blame. It's about ownership. And ownership is what turns an individual contributor into a force multiplier.
The Spark
Holding high standards can be hard but the reward is fulfilling. When you work in a team of high standards, you feel like you are building something special. Every decision you make, day in and day out, impacts all of us in interconnected ways. Every day you choose to write clean code, go to the gym, ask the right questions, and investigate new technologies, you are building a long-term habit brick by brick. There are ripple, butterfly, and force-multiplier effects that will elevate you and inspire your peers. The engineers who reach the top 1% aren't doing anything magical. They're doing the bare minimum extraordinarily well and consistently. Doing it when they are observed and especially when they are not. A lot harder in our modern remote workplaces.
Good Process, Architecture, and Measurement flow from Good People. They are defined not by their raw intelligence or their years of experience, but by the standards they choose to hold themselves to and how they interact with their fellow teammates. They bring it to work day in, day out — I call this The Spark.
What are your standards? What are your Prime Directives?