Method

Principles and operating guidelines for effective, productive engineering in complex hardware development. 🚀

---

---

Principles

1. Engineers first.

   Any productivity, collaboration, or project management tools which are intended to form a critical part of an engineer's workflow shall be designed for their end-user: the engineer. Engineer productivity should be defended, so poor or frustrating user experiences must be minimised, and any onerous or duplicated reporting requirements eliminated.

2. Clarity of language.

   Repurposing tools from different disciplines can work, but agile jargon has no legitimate role in complex hardware development. In the interest of shared understanding, tasks should be known as tasks, and projects as projects. Priorities and severities should be defined via simple, easy to understand hierarchies.

3. Visibility and transparency.

   Excessive need-to-know policies cripple productivity, and exclude engineers whose contributions could mean the difference between victory and defeat. Within the core team working on a given programme, work should be shared early and often, and progress made visible to all.

4. Writing culture.

   Concise, written communications should be the default. Producing well written text forces careful consideration of the subject matter, and forces the author to structure their thoughts in a clear, readily consumable way. Time invested in clear and well written documents is repaid when downstream processes run smoothly, without the need for ad-hoc and repeated requests for clarification.

   Any verbal communications giving rise to significant changes in direction should be transcribed and shared.

5. Interrogable history.

   Readily enabled by good visibility, transparency, and an emphasis on writing culture, interrogable histories allow for engineering decision making to be tracked over time, for repeat mistakes to be avoided, and for staff changes to be gracefully handled. Departing staff do not leave a knowledge vacuum in their wake, and new staff can pick-up tasks without distracting others to ask for information.

6. Peer checking as standard.

   Mistakes are unavoidable, but their consequences need not be. Minor errors are often readily caught and corrected as part of a review and sign-off process—but this process must extend beyond drawings and change orders. Calculations, spreadsheets, simulations, configurations, and reports should all be subject to a fast, simple, flexible review process, and engineering tools should support this.

7. Opinionated tools.

   Opinionated software allows teams to take advantage of specialisation. With overly configurable products, engineering organisations must redirect resource to support configuration and maintenance of these tools, when their focus should be engineering. With opinionated products, that configuration and maintenance can be offloaded to specialists and subject matter experts.

8. Assigned ownership.

   Assigning ownership fosters engagement and autonomy. At all levels of the project, work items should be assigned an individual owner. The item's owner should hold responsibility that item, and should be empowered to deliver the desired outcome—whether that lies at the programme level, or the individual task level. Other team members may be required to contribute, but contribution should be directed by the item's owner.

---

Operating Guidelines

1. Use twin objective horizons and n-week cycles.

   Deadlines, even internal ones, can help create momentum, and help engineering teams progress through design iterations. A long-term horizon should be kept in mind for broader project objectives, while a short-term horizon helps create tight iteration loops and instils a feeling of momentum. On a regular, cyclical basis, the long-term horizon objectives should be considered, prioritised, and assigned to a limited scope milestone or n-week project segment. Two-week cycles are common in software, but this will be organisation-dependent.

2. Keep task scope small.

   When humans recognise a task or project as having been completed, the brain releases dopamine, and makes us feel good about ourselves. We can leverage this to establish a positive feedback loop, making engineers more motivated to work harder, achieve their next goal, and unlock more dopamine. This is best enabled by keeping task scope small so that individuals receive that positive feedback on a regular basis—rather than facing a vast and seemingly impenetrable task, with no opportunities for regularly checking items off the list (and triggering that dopamine release).

3. Try to mix disciplines.

   Engineers assigned to the same project can be grouped and seated together, even when they have diverging specialities and objectives. Cross-pollination of ideas can offer immediate benefit, and cross-functional teams help prevent siloed and fragmented 'us vs. them' cultures developing.

4. Run weekly retrospectives.

   Run a brief weekly meeting, along the lines of a 5-15. Go around the room and for each contributor note down:

   • Accomplishments for the week.
   • Priorities for next week.
   • Challenges foreseen.
   • Lessons learned from the week.

   As you build a repository of these notes, you get a clear sense of how things are progressing beyond what's measured by tasks completed or milestone progress statistics. It's also another way to help celebrate success within the team, sharing achievements that might not otherwise be discussed—and helping unlock more of that dopamine release.