Engineers want to write robust, efficient code that's been thoughtfully put together, and can appeal to all potential use cases. This is often in opposition to how lean products should be built, especially in early stages that are focused on learning. With a team that's practicing lean, how do engineers get fully engaged as active participants? Evan Henshaw-Plath of Neo interviewed Melissa Sedano (Chief UX Officer at BloomBoard) and Sam McAfee (Director of Web Engineering at Change.org) about how their engineers are now 'thinking lean' through all stages of development.
Never start with code
One approach that Melissa strongly believes in is doing anything and everything her and her team can - before writing any code. You hold many assumptions ahead of time, and need to first create non-code iterations first, with paper prototypes and clickthroughs. Only after putting those in front of customers can you encourage and prove to engineers that what they're building has had time spent on it, and will lead to a valuable learning experience that have been pre-vetted.
Two Streams - Validated vs. Unvalidated
After Sam arrived at Change.org, they adopted a new approach to separate their engineering team's time into 2 distinct types of work - Validated vs. Unvalidated. For unvalidated hypotheses, the aim was to build as quickly as possible - whereas validated projects were based on learnings that had been validated previously. Differentiating to the engineers which type of project they were working on was an extremely meaningful description that was given up-front, before any code was written. It gave their engineers a very clear goal, with expectations around robustness of code and cycle time.
Focus on learning
Running learning experiments leads to rollercoasters - you find one change that creates a 10% lift, but only after you've run 8 (or 80) other experiments. One key step that the panelists spoke about was reorienting engineering goals around learning versus long-lasting, clean code. If you're not able to clearly articulate and announce this goal, people will tend to revert to whatever they're comfortable with as an indication of progress and quality - which, for engineers, is often robust, efficient code. Focus on the fact that learning quickly actually leads to less wasteful code, and allows engineers to only build and spend time of what really works.
Exposure from soup to nuts
Getting engineers involved at all stages of the product is another great tactic to help encourage more technical team members to gain a better understanding of the ultimate learning goals of product iterations and experiments. This means always having open invitations to everyone on the team to usability sessions, customer interviews, and any other ways for team members to actually connect with customers. At Change.org, notes from their customer sessions are circulated to everyone at the company in case they were unable to attend, so they can at least reference the materials when there are questions around why or how to build something.
There was mention amongst the panelist of a future when anyone at a company could commit code, and they spoke about how the design process has slowly migrated from specifically the 'designers' to other category-experts throughout various organizations. Everyone saw the value of such an approach with respect to engineering (in theory), but admitted that it's still quite a reach from where most startups are today. For now, the best approach to allowing lean to penetrate all aspects of a company is to work smartly with engineers on how to best leverage their skills and capabilities, and encouraging lean throughout their efforts by promoting clarity and orienting around learning.