Context

As the organization expands into new countries, the development team I lead is expected to grow significantly. With more people comes a recurring pattern: the same management friction keeps surfacing. Past generations may have relied on unspoken mutual understanding, but that approach is becoming increasingly difficult to sustain. I have come to realize that without writing down the team's norms, operating principles, and leadership expectations, collaboration problems will keep multiplying.

The Culture We Want to Build

• We expect members to do things well, not just get them done. If you need more time, say so.
• We accept imperfection — but every time you finish something, reflect on how to do it better next time. Be better tomorrow than you were today.
• Mistakes are acceptable; we all make them. When you do make one, try to propose how to prevent the team from repeating it.
• When you come with a problem, think first and tell your teammates what you have already tried. Every question should be a starting point, not a dead end.
• Be proactive. Sync your status with teammates as much as possible, and enjoy sharing what you learn.
• Encourage different perspectives and respect every teammate's opinion.
• Team performance comes before individual performance.
• Doing your job well is the baseline. Everything beyond that is what counts as performance.
• If you are unhappy with the current situation, let's talk. Better yet, bring some clues or potential solutions to the discussion.
• Our pace is fast. Beyond coding, there are many other responsibilities — communication, requirements clarification, analysis. Everyone is busy. You will often need to untangle unclear problems and propose solutions. When servers go down, you are expected to help resolve them. The work is tough, the standards are high, feedback will be direct, and there is plenty of challenge — but also plenty to learn. If this way of working does not suit you, you are always free to choose otherwise.

Work Discipline

• Overtime is generally discouraged, but do not cause others to work overtime either. Respect this comfortable working environment — do what needs to be done when it needs to be done, and keep things reasonable.
• If you arrive a few minutes late, leave a few minutes late. That is fair to the team and others, unless you have a specific situation you have cleared with your manager.
• We use time estimates, and in most situations we do not want engineering quality to be cut for the sake of time. The flexibility exists to handle unexpected situations — please value it. Engineers at many other companies are chased by deadlines every day. If there is no sense of time and responsibility, estimates will need to come back.
• Remote work is a company-granted flexibility based on mutual trust. If performance suffers or work attitude is poor, a manager can require you to return to the office at any time.
• We dislike micromanagement, but we cannot accept hiding information. Speak up directly. The more transparent you are, the more trust you earn — which translates to more freedom and autonomy. The opposite leads to more scrutiny.

Communication

Have you ever asked yourself: if everyone just does their own job, why bother communicating at all?

Modern business is a team sport. Any single person's expertise is limited. If you want your skills to create real value, you need the support of others. Communication at work is ultimately about getting things done — helping each other understand constraints, reaching consensus, and securing the resources needed to solve problems.

Openness to Feedback

No one here is criticizing your code or making personal attacks. The reality is that in most careers, very few people will ever take the time to tell you what you need to improve. If you do not know what to fix, you will keep running into the same problems regardless of how many jobs you change — and the team suffers when work is done poorly. Nobody wants to inherit unmaintainable code or work alongside someone who does not communicate well.

When someone gives you feedback, try not to take it as an attack on your work or your identity. Flip it around: this is exactly how you find out how to get better. Be genuinely open to it.

If you receive feedback like this, the more professional response is:

• Think about whether this change is in the team's interest.
• Then: what should the next action be?

When a Proposal Gets Rejected

When a suggestion is not adopted or a proposal is shot down, it is usually because the approach was wrong, the preparation was insufficient, the thinking was incomplete, or the timing was off. Beyond identifying the problem, you can also help find executable details and think about how to reduce the friction of the proposal. Ask yourself: if everyone at a company only raised problems and no one worked out the execution details, could anything actually move forward?

Code Review, Retrospectives, and Refactoring

Whoever reviews your code — once you have made the changes, always go back to that person to close the loop. That matters a lot.

It is also a good habit to periodically revisit code you wrote in the past. You can raise a refactoring request, create a ticket, and discuss scheduling it with your manager. When requirements are tight you may write code that is hard to maintain — in those cases, open a ticket to record the debt and revisit it later.

Alignment and Adaptability

The theoretically optimal solution is often not the most appropriate one. Official documentation or a single perspective may not account for other dimensions: legacy systems, historical context, resource constraints, team dynamics, time, or leadership expectations — these are all real constraints.

Because teammates have different experience levels and backgrounds, different decisions are made in different contexts. During your growth, you will encounter decisions that do not make sense at the time but become clearer with experience. If you cannot take full responsibility for the overall outcome, and if you do not yet have enough experience in a particular area to fully understand someone else's reasoning, then for now, set it aside, try to adapt, learn it — and then come back and discuss.

Managers will listen to and consider everyone's views, but the manager's role is to be accountable for the team's overall results as assigned by the company. On major issues, the person ultimately responsible for the outcome should have the final say on critical decisions. This is something we need to understand and respect on both sides.

