Mrkd culture: open communication, relationships, and a team that grows together

Culture at a lot of studios is a values page nobody reads. Ours is a set of specific things we run day to day, and they add up to one posture: we treat mrkd as a relationship, not a hierarchy.

That is not a slogan. It shapes how we communicate, how we give feedback, how we handle wins and setbacks, and how the team spends its time together. And because software work is a relationship business — with clients, with each other, with the products we build — the culture ends up shaping the work itself.

Here is what running mrkd as a relationship actually looks like.

Open communication, both ways

The single most defining thing about our culture is that communication runs two ways. Not top-down memos. Not one-way management directives. Not "the leadership has decided." Everyone on the team can raise a concern, disagree with a decision, push back on a plan, or ask for something they need to do their best work — and be heard when they do.

That sounds obvious. In practice it is rare. Most studios say they value open communication and run themselves as quiet hierarchies where information flows down and problems flow up slowly, if at all. We built ours to work the other way.

Concretely:

• Decisions that affect the team are discussed with the team before they are made, not announced after. If a discussion has to happen fast, we explain why and revisit.
• Every person on a project has direct access to every other person on it, including the founders. There is no invisible layer to route around.
• Concerns raised by the team are answered — not deflected. If the answer is no, we say no and explain the reasoning.

Two-way communication is the mechanism. Everything else in this post is downstream of it.

Feedback as a relationship investment

Feedback in most workplaces has two failure modes. Either it is avoided until things get bad, or it is delivered as a verdict rather than a conversation. We treat feedback as neither.

Feedback at mrkd — good or bad — is relayed constructively, in the moment, aimed at growth. That means:

• Praise is specific and public. A win is called out, in front of the team, with the specifics of what made it good. Generic "great job" is not feedback. Naming what a person did well gives the rest of the team a model to learn from.
• Critique is specific and private. Something that needs to improve is raised directly with the person, in a one-to-one, in a conversation — not in a Slack channel, not in a group meeting, not left to build up until the next review cycle.
• Every piece of feedback is aimed at improvement. We do not give feedback to be right. We give it because we believe the person can do the work better next time, and we want to help them get there. If we do not believe that, we have a bigger conversation to have — not a feedback conversation.
• Feedback runs both ways. The team gives feedback to the founders as often as the reverse. If leadership makes a decision the team thinks is wrong, we hear about it directly.

That posture is what makes feedback work as a relationship investment rather than an event. Over time, people at mrkd get comfortable saying the hard thing, kindly and specifically, because the culture has proven that saying it is safe.

We grow as a team, not as individuals

There is a version of the software studio that runs on internal competition — quiet rankings, tenure ladders, individual bonus pools, the star-of-the-quarter model. We do not run that model.

We run the opposite. Every project at mrkd is a team win or a team miss. When a project goes well, we celebrate together, name the specific contributions, and figure out what we can generalise from it. When it goes badly, we look at what the team missed — not what one person got wrong.

That means:

• Wins are shared. When a client project ships well, everyone who touched it gets the credit. The person who wrote the CSS and the person who ran the client relationship both mattered.
• Setbacks are collective. If a phase exit slips or a decision turns out wrong, we look at the process — the specs, the review, the assumption — not the individual. If a person did make a mistake, that conversation happens in private and privately.
• Learning is out loud. New tools, new patterns, mistakes worth talking about — we share them in the shared channels so the next person on the team benefits. Nobody hoards knowledge.

The point is that a team compounds when it grows together. A team where the strongest person is protecting their edge does not compound. It stagnates at the level of the strongest individual, and then loses them.

Collaboration as the default posture

Collaboration at mrkd is not a value on a page. It is how the work is structured. Every project is small enough that everyone who touches it can be in every important conversation. Design reviews include engineers. Engineering reviews include designers. Content and PM sit in both.

The reason is not diplomatic. It is that the software gets better when the person about to build it heard the argument about how it should behave, rather than reading a summary two days later.

Practically, collaboration at mrkd shows up as:

• Small teams, on purpose. We would rather run three tight teams than one big one.
• Shared authorship of the important artefacts — specs, design systems, technical decisions.
• A push-and-help ethic. When someone is stuck, they say so, and someone helps. When someone is shipping something new, someone else pushes them to make it better. Both directions.
• No single point of knowledge. If only one person understands a system, that is a bug in the culture, not the codebase.

What we deliberately do not do

Culture is defined by what a team does not do as much as by what it does.

• No one-way memos from management. If a decision needs to be communicated to the team, it is a conversation, not an announcement.
• No punitive feedback. Feedback delivered to punish or shame is not feedback. It is politics. We do not run that model.
• No hoarding of wins or knowledge. A person building their personal profile at the expense of the team is a problem we address directly.
• No hero culture. If a project needs someone working Saturday, the project is misspecified. We rescope with the client — we do not let one person carry it alone.

What it means for clients

The culture is not just an internal thing. It shapes what a client experiences.

Nobody is hiding a problem. If something is going wrong on your project, the person building it can raise it to the founders without going through a chain. That means you hear about it early, which means it costs less to fix.

The team on your project is stable. People stay because the culture is good. That means the person you meet in kickoff is the person still on the project at month six.

The way we communicate with each other is how we communicate with you. Direct, honest, kind, and specific — with feedback delivered constructively and questions asked openly. If a client brief has a problem, we raise it. If a decision the client made needs revisiting, we say so. Same posture, inside or outside the studio.

For the specific practices that back this up — how we hire against that culture, how we deliver against it — see how mrkd hires and one studio, one system.

The answer

We run mrkd as a relationship. Open two-way communication, feedback delivered constructively in both directions, shared wins, collaborative work, and a team that grows together. That is the culture. It is not a values page — it is what you experience the first month you work with us.

If you want to see what a team run this way delivers on your kind of work, send us a short brief. We reply within one business day.