
Ask HN: As a team lead how to handle project going off the rails? - le-mark
This is kind of a banal story. I&#x27;m the lead developer on a &quot;modernization&quot; project that&#x27;s taking a lot longer than anticipated (you see where this is going). The team is great, it&#x27;s just that the work is way outside their comfort zone. The business has been selling the new version pretty hard and we&#x27;re not going to make the release (about 3 months to go).<p>Question is; as a lead how would you handle this? I think my direct manager has a healthy dose of skepticism about the timeline, but the product owner doesn&#x27;t. At what point should I start sounding the alarm? I&#x27;d like to give it a couple of weeks and see if the team picks up pace but I&#x27;m not confident.
======
ljw1001
This is not going to be like the other advice you get, but I've managed many
projects in different organizations and I think it is sound. First and
foremost, don't sound any alarms.

Many organizations have common characteristics in this regard. First, they
don't expect you to be on time. Sales may think you're going to launch on
time, but it's in their financial interest to think so. The rest of the org
probably made a schedule they know you can't meet because they think it
motivates you to work harder.

Second, unless you're in a startup where everyone's inexperienced, most people
probably already know you'll be late, but aren't saying it out loud. They
likely have discussed it (up the chain) in meetings you're not in.

Third, people do shoot the bearer of bad news. You can earn a rep as a
negative person if you make _true_ predictions out-loud that don't fit the
common desire. This is especially true if some of the senior people who know
(like your boss) haven't been forthcoming with their bosses.

Have a quiet conversation with your boss over lunch or beers - not a meeting -
and tell him/her what you think. Be prepared with details, but if he/she
doesn't ask for them, don't provide any. There's a good chance he/she already
knows as you suspect.

Even more casually (lunch/beers), express your concerns to the project owner.
It's probably not new news to him/her either. Being "positive" is a huge part
of the corporate game.: Again, if no details are asked for, don't provide any.
Shift the conversation to the weather or the world cup.

You're now down. Go back to work.

~~~
tootie
Disagree. Just be real. When I joined my current company, they had a project
kicking off with a ridiculously short timeline. I asked the product manager to
think about how many stories were in the backlog, how many might be added as
we went, how many stories they could get through per sprint given the team
capacity and then you can put a rough date on it and continue adjusting every
sprint as the backlog shrinks and you get a clear picture of velocity. Our
first pass put us about 400% over the allotted time (an estimate that has held
up pretty well since then).

Next step, is to spell this out to your project team leadership completely
unvarnished. Tell them your conclusion and how you got there. Don't let them
bargain over your reasoning unless they actually have better evidence. The key
is to never say "this is too hard" or "we don't have enough people" or make
any other excuses. Not should you be overly emotional. Just give the facts.
It's a fait accompli.

Then just ask how they want to deal with it. There is absolutely nothing to be
gained from beating around the bush. I've done this more than once and was
always taken seriously. One time we had even already signed a fixed-bid
contract before I was able to give them an estimate. What you've committed too
doesn't change the course of what's actually going to happen.

~~~
lostcolony
Oh, hey. You had a fully fleshed out backlog, some initial tracking, with a PO
who actually wanted to know rather than just tell the business "everything is
okay" and block his ears (knowing that failure to deliver will reflect dev,
not him).

