Remember the old days when you had to ship out physical packages to customers in CD format? A different version came out every 6-12 months, and it was a big deal with a big buildup. Now the landscape looks much different. Continuous integration pushes changes and updates all the time. There’s less build up and more focus on SaaS, and you just keep improving.
Coming next summer…
Sometimes I’ll still have to schedule a release, for instance, to meet shareholder expectations or for a large revision or totally new product. In this case, I’ll factor in a 20% margin for timelines and schedule release by season. This frees me from a looming public due date and gives me freedom within a three month buffer instead.
My preference though is to constantly push changes all the time with no big build up. But if I’m doing a whole new rewrite, I’ll do it by season/quarter.
It’s all on me
What’s the best way to hit or beat your deadline? GET THE BEST PEOPLE. You only want people on board with exceptional skills and drive. If need be, bring in experts and consultants. Don’t know who they are? Ask around. Get a personal recommendation on someone who’s done stellar work. Great ideas and management won’t take you very far if you don’t have the team to carry out the plan.
The B Team gets B results, but the A Team gets A results. Don’t want to build it internally? Then go out and get it — hire or outsource to the people that will get the job done. As CTO, I’m ultimately responsible for anything that happens in technology. I get to point zero fingers. And what’s the CEO thinking if things go south? They’re thinking, “It’s my fault since I hired this CTO who failed.”
Pause and consider that for a second. The CEO feels like a failure for hiring you. That’s brutal. Now flip it over. What if the CEO feels like a genius and a hero for hiring you? Let this be your motivation for assembling a superlative team.
Next, it’s critical to consider the minimally viable lifecycle. I do this by starting with the most basic implementation of a feature then rapidly release updates. Let’s say I want my app to do text messaging. So with my first release, I won’t roll out a snazzy GIF keyboard. Instead, I’ll build a rock solid, basic end-to-end messaging platform. I establish and nail down one goal. Now, my team, my shareholders, and myself are all satisfied.
I’m not done yet
If I start with a really easy and basic app, then I deal with a small set of issues with each update. My timeline becomes more predictable. Compare this with trying to build a massive production application which may be ready and working locally, but when I go to production I have 70 production-related issues to fix.
In other words, when I’m sitting there at my computer it might work fine, but in order to put it into production an entire new set of issues arise. I used to say, “I’m done” when I completed staging, but I was wrong. It’s done when the application is fully operational in production. As a leader, it’s important to think from a non-technical perspective. ‘Done’ means that it’s done from the perspective of the end user.
Keep momentum going
Instead of accumulating a ton of work in a massive staging process, I put out the very first basic version into production. It’s neat, clean and fully functioning. In a similar fashion, I roll out all updates directly into production too. I don’t try to do it all at once. Instead, with this step-wise strategy, I’m constantly releasing fully operational products and updates.
I try to make it simple and beautiful, but I don’t use simplicity as an excuse to cut corners. When I limit my focus and scope, I’ll produce excellent UX. If you chop it up and solidly hit each goal, you set up a string of victories to keep momentum going.