# Welcome!

> Software engineering is not computer science,\
> And computer science is not coding;
>
> Better engineering practices improve predictability of costs and schedules,\
> provide early warning of problems,\
> support better management,\
> and reduce risk of overruns.

## We are Product Engineers

We do more than just write code, we’re more than just a feature factory.

We are co-owners of the product experience. We look at the full picture to understand the value and impact of what we’re building.

We contribute to the full spectrum of a product’s development; from PRD [(Product Requirements Document)](https://en.wikipedia.org/wiki/Product_requirements_document) to code to tests.

We regularly talk to customers and end users; we rigorously analyse and measure the performance of features, and unearth opportunities to improve.

## High alignment, High autonomy

Alignment and autonomy are two important axes which can be used to classify teams:

1. *Low alignment, low autonomy:* micromanagement culture, shut up and follow orders, teams have little understanding about why they’re moving in a particular direction
2. *Low alignment, high autonomy:* helpless leaders, teams do whatever they want, things go everywhere and nowhere at the same time
3. *High alignment, low autonomy:* strong leadership and organisation direction, yet leaders end up giving instructions to teams on what to do and how to do it too
4. *High alignment, high autonomy:* This is where we want to be! Leaders focus on what problems to solve; teams are strong and independent enough to figure out how to solve them!

To get this degree of alignment, our teams must adhere to a set of non-negotiable standards—**The Obvious Way**—which include:

* A common vocabulary to enable strong communication
* Code formatting and style guide
* Pull requests and reviews
* Git process and trunk-based development 
* System architecture
* Daily standups 
* Iteration planning 
* … and more!

## Structure and Process

Every time we’re trying to change people’s behaviour, we need to start them off with a lot of structure, so they don’t have to think. A lot of what we do is habit, and it’s hard to change those habits, but having very clear guardrails can help us.

{% hint style="success" %}
Trust is more important than control!
{% endhint %}

* We don’t want people in the team who we cannot trust.
* To be agile at scale, requires trust at scale.
* No politics and no bullshit, means no fear.
* Fear kills trust and innovation
  * If failure gets punished, no one will try new things
  * The organisation as a whole will suffer!