You had leaders who were willing to listen to facts rather than prioritize
consensus (which brings with it the belief that because you were the
dissenting voice in the room demonstrates you're divisive and a problem).

You landed in a really good culture, just one that hadn't faced reality yet.
You've yet to plumb the depths of corporate America. :P

~~~
badloginagain
> You landed in a really good culture

Here's the crux of the matter. Your approach needs to be tailored to the
culture you're in. The higher up in the leadership chain you go, the more
important your understanding of the political machinations of your company is.

All corporations have politics, even the smallest startups. Some are just more
cutthroat/feudal/kafkaesque than others.

~~~
borkt
Once you realize you are at a company where telling the truth leads to a
negative consequence (an incompetent manager hired after the truth told. Their
first time managing a department. The department did not previously exist in
the enterprise. The department is specifically to roll out a technology they
have never worked with before throughout a large company.

Lets say you were in charge of the project, are intimately familiar with the
technology, and had a clear plan that would lead to success but upper
management wasn't happy with the timeline. Their goal seems to be to quickly
complete this project to display it as a "win".

Now the new manager was brought in, does not understand or care to understand
the complexity of the project, and just keeps asking "when will it be done".
Then got tired of that and changed to have it done in 2 weeks which is
unreasonable, and then gave you an entirely false, negative performance review
based on information they apparently forgot to actually verify or they would
have known it was already complete and the people who were on the receiving
end of the product are incredibly happy.

HR is asking for a meeting to discuss, what do you do? Tell HR about the depth
of the incompetence Tell HR you weren't getting support from upper management
Tell HR to look into what on earth was the reason this specific manager was
selected.

or

GTFO?

This is a real life circumstance I am dealing with. I believe in the
technology but unless changes are made it will be a guaranteed failure. Upper
management likes the technology and really wants success here, but I know it
wont happen unless then changes are made, and the people between the senior
executives and me are making it impossible to be a success.

~~~
badloginagain
If its gone to HR its already gone pear-shaped. Lay down the facts as you see
them, let them know exactly what happened, tell the truth.

If they take it out on you, you know its time to go, but maybe this guy has
been pissing other people off and you have no idea about it. Maybe its HR
doing due diligence to fire.

Don't make accusations or shit on anyone, you don't know the whole story. Play
to your strengths, which is knowing the tech and what it takes to get it to
where it needs to be. Make sure you point out your attempts to communicate
this fact. Provide any evidence of this- emails, etc. where you're
communicating the state of the project and your projections for it. Let them
know you've been frustrated with the miscommunication, but make sure that the
miscommunication has started with you.

Again, don't shit on anyone. Stick the facts, so that if it blows up in your
face it says more about them than it did about you. Its also the kind of
resolution I'd I want to see on the interviewer side of "How did you resolve a
difficult situation".

~~~
borkt
Thanks, it is progressing as expected. The only shitting on that was done
involved providing repeated examples of attempts to get clarity or schedule
meetings that were repeatedly ignored or cancelled at the last minute (which
the supervisor for some reason told HR I was the one cancelling). Didn't call
into question their competence, just provided support for my side from others,
and examples of where the review was completely falsified. Spoke with CLO
prior to all of this who is a mentor of mine and is incredibly upset with the
treatment I received and says company will provide severance and
recommendations if they can't find a suitable location in another department
internally.

------
Chyzwar
I suspect that you did not managed expectations. PO was not really working as
the proper owner and have no clue about progress and effort being put. Your
direct manager does not care as it can always blame everything on you. And the
team is not so great if they have problems with "comfort zone".

First get PO on board. Choose the process that will push PO into the central
role: Kanban, Scrum, XP(anything really). Work with the PO to create user
stories, estimate and calibrate. PO should work with stakeholders to ensure
that the timeline is realistic.

Get your team a proper training. Hire someone to do training on the tech you
use. Get some courses from Pluralsight/Udemy that will be mandatory for
everyone on the team. Extra day in month spend on training is not much but it
will up-skill people quickly.

Drag in your manager. Get him into a meeting and ask for a guidance of the
senior manager. Make him co-responsible, he might help with funding on the
project. Cut features to absolute MVP. If nothing works, escape sinking ship.

~~~
adrianhel
And if it's an online solution, propose to roll out some features gradually.

But yeah: 1\. Be honest with everyone 2\. Invest in online courses for
everyone 3\. Lay out a simple roadmap for the minimum MVP 4\. Hustle

And next time use my recipe for estimating. Spend ~ a day on this.

1\. Split up everything into the smallest subtasks 2\. Estimate the time all
subtasks take. Uncertain? Write down a low and a high. Still uncertain? Split
the task into subtasks or confer with someone. 3\. Add the times together and
multiply by pi. If applicable, do it once for the high and once for the low.
4\. Present the high estimate. It is probably closer to the truth. Estimating
the low as well is more of a psychological trick.

Don't use the subtasks for the development though. They will be too fine
grained.

~~~
kefabean
The multiply by three approach has also worked for me in the past. People
often estimate the time taken to do _the_ task, typically not taking in to
consideration the other aspects of their job (eg
comms/planning/rework/productionisation/etc) needed to get said task done. I
do like the use of pi though, I’ll be adopting this going forwards!

~~~
sbov
With experience you can account for this. What's hard to account for is some
3rd party vendor blowing you off, or slow rolling you, for weeks. Or
management pulling you into another project.

Each integration point with a 3rd party automatically adds an extra 1 week+ to
my estimates, depending upon the complexity.

------
jasonm23
Assess the product delivery in terms of risks. Look at what's on the roadmap
and build a 2x2 matrix of the intended features.

Get some post-its and write down each feature. Organized on the 2x2 with these
axes X: "risk/complexity" Y:"desirability" (that's business & customer
desirability.)

Setup a meeting with your products owner and others to try and get a good deal
of feedback and communication, reorganize the 2x2 matrix during the meeting to
build understanding of risks and priorities.

With everything on the table the big risks should be clear and addressable.
The product owner will be able to make some changes to the product plan.

Visibility and transparency is key, don't do an ass covering exercise, and act
sooner.

Make sure you understand what has been difficult and outside the teams comfort
zone, where improvement could be made etc.

Also be aware of the motivations for the product owner and empathize. Build &
strengthen that relationship.

Better feedback loops, better clearer/slicing of feature requirements... I
could only generalize, but aim to improve communication and even if all goals
aren't met it will be a healthier place and contingency will be easier to work
on.

~~~
blahblahblogger
> Organized on the 2x2 with these axes X: "risk/complexity" Y:"desirability"
> (that's business & customer desirability.)

Not to sound like an idiot here or anything, but does that mean something like
this: Risk | Complexity \---------------------------------- BiZ desirability |
| \---------------------------------- Cus desirability | |

Can't an item be in many of these squares?

~~~
kd5bjo
What's being described is an X-Y scatter plot:

    
    
             Necessary
                 ^
                 |
      Simple <---+---> Complex
                 |
                 V
            Nice to have

~~~
lioeters
This makes the most sense to me.

If I were in the OP's position, I would start discussion with the direct
manager as early as possible - and begin by breaking down the remaining scope
in terms of where the features are in this diagram.

If the product must be "ready to ship", clearly some corners will need to be
cut - especially the bottom right.

~~~
jasonm23
Exactly.

------
bbrunner
Tell the product owner what the situation is and collaboratively come up with
either:

a) a new timeline that you believe you can meet or b) a list of tradeoffs that
can be made to get the project out the door in time

I have been an engineering lead and a product manager and it is much better
for everyone to just be upfront about all of this.

You know what your team can produce and (roughly) how fast they can produce
within an order of magnitude time-wise. The product owner should know what
stakeholders actually want product-wise and what an acceptable timeline looks
like. You should be able to work together to narrow the scope of what is being
worked on to a point where your team can accomplish it within the timeframe.

Communication and setting expectations are key. This needs to be done both up
front and on an on-going basis. As an engineering manager, you should be able
to evaluate, week-to-week, where things stand and which tasks may need to be
cut to make a deadline or how far a deadline should be pushed back if things
can't be cut. Your product owner should be able to weigh in on this and should
already be prepared to pare down requirements if necessary.

It may be painful and embarrassing to start having these conversations now,
but it is significantly less painful and embarrassing than having these
conversations in 3 months when the product is expected to be delivered.

------
jacquesm
It sounds to me as if you're doing a 'big bang' when you should be doing
something incremental instead.

Great way to lose your people because at some point the only way to make the
artificial deadline is to increase the pressure on the team building it to
satisfy the manager. Those that can move out will do so, you will be left with
the people that do not have much in terms of options to finish the job.

This movie has played 1000's of times in badly managed tech companies.

~~~
rejschaap
Incremental is key here, 'modernization' sounds like a large and blurry goal.

You need to get this under control as soon as possible, definitely don't "give
it a couple of weeks and see if the team picks up pace". Start making lists,
what has been done, what needs to be done, prioritize and start tracking that.

Don't create big tasks that are measured in percentages (frombulating the
gizmobob is 42% done). Make small tasks that are either done or not done (0 or
1). Small tasks meaning measurable in hours, not days, let the people who will
do the work make the estimates. Don't worry, this is not micromanaging, this
is properly managing a project, and yes, it will take some of your time
keeping track of all of this.

There is also the question whether should you be doing this or should the
product owner be doing this? Obviously the PO is not doing this, and you have
a leadership position, so I would not hesitate too much.

