The journey of a thousand miles begins... with a field trial to verify assumptions.
You need to do one before you do a thousand. If you are painting a house, try the paint on a part of the house people can't see. If you are upgrading systems, do a few first before you start the mass migration.
The journey of a thousand miles begins... with doing it manually a few times, writing down the process, making sure the team agrees, then automating it.
The only way to automate something is to make sure you know how to do it manually first.
The journey of a thousand miles begins... starts with the least risk adverse customers before rolling out to other groups.
Once I was on a team that served 5 customer groups. The leader of one of those groups literally told us to upgrade them first because they want to be on the cutting edge. We told him we would but that was a lie. They were the biggest cry babies. They wanted to go first because they thought it was a status symbol. We started upgrades with a different group, one that were risk-taker and good at partnering and reporting bugs. Then a few more groups. The status-seekers were next to last. The last was the group that was definitely risk adverse and was happy to go last.
The journey of a thousand miles begins... after we forego backwards compatibility since the old system sucks but the users dont know it yet.
If you are maintaining backwards compatibility you are holding onto the past. Break compatibility when you need to. Customers will grumble but afterwords they'll thank you.
The journey of a thousand miles begins... after we promise backwards compatibilty with the previous journey.
Because other wise they'll sabatage our project. They'll find out how compatible things are when its too late.
The journey of a thousand miles begins... begins right away and asks forgiveness later.
Asking for permission shows you are looking for an excuse to procrastinate.
The journey of a thousand miles begins... never gets started if too many approvals are required.
Once you have been asked to get approvals from more than 3 managers you should just abandon the project. They're trying to tell you they don't want the project done. Or, that you should do a trial without asking and ask again once you have a working demo. The person that invented gmail was told by everyone "that's a dumb idea". When he showed a barely working demo the same people begged to use it. In theory Wikipedia can't possibly work. It only works in practice.
The journey of a thousand miles begins... is first mocked, then fought against, then considered obvious what we've always done.
Often paraphrased. Google it if you haven't heard.
The journey of a thousand miles begins... with celebrations for those that will end up doing the least amount of actual work.
Let them have their gory. You're here for the pleasure of doing good work.
The journey of a thousand miles begins... after the new budget is approved and we hear from legal.
Which means never. You go to legal if you are afraid to say "no" and want someone else to blame. Though, I've worked at some companies where legal's job was to figure out a way to get to navigate through the rough waters so that the goal can get achieved. There you and legal become partners against the real enemy: the PR department.
The journey of a thousand miles begins... if tell everyone it's 1 mile then use our success to get approval for the remainder.
See the gmail story above.
The journey of a thousand miles begins... if we claim it solves the CEO's 'emergency of the week' even though it fixes something else.
I once got approval to set up a single-signon-system for the entire 100-person company because I told the CEO that it would solve... I don't even remember but it got me the budget I needed.
The journey of a thousand miles begins... after we rephrase it using buzzwords to get political support.
Do it in the cloud, damn you!
The journey of a thousand miles begins... late at night so the manager that rejected it doesn't know we're doing it anyway.
When I was at [company name deleted to protect the innocent] the developers proposed restructuring how they would work in ways that today we'd describe as "Agile Methodology" (but before that term was coined). The the CEO not only rejected it but forbid us from doing it that way. That's what the VP of engineering said. We did it any way we just never told him. When he got 3 releases, one per month, instead of having to wait 3 months for any features at all he was so happy he stood up in front of the whole company and talked about our fantastic work. Did we point out that he had forbid us from doing what he was praising us for? Hell no.
