Engineering Team Hub

Engineering Engineering at Northstar A starting point for Northstar engineers and partners across office and frontline locations. This fictional gallery example brings team practices, architecture guidance, on-call resources, and design records into one place. Confirm Northstar-specific details and app access before publishing. Go to a team resource Choose the page that matches what you need. How We Work See the example team rhythm and onboarding sequence. Architecture Overview Browse architecture topic areas and find maintained documentation. On-Call Learn what to confirm and where configured on-call details live. Decisions & Designs Find guidance for decision records and design documentation. What belongs here Team rituals and onboarding: start with How We Work . Its cadence is an illustrative example, not a confirmed Northstar schedule. Operational on-call work: use Northstar's On-Call app for configured schedules and operational details. The app's availability, team coverage, and access depend on Northstar's configuration. Maintained team knowledge: use the Wikis app for current onboarding material, architecture documentation, decisions, and designs. This site is a guide to those destinations, not a replacement for their authoritative content. How We Work Team rhythm and onboarding Use these examples as a starting point; confirm the actual team cadence and process with Northstar engineering owners. A useful team rhythm makes work visible and gives colleagues a reliable place to raise questions. The cadence below is illustrative, not a Northstar commitment: a weekly planning check-in, a brief asynchronous status update, and a monthly review of recurring work or learning. For each recurring ritual, confirm its purpose, audience, owner, where notes are kept, and how colleagues who cannot attend can contribute. Northstar engineers work across office and frontline locations, so publish accessible notes and avoid making attendance the only way to get essential context. A practical onboarding sequence The example sequence helps a new colleague find the right owner and current material. Northstar team owners should confirm the actual onboarding steps and maintain the detailed guidance in the Wikis app. Confirm your team and access Ask your manager or assigned onboarding contact which engineering group you are joining and which tools and spaces you should be able to open. Read the maintained team guide Open the Wikis app and find the current engineering onboarding material. If you cannot locate it, ask the team owner to identify the authoritative wiki. Review how the team coordinates Check the team's confirmed rituals, documentation expectations, and handoff practices; do not assume this sample cadence is in use. Confirm operational responsibilities If your role includes on-call work, confirm eligibility, training, and team coverage before taking part. See the On-Call page for what to verify. Upcoming engineering events Architecture Overview Architecture overview Use this page to orient yourself, then consult the maintained documentation in the Wikis app. This gallery example does not assert which systems Northstar runs or how they connect. The topic areas below are a reading guide only. Confirm Northstar's actual services, boundaries, data flows, and ownership with the relevant engineering owners before adding company-specific architecture claims. For a system change, use the current architecture documentation and diagrams in the Wikis app as the source of truth. If a diagram or description appears out of date, ask its owner to correct the maintained record rather than creating a competing copy here. Topics to document These are documentation categories, not claims about Northstar's implemented architecture. System boundaries Describe the responsibility and boundary of each confirmed system or service. Name the owning team or role. State what is in scope and what is not. Link to the maintained system page in the Wikis app. Interfaces and dependencies Record confirmed interfaces and dependencies so a reader can understand where a change may have effects. Identify the source and destination of each documented interaction. Record relevant constraints only when confirmed by the owner. Keep diagrams and written descriptions consistent. Data and operational considerations Explain only verified data handling and operational characteristics relevant to the design. Use the organization's approved terminology. Identify the owner of the documented information. Separate known behavior from assumptions or open questions. Find the maintained architecture material The Wikis app is the destination for current architecture documentation and diagrams. Confirm the authoritative wiki locations and page owners with Northstar engineering before publishing this hub. Open the Wikis app and search for the system or architecture topic you need. Check the wiki page's owner and last-maintained context before relying on it. Ask the listed owner to correct a diagram or description that no longer matches the confirmed design. On-Call On-call work at Northstar Use the On-Call app for configured schedules and operational details. Northstar's On-Call app is the destination for on-call work when it has been connected and configured for your team. Schedules, service coverage, eligibility, and app access must be confirmed for each team; this sample does not define incident response or escalation procedures. Before joining a rotation, verify the current team guidance and confirm that you have the required access and preparation. Use only the operational instructions maintained by the responsible Northstar team. What to confirm before a rotation These checks are preparation prompts, not an incident procedure. Confirm coverage and eligibility Ask the responsible team owner which service or team the rotation covers and who is eligible to participate. Check app access Open the On-Call app and confirm that the schedule and operational details for your team are visible to you. Read current team guidance Review the team's maintained instructions and preparation requirements; do not rely on this hub for response steps. Resolve open questions before starting Ask the confirmed team owner or help route about gaps in access, coverage, or instructions before accepting on-call responsibility. Open the On-Call app Schedules and operational details appear there only when Northstar has configured them for your team. App access, team coverage, and the correct help route are Northstar setup checks. Use the On-Call app to check the schedule and details available to your account. If your team or schedule is missing, contact the Northstar owner or help route confirmed for the app. Owner and correction route Setup required before publication. Do not publish a team as covered until its owner has confirmed the configuration. Configuration owner Name the role that owns each team's on-call configuration. Correction route Name the approved route for access or schedule corrections. Review trigger Name the trigger for reviewing this guidance. Decisions & Designs Record decisions and designs The Wikis app is the maintained home for engineering decision records and design documentation. Decision records Use a decision record to make a significant engineering choice understandable after the discussion has ended. A useful record states: The context The decision The alternatives considered The consequences The owner or date, when those details are confirmed Design documentation Use design documentation to explain the intended approach, relevant constraints, and links to confirmed architecture material. These are documentation examples, not claims about a specific Northstar system or decision. Keep the authoritative record in Wikis Keep the authoritative record in the Wikis app. Link to it from relevant team discussions or work items rather than maintaining competing copies in this site. Find or maintain a record in Wikis Search the Wikis app for the current decision or design page. Confirm the team's decision-record convention and wiki locations with Northstar engineering owners. Check whether an authoritative record already exists before creating another. Ask the record's owner to update it when the decision, design, or confirmed context changes. Keep links to related architecture material together in the maintained wiki record. Keep records useful Page owners should check that the record still reflects the confirmed decision or design when the work changes, a decision is superseded, or an owner identifies an error. During setup, assign a responsible role for this page and provide an approved correction route. Do not imply that a record has been reviewed until its owner confirms that review.