Skip to content

Latest commit

 

History

History
55 lines (39 loc) · 2.59 KB

README.md

File metadata and controls

55 lines (39 loc) · 2.59 KB
Raw

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) 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!