There's an old joke in software development, "How much time does it take to design software?" Answer: As long as you have scheduled for the design phase.
I know. Not funny, "ha, ha" but pretty apropos.
If you've been involved with a number of software projects, you already have an intuitive sense for this. We've all been involved with projects that seem to drift, and drift and make progress. There's a healthy balance between allowing a design team to dream up functional requirements, talk with customers, analyze competitors and, for technical projects, research the latest cool-kid tools to play with.
Design with no constraints becomes a research project.
You see there is a creative tension along the spectrum of time and scope. If you pull too hard at the scope end of the chain, your time drifts. If you pull hard at the time end of the spectrum, you end up shipping inferior product. As obvious as it seems, I assure you that many teams I'm involved with don't sit down and have hard enough conversations about the need to hit time-based deadlines, so dates slip.
CEOs are time-driven creatures. We feel pressure to hit milestones for a variety of reasons: investor presentations, conference demos, customer sales meetings, competitive pressures, a need to drive revenue, business development commitments -- whatever. CEOs who are tough but fair-minded set aggressive targets on "time" and communicate clearly with engineering why there is a deadline.
We live in an era of more product-dominant companies where a perfection complex for features and design delay business realities when it comes to shipping products. It's why I'm such a big proponent of Eric Ries' Lean Startup movement and of virtually anything written by Steve Blank -- the latest is The Startup Owner's Manual written with Bob Dorf. These authors have spawned a movement to emphasize the need to ship product early, get customer feedback, and then continually revise product until you get the right feature and design for your customer base.
I have found that one of the most effective tools in driving software completion is having "big hairy goals" like demo'ing at a major conference. There is nothing that will focus the mind more than not wanting to be on stage with a demo that bombs. For engineering it focuses one's energy on a critical date, and there is the satisfaction of being able to see the immediate results of your hard work in front of a large audience.
Obviously you can't always present at conferences to hit delivery dates or this would happen. As an alternative I've also found board meetings to be a good rallying call. You set up a set of features that you'd like to have completed in time to show your investors and even invite some key engineering staff to come in and do the demo. It provides a tangible goal and also rewards the team that completes the project with the opportunity to interact with the board.
The funny thing about time constraints is that when set with the appropriate balance of having enough time to deliver something meaningful you can actually use time constraints to drive creativity. Knowing the way my mind works, I find that time pressure drives creative bursts. I wrote about it in this post on The Urgency Addiction. This is especially true in people with ADD who have less active front cortexes. The adrenaline of time pressure stimulated the frontal cortex and kicks in a creative gear.
One has to be careful about not proposing too many of these "death marches" per year because it clearly isn't productive to have your engineering team in a perpetual state of high output in the name of competitiveness. When you realize that company building is a marathon and not a sprint you'll start to appreciate not making every weekend a workathon in the name of hitting deadlines. Push too hard on engineering too many times and you'll start to evoke a Pavlovian response is to call bullshit that this is yet another "mission critical" release.
As the CEO or project lead, you need to be engaged enough to know when the constraints you're placing are having a damaging effect, which of course unrealistic targets can do. You need to be involved in the project to measure when key interim dates are slipping and it looks difficult to meet the deadline. This happens on 100 percent of projects.
This is exactly where leadership comes in. As a leader you have the choice along the spectrum to either let the date slip or cut scope. Of course every project is different so there isn't one single answer but I usually suggest starting on the side of which features can be delayed for a "fast follow" after the initial ship date. If you're not actively involved you'll get both scope drift AND time drift. Given enough time to dick around I assure you your team will find other "interesting additions" to your scope that perhaps you'd prefer not to have if it meant sacrificing your date.
I am willing to cede my ship dates, but I never let on to this fact early in the project or the creative tension and focus dissipate.
I have found that one of the most useful things I can do as a VC is to meet with early-stage teams of the companies in which I've invested and have the debate with them about critical projects. They often lay out scope and deadline pressures, and we have a debate about what is "core functionality" and what can be delayed. Sometimes it's helpful to have an outside pair of eyes on the problem as these issues tend to get quite emotional. And when you're not the person involved in the project for months you tend to be pretty impartial.
If you have an advisor close to the company with product experience I highly recommend bringing them in from time-to-time for these types of conversations.
I was having the (time-scope) chat last week with my friend Kara Nortman who runs parent crafting business Moonfrye. She of course pointed to the third dimension -- resources. Of course that's the natural third corner of the triangle. There are many projects where adding resources can increase your scope or help you hit your time. Conversely, there are many projects where diverting resources requires you to cut scope or slip dates.
If you don't have a strong VP of Engineering who can manage estimates, task completion, assignments and kill scope creep, you're dead.
The one word of caution that Ryan Lissack taught me long ago ... often times adding more bodies to an IT project just slows things down. If you have really high competence on the team and everybody knows what their doing sometimes extra bodies just slow down your best performers.
And we all know the fallacy of the "mythical man month" and how beyond a certain number of people productivity drains. I wrote about this some time ago in my post, "Nine Women Can't Make a Baby in a Month." The best advice I have is to establish a close and trusting relationship with your VP of Engineering and know when adding resources will help vs. hinder.
In summary: I have been involved with software development for 25 years. Intuitively all teams know that without strong deadlines projects drift. Yet one of the most common occurrence even in this day of information freely available on the web it continues to plague more companies and more projects then you can imagine.
Set hard deadlines. Manage to them compassionately. Seek ways to cut scope and do fast follows. And have the trust in your engineering leadership when they tell you that the date is unrealistic and must be changed.
This article was originally published on Mark Suster's blog, Both Sides of the Table.