What do you do about that very talented and creative designer/engineer who never hits a deadline?

Richard Bullwinkle VP of Products & Marketing at Dictionary.com

July 23rd, 2015

Everyone knows it's hard to find great Silicon Valley talent. I've been lucky enough to find some really sharp people to work with. But now, and several times in my career I've worked with inspired designers and engineers who have great ideas, amazing talent, and no ability to hit a deadline. Time is money, especially in the earliest stages of a startup. Is it ever worth it to work with them?

John Petrone CTO at LaunchPad Central

July 23rd, 2015

In my experience few of us are fabulous at hitting deadlines for fundamentally creative activities. Too many uncertainties to begin with, and a deadline approach focuses on external driving factors and not on the actual effort and elapsed time required.

Perhaps a different approach would serve - ask instead how long a certain set of functionality would take to design and build - and then measure how long it really does, while keeping on the pressure as the commit date approaches.

I've had great engineers that are terrible at estimating - knowing that ahead of time I can double the estimate they give me and set expectations for delivery dates accordingly.

Daniel Esbensen CTO at SheerPower Auction Services, Inc. and Information Services Consultant

July 23rd, 2015

Hello, We have had great success working with super creative types hitting deadlines by: o breaking down all projects into weekly deliverables (daily ones for some super-creative types) o request and pay for them to report via email or other simple system DAILY two things: 1. What in general did you get done today (highlights) 2. What do you plan on getting done tomorrow In this way, possible deadline issues can be discovered very early and addressed. Dan E. ===

Ajay Sikka CEO at OmniM2M & Ci2i Services, Inc.

July 23rd, 2015

I agree with the comments above - quality trumps delays. I prefer to have the team work on smaller (bite size) chunks. Once you factor in suitable padding on these smaller projects, and build a process around it, the "shock" value of delays is minimized.

Joanan Hernandez CEO & Founder at Mollejuo

July 23rd, 2015

Hello Richard,

What you have is a management problem. Which BTW, is one of the frequent challenges of being a manager. This human behaviour doesn't apply only to engineers/designers, apply to any subordinate you might have. So, the trick -I think- is to learn to live and deal with it (not an easy task). Personally, I would factor in if the person does the job within reasonable delays.

Quality varies according to the eye of the beholder.

I suggest this great read about Software engineering schedule.

Best of lucks!

Cheers!

David Faith Managing Director at Certified Project Management

August 27th, 2015

Hi Richard,

PERT, or 3 point estimation technique is a simple, concrete, actionable thing you can do right away to mitigate the effect of a team member who consistently misses deadlines. It boils down to a somewhat predictable form of estimate padding, which you can tweak over time. ( I mention this first, so you can stop the bleeding and get a measurable baseline on the issue).

Here is a very approachable article on this helpful technique.

Do you remember the "I Love Lucy" episode where Lucy and Ethel can't keep up with the conveyor belt in the chocolate factory? Once they found themselves unable to complete a task, all discipline and restraint go right out the window!

Hilarious consequences on TV... but not for the business!

Some projects get into trouble because they underestimate the cumulative effect of doing scheduled tasks in the wrong order. Which is usually what happens next after deadlines are missed . There's a whole body of (seriously overlooked) practical knowledge on the Theory of Constraints. Don't know why it hasn't really made it into the lexicon ( maybe 3 words is too much of a mouthful in our day and age; compare: "agile" or "scrum"?)

So in addition to weighting your task estimates, you may also want to put some padding a.k.a "lag" in between critical tasks on your timeline/roadmap" The not so obvious advantage here is that if the problem is temporary and resolved ( i.e: temporary burnout) then you get to re-capture lost time at predictable, scheduled intervals.

Regarding whether you should cut your losses, surely depends on a number of other factors, some have been already mentioned. However, since we're really not appraised of all the details and nuances of your particular situation; I'll opt for Wittgenstein's famous advice. :)

Stevan Vigneaux Director of Product Management and Marketing at Mimio