------
mathattack
If you bury it as others suggest, you will lose credibility as a leader even
if you have covered yourself. There is no good answer to “Why are we finding
out about a 3 month slip the Friday before deployment? If we are 3 months
behind shouldn’t we have more than a day of notice?” Execs hate surprises and
engineers hate bosses who don’t tell the truth.

The key to surviving this is:

1) Informally let everyone who may look bad know the truth.

2) Gather data. (No metric is perfect but this takes it away from being about
people)

3) When it comes time to present formally, list what you are doing about it
and what everyone else needs to do. It should be worded as, “To hit this date,
we need Jane QA to do X, Joe PM to pick the two most important features, bla
bla...”

4) Document #3 in a plain-English follow-up email. List names not orgs.

5) Send weekly updates to number 4 in writing.

If people don’t give you the help you need, you’ve done your part. They also
won’t be surprised.

In all of this, be specific, factual and unemotional.

------
LoSboccacc
Never let time pass. Project timeline slips one day at a time. As a lead your
role is not to control scope, but if you feel your team will not be able to
deliver by deadlines you have to make a case for it and you’ll need:

\- A simple summary: we need to deliver by x but current estimate point at y
being the delivery date.

\- An estimate of delivery for each features you have visibility and their
dependencies (not task, features. This email will escalate at some point and
you need it be management friendly)

\- A backing analysis to defend your task time estimate. Maybe as an external
link or attachment.

\- A suggestion on a set of feature you feel could be cut or postponed after
release to keep the project within deadline.

The fire alarm need to be sounded immediately as you see smoke. Start with
your direct manager, but first build consensus between the team: you’ll be
squeezing the manager toward the owner, and for him tje path of least
resistance will be to put pressure on you and the team.

------
patan2
Whatever you do, DO NOT ADD new team members to an already delayed project. It
will delay it further. Break down the project into simpler tasks that can be
assigned to a team member and be tracked. Attach strict responsibility of task
to team member. And last and most important, talk to your Management about
timelines. Make it very upfront that it will take X number of days and no
lesser.

~~~
muzani
3 months is actually enough time to add people, especially if there's the
possibility of a deadline extension. I normally consider 1 month the break
even point. You do have to schedule training and all.

Another way to look at it is that programmers hate death marches. Projects
like this could lose people, and sometimes it's good to have some backup.

~~~
jcadam
Depends on the project. In aerospace (my industry), 3 months is not enough
time. There's so much process and bureaucracy that _everything_ moves very
slowly. At 3 months, the new person may be just starting to look at source
code.

But of course, they still try it anyway.

Lead: "We're in serious danger of missing our delivery date in 6 months."

Suit: "Egads! Here, have 5 new grads with no experience for your team, get it
done!"

------
mikekchar
Words I've used with success before: "I've got some bad news. I've been
running the numbers and based on our current progress, it doesn't look like
we're going to hit our release schedule. Now, it's possible that we've just
hit a slow patch and we will pick up steam later on, but my experience has
been that this rarely happens. Everybody on the team is still really
optimistic and we're working very hard to hit the release, but I wonder if we
should start to make a contingency plan. For example, if we take this part out
and plan it for after the release, I think it will help. If we pick up speed
again, we can just roll it back into the process. I really don't want to add
any more people on the team right now, because we have a really good chemistry
at the moment. I don't want to risk losing time by trying to integrate someone
new. What do you think?"

If the response is, "You'd better hit the dates or heads will roll", then
respond with, "Of course we'll do our absolute best!" and start looking for a
new job.

If the response is, "That's disappointing, but we can't change anything
because all of our marketing/whatever is dependent on you finishing everything
on that date." Respond with "Of course we'll do our absolute best! Let's see
how it goes for the next 2 weeks and hopefully it will get better". Start
poking around under the hood to see if there is any wiggle room for pushing
things out (i.e. are you being fed BS, or is it really the case that the
company is doomed if you don't deliver). 2 weeks later have the appropriate
conversation. One time I had to say, "I completely understand the position
we're in, but I'm sorry to tell you that the odds of us completing our part of
the work on time is extremely low and I can't think of a way to fix the
problem. I think we're going to need to work on a new business plan."
Basically its realistically discussing the "we're totally screwed" reality.
Try to find the best compromise that you can, while looking for a new job in
the background :-)

Otherwise just play it by ear. Unreasonable product owners will be
unreasonable no matter what you tell them. You might as well tell them the
truth. If they are going to flip out, then let them. If your product owners
flipping out bothers you a lot (it bothers me a lot ;-) ), then look for a new
job.

However, my experience is that when you are not flipping out yourself and are
open to listening to the other person's problems, usually good things happen.
I don't often look for new jobs when my projects aren't working out as hoped.

~~~
adrianhel
If you get the marketing team response, determine what has actually been
marketed. You can probably remove some things with noone being the wiser.
Create a prioritised backlog. You'll be the only one knowing that feature X
probably won't reach the release, but noone will care. I did this recently and
everyone were excited about the release, despite pushing for some features
that were labeled low pri.

