CodeDrivenNYC: Tools and methods to make development teams more productive
Posted on March 23rd, 2016
03/22/2016 @FirstMarkCapital, 100 Fifth Ave, NY
The speakers spoke
- James Turnbull, CTO at Kickstarter: From Rails for Reasons?
- Evan Whalen, Engineering Manager at Blue Apron: 8 Habits for Productive Teams
- Dustin Lucien, CTO at Betterment: Fluid Teams: How Betterment Builds Product
Evan Whalen@BlueApron (recipes and ingredient for those recipes delivered to your door) talked about habits of productive teams. He emphasized three points
- Psychological safety
- 8 habits of productive teams
Psychological Safety. The Google Aristotle Project concluded that successful teams fostered a feeling that team members support each other. They called this psychological safety as members were secure that other team members wouldn’t embarrass them.
8 Habits. Evan takes his inspiration from Stephen R. Covey. He main points were:
- Be proactive – clearly define responsibilities to set expectations. Members need to share responsibility
- Begin with the end in mind – convey purpose, not urgency. Future-proof APIs and schemas
- Put first things first – make engineer happiness a priority – support passion projects
- Think win-win – have regular communication with key players to create mutually beneficial solutions
- Seek for to understand, then be understood – encourage face-to-face conversation, brown bag tech talks, group code reviews, etc.
- Synergize – empower through delegation. Cross-team communication : avoid working in silos, be transparent on work priorities
- Sharpen the saw – give immediate feedback – radical candor (see Kim Scott post) – challenge directly but care personally
- Find your voice and inspire others to find theirs – balance support with delegation
Feedback. Every 6 months developers are anonymously surveyed (using Glimpse) as to their happiness and empowerment. From this information create a task list of 3 areas for improvement.
In the second presentation, Dustin Lucien @Betterment (financial planning leveraging automation) spoke about their dynamic process to best match the needs of the company with the skills and interests of individuals. They do this with a mix of teams responsible for specific products/functions (home teams) and small, mission-driven teams (pods) working on specific projects.
The flexibility to move developers from home teams to short-term focused pods avoid silos and spreads knowledge and expertise through the company.
To allocate individuals to these special projects, Betterment uses an auction system. Inspired by work done at Pandora, each customer is given a value of $5/month and the total revenue for customers affected by new products/services is auctioned. Team leads submit projects and individuals bid on them. Management determines the makeup of the pods based on the individual interest and level of enthusiasm for each project (as indicated by the bidding). This process of creating new projects and assigning individuals to pods is repeated every 60 days. Management also makes sure that there are still sufficient resources in the home team (20% to 40%) so the home teams can continue their functions.
But as the company has grown, challenges have increased to this model.
- They have 3 strong lines of business, so fungability of skills across the organization is more difficult.
- The maturing of products demands more stability in the resource allocations.
- As a result they will probably move to a 90 day cycle.
- They will adjust plans to emphasize ROI on OKR.
- Other the other hand, teams are now large enough that they can now adjust their own resources to accommodate new projects.
Dustin noted the role of management. Pods are created with at least one person with leadership aspirations. Also the company is still small enough (currently 150 people) that everyone knows everyone else. New hires are put in “bands” to encourage rapid assimilation into the company. Groups in pods have often worked together before.
He also noted that pods are allowed to deviate from the original plan. But the pods and the teams need to operate under the leadership of an architecture group (which is outside the teams and pods). That group determines the overall system architecture and reviews the development process and outputs.
To close the presentations, James Turnbull@Kickstarter talked about how they went about upgrading the tools used in their development stack.
When Kickstarter was started they chose Rails as their development tool. As usage of the site has grown, they have come to realize that they needed to rearchitect the site. James said the issue was not scaling, it was resilience as breaks in one part of the code often created issues with other parts of the code. They decided to replace the monolithic Rails application. They did this using a process involving the entire development team. All members of the development teams worked on the following steps:
- Specify broad conditions that the new system needed to satisfy
- Do a broad paper bake off – compare many languages: JRuby, Clojure, Go… – consider the community, prior art, etc.
- Create a short list – Ruby, Java, Clojure
- Do a real world bake-off: create the code for the comment subsystem to test authentication and monitoring, etc. Ask whether there are their developers familiar with the language? Will it run faster? Does it scale? How convenient is it to use. Is there a body of people who have solved these problems before?
- Made a decision. The development team conducted a town hall meeting in which groups who had worked on the bake-off code presented pros and cons to the whole team. They decided to use Java.
- The big win was developing a process to make decisions. For future development, individuals or small groups can propose experiments on technology that the group as a whole could use. They can then conduct a smaller version of the above process so the group as a whole can learn from the smaller group’s experiences.