Inside Menlo Innovations - an Intro From an Ex-Menlonian

I was in start-ups and being somewhat of a road warrior.  My own start-up won an Inc. Web Award, I'd been to Dubai, and then I had to get divorced.  Without going into much detail, what it meant to me was that I had to do something to support my family that didn't mean weekly travel.

Enter Rich Sheridan, CEO of Menlo Innovations.  At this point I can't recall who made that introduction, but I do remember what they said: "you HAVE to have coffee with Rich!"  There's something about a combination of passion and story telling ability that makes Rich one of the more captivating people to talk to.  He met me and then invited me up to see Menlo...I was instantly in love with the place.  The walls were full of paper, the air was a-buzz with the chatter of innovation.  I couldn't help but want to be a part of it.

You can't just pass an interview with Rich to have the opportunity to work at Menlo.  You have to go through an "Extreme Interview,"  This means a cattle-call style interview, at night, with (in my case) over 40 other interviewees all in the same open space.  Rich introduces himself, welcome's everyone, and advises those there to get work: "your job is to get the other person hired."  After that, it's pairing with three different people on three different tasks all while being watched by three different "facilitators" who are already do work for Menlo.

As facilitators, you look for things like sense of humor, ability to share the pen, accept ideas from their partner?  Are they overbearing or do they listen well to their partner?  How do they do under the pressure of trying to get progress on an hour long task when they only have 20 minutes to complete it?  At the end of the night, when candidates leave, facilitators gather for dinner, pictures of interviews are projected on a screen, and the three who observed the tasks vote with thumbs (up, down, or middle for undecided.   If there isn't a consensus, discussion, sometimes very passionate and spirited discussion ensues.   Successful candidates progress.

Because all team roles pair at Menlo, the next step is to pair in with different projects in one day, then 3 days, then a week, then three weeks if you are successful.  With feedback all along the way.  Success means that you are generally back on the schedule every week - as long as client work remains. 

I was lucky to be on that schedule for almost 3 years in the late 2000's.  Lucky because it allowed me to learn Agile from soup to nuts, lucky because it enabled me understand how Innovation and Lean Start-up work as a system, and lucky to work with passionate and brilliant fellow Menlonians.  Personally, those were the roughest three years of my life, but professionally I still pull from that experience at least weekly to inform the way I think about my company, my clients, and my work.

In my next Menlo related post, I'll talk more about Menlo's process, in the meantime you can read Rich's book, "Joy".

Digital Mindset vs. Mergers and Acquisitions Mindset

In my career in start-ups and as an executive in the Digital Space, it's become very clear to me that leadership mind-set matters.  ALWAYS.   Everything from company strategy, goals, to culture are all set from the top.  Whether or not they are formally communicated, or left to trickle through the rumor mill,   the organizational ability to Innovate using Lean-Start-up, Design Thinking or even Agile relies on leadership's formal or informal point of view.  How does your organization rate on Leadership Mindset?  

I've worked with and for a variety of companies in "Growth Mode," but growing doesn't mean ORGANICALLY or with an innovation mindset.   Public companies are especially subject to Mergers and Acquisitions vs Innovation mindset, but here are some ways to tell whether your efforts in Innovation and Digital Transoformatin will get support, or be slow-rolled by leadership.

If you are already in the process of buying another company, this may be a tip-off but here are a few reasons that leadership may even be in the middle of an acquisition but STILL support a Digital Transformation:

  • They are buying a company that has a new technology it would take longer to build internally
  • An acquisition is successful in a key market that would compliment your company's existing buisiness
  • The employees of the Acquisition target possess skills sets that aren't present in house

 If any of these ring true that's great!  Many times, however, a company will be merge with a competitor to GROW SCALE.  This point of this is, generally, to keep from being disrupted by becoming a bigger player (too big to fail, anyone?).  This pleases investors, feels to leadership that they are building a company that can win on scale alone,  and increases market share and profitability without the need for Innovation, Product or Design Thinking.  This is the mindset that will kill (or at least slow roll) any Digital, Lean, or Agile mindsets that may have been forming within parts or the organization.  The mindset here will be integration and consolidation only - at least in the short term.

Keep this in mind and weigh how fast and where you start with Digital in your organization.  Start small with the willing, and have a lot of success to show leadership before expanding. 

Lean and Agile, or Lean vs. Agile? (hint: depends on why you ask)

When you've been through a Lean Transformation, you have probably started thinking about how technology fits into all of this.  I have been asked to speak on this subject several times, but reason organization ask for a session can be quite different.   One of the most common asks is very general, along the lines of "Can you come in and explain to our organization what the difference is between Lean and Agile?"   Below is a look look at some of the underlying questions that organizations face with regard to Lean and Agile Transformation, taking Lean into Technology Organizations, or communication between practitioners of "Lean" and practitioners of "Agile".

  • We use Huddle Boards, they have Stand-ups - can't we all just use the same tools and aren't the the same thing anyway?
  • Why won't technology understand the concept of standard work?
  • Agile looks a lot like Lean, so why is this a separate effort?
  • Lean is so much more powerful and proven valuable, why aren't is our company leveraging Lean more?

On a principle level, there is no difference between Lean and Agile.  Both are about leveraging data, respecting people, problem solving, and continuous improvement and both grew out of Lean Manufacturing (yep, Agile did too).  For years, Lean was used for problem solving in Manufacturing, whereas Technologists started leveraging Lean thinking to solve the much more constrained problem set of early and frequent delivery of valuable software.  Fair enough.  Right?  Not really.

Depending on how your Lean Implementation went and how any Agile Transformation is going, both your Lean and Agile work may get stuck at the team level.  Setting up in cross-functional teams saves time, people like it, and work is proven to get done faster, but it can also results in Lean teams (on the business side) and Agile teams (within technology) working separately, not having of view of why they exist.  We then choose a tool set,  a structure, a process, roles.  We stop at one M (in Lean terms), or SCRUM/Kanban teams (in Agile).  

If change efforts (whether Lean or Agile) are not rooted in delivering on Strategic BUSINESS Imperatives,  then expect to bogged down in roles, org structure, HR issues, and language wars.  Both Lean and Agile are both a means to an end and that end is the success of the company.  A well articulated and implementable strategy with success measures (KPI's, yes) allows your people to be principles based, success driven and enables employees to organize, collaborate, and prioritize to deliver to strategic goals - the results will be both lean and agile.

Cross-Functional Demystified

I was speaking at a conference a few weeks ago and got a question about Cross-Functional Teams.  The way he asked the question, it was clear what he meant - he meant "how do I get QA to work with my development team?"  It may shock you to hear me say that having a SCRUM team of Developers and Testers does NOT mean the team is cross functional.  I'll explain:

In football you have catchers, running-back, quarterbacks, defensive lineman, etc.   If the opposing team fumbles the ball right in front of a lineman what does he do?  Stand there and say "Where are they guys who are supposed to run this ball?  I don't run the ball.  HELP!!!"  No.  He grabs the ball and runs as fast as he can...sometimes even being responsible for the game-winning touchdown.  That's what we mean by being cross functional.  How does this football player know what to do?   He knows it's his responsibility.  He knows the rules of the game.  In addition to his squad work, he works with the rest of the team on real plays in true game scenarios.

So what am I saying?  Have the SKILL SETS on the team is one thing.  Having people who are given permission to, expected to be and TRAINED TO BE cross-functional is something else.  Cross-Functionality isn't just a skill set it's a MINDSET that breaks silos across disciplines and hierarchies.  It has to be taught, recognized, and rewarded because it isn't easy.   The risk of not being cross functional?  Bottlenecks and your organizational "dropping the ball" in the market, losing to competition, and falling behind on the innovation curve.

Check back for a post about how incentives can help.