------
d--b
A company is a company, your manager is in your team, the product owner is in
your team, the salesman is in your team, the CEO is in your team. Talk to your
manager, and your manager will talk to the stake holders to see what to do
about it. Delays happen all the time. No biggie. Just try and understand what
went wrong (to make sure the next one doesn't suffer the same) and how much
time it will be costing. They'll be asking you anyways...

If you're in one of these companies where people are not allowed to screw up,
then I would recommend you start looking for a healthier work place.

Good luck

~~~
OliverJones
Exactly. Managers manage many things, including expectations. Make sure your
manager and you are on the same page about schedules. Then let her do her job
while you do yours.

If your manager decides to blame you, rather than defend you and your team,
it's resume time.

~~~
arethuza
Managing up is the most important thing a project manager can do ("shit
umbrella vs shit funnel") - if they haven't been communicating the actual
status of the project then they haven't been doing their job.

If they don't _know_ the actual status of the project then they haven't been
doing their job either.

------
jezclaremurugan
This contradicts the advice others are giving but in my experience here's what
has worked for me. * Communicate early * Document the warning signals - have
an email thread - this is critical in saving you later * You will be asked to
hustle, have explanations for why hustling won't help reach the deadline *
Have clear reasons why the delay is caused - why wasn't the skill gap known
earlier?

Be ready to lose some weekends and burn additional hours - but people will
appreciate your being on top of things.

People shoot the messenger - when the messenger is too late in delivering the
warning when the rest of the business can't do anything to fix it. Even if
management is anticipating delays - it will still look good on you that you
are able to foresee problems, and your foresight will be rewarded later on.

People don't like hearing bad news - but if the bad news is delivered early
and documented in such a way that it makes them responsible for not acting on
warnings, they tend to work on it positively.

If you do the above and still get shot as the carrier of bad news - the work
culture is toxic you are better off working elsewhere.

------
ChuckMcM
This is such a hard question because it is intimately intertwined with the
culture of the organization in which the activity is occurring.

Bottom line, stay true to your own sense of integrity and be honest with
whomever asks for your assessment of the situation.

I agree with the other comments that suggest you have conversations about your
management and that you journal your progress and concerns.

The cultural question is around what happens when it is obvious the schedule
is going to slip. In some organizations the group looks for someone take the
heat and they heap a world of pain on that person. Generally that is the
person who doesn't have any record to back up their assertion that they told
everyone else it was not going to work. In other groups there will be a great
ceremony of replanning and another unrealistic deadline will be pronounced and
the cycle will simply repeat. Sometimes organizations will want to figure out
how they got the schedule wrong and apply fixes (your journal will be
invaluable there).

------
larrywright
The most important thing is to show progress. Agile/Scrum/XP are much-maligned
these days, and with some good reason, but the one thing they do very well is
to get you on a cadence of delivering working, demo-able code on a regular
interval. Every situation is different, but in my experience being able to sit
in front of stakeholders every couple of weeks and show them what you've just
built, talk about what you're building next, and explaining anything that
might impact that, gives people a lot more confidence in a team. In my
experience, what scares stakeholders is when the nerds disappear for months at
a time with only hand-wavey status reports to show how they're doing. Get them
in a room on a regular basis, and demo what you've built. If you can't get
them all in a room, record screencasts and share them, or demo over
Skype/Hangouts/etc.

------
boffinism
> we're not going to make the release

> At what point should I start sounding the alarm?

Immediately.

IMMEDIATELY

~~~
arendtio
Well, ring the bell NOW so you still have time to act. Make sure you bring all
the facts you have that make you think that you will miss the release. Ask
your team what they think how much time it will take them, given that new
evidence.

Then get everybody onboard (your direct manager first). Talk about the
problems you have and how you can solve them. Make a plan that _everybody_
believes in and set a new release date together.

In general, modernization projects are not about timing, but about high
quality. So cost are the only variable here, making it important to know how
much that project is worth for your organization. Is it just nice to have or
critical for the development of the next years as it cleans up a lot of
technical debt? Keep that in mind as the consideration of stopping a project
is always on the table when it leaves its frame.

------
aytekin
You will not be able to release “everything” in 3 months, but what if you
picked the most important parts and focused on getting those out?

------
hallihax
I think ljw100's advice is pretty spot on.

It's very tempting to think that on a practical level, people 'need to know'
what's going wrong. Unfortunately it is often very difficult to accurately or
objectively assess what the underlying problems are and in many cases, what
you perceive as a problem can actually turn out to be a symptom of some other
issue.

Project slippage happens all the time - and in and of itself it may not
indicate any serious issues. It could just be a case of poor estimation, or
scope creep, or some other 'process' related issue which is unlikely to be
something any single individual can do anything about.

In my experience, the best way to deal with these kinds of situations is to
make sure you're keeping your relevant colleagues up to date. If you feel like
some deadline isn't going to be hit - it's probably best to voice your concern
about that risk (and only that risk) to your immediate superior. In many cases
it's likely that people are well aware of how behind things are - but everyone
has a different assessment as to why.

In such situations it's often the case that the most you can do is to tend
your own garden. It's important to keep the chain of command - even in small
organisations (and especially when dealing with multiple teams /
stakeholders), and avoid trying to assign blame (or even identify 'the cause')
unless specifically tasked with figuring it out.

Basically: if it's not your job to raise hell about things, then don't. Keep
your superiors up to date with progress and let them figure out the
implications.

Although it can be intensely boring, project management tools can help to de-
politicise these kinds of situations: graphs aren't personal, and the more
regularly the relevant people can get a snapshot of progress, the less likely
it is that it'll fall to you to point out when things aren't going as
expected.

~~~
convolvatron
if you're doing it right, its not boring at all. its only boring if the work
and the people are meaningless abstractions, which makes moving them around on
the board pretty pointless.

if they are your people then there are all sorts of opportunities to
reorganize what gets done first, and who is working on what, and how it all
fits together.

you can take a unfocussed seemingly infinite amount of work and turn it into
'if we can just get this seed part done, then the rest can hang off that. jane
and timmy, since you are both working adjacent to that piece, and I trust you
both to sit down and make it happen - please do that'

thats the best part of the job

~~~
hallihax
Fair enough - I actually don't mind the PM side of things all that much, it's
just not what flips my bits.

------
rinka_singh
* Put a risk database in place - what are the project risks, mitigation strategies, probability the risk will happen and the impact on the project.
    
    
      Start tracking this risks DB on a weekly basis
      Involve your Manager and the product owner in the risk analysis and mitigation task.
      It is shared responsibility of management.
    

* Use this to forecast the Estimated time to completion (ETC) - STARTING NOW,
    
    
      Each week update the ETC and show how it has changed as a result of the risk mitigation.
      Sit down with the product owner and juggle the features to get to an optimum mix of ETC, features and risk.
      He/She has to take responsibility along with you.
    

* Communicate, communicate, communicate.
    
    
      Up and Down and sideways...
    

Best..

------
ochrist
First: It's difficult to advice on these matters in cyberspace. But as I have
been in similar situations, I can give you some general advice: First, break
things up in smaller phases or sprints, setting some milestones based on
sensible estimates. Get the team to commit to these estimates and the
timeline. Second, ask the customer/PO to prioritize features (as others have
pointed out) in Need to have, nice to have etc. Third, make the customer/PO
prioritze what is most important in the project triangle: Time, scope, quality
or price. If you make a simple plan (eg. a burn down graph), you can follow
the progress and adjust the plan if necessary. You might consider doing a
simple risk analysis as well. Good luck.

~~~
wolco
The best advice in the comments. You breakup the project into sprints and let
the product owner choose priority.

------
_dan
Tell _everyone_ there's a problem. Immediately. Make sure they understand that
"working harder" isn't going to fix it.

Reset everything. _Massively_ reduce the scope of the project and make sure
everyone knows that's what you're doing and to expect to see something being
delivered soon, but that it will be a small and simple component intended to
get _something_ out there.

Deliver the smallest useful thing you possibly can as quickly as you can, and
show everyone,

Once you've delivered a few parts get a bit of momentum, get everyone together
and hash out a _slightly_ bigger next step.

------
ransom1538
For next week, get a list of things you can work on. Spend 30 minutes with the
team monday morning deciding what is the most important to work on. Agree with
the team these items will be done by Monday (if something can’t be done in a
week break it down.) Execute.

Things cannot be* late. You are only on a week timeline. There is no other
timeline. Forecasts outside the week are unpredictable and should be ignored.

This will give you a velocity (items done per week) and start quickly building
team confidence. Things get done.

Don’t let anyone change or modify the week goals. If some one wants something
they pitch for it Monday.

------
ksec
I do not believe in blindness optimism which seems to be the way things work
in Silicon Valley. But That doesn't mean you are not going to achieve it, but
you have to strategically plan your features / function.

A Project or Product are never really finished. There is always a long tail of
things to do or remake. In case of the goal being so far ahead, pick three (
or may be just one depending on teams size, but no more then three ) things /
function / product features, that it MUST work, start _sprinting_ towards
those goals. Make them sound as easy as possible. Make a deadline that they
know they could _sprint_ to. My experience has taught me, may be only 1 out of
every 10 or 100 person can see the bigger picture. Human are not very good at
broad perspective, that is why you must set small enough goals, that is
mentally easy to comprehend, and therefore mentally easy to achieve with hard
work, but not impossible, damaging morale.

Most of the time, ( if not all the time ), once you prioritise those goals and
reach within 80%, of what _looks_ nearly finished project. This is a good time
to talk to direct manager, because your last 20% of project will likely take
the same amount of time as your first 80%. The higher management will
hopefully, having seen the good enough 80% work, decide on which direction to
go next. ( Which is another broader set of view on how to jiggle product /
project / business/ operation / expenses priorities. )

------
kodablah
I am no lead, and never will be with my attitude towards these things. But
sound the alarm immediately, realize that the business doesn't care because
they have deadlines, watch it burn, then leave such a toxic environment. The
order of the last two steps is interchangeable.

Sadly, everyone thinks removing yourself from bad environments, especially as
a lead, is selfish as though the company isn't. Also, many assume leaving is
impossible/difficult, but in our industry at this time, that's rarely true.

------
bluGill
Others have hit on this (so read the discussion: they are right - even when
they seem to contradict each other), but I'll say it again because I think it
is critical.

You need to find the real needs of the real users and customers. You need
these in priority order. Perfect answers are not required, just good enough
answers. Now get your team focusing on getting things done in priority order.
When your 3 months are up you can then say "we didn't get everything, but we
think it is good enough".

If you cannot get someone else to tell you priority, then start asking
questions until you can come up with an answer. Sometimes you have to make a
decision and hope you are close enough. Sometimes you will find other people
(marketing, sales, your boss) who will help. An incomplete team that
recognizes that things might not be perfect but they can influence one where
the imperfections are is better then going alone, but go alone if you must.

Note that customers and users are not always the same! If it is a customer
need you can fake it as it won't be used, so make this look good, but make it
obviously useless to users. If it is a user need it needs to work right, but
it doesn't need to look as good since the customer has already bought it. Of
course for release two you have feedback on what needs to be fixed.

------
everdev
Set some interim goals, estimate them and measure progress. Take that progress
and estimate the remaining work. There's no accounting for the unknown, but
IMO it's best to raise the alarm as soon as possible. Just make sure you and
the team have the ability to deliver the project, otherwise it's time for a
different conversation where you look for outside help.

As much as everyone hates deadlines they are important and try your best to
meet them if they're realistic.

------
Double_a_92
1) Tell the manager that "sold" it to the customers

2) Create a clear list of planned features with him (if you haven't already)

3) Priorize the features. I.e. find out the ones that where really promised to
the customers (the manager knows). Usually it's just 1-2 key features that
sell the product.

