Organizational Design and Scaling Questions

Approach (high level)
I organize a mix of product/feature teams and shared-component teams so we get deep expertise and fast delivery: product teams own user journeys and iterate quickly; component/platform teams own critical libraries, infra, and APIs.

Structure & trade-offs

• Feature teams: fast end-to-end delivery, close to PM/UX, higher ownership — risk duplicated infra and inconsistent APIs.
• Component teams: technical depth, API stability, reuse — risk slower feature feedback and handoffs. Balance by clear SLAs and partnership agreements.

EM span of control

• Aim for 6–10 direct reports; EMs of platform teams include at least one tech lead to preserve technical depth. Use IC tech leads to keep EMs focused on people/roadmap.

Reduce coupling

• Stable API contracts, versioning, and well-documented SDKs
• Cross-team roadmap syncs and joint OKRs for shared outcomes
• FYI code reviews, periodic cross-team pairing, and “API owner” rotation to reduce bus factor

Example outcome
We cut release friction by 40% when platform ran a dedicated SDK + SLAs and product teams had feature toggles to decouple releases.

Situation: We had a weekly all-hands engineering demo that people genuinely loved, because it created visibility and helped newer engineers feel connected. As we grew from 18 to 45 engineers, it stopped working. The meeting became too long, and teams that had urgent delivery work felt pulled away every week.

Task: I needed to change it without making people feel like we were deleting a piece of the culture.

Action: I explained the problem with concrete examples, not opinions. I showed that the meeting had become 90 minutes long and that only a small part of it was actually useful for most people. Then I proposed a pilot: keep the demo spirit, but move updates to a shared doc and reserve the live meeting for 3 short demos and team recognition. I also asked respected engineers to help shape the new format so it felt like a team decision, not a top-down cut.

Result: Most people adapted quickly because they saw that the goal was to preserve connection while giving time back to teams. The people most attached to the old format were heard, and I made space for them to keep the storytelling and celebration part. That taught me that when a ritual is part of culture, you do not just replace it. You explain what it was doing for the team and then design a smaller version that still does that job.

I would not rely on a culture dashboard alone. I would look for signals that show whether the organization is becoming more effective and resilient, or just more process-heavy.

Signals I would check:

• Retention and regretted attrition. Healthy cultures usually keep strong people, especially in critical roles.
• Employee feedback trends from pulse surveys and skip-levels. I care less about a single score and more about whether themes improve.
• Psychological safety. That means people can raise risks, disagree, and admit mistakes without fear.
• Decision speed and clarity. More formal is not always healthier if every decision now needs extra approvals.
• Cross-team friction. If growth creates more handoffs and blame, that is a warning sign.
• Manager quality and onboarding. New hires should ramp faster, not get lost in bureaucracy.

Worked example: if engagement rises from 72 to 75, but regretted attrition also rises and teams report slower decisions and more escalation, I would say the company is getting more formal, not necessarily healthier.

The key is to compare people signals with execution signals. A healthier culture helps teams ship well, collaborate well, and speak up early.

In the first 90 days, I would focus on reducing ambiguity while protecting startup speed.

What I would change:

• Create a clear decision log so people know what was decided and why.
• Standardize onboarding with one common path for every new engineer.
• Set a predictable manager cadence, such as weekly 1:1s and a weekly staff meeting.
• Clarify team ownership so there is less overlap and fewer surprise handoffs.

What I would deliberately leave alone:

• Direct access to founders for important issues.
• Fast iteration on product ideas.
• Small, empowered teams that can move without too much process.

Example: if one team is choosing between two implementation approaches, I would not force escalation. If a decision affects 3 teams or the architecture for a core service, I would bring it into a broader review.

My goal would be to add enough structure to remove confusion, but not so much that people feel managed by process instead of by judgment. That is usually the sweet spot when an org grows from 25 to 80.

I would make performance management more consistent by clarifying expectations, creating regular calibration, and separating feedback from promotion timing.

First, I would define a lightweight career framework. That means a few clear levels with examples of what impact looks like at each level. For example, a mid-level engineer might own a feature end to end, while a senior engineer is expected to influence design across a team or two. The point is to make growth visible, not bureaucratic.

Second, I would ask managers to give feedback continuously, but I would run quarterly calibration sessions. Calibration means managers compare notes to reduce rating drift, so one team is not much harsher or much more generous than another.

Third, I would make promotion decisions evidence-based. I would look for repeated examples of scope, judgment, and impact, not one heroic project.

Example: if an engineer led a release, mentored a newer hire, and improved a process over two quarters, that creates a much stronger case than a single high-profile win.

This keeps the process lightweight, but people still know where they stand and what to do next.