After Leaving Google, My Definition of Good Work Changed

I left Google in July 2024. Before that I worked as a software engineer at Salesforce and then Google. Now I build CollabOps, meet customers, and set the direction for the team and the product. The title changed, and so did the questions by which my work gets judged.

The things I valued as an engineer still matter. Understand the problem precisely, build a structure that can be maintained, explain it so colleagues can review it, confirm it in production. That way of thinking helps me almost every day since founding the company.

What changed is that the problem sitting in front of all that became my responsibility too.

What is the difference between an engineer and a founder?

Whether the problem is handed to you or chosen by you. Which customer problem to solve, why it has to be solved now, how far to build. As an engineer, someone else had already answered those questions. Now I have to answer them, and no matter how sound the technical choices are, if those questions stay blurry there is no way to tell whether the company is moving forward.

Honestly, I underestimated this difference at first. Change the code and the effect is visible right away. Understanding what makes a customer buy takes conversations, and the answers come slowly. But the information that matters most for setting a company's direction turned out to live mostly inside those slow conversations. That is how I learned that the work that is easy for me to control and the work the company needs are not always the same thing.

Does building more features make the product easier to explain?

No. It makes the explanation longer. I am comfortable showing what we built. Issue tracking works, code review works, pipelines run. But why a customer should change their existing environment and pay for a new product needed an answer separate from the feature list.

That answer came from asking which decision the customer currently finds hard to make. In our case it was "can this change go to production," and gathering the evidence for that decision in one place became the center of the product. I wrote about that process separately in We Added Features, and Explaining Why Us Got Harder. The experience of building many features remains an asset. Deciding which problem to point that asset at was a separate job.

Is it good when the founder handles things quickly themselves?

Not if the same thing ends up waiting on the founder again next time. Leading the team went through a similar shift. Solving problems I can solve directly is still necessary. At the same time, leaving behind the context and criteria that let the team judge on its own became more important.

Take a screen whose purpose is unclear. One option is to fix the copy myself. Ten minutes. Another is to sit down with the team and write out the first question a user is trying to answer on that screen. An hour. The second output stays with whoever builds the next screen. I think what a founder produces has to include those criteria, not just code and copy. How to hand them over is the subject of What Is Missing When We Ask People to Take Ownership.

So the question I ask at the end of the day has changed. Alongside how much got done, I ask:

• Did I understand more about what would make a customer decide to buy?
• Did I explain a criterion the team had been guessing at?
• Did I decide what we will not build this time?

None of this makes technology less important. It makes the question of where to concentrate it more precise. A company with limited people and time cannot secure every good technology at once. We have to choose the depth that the problem we are solving actually requires.

How should big-company experience be applied in a small company?

Bring the problem the practice was solving, not the practice itself. Working in large organizations gave me valuable standards: the density of code review, the role of design documents, the habit of watching operational metrics. But this company has its own conditions. With different headcount, customers, and operating environment, importing only the form of a process makes some of it far too heavy. To apply the experience I had to go back and understand what problem each practice was originally there to solve.

I still look at the company through an engineer's eyes much of the time. I like laying out structure, understanding the connections, checking what actually ran. I am adding the conditions of customers, team, and business onto that view.

What changed after leaving Google is that the definition of good work widened beyond my own output. Does what I built work? Can someone else finish their job with it? Does the customer find that result valuable? The day used to end once the first question was answered. Now it ends when all three are.