The economy strikes back against coronavirus

My take with Katina Stefanova on Coronavirus and how silicon valley can step up here.

https://www.forbes.com/sites/katinastefanova/2020/02/26/the-economy-strikes-back-against-coronavirus-interview-with-noah-kindler-former-executive-at-canoo-and-knotel/

#coronavirus #coronaviruschina #innovation #venturecapital #startups

Automotive hates agile: Phased delivery and governance

I want to thank my fantastic (twice) former colleague Amin Ariana for much of framework here.

I experienced huge frustration here, and wanted to share thoughts on why.

Two accepted principles of almost any automotive product development are: Phased delivery and governance.

Typically, powerful parts of the organization, that control significant resources will manage both of these, in the name of, "coordination," and "watching the money."

Phased delivery:  Programs are divided into phases, with various interim milestones before full production: alpha car, beta car, pre-production, low-volume, etc.  For each phase, there are a set of requirements, which become more complete overtime. 

This naturally appeals to people because each milestone allows for judgment on what is 'ready' and what is 'behind.'  It also forces decisions (vendors, engineering trade-offs) that otherwise might end up in paralysis or continually pushing for a better deal.

Governance:  By its nature, this is a group of functions that track progress, are involved and often approve major decisions, and apply countermeasures and involvement when they perceive need.  Two of the most common ones in automotive are: 1) vendor approval, and 2) budget/internal hiring.

Effectively, to get access to resources, such as hiring contractors, hiring internally or using other vendor products, someone outside your group needs to be convinced.  While this in theory provides an important counter to 'going rouge' or lack of accountability -- in practice, it gives a ton of power and input to non-experts, who typically set up a process for non-software parts of the business, and then demand compliance in the name of, "I watch the money carefully," or, "I want to make sure it all comes together," and force non-agile into the system.

The challenge here is that automotive is just not set up for agile.  Even if a sub-culture can work this way, there are lots of functions that simply don't care, and gate resources.  They block agile, slow down quick decisions and force large requirements, which are inevitably pulled up at a later date for, "where are we on this?  You gave this to me..."

So, what to do:

Often, when stuck in this trap, people try to work around it.  Thinking, well, I'll just fill out the form, but we can all shake our head in agreement when we say we're agile.  Good luck.

Instead, explicitly opt out of this at the beginning, but propose an alternative.  Include the vendor, governance and other such teams in sprint planning sessions.  Bring them into the tent.  Make sure that the person/people involved is sufficiently senior to actually approve, and not just a token person tracking progress. 

Agile is tough in this environment.  The system rejects it.  There are teams built to reject it.  We naturally want to please people and try to be helpful for their "board presentation on what we're delivering over the next 9 months.  "Just a few bullets."  "Now, a bit more detail, like everyone else has."

Just say no.  Half measure lead to full failure.  Agile means agile.  Set up the whole company for success, or don't bother and accept bad software, just like everyone else in this industry.  And, don't listen to McKinsey here either (per my previous post). 

Agile and automotive: McKinsey's take is wrong

McKinsey recently published an article on software in Automotive: https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/mastering-automotive-software-launch-excellence?cid=soc-web

Here's what they say about it:

The McKinsey Center for Future Mobility just released the article "Mastering automotive software-launch excellence". In the article, we provide an overview of the escalating role of software in the growing launch problems, analyzing its root causes and providing two solution approaches following the launch excellence framework. We, then, dive further into how automotive players can crack the code on superior launch performance by reducing complexity and increasing robustness in embedded software development. More of our latest thinking on www.mckinsey.com/mcfm.


My take:
Frankly, I think McKinsey missed it here and their analysis here is a bit dated, misses the major challenges, and will never make automotive software of the quality or experience people expect from their computer and phone.

There is a whole cultural and values based analysis of automotive delivery, throughout the ecosystem, that reminds me of many other industries pre-agile (15-20 years ago) and stands in the way of the necessary changes. They have a way of working around negotiation specs and delivery - and view software as a part or sub-system, with a whole organization behind this (finance, program, manufacturing, design, etc). Software isn't 'isolation' or treated as a part, that needs to be spec'd and finished, but an agile mindset of delivery. 

