The notion of Lean Staffing is best paired with the concept of The Lean Startup. He describes it in his book The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Eric Ries speaks of startup lessons learned at IMVU and from ther 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 goes deeper. He focuses on understanding on how to best find out what would best delights prospects, customers, and the market. He explores how to 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. This is an approach developed by Taiichi Ohno, one of the inventors of the Toyota Production System. It’s described in 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. It’s about finding, hiring, developing and retaining the adaptive talent. These become 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. This was done 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. People that collaborated to find solutions to problems they hadn’t solved before. Candidates that were excited about dealing with new challenges 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. 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 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 by our driving to reduce the push to live in production time down to 7 minutes. I ensured each new hire had a task of making some improvement to the new-hire spin up process. This ensured it was always current and improving. It also set the culture of always improving everything you touch. I also later did this at Twitch where we needed to scale rapidly. The emphasis was 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. 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. This was due to growing the engineering team and the number of changes and tests that were being added. The build dashboards had become typically more red than green. And, the fastest turn-around from pushing a change to seeing it in production had crept to over an hour. We made a concerted effort to improving our tests, rollout systems and load balancing. Doing this across over 100 servers, brought that time back down to under 7 minutes. For more on rapid iteration, see also Talent Code

Mentors

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.

Broadvision Experiences

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.