4) Focus just on those and code properly. Especially if you are doing a
rewrite / modernization. What's the point of having a new product, that is
hacked spaghetti code from the beginning?

------
lscharen
One thing to do is to push the knowledge and acceptance of the situation up
the management chain, especially to the non-believing Product Owner, lest the
Thermocline of Truth[1] be revealed in two months and three weeks.

1\. [http://brucefwebster.com/2008/04/15/the-wetware-crisis-
the-t...](http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-
themocline-of-truth/)

------
q-base
If you are lead, then you should lead. If you lose faith, they lose faith.

That being said, faith won't magically fix everything. If you are unable to
make it, then figure out what you can deliver and then tell your
manager/product owner. Deliver the "bad news" with a constructive alternative.
Cut away some features and then going forward be ruthless about scope creep.
Urgent thing CAN come, but then others needs to be removed.

------
dodgyb
Be prepared for the questions that you will be asked when the alarm is raised.

Q1. Why late? Work is 'outside of comfort zone', thus accurate estimates are
impossible.

Q2. When will it be ready? Scope, timescale and quality are interdependent.
Ask 'the business' which two are most important to them. The remaining item
will need to be revised. My recommendation would be to curtail scope and
deliver the rest in phase 2. If they say timescale can be extended the revise
estimates based on current velocity, i.e. if you are 30% behind where you
expected, add 30% to all outstanding work items. If quality is cut, make sure
they are aware of the additional support and maintenance costs that will be
incurred.

Either way, do as rinka_singh says and get the PO/PM to establish a risk log
accessible to all. I would add that each risk should be assigned to someone
who is responsible for tracking it. Review the log each week.

Raise the alarm now because there will be dependencies, and you are probably
not aware of all of them.

I would not be worried about how the alarm is percieved, if your intentions
are to steer 'the business' away from a cliff it will be recognized.

------
bsvalley
Setup a meeting with the dev team (only). Go over all the main features
required for this release, ideally, they should already be in a form of "user
stories". Depends if you're in an Agile env or not... in 2018, I hope you guys
are.

