Argument isn't the right word. No, we weren't arguing. But we sure were having a spirited discussion.
We had a super talented team to do a quick project. The chief programmer/engineer and I were having - well, we weren't arguing, no, we weren't doing that. But we were spiritedly discussing. He had realized that the general technology stack we were going to use had some limitations, and he wanted to go back do it in Ruby on Rails from scratch.
"Timetable?" I ask.
"Three weeks," he says.
"Unacceptable. Let's go forward with what we've got. I'm aware of the flaws."
"I don't think you understand Sebastian."
"No, I do understand. We're pushing problems down the road. They're big problems. I get it. It's no good. But we need to move fast here. We have lots of team members, lots of moving pieces."
He goes on to explain that a few weeks now means we'll have much less work later in maintenance.
I got it. He's an extremely smart guy, one of the top technical people I've ever met. But I have this strong intuition, this vague not-quite-explainable thing... how do I explain it?
I try: "Okay man, you know when casinos get their license to open up in Vegas? Every day they're not open that they could be, they lose something like a million dollars. So when they build, they don't care about causing problems down the road, because a five day delay means they're out five million. Just do it as fast as you can, and use all the resources you've got later to fix it if the project is successful. And if it's not, you don't have a problem anyways."
That halfway explains it.
He reiterates though, that we're building up some huge technical debt by doing it this way.
"I know. Okay. Let's say we need human intervention on all the accounts for a number of actions, every month. Let's say one hour per customer per month of customer support guaranteed. Totally destroys scalability. Got that mental picture? Okay, that would acceptable and preferable to getting the coding done three weeks behind schedule."
"That's insane. That's just... that's insane. Don't you want to make any profit?"
"Well, this is relatively low level customer support type stuff. Maybe it whacks 25% of their initial margins to have someone do it all. That's really bad when we could build out something elegantly automated. But we're going onto an entire new stack, there's some percent chance - maybe low, but not zero - that we run into a roadblock over there too. And so three weeks have passed, and now we've got another problem..."
I'm still trying to understand this time thing. I'm not explaining it well. I don't even really understand it well yet, except for getting the impression that it's really really important.
I try explaining like this - "How many projects have you done? I've done... I don't know how many, but enough that were six months late, eight months late, a year late, or even canceled. That happens a lot, it's normal actually. See, projects don't die because they're launched half-complete or with a problem down the road. You're saying, our shit totally falls apart at 10,000 users. Whatever man, if we've got 10,000 users we've got a hell of a lot of money to rebuild from scratch, even with all the damage that entails. Projects don't really die from launching too early as long as the customer-facing stuff all looks good and does its thing, projects do die when they slip forwards. Momentum is lost, people get demoralized... we've got two people waiting on this next step as a dependency, they can't move until it's done. They're going to wait two weeks? And then, with no guarantee of being ready at that point? No, we need to move fast. Yeah, we're pushing the problems down the road, but we can solve them down the road. Problems down the road - that only come up if we're successful, mind you - they won't kill us. Going too slow will kill us. It kills projects."
I'm still not satisfied with that explanation. But there's something there. Perhaps it's a culture of things going "just a bit" into the future that's so dangerous? I still can't quite explain it right, but I'm starting to see things happening in faster feedback loops as crucial for success.
Subscribe to SEBASTIAN MARSHALL
Get new posts sent to you. If you change your mind later, unsubscribe with one click.
You're a member of this community! Use the buttons on the right to vote on ths post or share it with others. Or leave a reply below.