What enables a team to work efficiently?
Tldr: we should be able to do our work more efficiently in the office than out of it.
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.
Efficient teams can see individual tasks as part of a larger effort and think independently. The phrase “autonomy” speaks to this. A charter or set of core values helps. To quote Valve’s handbook (pdf): “A fearless adventure in knowing what to do when no one’s there telling you what to do.”
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.
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.
Given clear ownership and overarching goals, people should be able to self-organize.
HBR’s article “Beyond the Holacracy Hype”) discusses pros and cons.
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.
Provide folks doing focused work with uninterrupted time, eg “no-meeting Thursdays”, cancelling meetings for hackweek, etc. Paul Graham’s “Maker’s Schedule, Manager’s Schedule” and Joel Spolsky’s “Task Switches Considered Harmful” describe this well.
I’ve had success adding “focus” blocks to my calendar. During these blocks, I work from an undisclosed location and avoid chat and email. Outside these blocks, I work from my desk and am open to collaboration and interruption.
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.