Any Single Skill Is Just a Starting Point

When applying to any company, your compensation is determined by what problems you can help the company solve, your level of expertise, and your work ethic.

When you are just starting out, there is a lot to learn: frontend, backend, team collaboration, communication, project management, testing, CI/CD, system debugging, operations, and managing up. If you only master one skill, your career runway will be short and your development will be constrained.

For example, if the company wants to expand to a new country and needs someone to be the owner of that market, you can say it is not your job and you have no interest in learning it — but then that promotion and raise opportunity is not yours to compete for. Mastering one specialty is important, but a company does not generate revenue from a single skill alone. Limiting yourself to one skill limits your influence in the business. Think of yourself as a company: if you only have one revenue stream, you are also limiting your own possibilities.

The Uncertainty of Software Development Requirements

In any organization, the further down you are, the clearer the work tends to be. The higher the role, the less clear — and the lower the success rate. More experienced developers need to be capable of clarifying and solving ambiguous requirements and problems. Not everything will be spelled out clearly. In software development especially, the same written words often mean different things to different people.

Performance

Junior developers are expected to focus on getting familiar with the work environment and doing their assigned tasks well. More experienced developers, however, are not measured purely on completing assigned code tasks.

• 60% core development — daily development work (efficiency, quality, team collaboration, importance of owned project items).
• 40% extra contribution — communication, coordination, requirements clarification, proposals, mentoring new members, helping the team grow, refactoring, introducing new technology to solve problems, identifying and resolving team-wide issues, leading projects, and additional contributions.

Note: Seniority by years of service does not equal seniority by capability. Capability is not limited to technical expertise — what we care about more is maturity in how you approach work, think through problems, and handle interpersonal dynamics.

Team Positioning

What does the team lack? What hard problems does the company have that align with what you want to develop?

Often, as a company grows to a certain stage, new roles emerge organically. The key question is: when the moment arrives, do you see it — and can you seize it?

Every opportunity comes bundled with work you enjoy and work you do not. Sometimes you cannot choose. During business hours you have the same time as everyone else. If you only learn during work hours, that is generally not enough.

Growth

Opportunities are always there. The question is whether you are mature enough to claim them.

• Can you solve more of your manager's problems and help the company hit more of its goals?
• Is there enough trust and alignment that things can be handed to you without worry?

Additional Benefits and Perks

Some additional benefits are tied to your performance and the level of trust you have built — they are not one-size-fits-all. The difference in contribution and trust means the difference in perks. All of them need to be earned over time by demonstrating yourself. When you perform at the same high level, you are also welcome to negotiate for them directly.

• Opportunities to interview candidates or onboard new members
• Inclusion in meetings on major strategic topics or direction decisions
• Leading projects
• Work-from-home days allocated based on annual performance reviews
• Additional leave for performance that exceeds expectations
• Project bonuses for major deliveries
• US business trips — this is not a perk, it is a responsibility. Think carefully about what value you can bring to the team if you go.

Note: We look at long-term, sustained, consistent performance — not isolated high points.

Systems Thinking

In large systems, you will often notice that a bug you fixed before has come back. The root cause was never truly addressed, even though fixing root causes tends to be expensive. For this reason, we expect more experienced developers to invest more time in thinking through problems so that issues do not resurface. For proposals on complex problems, please provide at least two solution approaches (short-term, mid-term, long-term):

• Quick fix — solves the immediate problem with low cost and effort; likely to recur.
• Leverage fix — invest a bit more time each iteration so the problem does not happen again in the medium to long term.
• Root cause fix — high investment cost, harder to achieve.

Task Urgency

By Task Type

Business-impacting bugs > Feature requirements > General bugs > Optimizations

By Task Nature

Urgent

Issues that block checkout or cause billing errors — potential financial losses, or tasks explicitly flagged by leadership — must be addressed immediately.

Important (Planned)

Items like Lighthouse improvements or Black Friday pages — follow the plan.

Not Important, Not Urgent

Refactoring, optimization, etc. — do during downtime.

Neither Important nor Urgent

Skip entirely, or handle only when truly free.

Fairness

In team collaboration, unfair situations come up often. But if you are only focused on whether things are fair, a lot of work will not get done. You can only pick up and run with what is in front of you, and the environment always has constraints. If you cannot push others forward through skill and influence, you work with what you have, and do what can be done. At that point it comes down to who cares more about the outcome — and whether fairness matters more to you than creating the value itself.

Note: If I do not move until the opposition moves, and my allies do not move until I move, everyone just stays stuck.

Underperformance and Removal

When we bring someone onto the team, we expect them to share the workload, align with team direction, and grow together. But it is not uncommon to encounter someone who is passive, refuses to take feedback, and shows no improvement after communication. In those cases, a performance improvement plan (PIP) will be initiated. Anyone who receives a formal warning or PIP will receive zero year-end bonus for that year and will have work-from-home privileges suspended until performance improves.