Posts Tagged with "an-elegant-puzzle"

Reference #31: An Elegant Puzzle

There are at least three classes of solutions within an organisation: process design, culture change, and organisational design.Read more →

Reference #32: An Elegant Puzzle

Small teams are not teams. At less than four members, a team is a "sufficiently leaky abstraction" such that it takes on attributes of an individual. At this point, a team is noticeably impacted by sick days and holidays.Read more →

Reference #33: An Elegant Puzzle

The steady state of a team should be 6-8 members. To create a new team, don't start with an empty team. Instead, grow an existing team to 8-10, then split into two teams of 4 or 5.Read more →

Reference #34: An Elegant Puzzle

Disassembling high-performing teams leads to a global loss of productivity. This is an argument against re-allocating team members to where the highest urgency is.Read more →

Reference #35: An Elegant Puzzle

The expected time for a team to complete a task increases with utilisation. This time approaches infinity as utilisation approaches 100%. This is an argument for building slack into your teams.Read more →

Reference #36: An Elegant Puzzle

To balance team utilisation, prefer to shift scope (responsibility) rather than people. This can be done rapidly to improve slack, by moving scope to a team with too much slack and away from a team with not enough.Read more →

Reference #37: An Elegant Puzzle

Specifically referring to software, systems survive one order of magnitude growth. For a system whose traffic doubles every 6 months, you will need to rewrite or reimplement it every 1.5 years.Read more →

Reference #38: An Elegant Puzzle

As observed in "The Phoenix Project", you only get value from projects when they finish. This means you must ensure some of your projects finish.Read more →

Reference #39: An Elegant Puzzle

Larson references the four measures of developer velocity from "Accelerate":Read more →

Reference #40: An Elegant Puzzle

A strategy is practical, detailed, and provides an approach to a specific problem. Write as many strategy documents as you need.Read more →

Reference #41: An Elegant Puzzle

In "Good Strategy / Bad Strategy", Rumelt describes a strategy as having three parts: diagnosis, policies, and actions.Read more →

Reference #42: An Elegant Puzzle

A large part of writing good strategy is acknowledging constraints. These often involve people or organisational aspects which are uncomfortable to acknowledge — but these constraints cannot be solved without explicitly calling them out.Read more →

Reference #43: An Elegant Puzzle

Bad goals are indistinguishable from numbers. It is unclear from reading them whether they are ambitious or why they matter. Good goals comprise four specific types of numbers: a target, a baseline, a trend, and a time frame. A target states what you want to achieve.Read more →

Reference #44: An Elegant Puzzle

Consider two types of goals: investments and baselines. Investments describe a future state you want to reach. Benchmarks describe parts of the present system you'd like to preserve.Read more →

Reference #45: An Elegant Puzzle

Push notifications, rather than dashboards, may be more effective when it comes to ensuring action is taken on changes to your goal metrics. Even small nudges like these may be enough to stir action.Read more →

Reference #46: An Elegant Puzzle

Migrations are the only way to make meaningful progress on technical debt.Read more →

Reference #47: An Elegant Puzzle

When considering reorganisations and an organisation's design, prefer explicit gaps of ownership and responsibilities over implicit gaps.Read more →

Reference #48: An Elegant Puzzle

Career ladders have a side effect of increasing competition. They funnel people at the same level towards a finite number of roles.Read more →

Reference #49: An Elegant Puzzle

Here's a brief primer on speaking with the media:Read more →

Reference #50: An Elegant Puzzle

One approach to leading without authority is "Model, Document, Share". This can lead to more adoption than a top-down mandate.Read more →

Reference #51: An Elegant Puzzle

Larger organisations tend towards centralised groups for product and engineering decisions. These are commonly "product review" groups for standardised product decisions, and "architecture groups" for consistent technical designs.Read more →

Reference #52: An Elegant Puzzle

When presenting a topic — either in writing or while giving a presentation — it is important to start with the conclusion and frame why the topic matters.Read more →

Reference #53: An Elegant Puzzle

To guide decision-making, consider your company (which includes other teams), your own team, and yourself, in that order.Read more →

Reference #54: An Elegant Puzzle

There three broad types of engineering management roles:Read more →

Reference #55: An Elegant Puzzle

As a manager, you should make your peers your first team. This means being able to disappoint your team to help your peers succeed; this comes from having a broad perspective.Read more →

Reference #56: An Elegant Puzzle

An environment of needing to "work harder" to solve mounting problem leads to the birth of hero programmers.Read more →

Reference #57: An Elegant Puzzle

These are two options to fix a broken engineering system — that is, one that is unsustainable and leads to hero programmers.Read more →

Reference #58: An Elegant Puzzle

Small companies tend to rely on referrals for job candidates. Large companies rely more on sourcing candidates.Read more →

Reference #59: An Elegant Puzzle

Most performance management systems comprise three elements: careen ladders, performance designations, and performance cycles.Read more →

Reference #60: An Elegant Puzzle

For the long-term success of a newly created role, you should frame it independently of other roles. Instead of defining a role by the tasks being offloaded from another role, provide it with a self-sustaining mission.Read more →

Reference #61: An Elegant Puzzle

In interviews, prefer to test for candidates showing — not just telling — strength.Read more →