• The key success factor is not tools or technologies, but collaboration between people.
• The biggest challenges cannot be solved alone, but only through exchange with others.
• Shared learning leads to better results than working in isolation.
• Collaboration between customer, partner, and platform provider significantly accelerates progress and requires organizational discipline and trust.

Cybersecurity is not a separate activity at the end of a project. It is a quality attribute that must be considered throughout the entire software lifecycle. Sometimes, Security by Design is also called Security First.

• Consider cybersecurity requirements during requirements gathering and w design - not just implementation
• Follow the principle of least privilege for users, processes, and services
• Prefer established security mechanisms and libraries over custom implementations
• Include automated security checks (static analysis, dependency analysis, etc.) in the CI/CD pipeline
• Consider how security updates and vulnerability disclosures will be handled throughout the product's support lifetime

Make work visible

• Share intermediate results, not only final outcomes
• Document decisions briefly (what + why)
• Default to open knowledge (wiki, gitlab, code)
• Rule: If others cannot see it, it does not exist
• Example:

  • Share WIP SQL / diagram instead of waiting for final version

Ask early

• Ask when stuck (>30–60 min)
• Clarify uncertainties early
• Avoid long solo trial-and-error
• Rule: Always provide context + options when asking
• Example:

  • “Tried A and B. A fails due to X. Option1: X, Option2: Y – preference?”

Think in drafts

• Share ideas early, even if incomplete
• Invite feedback explicitly
• Prefer iteration over perfection
• Rule: Draft before implementation (5–10 lines/sketch)
• Example:

  • Sketch pipeline before coding (raw → agg_1min → agg_1h)

Reuse before building

• Check existing solutions first
• Ask others for prior work
• Adapt instead of reinventing
• Rule: Spend a few minutes searching before building
• Example:

  • Check existing SQL/query instead of writing from scratch

Make decisions explicit

• Capture what was decided
• Capture why it was decided
• Keep it short and traceable
• Rule: Max. 3–5 lines per decision
• Example:

  • Context: Downsampling
  • Decision: SQL buckets
  • Why: Stable, simple

Work in small feedback loops

• Show progress early
• Validate direction before scaling
• Iterate in small steps
• Rule: Prefer many small steps over one big solution
• Example:

  • Test with 1 channel before scaling to 120

Normalize “I don't know”

• Ask questions openly
• Treat questions as contributions
• Avoid silent uncertainty
• Rule: Uncertainty must be visible
• Example:

  • “Not sure about X – is this assumption correct?”

Build trust through reliability

• Do what you say
• Communicate early if you cannot meet commitments
• Make progress predictable
• Rule: Never go silent on blocked work
• Example:

  • “Delay by 1 day due to X, new ETA tomorrow”

Focus on the problem, not the person

• Challenge ideas, not individuals
• Assume positive intent
• Be direct and respectful
• Rule: Critique = idea, not person
• Example:

  • “Approach seems complex because of X” (not: “you did this wrong”)

Keep it simple

• Prefer simple, robust solutions
• Avoid unnecessary complexity
• If it’s hard to explain, simplify it
• Rule: If you cannot explain it in 2–3 sentences, simplify
• Example:

  • Replace complex logic with simple SQL aggregation