Then during this meeting, run a deeper and more detailed estimate for each
user story. How long would it take, what work has to be done and is it
depending on any other team or future work? etc.

When you get a better understanding and know how off the original
estimation/deadline is (compared to this new one), setup another meeting with
your PO and your manager to share this information. Obviously you will need
material for this meeting. As a lead, that's your job to create that material
(slides, etc..)

That's it. As a lead, your job stops here. Any other decisions will have to be
made by your PO or manager. Your role is to share that knowledge because these
2 don't have a clue about the actual work that has to be done down to the
lines of code.

Good luck (you're not doing anything wrong at the moment, just bubble up the
information and let them do their job).

------
scarface74
I wish I had some good takeaways from my first and only experience as a dev
lead.

The Good:

\- I came in with a blank slate. They had no source control, no CI/CD, and two
"database developers" using an ancient platform with only passing knowledge of
any modern language - C#. I was able to implement best practices and teach
them how to code in C#.

\- The developers were eager to learn and were smart.

The Bad

\- The company moved the entire project to AWS but to get anything provisioned
I had to go through both my manager, the net ops people, a bunch of hired
consultants, and an outsourced cloud management company. I never did get
access to anything outside of some EC2 instances.

\- None of the people involved knew anything about AWS besides how to
translate an on prem network to AWS and then wondered why it costed more.

\- I had a budget to hire, but only contractors. All of the best developers
wanted a full time job with benefits. I never got the cream of the crop.

\- When the company was acquired, they decided that they didn't "want to be a
software company" and wanted to outsource everything. They did however want me
to lead two more projects to completion. I stayed long enough to finish phase
1, but it wasn't the best implemented thing in the world. It was
architecturally sound, but didn't leverage anything AWS provided.

\- Everyone above me was jockeying for position at the newly merged company
and didn't make development a priority.

My solution:

\- I left for a job that pays slightly more where from day one I was given AWS
admin access (yes I had the qualifications and experience). I'm now "just" a
Senior Software Engineer but I am nowhere near as hamstrung when it comes to
getting things done.

------
ddebernardy
There are hints in your question that you might be undergoing some major
rewrite/refactoring across the board. If so, that has always failed insofar as
I've experienced or seen experienced it.

FWIW a better approach would have been to break the entire thing down into
smaller, more immediately achievable milestones. Ideally do so alongside
enough exciting new stuff to keep your developers' morale high - be weary that
some might already have low morale if they're noticing that the project
they're working on is going nowhere.

At any rate, the time to bring up the problem is likely now. Have a candid
discussion with your team. Explain what's going on; collect data points you
might be less aware of and new ideas as you do. Sketch out a brief but equally
candid status of your current situation (in writing) to let your manager and
the product owner in the loop, along with an outline of next steps get things
back on track.

------
dylanhassinger
Read "Getting Real"

