Stephan Schmidt - July 3, 2026

Structure Your Tech Department Around Ownership

The Pool Ball Model: hand out responsibilities end-to-end, one name per ball

How do you structure a tech department? How do you organize your engineering teams, who owns what, who reports to whom? There are thousands of books, articles and conference talks on the topic - I’ll add something where I differ.

First, think for yourself. What worked for others might not work for you. The Spotify model with its tribes and squads? Might work. Team Topologies? Might work. DevOps teams? Might work. Platform teams? Might work. But they might all be the wrong solution for you, because your company is different - different people, a different product, a different business model and you’re at a different stage than they were when it worked for them - and copying an org chart from a conference talk is cargo cult thinking, the dance without the reason behind it.

You are not paid to copy things from the internet. You’re the highest paid techie in the company, paid to think, to make the decisions only you can make, and to own them.

The Pool Ball Model

My model for structuring a tech department is simple: structure around ownership.

Owning something means making the final decisions about it. If I own a car, everyone can have opinions about where the car should go, and they will have opinions, but in the end I decide where the car goes - and if I can’t decide where the car goes, I don’t own it. If I own a house, I decide whom I let in and whom I don’t. If I can’t decide that, whatever the deed says, I don’t own the house.

The same holds inside a company. If you own “code quality” as an employee, it’s up to you to decide what code quality means and how to get there. You listen to people, you gather opinions, and then you make the final call. Just like with the car.

Ownership and responsibility are two sides of the same coin: responsibilities are the expectations others have of your role, ownership is the permission your role has to act on them. If you own something, you’re responsible for it.

Now the pool balls. I envision a company as a flow of responsibilities and ownerships, and the CEO gets theirs from the law, from shareholders, from customers, from employees, from the IRS - grow revenue, bring new products to market, do proper accounting, protect customer data. Think of each responsibility as a pool ball with a label on it, and the CEO holding a basket that everyone keeps dropping balls into.

The CEO can’t play all the balls, so they hand them out. The ball labeled “Proper Accounting” goes into the CFO’s basket. The ball labeled “Protect Customer Data” goes into the CISO’s basket. Those people own those balls now.

Why End-to-End?

Hand out responsibilities as end-to-end as possible. The moment you split one - half a ball here, half a ball there - and something goes wrong, the fingerpointing starts, and you’re on a hunt through the org chart for who is responsible and whom you can hold accountable, and everyone involved has a good story about why it was the other half.

With end-to-end ownership it’s clear whom to hold accountable: one person. And you don’t need to care how they manage the ball internally or how they fix their problems - that’s the whole point of handing it over.

Who Gets “Bring Products to Market”?

Here it gets difficult. You can’t give that ball to the CTO, they only build products. You can’t give it to the VP of Product, they only think up new products. So most companies split it: “think of new products” goes to the VP of Product, “build and operate products” goes to the CTO.

The problem with splitting: when the two misalign - and they will, over priorities, over quality, over that rewrite one of them wants - cleaning it up is your job now. You split the responsibility, so you own combining the results. Every split ball rolls back into your basket eventually.

So it’s often better to have one person own bringing products to market: a CPTO. Not sure a CPTO is the answer for every company - the role has its own traps, and it costs more than most CEOs expect - but one ball, one basket, one name.

Who Reports to Whom?

Ownership settles who holds which ball. The second question is reporting lines, and my rule is just as simple: people report to you because you want to manage and guide them. If you want to manage and guide a topic, that person reports to you - and if a topic doesn’t interest you and there is nothing for you to manage, that person should not report to you, even if every org chart on the internet says otherwise.

The test is your management team meeting. Who should sit at that table, what do you want to discuss? Everyone who needs to be in those discussions should report to you, and whoever has nothing to discuss at the engineering management table doesn’t need to report to you. Then watch the meeting itself: if two people keep discussing things between themselves while everyone else waits, one of them should report to the other, not both to you. And if someone at the table constantly needs to check between meetings with a person who is not in the room, that person belongs at the table - and reports to you.

What Do You Own?

So what are your responsibilities as CTO? I don’t know. Everyone is different, and the only way to find out is to ask your CEO what you’re responsible for and what you own in their mind.

(You did ask them, didn’t you?)

When I ask coachees what they own, I mostly get a job title back. The core is usually developing products and features and operating them, but there is more sitting in your basket than you think: security (don’t leak data, don’t get hacked), compliance (don’t break laws), people development (don’t lose talent), stable operations with high uptime, performance for happy customers, supporting the business with innovation. All of these need to be handed out to your direct reports as end-to-end balls with one name on each - written down, because if it’s not written down, it doesn’t exist. (Sorting out which balls are even in your basket is where I start with most coachees - a coach has seen a hundred baskets, you only see your own.)

Go ask. Then hand out the pool balls.

Most of the CTOs I coach didn't know CTO coaching was a thing until they were already drowning. It is a thing - here's what it is.