Until these barriers come down, software in cars will continue to be the worst part of the user experience, and the few that master it (I'd put Tesla in the lead) will delight their users and find that software is not 'just another part of the car' but one of the key elements of the mobility experience and delivery

Software has never done with half measures, and these recommendations are even less.

How to teach your kid to ride a bike (Noah's method)

When I learned to ride a bike...a long time ago...my dad basically ran behind me holding the saddle and yelled, "Pedal!"  My only recollection of the experience is raised voices and tears.  From both my dad and me.  Lots of skinned knees and generally lots of, 'lessons.'

So, when it was my turn to teach, I tried a different way. Since then. . .   I'm 4/4 in teaching kids to ride a bike, ages 4-6.  This includes both of my sons, and two nephews.  They all learned in under 3 lessons, with no lesson longer than an hour.  There were no/few tears, almost no falls and no raised voices.  Actually, not so bad.  And it was amazing.

Here's how....

After doing research (i.e., googling and going on youtube), this video is fantastic:

 Learn to Ride A Bike In 5 Simple Steps  

I basically followed this, but I also added a few steps:

0.  Burn the bridge behind you.  Tell your child that training wheels are done and never going back on.  This is good for your kid..., and you.  Then, remove the training wheels.
1.  Before starting, 

  - remove the pedals (threading is backwards on one so they lock as you go forward, but they're easy to take off with a crescent wrench- here's a youtube link for doing it:  https://youtu.be/jD0vhR7SgZU), and

  - make sure the seat is low so your kid's feet can be flat on the ground -- it'll look comically too low, but it should

2.  First step is just to walk with the bike between their legs (takes about 1 minutes).

3.  Start gliding down a gentle slope.  It can be very gentle.  Start only going up a bit and increase as your child gains confidence.  It helped to play a game -- we moved a rock as each boy went further.  Lemonade and skittles also helped with the motivation.  I also did it myself to be goofy and add fun.

4.  Once your child has gliding down mostly, then go to a parking lot and push.  When you push, it's better to push than to run and let go (in fact, running with the child doesn't help much).

5.  Once you can push your child pretty far, put the pedals back on.  Help your child start (starting is really hard).  Hold under his armpits and tell him to start pedaling, then, push to add momentum. It's important that your child is pedaling to start and you don't just push.

6.  Tell your child to put his feet down when finished. And...
7.  I made it a game with lots of levels.  (Level 1, walk with the bike between your legs...  Good job.  Here's a skittle!).  Worked pretty well, especially with my first son.  By the time he got to level 6, he was a pro.

Once your child can go this far, he/she really only has to learn to start, which takes practice, but he/she eventually learns that the key is to start with one of the pedals at about 1:00 and give it a hard push down while pushing forward -- and starting to pedal.

Some notes: 
-  I found it not helpful to run with my child and let go.  While natural and classic, this doesn't help much.  
- It doesn't help to lie and say, "I'll hold on." when you won't.  
- Training wheel, in spite of their name, don't really help train.  The only, sorta benefit is learning how to pedal -- and well- most kids know this from tricycles, hot wheels/ etc.  Brits called training wheels, 'stabilisers,' which is probably a better name, though they should have a z.



And, for inspiration, here are my sons' first days on bikes:

Alex (4 years old at the time):

Teddy (4 years old):

  

Good luck.  Would love to hear more tips and any feedback that people have.

Agile is not a process!

I recently read an article from a consulting firm about the benefits from moving from the, "waterfall process," to the "agile process."  The article then proceeded to dutifully outline all of the major elements of agile:  sprints, trains, daily scrums, stories, story management, cross-functional teams, etc.  The article then talked about why changing process was good and organizations would see a strong uplift in the application development.

WRONG.

And the article wasn't wrong because it espoused falsehoods.  It was wrong because it missed the heart of agile, and confused the output of agile with its input.

At its core, agile product development is a set of beliefs around building software to:  1) reduce process, 2) push responsibility to the person doing the work, 3) empower individuals, and 4) increase communications over heavier process.

The output of this methodology is very much what we generally thing of as agile. And, you need to guard against the re-appearance of process, as this is a natural quick-jerk reaction for most people, and takes high-level support to avoid.

I'll give an example.  At one company I was at, we had a deadline and ended up pushing out something through Q/A which ended up being very buggy.  The was viewed as a process breakdown -- Q/A had signed off on something not ready and hadn't had sufficient time.  The result was to add more process, in this case:  1) a 'rule' that Q/A had to have at least a week, and 2) a layer 2 of Q/A to sign of on production releases.

This seemed reasonable.  Think it worked?  Yeah, right.

Instead, agile methodology would do away with the Q/A sign-off and have developers sign off on their work.  Effectively, you blow-out of the process.  The individual would be responsible for signing off on his/her own work and when it was ready.  If the work turned out to be buggy, or there were integration problems, you would roll back (more about the environment later) and ensure that people communicated for easier integration.  There would be lots of social pressure not to release buggy code.  And that's it.  And it works a lot better.

Also, the article missed another point about only having good engineers.  Agile very quickly exposes people who are getting things done, and those who are not.  Sit in on a handful of scrums, and you'll very quickly know the people who are getting things done, and who are not.  Also, with agile, the bad engineers do not hold up the good ones or create roadblocks.  I won't go into the decisions to exit bad engineers, but with agile, at a minimum, they don't cause problems like they can when they push themselves into the critical path.

And, your products get better.  Users are horrible at articulating what they want, what they need, non-standard/edge cases, and knowing what they don't want.  Users are much better at reacting.  With agile, you get users reacting what they want, and your products improve tremendously.

My opinions come not from theory -- in theory, I love waterfall.  It seems to make lots of sense to write requirements and figure out what you want.  My opinions come from practice; I've never seen waterfall work well at all.  The shift out of a process mindset is counter-intuitive -- I've heard dozens of times someone say something like, "But if I were going to build a building, I would want to know what it would be used for, make blueprints, know my materials....before starting to build."  Needless to say, that's probably true for a building.  It just isn't for software.  Have the confidence that agile works.  It works fast too.