[http://gettingreal.37signals.com/](http://gettingreal.37signals.com/)

Yes sound the alarm. Your heading towards a a million dollar failure.

Instead define a bare minimum feature set for 1 user role, build a mvp with
that minimal feature set and get it into the hands of users

then start adding more

------
sajagi
It all depends on what kind of company are you in, what kind of people are
your superiors, etc. How much politics and backstage dealing is involved?

In an ideal situation I would say call be honest and tell the stakeholders
your view.

On the other hand, from my corporate experience, it's not always the best
course of action. See - as lwj1001 already said - some companies play sort of
meta-game, where certain things are known but never said out loud. If you are
in a position to change the environment - great! (But this is not likely the
best opportunity to do so). Otherwise... I would still say your opinion to
those who need to be informed, or even better - write them an email. The
reason is - you might have to cover your ass in the near future. The worst
that can happen is that everyone assume everyone know yet there is someone who
doesn't.

------
Cieplak
Not sure if there’s a silver bullet, but there are certainly lead bullets. I
found this really helpful:

[https://hbr.org/2015/01/what-everyone-should-know-about-
mana...](https://hbr.org/2015/01/what-everyone-should-know-about-managing-up)

------
trm42
Sounds kind of familiar. We started a mvp/prototype that was handed to one guy
without that much of a planning. That guy is really good coder but not a
product owner/manager, documentor or planner. You see where this is going?
This was about empowering team members with responsibility.

Without a concrete plan it was really hard for the rest of us to help or say
what's really important. And so began the feature creep for something that was
suppose to be a quick prototype ended up being whole implementation which took
half a year to get first somewhat working version.

The problems for us was we didn't know status of anything as it was always
promised to be ready in 1-2 weeks but feature creep made it bigger and bigger.
We tried to help with planning sessions etc but that wasn't enough to get the
prototype back to track.

As everybody got a bit too rosy picture of its status, our salesguy started
selling the idea forward. The timing seemed to be right etc but we didn't have
even proper deml version as the one guy chugged on with his waterfall ad hoc
dev style...

After our sales guy confirmed there's lot of demand for this proto and we got
the first somewhat working version out and when the next steps were not really
sane, we made an intervention which we felt we should've done four months
earlier.

First we had a team discussion and decision what should we do together for the
situation and then we created concrete plan for the next steps we felt we
needed to get first sane version out. Then we made this public to everybody.

The funny thing with this intervention was that the guy who made the feature
creep proto felt relieved after this. The biggrst reason why we were so
reluctant to intervene was that this guy would get badly demotivated but he
had chugged on so long he did get really stressed and frustrated with the
situation but didn't know how to get help in the hole he had dug in.

So my advice is to talk out loud and make things visible. Timelines, features
bot yet implemented etc. Maybe a gant timeline etc. These helped us to get the
project to a sane point shere to continue.

~~~
BigJono
> Without a concrete plan it was really hard for the rest of us to help or say
> what's really important. And so began the feature creep for something that
> was suppose to be a quick prototype ended up being whole implementation
> which took half a year to get first somewhat working version.

This is interesting. Every example of scope creep I've run into has been a
case of too many cooks in the kitchen, or an over-zealous "thinker" (as
opposed to a "doer"). If I want to avoid scope creep I limit the scope of the
project to as few people as possible and get them as close to the users/market
as possible.

It sounds more to me like everyone _did_ get their two cents in, but not in
the correct way, and this lone developer was formulating the requirements
based on way too many informal channels rather than one structured one.

------
sethammons
Break things up into milestones (preferably deliverables). Put team-agreed-
upon date estimates. Provide regular updates to higher-ups on the status
(maybe every week or two). Try green, yellow, red as classifiers on each
milestone. Identify potential issues and/or blockers. Communicate those and
what your team is doing to mitigate them. Document what does get achieved, and
communicate that too. Come up with contingencies and compromises, such as "if
we remove freature x, we could shave off 5 days, or if we have extra help
testing features a, b, and c, we might be able to push up milestone y.

At least, at my org, these are all considered appropriate.

------
User23
Please forgive my generalizing, but there aren't a lot of specifics to work
with.

Scope creep is often a major factor in situations like this. In my experience
product people usually believe that relatively small feature changes imply
relatively small engineering effort, and of course that doesn't hold
generally.

Sometimes product people will try to sneak scope creep by as a "clarification"
of requirements, which almost always leads to the situation you're in.

So, depending on your environment, it may be constructive to draw attention to
this, if it's applicable.

------
kps
_The Mythical Man-Month_ , Fred Brooks, 19fucking75.

What has been done is what will be done.

------
lmeyerov
Yep. Folks know (or you have bigger problems). Leadership doesn't want FUD nor
misleading positivity, they want constructive & predictable leadership... even
if late.

The conversation they want is, "As the leader, the risk X has now hit, and to
avoid underlying Y happening again and achieving predictability goals Z, I'm
leaning to A or B on this timeline with those key delivery+derisking
milestones. To get there, can you help with resource/negotiation/decision C,
and what are your thoughts on alternatives?"

------
benbristow
Split the project into sub-tasks and order them on a kanban board
(Physical/Digital). Figure out which sub-tasks are most important and work
through them. Assign them to people if need be. Take time out to do a standups
around this board at the start/end of the day to figure out where you're at.
Higher ups will be able to see this too and probably will appreciate the
clarity.

Even if you don't hit your full deadlines you'll have a more complete
'product' this way

------
crististm
By the way: it's your job to buffer the pressure from upper management towards
the team so they can see you have a backbone and to maintain morale. They are
_your_ team.

------
totalrobe
Maybe your org is different, but the way your question is worded you are a
lead developer, not a project manager. I'm a believer in flat orgs to some
extent, but as a product owner/pm myself, this communication should be coming
from the dev project manager, along with revised timeline and/or mitigation
plan. The only alarm should be to your project manager, and in the form of
objective analysis of the number of items completed against the plan.

~~~
arwineap
To add to this, maybe your PM can help by getting scope reduced, or additional
QA resources.

If they suggest more dev resources, be wary; that almost never speeds up
project completion

------
shove
What's funny is, you can armchair quarterback this all you want and it likely
won't matter one bit. Toxic organizations gonna be toxic, and healthy
organizations (probably) gonna be healthy. From outside, it's nearly
impossible to tell which is which and by the time the OP is sure, it'll likely
be too late to make any difference.

Maybe they make you the hero, maybe they make you the fall-guy. Very little
you can do to influence that. Focus on the work.

------
al2o3cr
Lots of good advice on prioritization & managing expectations already, but
here's one part that jumped out that hasn't seen much attention:

> The team is great, it's just that the work is way outside their comfort
> zone.

This reads to me like the team doing the implementation literally _couldn 't_
have estimated this work at the start. Who in the company committed your team
to deliver a fixed set of features in a fixed timeframe with new technology?

------
wsy
In addition to all the good advice already given: this question has (at least)
three different dimensions:

\- what would be best for your company?

\- what would be best for your team?

\- what would be best for you?

Try to come up with answers for these questions separately. In particular,
find out what is important for you personally (making a career, gain trust
with your team, being open and honest, etc.). Identify the communication
strategy which optimizes the outcome for you, your team, and your company.

------
wiz21c
Question : why does it take longer ? Team ? Development process ? Strategy (by
modernization, I think "rewrite", which is always hard) ?

Question : how will suffer if you're late ? (no, it's not the end users, it's
someone, somwhere who said it was possible, whose career path is tied to the
project, etc). Make sure he won't suffer too much, that may give some room on
the planning.

------
tmaly
The project will either fail or be severely scaled back to launch a minimal
version of what was promised. I would hedge bets and try to figure out what
the crucial features of that minimal version are. Focus on those, and build
extensive testing that will help you when its crunch time. I did just that and
was able to launch a project.

------
z29LiTp5qUC30n
Well there is only one way a modernization project could have gotten into that
position; You were doing a rewrite.

A modernization project is only a modernization project if it is incremental
by design and you have frequent releases (minimally monthly).

Throw out the flag onto the field and get the train stopped before you end up
causing the entire group to be fired.

------
icedchai
This is basically normal. Virtually every software project, except incredibly
simple ones, has delays. People, even experienced ones, are very, very bad at
estimating.

Just meet with your boss and manager and explain the issues, sooner than
later. If the product owner is still in denial, well, you told them... They
have to face reality.

------
ujjain
Keep morale of the team high.

Nothing worse than feeling to be on a failing project with lots of pressure to
make unrealistic deadlines.

------
debt
"The business has been selling the new version.."

But it's not built yet? IANAL, but make sure they're doing this correctly.
There's a fine line between selling and outright lying aka fraud especially if
the "new version" doesn't exist.

Serious question, are there any adults around that can help your team?

------
skate22
If you're not on schedule, tell your PO. We estimate tasks to be done as if
they were done by even the least experienced teamate.

My PO would rather cut a few features and hit the deadline than deliver
nothing because we wern't conservative in our estimates.

It's a lot easier to plan for the worst early & hope for the best

------
raverbashing
> At what point should I start sounding the alarm?

Last week ideally. But now is fine.

> give it a couple of weeks and see if the team picks up pace

They won't if nothing changes.

What do you mean by "outside of their comfort zone"?

Is it a technology that people don't master yet? Do you have experts on that
technology already on the team?

------
feyn
FWIW [https://neilonsoftware.com/2018/07/12/my-response-to-as-a-
te...](https://neilonsoftware.com/2018/07/12/my-response-to-as-a-team-lead-
how-to-handle-project-going-off-the-rails/)

------
adrianmsmith
In addition to the other advice here, regarding how to handle this politically
and from a communication perspective, I think you need to quantify to what
extent you're not going to make the release.

\- You need to write down all the things that need to be done, the granularity
of task should be between half a day and two days. (Anything larger than 2
days will be a task like "refactor this system" that hasn't been though
through enough, and thus likely to be completely wrong.) Do this in a meeting
with all your team members, they will be telling you what they foresee they
need to do.

\- If you can't estimate things, because e.g. the system design hasn't even
been started yet for those things, you need to design them, at least on a very
high level. So that you know, at least to some extent, how long you think
they're going to take.

\- Write down estimates for the aforementioned tasks, in person-days, by
getting your team members to estimate these tasks.

\- Ideally use some kind of task planning system such as MS Project,
LiquidPlanner, manuscript.com or some JIRA plug-ins that can handle this sort
of stuff. But even a Google Spreadsheet shared between your colleagues will be
better than nothing.

\- Now you'll know an end date. How far out is it? 4 months rather than 3? 12
months rather than 3? That makes a difference. If you're going to be late, you
management may wish to give you an extension. If the project's going to take
another year, management may wish to cancel or change the requirements
significantly. You have to provide them with the information to enable them to
make that choice.

\- If it's decided to continue, then update that spreadsheet all the time. Get
your team members to update it, and if they don't do that, then talk to them
every few days and get them to tell you what they still need to do. Focus only
on the future: remove tasks when they're done, add new tasks as they arise,
change estimates on tasks as they're partially completed. So even if you
decide to continue, maybe in one month it becomes apparent you haven't made as
much progress as you'd like, or there have been unforeseen difficulties
resulting in more tasks. Know if it's going off track again as soon as
possible.

Estimate will be wrong. Things always take longer. This is a minimum bound.
But if your spreadsheet says you need another 12 months on a project that only
has 3 months to go, you can be sure that it won't be done in e.g. 2 months,
that's useful information to have.

------
mudiaga
You should have the talk with the product owner already. It's always better to
be open about these things early. Discuss the possibiltiy of completing only
the core features first.

------
jonbarker
A good customer success team can patch sales up that might have promised
features that won't be to spec. But that bandaid only lasts for a short time.

------
ajcodez
I would send upbeat emails at every milestone listing the accomplishments of
your team. Throw in some tech speak to impress non tech people. By the time
the deadline comes and passes anyone on the email thread will know how much
your team has done and will trust you to finish the job.

I would also assign tasks or busy work as the deadline approaches to anyone
who is waiting on you to launch. Have them beta testing, etc. People are a lot
more patient when they have things to do and a lot less patient when they are
just waiting for you to finish already.

------
trh88
Best advice I have ever been given (in project management generally) is that
it does sometimes go wrong, and when it goes wrong:

STOP. RESET. CONTINUE.

------
chiefalchemist
Lots of great input. I'm still going through them all.

That said, I would update my resume and reach out to my network.

If this ends badly you want to be prepared.

------
egeozcan
Cut features until it'd make the deadline, even weeks before the deadline.
Have something to show. That's my only advice.

------
loydb
I'm firmly in the 'raise the issue with your boss immediately, and let him own
the fire alarm decision' camp.

------
pdfernhout
As others have said, key at this point is going to be to _prioritize_ in
relation to business needs. As hard as that all will be, the process will only
get more difficult the longer you wait. I'd also suggest one thing you
prioritize personally for yourself whatever happens is eight hours of sleep
every night. :-)

