1.3Social Architecture Mapping

The technical system is only half the picture. The other half is the people.

Who Makes Decisions

Every organization has a formal hierarchy and an informal power structure, and they are rarely the same thing. The org chart says who reports to whom. The informal structure says who actually influences what gets built, how it gets tested, and what gets shipped.

Identify the key players:

• The architects and tech leads who shape technical decisions. Their opinions about testing will constrain what you can do.
• The product managers who decide what gets built. Their priorities determine what needs testing most urgently.
• The other QA engineers (if they exist). What is their approach? What tools do they use? What is their relationship with the development team? Are they embedded in feature teams or centralized?
• The developers who care about testing. Every team has at least one developer who writes thorough tests and values quality. Find that person. They will be your most important ally.
• The developers who do not care about testing. Every team has these too. They push code without tests, resist code reviews, and view QA as an obstacle. Do not fight them on day one. Understand their perspective first.

Cultural Signals

Pay attention to the small things. They reveal the culture more accurately than any company values poster.

Do developers write unit tests, or is testing entirely a QA responsibility? When a bug reaches production, is the reaction "let us figure out how this escaped our process" or "QA missed this"? Are QA engineers included in design reviews and architecture discussions, or are they brought in after the feature is built? Do sprint demos include test coverage alongside feature demos?

These signals tell you whether quality is a shared value or a department. That distinction shapes everything about your role.

The Unwritten Rules

Every workplace has rules that nobody writes down but everyone follows. Some examples from QA:

• "We do not block releases for test failures in the nightly run" (meaning the nightly run is informational, not gating)
• "We write tests for new features but not for bug fixes" (meaning regression coverage is growing more slowly than technical debt)
• "The mobile team does their own testing" (meaning there is a testing silo you need to navigate)
• "We use Selenium but we are thinking about migrating to Playwright" (meaning there is political context around tooling decisions)

You discover these rules by listening more than talking in your first two weeks. Attend every meeting you are invited to. Read Slack channels. Look at pull request comments. Read old Jira tickets and their discussions.