We prioritize supporting fast onboarding to enable scenarios like international remote contractors, interesting specialist chunks (GPU/graph/SPA/..), giving ind

We prioritize supporting fast onboarding to enable scenarios like international remote contractors, interesting specialist chunks (GPU/graph/SPA/..), giving individuals more leverage/reach, and keeping door open to moving more of our code to OSS: - OSS best practices: readme/development.md, docker, GitHub actions for CI/CD, GitHub wiki/issues/projects, conventional commits + PRs, etc: folks know most of the software lifecycle norms, how to navigate, quality expectations. OSS evolved for remote + async collab, so even better as we've gone int'l-friendly. - One click / command to get a full instance of a service or server. Whether 'docker compose up some_service' or labeling a PR with 'staging' (ephemeral instance per PR) or 'release', that's it. - Boring code: We focus our innovation points in a few areas (GPUs, graphs, UI, ...) and as much as possible try to mold the crazy stuff into proven stuff . Likewise, avoid NIH for as much as we can (ticketing, ...). Ex: Our core product python GPU services app is built with asyncio , rapids.ai , arrow, etc, but packaged as REST for internal service consumers. Likewise, most of the cloud/CRUD tier is 'just' a Django app + node, so having / thinking about GPUs is not required when developing that stuff. So teammates can building wild things where it matters, but for the standard things, have proven , predictable, and well-maintained OSS. - Easy service onboarding. Almost all HR via modern services (gusto, Carta,..), + dedicated person (we are small so share our book keeper with other startups). Same for dev, limited consolidated services with prebuilt roles, though we can do better there (SSO, ..). - Team member / project match. We ensure a match for the new hire: tech, type of work style, initial project scope, etc, so they have a strong sense of what to do initially. Likewise, longer-term, we hire for them to own/push a general direction, so we try to have a sense of natural succession of projects. Eg, currently hiring to help with cloud tier full stack UI, BI tool integrations, and potentially starting our GPU graph data science / infoviz R&D unit: all with clear first and successive projects. - hiring constraint: no hires for an area until it is sane. We do have some legacy cowboy code areas with hard dev envs, and want to hire folks for them.. but unless the job is explicitly tearing that stuff out, nope, that'd be a waste of good people. This stuff is important for increasing individual leverage/scale, enabling crazier tech, and opening the hiring pool. If I was going to start another co, would do again.