As other have also said, you're also going to have to tailor the way you
present the message about the facts (i.e. the "alarm") to your current
organization's culture and your specific situation in it. You'll need to keep
in mind your own talents/resources and current limitations in developing a
message or plan (see also "Dunning–Kruger effect" for risks on that).
Talents/resources and limitations include your own ability to present a
message and what help you can rely on from the rest of the organization to
develop a message and present it based on what your coworkers, manager, and
management chain value.

If you eventually want to reflect on the larger issues that may have gotten
you to this unfortunate situation and what your company can do better in the
mid-term and long-term, here is a reading list I put together that includes
multiple books on software engineering management as well as broader
surrounding issues -- including a great book by Matthew Walker on the
importance of adequate good sleep for everyone in an organization:
[https://github.com/pdfernhout/High-Performance-
Organizations...](https://github.com/pdfernhout/High-Performance-
Organizations-Reading-List)

One item from there:

"Why Deadlines Need to Drop Dead" by Eric Elliott
[https://medium.com/javascript-scene/why-deadlines-need-to-
dr...](https://medium.com/javascript-scene/why-deadlines-need-to-drop-
dead-321739ae6be1)

"Deadlines are incredibly destructive to team productivity and morale. The #1
challenge software developers face is unrealistic expectations. Can we
motivate & push without arbitrary deadlines? You can lead teams without
deadlines. You can still deliver code quickly. You can still ship in time for
Christmas. But you’ll be dealing with a different management framework. One
that puts the deadline pressure on product managers rather than developers.
... The point here is that instead of trying to build out the CEO’s ideal
vision of the product you’re bringing to market, you build out a beautiful
stepping stone on the way towards that vision. In place of arbitrary
deadlines, you deliver consistent, steady progress."

Eric Elliott advocates for the Marketing department creating each hype cycle
for what is already finished and tested.

------
snarfy
Who said it was going to be done in 3 months? Where did that unrealistic
number come from?

------
expertentipp
lawyer up, hit the gym

On a serious side though, perhaps release a beta version in the following days
with the current state of the service/product? Maybe even give the customers a
preview? That would be a cold shower and wakeup call for all stakeholders.

------
quintes
Note the risks ( non delivery ), inform stakeholders, and plan a roadmap of
deliverables.

------
PaulHoule
get some quantitative measure of progress (eg. make some kind of simple
burndown chart)

------
ryanolsonx
Ruby on rails. /trolling

------
gt2
Cut/Delay a few features so the thing can be launched?

------
iliasku
just move to sales / marketing. then you'll be the one making unrealistic
promises that noone blames you for when they don't get realised

------
svilen_dobrev
whatever u do, beware: HR dept is there to protect the company from its
employees. NOT the other way around - regardless how much anyone fanfares it..

------
kimdotcom
If it is written in JS, port it to Elixir.

Otherwise, rewrite it in JS.

~~~
tobyhinloopen
Something > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS >
Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir >
JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS >
Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir >
JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS >
Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir >
JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS >
Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir >
JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS >
Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir >
JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS >
Elixir >

OutOfTimeException

~~~
kimdotcom
I think this is funny.

Well done.