July 26th, 2015

There are five primary reasons for engineers missing a deadline.

First, they were forced into a deadline they never believed in. I have seen it time and time again - upper management pushes and pushes for "sooner, faster, better" until the poor engineer just says "OK" because that will at least make the meeting end so the work can begin.

Second, one "this will only take a little time" interruption after another was dropped into the work week, and thus into the schedule. But the schedule was not revisited, almost as if work could be added and completed magically.

Third, the estimate was made without enough facts, usually meaning not enough research.

Fourth, the infamous "feature creep" where new work was added along the same path but without honestly revisiting the schedule.

Lastly, and least of all, the engineer just isn't very good at scheduling.

Note that the top four of the five above have nothing whatsoever to do with the engineer.

Full confession here - as a Product Manager, Product Marketing Manager, VP or Product Management and even as a CEO - I have been guilty of all four of them. Though I'm getting better all the time.

Marc Pedri Chief Strategy Officer at D1M

August 28th, 2015

Based on my experience, everything comes back to "communication" and "manage expectations".

You could set the internal delivery -3 days, but your real deadline from the client is actually +3 days. So you have two internal deadlines on which you can put high pressure, but still, this might not work in some cases.

What helped me overall was to consider plannings and deadlines as the most flexible parts of a project.

There will be the previous mentioned "feature creep" or "change requests". In agile methodologies you would talk about this with the client. But if the client is not close enough, agile would not work. So why not driving back the conversation to the client about the scope. Scope change means increase/decrease which also converts into longer UAT phases as there is more to test for the client.

But what if the task is just to have a creative idea. Then you can't even break it down into smaller pieces nor request for more time due to added features.

Well in western cultures, commitment is something what could work here. But it definitely cannot be used in Asian cultures.

What helped me here was to have always a presentable plan B and first of all to understand better the difficulties the person is facing when working on that task. Maybe there is a block the person cannot overcome, or the focus on the priority is not clear, or the goal is perceived differently than expected. All in all, a closer communication to proactively avoid road blocks, wrong priorities and to provide some out of the box thinking its just what it needs to make that step closer towards a delivery on time.

John Anderson

July 23rd, 2015

Simple answer. Would you rather have crap on time or something great a little later. If they are at least consistent, and you can pad their estimates and come up with a reasonable actual date you feel it would be ready, then that's one thing. If they are all over the board, being late sometimes and really late other times, it might be worth looking for someone else.

A way to mitigate this is to have frequent checkpoints and detect when they first start going off course. It's easier to steer clear of the iceberg knowing about it as early as possible.

Depending on what you're building (are you selling style or functionality) then that could help your decision also. It's hard to find someone who can build functional things with style and elegance. But if you're selling something more commoditized, like DB stored proc's or just coding run of the mill logic, might be worth moving on with someone else.

Emily Boylan President LimeRed Studio | social impact consultant | for nonprofit, higher education, corporate social responsibility

July 23rd, 2015

The first thing to look at is whether the deadlines are reasonable. If they aren't, no one will hit them. Then, break down deadlines into smaller ones that are realistic and shoot for incremental progress. If you're familiar with Agile at all, this is the idea. Since we've switched to that method, everything is higher quality and clearer for us and clients.

It's up to the agency and client to set expectations, processes, and stick to them. The agency should guide it, but everyone is responsible.

I've been running a design and dev agency for 10 years and there are always things that come up in development that no one can account for in the upfront planning. We review how we're working with our clients every two weeks to make sure everyone is on the same trajectory. More frequent checkins might be a good solution.

There's a lot of talent everywhere. Look elsewhere, find a company that fits your culture. We're in Chicago and work nationally. Lots of agencies do.

Lenny Rayzman Network Hardware Engineer

July 23rd, 2015

Never go by engineer's estimate. The better they are, the farther they'll miss it. Keep tabs on progress but don't try to microanalyze. Things won't happen faster if you do!

Question stats