Team efficiency

Problem

What enables a team to work efficiently?

Solution

Tldr: we should be able to do our work more efficiently in the office than out of it.

Product ownership

Product management collects, aggregates and channels customer feedback to engineering.

Product prioritizes feature work and coordinates with engineering to delegate ownership, which enables engineering to allocate resources efficiently.

Systems-level thinking

Efficient teams can see individual tasks as part of a larger effort and think independently. The phrase “autonomy” speaks to this.

One team

Ownership for a product should fall within a single team for that team to move efficiently, as opposed to splitting ownership across multiple teams, who then must coordinate closely to ship anything.

Recognition

A team’s domain ownership should be broadly and consistently asserted, to avoid fighting for space and awareness. Join the team to work in its associated space or identify an uncontested space to work in.

Bottom-up innovation

Enable engineering to gain customer perspective and contribute to product development, and release pressure when product backs up, by clearly identifying channels for bottom up innovation.

Identify acceptable deploy channels for individuals, eg spend 20% of your time on self-motivated projects; attend internal “entrepreneur school” to associate with other independent developers and learn best practices; define a “labs” channel to enable low-friction deployment without polluting the main product offering; publish to your blog with this disclaimer and your github with this license.

Encourage sample app development. (Hopefully, a team’s tooling will be the most efficient option, but if not it’s feedback.)

Publish feature prioritization so side-projects have an “on ramp” back.

This relates to product ownership in that an engineer working on a side project is her own customer.

Focus time

Provide folks doing focused work with uninterrupted time, eg “no-meeting Thursdays”, biasing to Mondays and Fridays for meetings, etc. Paul Graham’s “Maker’s Schedule, Manager’s Schedule” and Joel Spolsky’s “Task Switches Considered Harmful” describe this well.

Infra product

Treat internal infrastructure as a product, complete with office hours, support rotations, documentation, SLAs, etc, to enable efficient application development on that infra. Mark McBride discusses this in the “Teammates as Customers” section of his post Coworkers Will Become Customers—It’s a Good Thing.

Feedback

Thoughts? Suggestions? Hit me up @erikeldridge

License

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 International License, and code samples are licensed under the MIT license.