Leaving Paris
I left Paris and came to the United States because I wanted to work in an environment that valued efficiency and outcomes. I was drawn to a practical way of working: decide what matters, build, and judge the result by what it accomplishes.
More freedom and lower taxes were also part of what I was looking for. I wanted more control over what I built and how I spent my time and money. The maker mentality appealed to me: take initiative, try things, and turn ideas into something useful.
I also wanted to maximize my learning. Being close to people building technology meant more opportunities to work on difficult problems, get direct feedback, and learn from different approaches. I wanted learning to be part of the work I did every day.
Hiring
Hiring engineers is an attempt to find the right combination of talent, motivation, and commitment. I think of talent as shaping the rate at which someone can learn and create more value. Motivation determines how much of that ability they apply. Commitment gives that growth time to compound.
By commitment, I do not mean loyalty for its own sake. People do their best work when they have enough time to understand the company, build judgment, and learn from the consequences of their decisions. The company has a responsibility to create an environment worth staying in and to keep earning that commitment.
The difficulty is that an interview is a short sample of what may become a long working relationship. In that limited time, I am especially tuned to passion, curiosity, and an engineering mindset. I want to understand what draws someone into a problem, how quickly they learn, and whether they care enough to keep looking after the obvious answer.
I like to start with something a candidate knows well and ask progressively deeper questions. A few follow-ups often reveal how thoroughly they understand their work and what interests them enough to keep digging. I am skeptical of LeetCode-style questions as a way to identify good engineers. I prefer logic problems that let me see how someone structures their thinking. Can they follow an argument through to its conclusion? What happens when I offer a counterexample?
Those abilities matter even more with AI tools. AI can produce a plausible answer quickly, but the engineer still has to examine the reasoning, find weak assumptions, and test counterexamples. I look for people who can use the tools without giving up the judgment that makes the result trustworthy.
Product strategy
I often disagree with product directions that sound like common sense, especially when the argument begins with what other companies in the industry offer. I want to test whether a product creates real value and whether our ability to create that value can compound. Revenue and stickiness matter, but they do not make a product strategically strong on their own.
The 7 Powers framework helps me think about what can actually become durable. A smaller company rarely begins with scale economies, a strong brand, or network effects. Counter-positioning can be more accessible because an established competitor may be unable to copy a new approach without damaging its existing business. Process power is also possible when years of operating choices become a system that is difficult to reproduce.
Technology can sometimes provide a cornered resource, such as an exclusive asset or a capability that others cannot readily obtain. But one technical improvement usually creates a head start rather than a lasting moat. Competitors can copy it, hire around it, or reach a similar result another way. The more durable advantage comes from what the company learns next.
Bruce Ge describes deep technical advantage as something built through many sequential research and engineering decisions over years. I think of it as building a mountain one brick at a time: each result changes which question should be asked next. Capital can fund more people and parallelize some work, but it cannot buy elapsed time or fully compress learning when tomorrow's experiment depends on today's result.
That accumulated capability creates resilience because it lives in tools, judgment, data, and thousands of decisions that are difficult to reconstruct from the outside. It also explains why people specialize and why they join organizations already close to a frontier. Reaching the frontier requires the base that others have spent years building.
In recruiting advertising, I apply this test to the path from scarce job-seeker attention to hires. An applicant tracking system may be sticky, and a resume database may create revenue, but neither necessarily strengthens our core capability. I am more interested in products and signals that help us turn attention into better hiring outcomes, then make us better at doing it again.
The poison of switching costs
Switching costs are a powerful moat, but they can also make a company worse over time. When customers keep paying because leaving is difficult, revenue becomes less connected to product quality. The company loses some of the pressure that keeps it sharp.
At Talroo, we avoid long-term customer contracts. There is a real tradeoff here. Predictable cash flow contributes to a company's value, and short commitments make that predictability harder. But they also force us to keep earning our customers' spend through the quality of our product and service.
I think the same principle applies to the software we buy. A large annual commitment, especially one that exceeds our actual usage, weakens the incentive to optimize. Once the money is committed, waste becomes easier to tolerate.
I want us to preserve the pressure to improve. Engineers should always have a reason to reduce costs, raise standards, and adapt. Some uncertainty is healthy when it keeps us honest.
Advertising
When ChatGPT first appeared, I worried about what it might mean for job advertising. If people began their job searches inside an AI assistant, they might never reach Google or the sites that had traditionally connected employers with candidates. It seemed possible that a change in interface could weaken much of the existing industry.
I have become less worried about the underlying economic function. Human attention is scarce, and employers will continue to pay for a chance to reach the right person. In that sense, attention is closer to land or gold than to a particular technology: its value comes partly from its limited supply.
What may change is where that attention is found. Job advertising has often lived in search engines, but it could move toward AI assistants, social networks, or whatever environments people spend time in. The distribution channel may change substantially even if the need to earn attention remains.
Improving engagement and application rates can make that attention more productive. But removing every step can make it easier to submit applications with very little intent. A higher conversion count can hide a worse outcome for the employer. Some friction is useful when it shows that a person has considered the opportunity.
I distinguish the durable function of advertising from its current form. Search advertising is one implementation of a broader market for attention. I do not know which interfaces will dominate, but I expect employers will keep paying to reach people wherever their attention moves.
Communication
I think of a company as an organism. The CEO, or whoever is coordinating a decision, needs information to move through it quickly. Upward communication matters because a blocker in one part of the company may be easy to solve somewhere else.
Good updates also create the peace of mind that makes delegation possible. When someone communicates progress without being asked, the manager can focus elsewhere with confidence that the work is moving. A useful update answers the status question before it needs to be asked.
I tell engineers that promotion requires creating value and communicating value. The work has to matter, and other people need enough visibility to understand its effect. Doing useful work matters, but career growth also depends on making the work and its impact visible.
I have come to see proactive communication as a management responsibility. I try to practice it consistently and make it a habit across the company.
Principles for engineers
When I asked myself how to become a better manager, I wrote down the behaviors that had helped me earn trust and get promoted. These are the same principles I ask engineers on my teams to develop. Together, they describe how I think engineers create value, work well with others, and become people the company can rely on.
- Start with business impact. Technical work matters when it improves the company or the customer experience. Understand the outcome you are trying to create before choosing what to build.
- Stay curious and keep learning. Seek out better tools and ways of working. Test them, form your own judgment, and share what you learn. This matters especially with AI, where the tools often move faster than established practices.
- Collaborate early. Bring other people in before uncertainty becomes rework. Ask for input, share unfinished thinking, and solve difficult problems together.
- Plan before you build. Clarify the problem and sketch the system before writing code. A short conversation, a whiteboard session, or a clear diagram can prevent days of unnecessary work.
- Practice craftsmanship. Treat working software as the starting point. Pay attention to reliability, clarity, usability, maintainability, and the details that determine whether the result is truly complete.
- Take ownership. Finish what you start. Follow the work through to its real outcome, and surface blockers early enough for other people to help.
- Communicate proactively. Listen carefully, ask clarifying questions, and confirm shared understanding. Keep people informed about progress, decisions, risks, and blockers before they need to ask. Career growth depends on creating value and making that value visible.
- Think in systems. Look beyond the task in front of you. Ask whether the underlying process could be simpler, faster, more reliable, or automated. Fix patterns, not just individual symptoms.
Learning and doing
My natural instinct has always been to understand a problem deeply before acting. That instinct has served me well, but it can also become a way of postponing the moment when an idea has to meet reality.
Jim Keller influenced how I think about this. A useful question is: if I understood this better, would it change the decision? Sometimes the answer is yes, and further study is worth the time. When the answer is no, the next step is usually to act, observe what happens, and learn from the result.
Augustus Intelligence made this tension concrete for me. The AI team was largely oriented toward producing research papers and was somewhat disconnected from the product. The research itself could be strong, but there was often no clear path from new knowledge to something useful for customers. That separation was one of several factors that limited the company's ability to turn its technical work into results.
I began my career with a stronger bias toward learning. Over time, I have learned to balance understanding with action. Learning matters most when it improves a decision, changes what we build, or helps us produce a better result.