As our company has grown, I've noticed something that concerns me. Many of the principles we were built on — ideas that once felt obvious to everyone — have quietly faded into the background. Not because anyone rejected them, but because we stopped saying them out loud.
Recent events have made it clear: it's time to say them again.
Because when these principles get blurry, roles get confused, systems get misread, and energy gets wasted on friction that should never have existed. Worse, we drift — slowly, invisibly — away from what makes this company what it is.
Who serves whom
Most companies operate on an unspoken assumption: headquarters represents the company, support functions represent order, and frontline people execute. That logic may be normal elsewhere. Here, it is fundamentally wrong.
On our platform, programmers and business units are the core. They are not managed by the platform — they are the reason the platform exists. The platform's job is to help them serve clients, create value, earn returns, and grow.
In this sense, programmers and business units are the platform's first customer.
External clients matter, of course — they pay for the work. But from the standpoint of how the platform should operate, we serve programmers and business units first, because they are the ones creating value. External clients connect to that value as the second customer.
This means every support function at headquarters — sales, operations, administration — must get its positioning right: we are not managers overseeing the frontline. We are service providers working for the frontline.
This isn't about status. It's about getting the organizational relationship right. Anyone who gets this backwards will inevitably make bad decisions — because the moment you place yourself above the programmer, you start directing, intervening, judging, and eventually making decisions that aren't yours to make. The platform stops being a platform and becomes a bureaucracy filled with management theater.
There are plenty of companies like that already. We don't need to become another one.
The Account Owner is not an executor — they are a business operator
When we assign a client to a programmer or a business unit, we are not distributing a task. We are making an internal investment.
A client is not "dispatched" to someone. A client is entrusted to someone to operate.
This distinction matters. If it's an operation, then the person running it should think first from the perspective of maximizing their own returns. They don't need to sacrifice their judgment for some abstract notion of "company-wide interest," and they certainly don't need to bend to the preferences of a support function.
Whoever bears the operating responsibility should hold the operating authority. This is why the Account Owner role exists.
Sales, operations, and other functions may offer suggestions, provide support, and help with analysis. But they have no right to override an Account Owner's decisions, and absolutely no standing to go around them.
Because if a client nominally belongs to an Account Owner, the responsibility sits with them, the risk sits with them, but the decision-making power does not — then "operating" becomes an empty word. Responsibility and authority split apart, and the result is predictable: no one truly owns the client. Everyone just owns their process, their posture, their appearance of coordination.
Support functions must guard against self-elevation
I want to emphasize this point — not as theory, but because I've seen early signs of it in practice. Some individuals in support roles have begun, perhaps unconsciously, to treat programmers as people who don't understand business, can't make good judgments, and need to be arranged, corrected, and managed.
This mindset is dangerous.
Behind it lies an unspoken assumption: "I understand the company's interests better. I see the bigger picture. So the programmer should follow my lead." In a traditional company, this attitude may be common. Here, it is a fundamental misalignment.
Programmers are not an accessory to the platform. They are among its most essential operators. If you treat programmers as incapable, you have already negated the platform you serve. If you place yourself above programmers, you have already positioned yourself against this organization's values.
The most common mistake support functions make is not a lack of effort — it's a misplaced sense of role. Once the role-sense goes wrong, support becomes control, assistance becomes interference, and collaboration becomes command. It looks like helping, but it's actually stripping the frontline of its operating authority and judgment.
Let me be clear: support functions do not inherently outrank programmers. A different title does not mean a closer relationship with truth. Different information does not give anyone the right to make someone else's decisions. The purpose of headquarters is not to become a referee — it is to become infrastructure, a support system, and a bearer of risk.
This is the thinking behind Core70's model — developers earn 70% of the revenue they generate. See how it works →
The Account Owner's authority has boundaries too
The Account Owner's core authority is over client relationships, not over project execution.
If an Account Owner is directly involved in a project, they naturally have a stronger voice in how it's run — their judgment comes from real participation, and their responsibility is grounded. But if they are not directly involved in the project, the programmer should operate with full independence.
They can offer suggestions, share client-level risk concerns, and express their perspective. But suggestions cannot become orders, and client authority cannot extend into control over project details.
Without this boundary, the Account Owner becomes the role most likely to generate internal friction: not doing the actual work, but constantly intervening in details; not bearing on-the-ground responsibility, but constantly issuing on-the-ground judgments. Over time, projects lose clear boundaries, programmers lose independence, and Account Owners waste the energy they should be spending on clients.
Our values run opposite to most companies
Why do these issues keep getting misunderstood? Because our values are genuinely different from most companies — in many ways, they run in the opposite direction.
Most companies put "maximize company interest" first. Every role, every process, every evaluation system ultimately points toward one goal: making it easier for the organization to mobilize and control people.
We don't work that way. Our foundational logic is: programmer interest comes first.
This is easy to misread, as if it means the company doesn't matter, clients don't matter, the organization doesn't matter. None of that is true. What it really means is: we recognize that programmers are the core agents of value creation, so the organization must be designed around them — not the other way around.
Programmer interest first is not indulgence — it is respect for the source of value. It is not anti-organization — it is a redefinition of what organization means. It is not short-sighted favoritism — it is a fundamental acknowledgment of who actually creates long-term value.
Where most companies expect the frontline to conform to company logic, we expect the organization to serve programmer logic. Where most companies have support functions manage the business, we have support functions serve the business. Where most companies emphasize control and decomposition in projects, we emphasize programmer independence and wholeness. Where most companies turn people into positions, we want positions to yield to the people who actually create value.
If you don't understand this, you'll keep trying to "fix" us with conventional management, and the more you fix, the further we drift.
We must prevent ourselves from becoming an ordinary company
Ultimately, I'm writing this not to argue about who reports to whom, and not to advocate for any one group. I'm writing it because I see with increasing clarity that an organization's greatest risk is rarely external competition — it is slowly forgetting who it is.
This company has come this far not because we're better at hierarchical management, but because we chose a different path early on: trust programmers, trust operators, trust the frontline's judgment, trust that power should go to whoever bears the responsibility, trust that the organization should be designed around those who create value.
This path is not easy, and it goes against most people's instincts. The organizational education most of us absorbed growing up says: the top knows best, the bottom executes; the center decides, the periphery obeys. The moment an organization gets complex, those old habits creep back in. Once they do, we rapidly become an ordinary company.
So let me say it one more time:
- Programmers and business units are not objects to be managed — they are the core of the platform.
- Headquarters support functions are not the organization's masters — they are its servants.
- Account Owners are not liaisons — they are operators.
- Projects are not extensions of a management chain — they are where programmers create value.
- Our values do not put company interest first — they put programmer interest first.
- Our organizational logic does not control the frontline — it empowers the frontline.
This is not nostalgia for the past. It is a choice about the future.
If we can hold to these principles, keep our positioning right, and keep ourselves from sliding back onto the track of a conventional company, then we still have a chance to preserve what makes us unique — and to keep going further.
But if these principles start to fade, get diluted, get quietly replaced by talk of being "more standardized," "more mature," "more like a real company" — then what we ultimately lose is not just efficiency, not just culture, but the very reason this company exists.
That is something worth thinking about carefully.