Brand: Artifact vs Operating System
Compare two mental models for brand: a static artifact (logos, guidelines, centralized control) and a living operating system (values, APIs, support, trust). See which choices fit your engineering team.
Loading…
Topic
Onboarding
30 posts about Onboarding. Every summary links to the original.
- 30 posts
- 11 companies
- 1 explainer
See the idea
Onboarding explainers
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Perspectives on Onboarding: Joining Shopify as an Engineering Leader
Shopify’s onboarding program is presented as an alternative to the common first-day experience of receiving a laptop, documents, and a team without enough context. It gives new engineers, including engineering leaders, a structured period of roughly six weeks to learn the product, merchants, engineering practices, and company values, including by creating test shops and using the admin. Avanti Ketkar and Maria Robledo describe how this preparation helped them connect onboarding content to later work, ship a pull request after using a test shop, and build relationships and trust in a remote environment. Their accounts also cover the adjustment to learning before delivering impact, moving from a .NET background to Ruby and Rails, managing time zones, and keeping technical craft relevant while leading teams.
Asynchronous Communication is the Great Leveler in Engineering
After Shopify became a remote-first company in March 2020, globally distributed engineering teams had to replace office habits and spontaneous context-sharing with remote-focused ways of working. The article presents a spectrum of synchronousness, ranging from video calls and pair programming through chats, recorded video, email, written documents, wikis, and READMEs, with increasing permanence toward the asynchronous end. It argues for writing as a primary communication mode, replacing meetings where possible, recording and rebroadcasting events, documenting decisions, maintaining a single source of truth in the Vault, and defining team norms for overlap, deep work, code review, and shipping across time zones. It also cautions that not everything should become asynchronous: synchronous meetings, pair programming, social activities, and intentional in-person gatherings preserve human connectivity, while asynchronous practices provide flexibility, equal access to information, and durable archives.
The AWARE Development Plan
The AWARE Development Plan presents a structured way to pursue long-term goals in software development, education, dance, or other areas of interest. David Ward developed it after seeing team members struggle to define their growth paths and describes using a similar process for his own goals. AWARE stands for Aim, Work Back, Achieve, Reflect, and Encore: define the desired outcome, work backward into smaller aims, execute measurable objectives, learn from the result, and maintain the plan. Short- and medium-term aims act as checkpoints, allowing people to identify missing experience, seek opportunities, and course-correct. Ward recommends reviewing the plan with a lead or manager, including during weekly one-on-ones, to select next steps, connect opportunities to aims, and ensure completed aims are reflected on.
Journey Through a Dev Degree Intern’s First Placement
During her first 12-month Dev Degree placement, the author worked as a back-end developer on Shopify’s Docs & API Libraries team, which builds libraries, tools, and documentation for developers. She describes an initially steep learning curve through work on Shopify CLI, including a change allowing Rails flags such as --db=DB during project scaffolding, and a Shopify Admin API Library for Node written in TypeScript. To handle uncertainty, she kept an Achievement Log, learned by adapting existing code and tests, paired with colleagues, asked for help, and reviewed draft pull requests with teammates. The placement challenged stereotypes about “real” developers and showed that imposter syndrome can coexist with genuinely needing more knowledge. She concludes that learning is collaborative, representation can strengthen inclusion, and becoming comfortable with discomfort is part of development.
Bridging the Gap Between Developers and End Users
Shopify describes how distance between developers and end users can weaken product context and empathy as companies grow. The company created Bridge the Gap in 2014, connecting employees with merchants through Support teams. The program uses workshops, an internal podcast built from support-call clips and discussions, and voluntary one-hour shadowing sessions in which participants observe Support Advisors helping merchants via chat, phone, or email. Direct exposure is presented as a way to understand unexpected product use, identify customer workarounds that may inform fixes or new products, broaden domain knowledge, and develop listening, communication, patience, empathy, and expectation-setting skills. The broader goal is to make merchants accessible to Shopify’s workforce as people rather than abstract accounts or personas.
Connecting with Mob Programming
A six-person team drawn from three teams had six weeks to complete an ambitious Shipping project, while several members were new to the domain or company and had not worked together. Pairing was uncommon, and pull requests received little substantive feedback, creating uncertainty about whether the team was growing, connecting, and learning. After Sheldon Nunes introduced mob programming, the team used a shared screen and ten-minute driver rotations, with each driver pushing changes before the next person pulled them. This kept everyone engaged, accelerated reversible decisions, limited context dumps, and made most code review back-and-forth unnecessary. Across nearly daily sessions for three months, the team reported stronger relationships, easier feedback, restored remote learning, and better support for newcomers, while identifying drawing, public discoverable calls, simple environments, cross-disciplinary participation, and breaks as important practices; tests and documentation were considered poor fits for mobbing.
Three Ways We Share Context at Shopify Engineering
Shopify Engineering treats context—the why, what, and how behind development philosophies, approaches, and choices—as essential to company, team, and individual growth. It describes the Development Handbook, which evolved from a 2015 Google Doc into a searchable internal website in 2018, with hundreds of developer-contributed topics maintained through GitHub pull requests, reviews, and Markdown. Dev Talks began as a weekly open stage and became an on-demand recording program after the 2020 shift to Digital by Design, with most presentations lasting 15 to 20 minutes. The Technical Leadership Team’s Shift podcast provides monthly, in-depth discussions of technical decisions, distributed in audio and video with transcripts. The programs continue to evolve while facing content-maintenance and participation challenges.
How Shopify Scales Up Its Development Teams
The article argues that scaling development is primarily about creating more effective teams, not simply increasing headcount. It first recommends checking whether an existing team prioritizes impactful work, minimizes supporting activity, and can ship code quickly while finding bugs; otherwise hiring may be premature. Shopify organizes product work into problem spaces and teams of five to nine, uses a multi-step process combining technical exercises with cultural assessment, and aims for at least as many onboarded members as onboarding members. New teams receive a baseline for work practices and technology, while transparent technical design, shared tooling with dashboards and embedded quality and testing standards, optional pairing, and frequent retrospectives support consistency and learning. The conclusion is that these practices, rather than hiring alone, enable development teams to scale more effectively.
Pair Programming Explained
Pair Programming Explained presents pair programming as two people writing, debugging, or exploring code together, while explaining why Shopify uses it for knowledge sharing, collective ownership, learning, quality, and onboarding. It defines terms including problem, solution, driver, navigator, expert, novice, and disengagement, and stresses that the driver handles implementation while the navigator guides broader strategy and spots errors. Guidance covers when to pair, the trade-offs among expert-expert, expert-novice, and novice-novice combinations, and the risks of “watch the master” or disengagement. Suggested practices include switching roles with the Pomodoro Technique, using Strong Style or Digging for Gold, and holding a retrospective to discuss flow, learning, and tension. The article presents pairing as a focused collaborative practice that benefits from shared attention, regular breaks, and deliberate communication rather than an unstructured coding session.
Grab's Front End Study Guide
Rapid hiring and engineering expansion created a steep learning curve for newcomers and backend engineers unfamiliar with modern web architecture. Grab created an opinionated front-end study guide to help engineers navigate JavaScript tooling, state management, and modern application practices. The guide frames client-side single-page applications as a scalable alternative to traditional server-side rendering, enabling clear client-server separation for multiple client apps hitting the same backend API. It establishes core competencies in ECMAScript 2015 via Babel and explains how component-driven interfaces in React improve maintainability and performance through virtual DOM reconciliation. Ultimately, the resource aims to ramp up developer onboarding and accelerate shipping speeds across web platforms.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.