The notion of Lean Staffing is best paired with the concept of The Lean Startup. In his insightful book The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries speaks of his startup lessons learned at IMVU and from many other companies he came to know afterwards including Intuit. He speaks to the processes behind effective startups; Lean Staffing speaks to the people behind those same types of startups.

In The Lean Startup and also his more recent book, The Leader’s Guide, Eric focuses on understanding on how to best find out what would best delights prospects, customers, and the market, how to build to that learning and gain adoption through minimal viable products, experiments and iteration into continuous improvement. If you haven’t read them, I highly recommend Eric’s books and the approaches we used at IMVU.

One concept he speaks of is the 5 whys, an approach developed by Taiichi Ohno, one of the inventors of the Toyota Production System and described in his book Toyota Production System: Beyond Large-Scale Production. Eric points out: “what started as a technical problem actually turned out to be a human and process problem.“ He frames startup as human institutions navigating uncertainty. I remain a strong proponent and having adopted of the Lean Startup principals. This site focuses more on the rest of the story: finding, hiring, developing and retaining the adaptive talent – the innovators and entrepreneurs that thrive on uncertainty to arrive at novel and compelling offerings.

As Paul Harvey used to say “and now, for the rest of the story…”

At IMVU, we also focused on hiring and developing engineers that loved challenges and loved to iterate and move fast. This included an interview process where each question was set up to get harder and harder until we had pushed beyond the candidates comfort zone. We did this because we wanted to find people that loved to think on their feet and collaborate to find solutions to problems they hadn’t solved before. If at the end of several such sessions a candidate was pumped about dealing with new challenges – they were a fit. If that sort of thing drained them, well then, not so much.

I still remember one of our architects Chad Austin coming out of an interview and shaking his head. I asked what was wrong. He said that interview was totally useless. Why? Because he had asked her to explain the internet and he kept going further and further to various bizarre edge cases and she always just knew the right answer. She was never outside of her comfort zone. He hoped someone else would find an area she was not so well versed in. We needed to see how she would think on her feet and collaborate with the interview to solve problems in unknown territory.

Starting on Day 1

We also had a tradition that every new hire was expected to push a change to production on day 1. This was enabled in part by our driving to reduce the push to live in production time down to 9 minutes. I also underscored that every new hire had a task of making some improvement to the new-hire spin up process to ensure it was always current and improving. I also later did this at Twitch where we needed to scale rapidly. The idea here was to put emphasis on the fact that engineers were hired to make an impact as early as their first day. At the end of their push, they’d send out a company wide email with something along the lines of…

• I pushed a change to production that improves the customer experience by xxx
• I added testing for my change
• I tested it locally and in product

This email was then responded to by everyone from the CEO down saying Welcome to IMVU! The implied message was that you were now part of the team as you had made your first improvement to the product on your first day.

Rapid Iteration

By the time I’d gotten to IMVU, the rapid iteration had slowed down quite a bit due to growing the engineering team and the number of changes and tests that were being added. The build dashboards had become typically more read than green and the fastest turn-around from pushing a change to seeing it in production had crept to over an hour. By putting a concerted effort into improving our tests and rollout systems and load balancing our testing across over 100 servers, we brought that time back down to under 9 minutes.

We also had a notion of an assigned mentor that would have some work in mind before a new hire started. It was their full-time job for a while to bring you up to speed. I describe this further in my post on Spinning Up New Hires. Wherever I go, I introduce the notion of having each new-hire/mentor pair make continuous improvements to the spin-up process.

We also introduced the notion of continuous improvements to our processes. A new change, such as using Story Point Poker would be introduced at the beginning of a sprint in terms of its intent and how it might work. We then discussed at the retrospective if the process change was effective, how we might improve it to try again in the next sprint or just throw it out as it didn’t work for this team. Hence, applying the principles of minimal viable product, experimenting and continuous improvement to our internal processes. At one point, I remember realizing that we were leveraging five very distinct development process within the company – each was arrived at being what was best for that team, the area the were changing and the constraints of the technology and releases (e.g. mobile vs web).

5 Whys

The notion of root cause analysis and 5 whys was not only effective in understanding why something worked different in production than expected. It also helped change the mindset of our engineers to be welcoming of taking risks and actually finding value in things breaking as a mechanism for not only improving the product but also the resiliency of our systems. It fostered a Growth Mindset (something I learned about from a colleague of Carol Dweck while I was getting my K-8 teaching credentials) in our engineers that encouraged them to not only continuously improve the product but everything about the company and themselves.

I have carried many of these principles forward into companies after IMVU while also continuously improving upon them after I left IMVU to triple the size of Twitch’s engineering team as their VP of Engineering and help them get acquired by Amazon for ~$1B. I then brought along many of these principles as I went back into hard-core enterprise software and hardware at Pure Storage where I was asked to come by several former IMVU colleagues – Pure became the fastest growing infrastructure company that went through a unicorn IPO and have since been brought on as VP, Engineering at Prosper largely because of my ability to impact the effectiveness of engineering teams.

In my role as VP, Engineering at BroadVision which during the dot com days was the fastest growing company of Nasdaq we achieved a $26B valuation. I managed multiple teams each supporting a product line (procurement, business-to-consumer e-commerce, business-to-business e-commerce, knowledge management, content management, online banking and billing). Each of these teams was 6-11 engineers and each competed with entire companies solely focused on one of the product spaces – we outperformed them all to a large extent because of the caliber of the people I hired and how we grew and leveraged the skills they had. More on the notion of high-functioning engineers: 10x Engineer – The Root Cause.

This Blog

The blog posts, links and references found here (at TalentWhisperers.com) focus on understanding how to find, inspire and retain people with growth mindsets that will contribute to your collective success. People that love to innovate, experiment and learn to make up cross functional teams as described in Eric’s books and talks. My insights start with my experience in software development dating back to the 80s and then enhancing what I found at IMVU in 2010 and beyond. Many of the sources referenced throughout this site certainly also continue to contribute to that knowledge.

CD

P.S.

In 2005, right about the time Eric was growing IMVU, I joined Intuit after a K-8 teaching hiatus. On my first day at Intuit, I was handed the book The Innovator’s Dilemma: The Revolutionary Book That Will Change the Way You Do Business and told to find a way to disrupt the business. Interestingly enough, I was hired into Intuit by the GM of the QuickBooks Payroll business who later became CEO of IMVU and enticed me to follow him there right after Eric left on his adventures as an evangelist of Lean Startup principles.

Also, all the avatars in the image above were ones I created while working at IMVU as part dog-fooding the product and getting to know the product and customers.