Coding Isn't Enough

When I started writing software, an engineer's job had clear edges. You picked up a ticket, wrote the code, opened a pull request and moved on to the next ticket. A product manager decided what to build. A marketer wrote the launch post. Someone from customer success, or another marketer, ran the demo.

That job is disappearing, and I think that's good news for engineers.

Code is cheap now

AI agents write a large share of our code. Writing code is turning into a commodity, and the engineers who were best at it are finding that typing speed was never the scarce part.

Good decisions are still scarce. Knowing which feature to build, which to skip, and what a customer actually needs is as hard as it ever was, and it matters more now that building is fast.

The rest of the work got easier too. The same tools that write code can draft a launch video script, design a landing page or run a data analysis on how customers use a feature. An engineer no longer needs to wait for a marketer or an analyst to get those things done.

Put those together and a pure software engineering role isn't enough at a startup like ours. The people who do best here use AI to handle the building and spend their judgment on everything around it.

What this looks like in practice

Here's how we built Conduit Operations, our module for cleaning, maintenance and inspections. A single engineer on our team owns it, from the first customer call through its launch on October 20 and our launch webinar on October 27.

There are whole companies built around this one product, and one of the largest took a private equity investment this year to keep growing. Our engineer rebuilt its core functionality inside Conduit, next to the guest conversations where most operations issues start, and made it better in the process.

This is what owning it looks like:

1. Getting on calls with operators to scope what it has to do
2. Shipping a first version of maintenance to a few customers
3. Improving it based on their feedback
4. Adding cleaning, inspections and the agents that run them
5. Working with partners like RapidEye on the launch
6. Running the launch webinar
7. Monitoring and tracking how it performs after launch
8. Iterating on it further with customers

Nobody handed him a spec for any of this.

Why one person is faster

In most companies, the handoffs and the context switching take longer than the work itself.

A product manager talks to the customer and writes a spec. An engineer reads the spec, has questions, and sends them back. The product manager asks the customer, waits for an answer, and updates the spec. Each round trip can take days, and every step loses some detail. The spec records what the customer asked for. It rarely records why they asked for it, and the why is usually what changes what you build.

When the engineer is on the call, the questions get answered while everyone is still in the room. The engineer can ask things that only make sense if you know how the system works, such as whether a repair task should be created as soon as the guest reports a problem or only after the cleaner confirms it. They hear the answer firsthand and can start on the change right away.

This used to be a minor cost. Writing code was the slowest step, so a few days of handoffs around it didn't stand out. Now that our engineers build much faster with AI, the handoffs are often the slowest part of shipping, and removing them is where the biggest gains are.

How a feature ships here

This is roughly how a new feature goes from a customer problem to everyone's account:

1. The engineer gets on a Google Meet or a Slack huddle with the customer and talks through the problem.
2. They build a first version and ship it.
3. They turn it on for that one customer and ask what's wrong with it.
4. They fix what comes back and check in again.
5. Once it holds up, they roll it out slowly to the rest of our customers in production.

Then the same person takes it to market. They record a demo video, help write the launch post, run the webinar and onboard the first customers. They also sit down with our sales team to explain how to position the feature and who it's for.

That positioning comes from the customer calls. After a few dozen conversations, an engineer knows which part of the feature makes a customer lean in and start asking about pricing, and which parts they politely nod through. Nobody else in the company has that view, because nobody else was on every call.

A product marketer would make a more polished webinar. But customers can tell when they're hearing from the person who built the feature. That engineer can answer any question about how it works, and when a customer says something is missing, they know what it would take to add.

Keeping the foundation solid

Giving every engineer a product line doesn't mean nobody looks after the shared systems. Some of our core systems have to work every time, and we put real effort into keeping them rigorously maintained, with good engineering practices around them. Security, support and infrastructure each have at least one clear owner.

On top of that, each engineer owns one or more product lines completely, including the customer conversations, the roadmap, the launch and what happens after launch.

Context still has to leave the owner's head. If one person holds everything about a product and they're out for a week, the team shouldn't have to start over. Customer calls can be recorded so anyone can watch them later. Decisions can go into the Linear issue, along with what the customer said that led to them. When something ships, a short demo in Slack shows everyone what changed. The goal is that someone else could pick up the product line without a long handover.

You own the decisions

When you take a product from the first call through onboarding, you make the decisions along the way: what to build, what to cut, when it's ready, and what to tell the customer. Those decisions are yours, and so are the results. When a feature takes off, you know why, because you made the calls that got it there.

Naval Ravikant wrote, "Embrace accountability, and take business risks under your own name." I think that applies to engineers as much as founders. Seeking out accountability is how you get trusted with bigger and bigger problems, and owning an outcome is far more satisfying than closing tickets. The payoff is financial, and it's spiritual too.

At product-focused companies like Conduit, writing code isn't enough anymore. It's also never been more fun to be an engineer. You learn how to scope a product, run a customer call, position a launch and host a webinar, on top of writing the code, and each of those makes you a better builder.

A lot of engineers say they don't want to be code monkeys. This job is the opposite of that. I think of it as being a product sculptor. You shape the whole product, and code is one of the tools you use to do it.

We're hiring

The engineers who fit best here could build a product end to end and take it to market on their own. They choose to work on a team of people who can do the same, and a team like that can take on the biggest incumbents and the most ambitious missions. We place immense trust in their judgment and taste.

This is what I look for:

1. You use AI to build fast, and you hold the result to a high bar.
2. You love talking to customers and come off a call knowing what to build.
3. You make good decisions quickly, with incomplete information.
4. You care deeply about your feature succeeding after it ships, and you keep going until it does.

If that sounds like you, send me a message on LinkedIn or take a look at our open roles.