How does software engineering actually work at Happydance?

Culture pages are usually where careers sites go to lie. Every company on earth claims collaboration, autonomy and trust, which is exactly why claiming them proves nothing. So instead of adjectives, here is the machinery: how the squads are shaped, how work flows, how decisions get made, and where the friction is.

How are the squads structured?

Each squad is small and cross-functional: a handful of engineers across frontend, backend and platform, a product manager and a designer, owning a slice of the product end to end. Squads own outcomes, not tickets, which means the squad that builds a feature also operates it, fixes it and hears about it when an enterprise client has opinions.

Small matters here. With clients like National Grid, Domino's and Canva on the platform, it would be easy to grow layers of coordination, and the discipline is not doing that. Fewer people per problem means your work is visible, your voice carries, and there is nowhere to hide, which is either the appeal or the dealbreaker depending on who you are.

What do the sprints actually look like?

Sprints are two weeks, bookended by planning at the start and review plus retro at the end, with a daily stand-up that is held to fifteen minutes. Mid-sprint is deliberately quiet: refinement for the next fortnight happens once, and the rest is build time, which is why the honest split of a week here runs roughly 60 to 70% deep work.

The full hour-by-hour version, boring bits included, is on a week in the life. The short version is that the ceremonies exist to protect the making, not to replace it, and any sprint where that inverts gets raised at retro, loudly.

How real is the code review culture?

Real enough that it is the thing new joiners mention most. Every change goes through a pull request, and reviewing here means reading the code, running it where it matters, and commenting with reasons rather than vibes. Review is treated as part of the job, not an interruption to it, and senior engineers are judged partly on the quality of their reviews, not just their commits.

Two ground rules keep it healthy. First, comments critique code, never people, and "why did you choose this?" is a genuine question, not a trap. Second, review is fast: a PR waiting days is treated as a squad problem. The payoff is a codebase where standards are shared rather than enforced from above, and where a junior's third week includes seeing a principal engineer accept their correction gracefully, because that genuinely happens and it teaches more than any values poster.

Accessibility review deserves its own mention. WCAG 2.2 AA is a hard requirement on this platform, so accessibility comments in review are normal, expected and non-negotiable. Engineers arrive treating that as compliance and leave treating it as craft.

How do decisions get made?

Product direction is set by product managers with squads in the room; technical decisions are made by the engineers closest to the code, with bigger calls written up as short proposals anyone can read and challenge. Architecture choices that cross squad boundaries go through an open technical discussion rather than a closed committee, and disagreement is expected to show up in the document, not in the corridor afterwards.

When decisions genuinely conflict, the tiebreaker is usually the client reality: this is an enterprise platform, and what keeps it trustworthy for a global brand tends to win over what would be most fun to build. Engineers who have worked in consumer startups sometimes find that adjustment real, and it is better you know before you join. The upside is that decisions stick. The roadmap does not lurch weekly because someone senior had a weekend epiphany.

What are hack days like?

One hack day (sometimes two) per quarter, and they are protected, not the first thing sacrificed when a deadline looms, because several shipped features started life as hack day prototypes. The format is simple: any idea connected to the platform or the craft, teams form in the morning, demos before the end of the day, and the best ideas get argued into the roadmap through the normal proposal route.

The honest caveat: hack day output earns its place like everything else. A great demo is the start of the conversation, not a golden ticket, and some people find that deflating the first time. We think it is the respectful version: your idea gets taken seriously enough to be tested against everything else we could build.

What frustrates people here, honestly?

Every culture has friction, and hiding ours would undermine everything else on this page. The recurring ones, straight from retros:

• Enterprise pace on some things. Change windows, security reviews and client sign-offs mean some releases wait when the code has been ready for days. It is the price of the client list, and it still frustrates people.
• Estimation on a tangled platform. Multi-tenant work makes some tickets swell mid-sprint, and retros regularly revisit why. We are better than we were, and not as good as we want to be.
• The AI ground shifting. Rework happens in the LLM layer because the ecosystem moves, and watching last quarter's careful abstraction get replaced stings even when it is the right call.
• Hybrid coordination. Occasionally the person you need is on their home day when you are in the office. Squads manage it with shared anchor days, and it is managed rather than solved.
• Small company trade-offs. Fewer specialists means you sometimes do work adjacent to your favourite work. Ownership is broad here by design; if you want a narrow lane, that is a genuine mismatch.

None of these are dealbreakers for the people who stay, and the engineer stories include people saying so in their own words. But they are all real, and the wrong move is pretending otherwise.

Frequently asked questions about how we work

How many days a week are engineers in the office?

Two to three, coordinated within each squad so the days genuinely overlap. The pattern is squad-chosen anchor days, not a company-wide mandate from a spreadsheet.

Do engineers get dedicated time to pay down technical debt?

Yes, inside normal sprints rather than in a promised future quarter. Refactoring is planned work with tickets and review like everything else, and the tech stack page is candid about where that effort goes.

Is there a formal on-call rota?

A lightweight one, shared fairly across engineers, with time off in lieu after any disturbed night. Incidents are rare on a platform this deliberately stable, but we would rather you hear about the rota from this page than from your first week.

Can juniors really challenge senior engineers in review?

Yes, and they do, and it is one of the healthiest habits in the building. The rule is that reasons win arguments, not job titles, and the reviews are public enough that everyone can see the rule being kept.

---

If a culture measured in mechanisms rather than adjectives appeals to you, see which software engineer roles are open right now. And if you want to know what all this looks like from inside one career, the progression page shows how people grow through it.