Well, that's enough for my agile soap box.  

The Idea List

I keep a list of idea that I think would be interesting to build a business around.  It's pretty simple.  I try to write them down when I think they're interesting, so I don't forget.  Sometimes, I email myself if I'm about to fall asleep, or write it down on a airplane when my mind is wandering, or frustrated, or trying to find something that I can't find.

The ideas themselves are just stubs that could be built into a business, not plans or details.  In face, I would argue that by themselves, they're worthless. There are lots of good ideas out there, which go nowhere.  For example, "website marketplace to allow people to list their apartments like hotels," does not mean you invented airBnB.  It's just an idea, floating around.  Even if you wrote it down, it's not clear that I'm the right person to do it, or that I would have/could have had the same outcome.

When I look back on them, most of them are easily shot down as horrible upon even a small amount of reflection:  too expensive to acquire customers, industry I know nothing about, too much of a marketing gimmick with little behind it.  

A few others ideas are shot down by a google search revealing that I'm several years behind and 1% in my thinking vs other people who entered the space a long time ago.  My 'innovation' is inevitably minimal.

Sometimes, the idea seems really exciting at the time, and then when looking back at it, it no longer does.  Maybe the prize isn't big enough, or you just couldn't imagine yourself getting up every day and trying to build it.

Then, there are a few that get a bit further.  I've spoken to people in industry or mocked up website -- even customers.  And, often you learn things that you don't expect, usually that there's a reason why this doesn't exist.  An industry structure you didn't fully understand or different motivations for decision makers.  

And then, well, there's the exciting ones.  The ones that make you leave your job, your safety and go for it.  It's good to know that there are a lot of those too.  And, even when the idea becomes a business and inevitably morphs and changes, that initial genesis and spark, is always a bit amazing.

NK

Know where the money is going

Following up on a post from a few days ago (http://www.noahkindler.com/2014/02/early-stage-grudge-work-accounting.html), I received some great comments discussing that in accounting in particular at an early-stage company, it's important to know where the money is going.

One friend even talked about how he did all his own accounting, just for this purpose.  

I couldn't agree more on the goal.  From a financial perspective, the money is expensive and it should be managed carefully.  Also, from a personal perspective, as an entrepreneur, you've given up huge amount of opportunity (e.g., higher paying job, unpaid time starting the company, etc.) and have probably also spent years teeing up the opportunity.  I know I've done that.  You've then sold much of the upside as equity to have this chance.  When you see the money go out the door unsuccessfully or poorly managed, it gnaws at you.  I've experienced the emotional reaction of seeing large checks go out the door for something that doesn't work.  Here, I like to make a distinction between well-spent money that doesn't work, vs. poorly spent money.

For example, at one company, we once used $50k on an ad campaign that brought on users for a $10/month product.  We obtained three users, or approximately $17k/user.  I called this the, "Buy them a Honda Civic" acquisition strategy.  

While this was very, very painful, it was ultimately a well thought out and managed campaign and given some constraints, we couldn't do a smaller test campaign.  I still believe it was well spent money, but expensive learning that something didn't work.  And it hurt  I still think of this when I see Honda Civics.

The even more painful time comes when you realize that you were careless and now have an invoice for something that could have or should have been avoided.  I remember signing a check for a monthly ad campaign that had stopped performing 60 days prior.  It has simply been overlooked as some other priorities had taken over  This prompted me to: 1) have a discussion and end the campaign immediately, and 2) change the way we did things going forward.  While it still was unpleasant, ultimately, the loss was minimized and avoided in the future, which is the best result possible at that point. 

Money out the door is a forcing function and moment of choice.  One of the simple steps that I always value and insist on is that someone involved in the fundraising process, and ideally the CEO (not a finance/accounting person), signs all the checks and approves all payrolls.  This ensures that every single dollar that leaves the account, is controlled and managed by one person with both financial and personal skin in the game.  (The only exception is an expense check to the person himself, as it's generally good to not have someone sign checks to himself)

While there are obviously downsides to this method (using checks, the occasional rush to find the CEO when he's out of the office when an urgent payment is needed, etc.), the upsides are substantial.  It's amazing how frequently simply signing a check makes you realize that you don't really need something (e.g., a software subscription you used to use and then moved off of with only legacy data, a contractor whose project hasn't performed well and you should make the call to end, etc.).  

Also, I always try to keep the overhead low on knowing where the cash is going, and put in place reasonable/minimal cash controls.  One of the easiest is having someone else enter the invoices into the accounting system and prepare the checks weekly.  This both: 1) reduces the time of truly administrative tasks, and 2) ensures a separation of the preparation of checks from signing, which is good cash control governance in any case.

Other parts of accounting like the exact definition of revenue, depreciation policies, differences between A/P liabilities and expenses, etc., are generally unimportant for start-ups as you focus entirely on cash and do not make different decisions based upon these differences.  Don't focus on them.  One of the best things to always challenge an accountant with is, "Does this matter?  Is it material?  Will we make different decisions based upon it?"  

Know where the money is going.