Tuesday, May 31, 2016

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:


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 you 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, they really only have to learn to start, which takes practice, but they eventually learn 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.



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.



Thursday, February 27, 2014

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.  


Monday, February 24, 2014

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

Friday, February 21, 2014

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.


Wednesday, February 19, 2014

Day 1 at a big company vs. Day 1 as a founder at a small company

One of my former board members, Stephen Semprevivo, and I were discussing the differences between your first day on the job at a bigger company vs. a founder:

Founder - day 1:  
- You have responsibility for absolutely everything.  This ranges from product, sales, facilities, operations, recruiting, accounting, compliance, legal, finance, IT, marketing, etc...  
- You have (almost) unlimited decision making authority, both formal, informal
- You have unlimited flexibility on title, office location, etc.
- As you go forward,  you give up these responsibilities/authorities and move to focus on highest priorities. e.g., you outsource HR, someone else takes over IT, you bring on a marketing lead, etc.

Bigger company- day 1:
- You have effectively no responsibility. Even if you're hired for something with formal responsibility specifically, you're certainly still being evaluated before you're trusted to fully take it on
- You have no decision making authority.  Even if you have something formal, undoubtedly, there's still time before you're trusted
- You have no flexibility on title, office location.  It's already set
- As you go forward, you gain these responsibilities/authorities as you increase in importance and trust within the organization.  e.g., you now need to sign off on all hires, or approve certain budget items or approve any product changes of a certain sort

While there are obviously some generalizations here, and of course many more differences (I've tried to focus on responsibility/authority matrix) the principle is pretty sound.  I've seen people struggle both ways, going big->founder or founder->big.  I even now explicitly have  conversation with people who have never been at a very small company about how it's different and how some of what makes someone successful at big, doesn't translate to small.

Thanks again Stephen for the great view.

Monday, February 17, 2014

The Daily Scrum

I have a strong bias against heavy process, in favor of closer communications, which allows you to 'blow out' of the process trap.  

None of this is theoretical.  I have seen brilliant, well-thought out process to create new products.  They have been lead by intelligent, capable and motivated managers with full buy-in from teams.

I've just never seen it work.  Process inevitably becomes a trap.  It's something that allows people to shut of their minds, stop making great products and think, "well, I'm following the process." None of this is necessarily lazy or with evil intentions; it's by design.  For example, "I'll push my code because the process is that Q/A tests it once I get it working."  Or, "that's a great idea, but I can't do it because our sprint/train started and we can't re-prioritize for another two weeks."  Or, "that would be great, but the CFO only allows budget updates quarterly, so maybe next quarter..."  And, then, well, there are the other cases.

One of the few process steps I recommend is a daily scrum.  It's a simple daily meeting where:
  - Everyone says what they did yesterday and what they're doing today in 90 seconds or less
  - It starts on time, irrespective of who is there
  - The goal is to identify when people should communicate (e.g., Oh, I did some work there a few weeks ago) and that no one is repeating work/doing something unknown
  - If people start trying to solve a problem, others need to ask them, "Great conversation, take it after the meeting."
  - Only people who have something to say should speak.  (there's more theory here on pigs/chickens if you're interested in googling)

The result is a fast meeting (under 10 minutes) where no one looks at his/her phone, and we identify any areas of coordination.  It also gives transparency into what everyone is working on and serves as a performance manager too (e.g., if someone is always doing the same thing and not making progress....).

We have even extended this to non-technical functions and found it tremendously useful.  It also leverages a focused/fast team, which is super important when you're a start-up!

So, I'm busy from 8:00-8:10 every morning.  As is the rest of the team.




Friday, February 14, 2014

Opportunity sits down next to you...

I was flying back to SFO from New York last week and started talking to the passenger seated next to me.  We had a wonderful discussion about soccer and children which made the flight go faster, but he also knew all about my industry.  He came out of the financial services and immediately got our product.  He was then able to introduce me to some potential clients that he knew.  We've already had follow-up and we'll see where the leads go.

It's always interesting to me how sometimes, it's the unexpected encounters which lead to progress, and why introductions/sales is in many ways a numbers game.  We often think of the formal interactions:  conferences, warm intros, friends -- as the only way to.  And, it's easy to shut-off when you feel you're 'off,' but often this would be at the expense of missing a great opportunity.  And, even when it's not a business opportunity, it's fun to get insights into Jose Mourinho's Chelsea FC team!

And yes, I can take a hint too, so I'm not that guy next to you who won't just stop talking if you're trying to sleep....