We absolutely must meet this deadline! Can you please do some overtime?
Honestly, how many times did you hear that question throughout your career? What was your answer? If you said “no” did the business add any sweeteners?
Only you can do it! You’re my hero, the best developer I’ve ever met! A god-damned Harry Potter of iOS / Mobile / Backend!
And if that didn’t help, did they bring out the big guns:
Project / department / company / the entire world’s future depends on it!
Do you want to have the blood of all these innocent lives on your hands?!?
What was your reply then? Were you unmoved like before, or did a thought of becoming a hero cross your mind?
The brutal truth is the weak project managers or product owners resort to such psychological tricks because… they work. Actually, they are far more effective than we care to admit. In the end, who would like to be responsible (even in their own conscience) for losing an important client and/or large fines resulting from not meeting a deadline?
But maybe it actually pays up to be a hero? Albeit a local hero, a person who single-handedly saved a company from bankruptcy must be widely regarded and properly compensated for their efforts, correct? Or maybe pure, cold professionalism is enough?
In this blog post we’ll try to answer this question together. Strap in and let’s go!
A story of a “hero”
I was “seduced” by the possibility of being a hero just once in my career. And I’ll never forget this important lesson.
I was working in a company producing online educational software. The project required us to implement extensions to the core component of the front-end app. The work was progressing as expected until we started working on the last extension. We immediately informed the project manager (PM) that the original estimations were too optimistic, and the release must be postponed by at least 2 weeks. The PM relayed the information to the client and they agreed. Back then, Agile methodologies were just being introduced to the software companies, so developers had virtually no direct contact with the client.
On the original release date, the PM informed us that the client changed their mind and demanded to meet the original release date. She claimed the client didn’t want to hear any arguments and threatened to sue the company if we didn’t deliver. She began begging us to stay “a couple of hours” over the weekend to complete the release (and thus save the company). As idealistic, and stupid, developers we agreed as nobody wanted to take the responsibility for potential bankruptcy of the company.
Naturally, “a couple of hours” over the weekend quickly turned to approximately 20h on each day. We soldiered on and on Monday morning deployed the app and sent an email to the client. Exhausted, we went home to take a short nap and returned to the office later in the day.
We fully expected a hero’s welcome: red carpet, handshake with the CEO, or at least a 6-pack 😀. We saved the company after all. Suffice to say, none of these happened. To make matters worse, there was no response from the client. Such an important release and not even a simple acknowledgment? That began to look bad, so we called the client. They confirmed receiving the released app, but were very surprised it arrived that day. Actually, they fully expected not to receive it for the following 2 weeks, as was initially agreed…
You can see where this is going, right? We immediately tried to reach the PM who organised such delightful weekend entertainment for us, but she was 5000 miles away from us, starting her vacation. As you can expect, the whole “save the company” stunt had nothing to do with the client. They were happy to wait an additional 2 weeks for the release. It had a lot to do with the PM however, as she required a perfect record of timely deliveries to various clients to secure her promotion
Although funny, this is unfortunately an actual story. I bet most of us have experienced (or at least heard of) similar situations. In general, being “company saviour” sucks. So please, don’t try to be one.
Why should we NOT try to “save the company”?
Why indeed? Firstly, because most of the deadlines in software development are just lines in the sand. Breaching these dates rarely results in any significant consequences: necessity to pay fines or delaying marketing campaigns. In most cases, deadlines are just arbitrary values that managers entered into a spreadsheet and submitted to their superiors. Unfortunately, once something is written in a spreadsheet, it has to be delivered. So says the “Law of the Corporation”! So, if a given manager does not want their performance evaluated poorly, they must ensure their deadlines are met. Regardless of how unrealistic, disconnected and arbitrary these deadlines are. Most of the companies are Excel-driven this way…
But what if the deadline is really important? How can you tell when there are real consequences associated with missing a given date? The answer is really simple: look closely how engaged the managers are. Do they also do overtime to stay with the development team? Do they work over the weekend? Do they actively help the team to finish the job e.g. by testing the app, fixing spelling mistakes in localisation files, etc.? Do they involve the team while negotiating the release scope with the client?
If they do most of the above, you can assume the matters are truly dire. However, I’ve seen only 2 cases like this throughout 20+ years of my professional career. And in both of them the client was more than willing to receive a stable, working application, at a cost of not having all the requested functionalities. That allowed us to cut the scope and, with some reasonable overtime, meet the requested deadline. And in both cases, the management supported us throughout the way, including crunching with us in the office.
In general, the golden rule here is: match the management’s engagement.
Arguably, the only downside of you refusing to “save the company” is that a given manager won’t get a bonus / promotion this time. But…
What is the alternative?
It’s more than enough just to be professional. Better yet – be a software craftsman. Solve clients’ problems, not just Jira tickets. Develop partnership with the client, where they commission your work but don’t tell you how to do your job.
In short: be professional, don’t be a “hero”.
Easier said than done! Where should I start? Below are a couple of tips you might find useful:
- Take full responsibility for the project success:
That means not only ensuring technical mastery, but also taking upon oneself a difficult duty of communicating with the business. And that involves an ability to say “no” whenever their expectations are unrealistic. Not “we will try”, not “we’ll do our best”, but simple, unconditional “no”. And the sooner you say it, the more time will the business have to appease the stakeholders and present them with reasonable alternatives. - Don’t make unrealistic promises:
Not only the business is guilty of overpromising. We, the developers, do that as well. It is in our nature to be optimistic when estimating project tasks. To believe in our skills and experience. To always hope for the best, etc. And there is nothing inherently wrong about this. We need to remember though, that our estimations are presented to the project stakeholders, which can get upset should we fail to deliver. And, honestly, so would we if e.g. a car mechanic told us the fix that was supposed to take 1 day wouldn’t be done in 2 weeks… - Don’t be afraid to impact business decisions:
In general, the developers should not make business decisions.
TLDR, we don’t often see a full picture, don’t spend enough time analysing market trends and the needs of the users. However, whenever these decisions impact our ability to produce quality software, we must act. In Agile methodology, a team can stop a sprint should its scope, goal or priorities have been changed significantly. Or to refuse releasing the application if the desired features are not implemented in an agreed upon quality. By all means, I do not endorse an open revolt against the business, but sometimes we need to step up to protect the business from themselves. - Crunch only to deliver something extra:
In general, overtime is always a symptom of something wrong going on in the project. Cranking up the working hours is similar to administering an aspirin for a broken leg. Yeah, it might even help for a while, but in the long term?
Instead, you should get to the root of the problem and address it. But this is a topic for another discussion 😉
In my humble opinion, the only “acceptable crunch” is when the team agrees to put in extra hours to deliver something extra, e.g.: implementing a killer feature, bumping up app security or getting rid of outdated dependencies. The only condition is, however, that the original scope of the sprint is already implemented and ready to be released!
How does it relate to my daily work as an iOS Dev?
To sum up: we’ve discussed why it does not pay to be a “company’s hero”. We’ve gone through reasons why some business people push for arbitrary deadlines and why most of these deadlines are just lines in the sand. Finally, we’ve discussed arguably the best alternative to “saving the company” – just being professional.
So, how does it all relate to our daily chores as mobile developers?
First of all, no more “Late Friday Night App Releases”. I worked once in a project where the client expected an app to be deployed to Testflight every week. As a result, the lead developer was building the production version of the app on his private Macbook every Friday evening, usually right before hitting a pub. Or right after returning from it…
Neither he, nor the client, saw anything wrong with it.
In general, the application should be released to the client for testing on the regular intervals – after a sprint is concluded. If these tests are successful, the client should decide if they want to release the app to the App Store. The moment you allow the client to force their way to release the app whenever they please, you’re dead. It’s really that simple.
Following up, try to treat the client as a partner, and not as your boss. As we discussed the benefits of this approach in the article: why is quality important in iOS projects?. To briefly sum it up – the client has a problem that they need fixed. Yes, we are being paid handsomely for our services, but that doesn’t mean that the client can tell us how to do our job. It’s on us to choose the tools and methodologies to remedy the client’s problems. If the client prefers to micromanage the entire software development process, it’s best to just walk away. Such a project can be a nightmare.
Finally, it’s always good to define a development standard for your team. A “bottom line” you’ll never cross. It should consist not only of technical guidelines, but also business ones, e.g. changing the app releasing schedule. Make sure to write it all down. Preferably in the project wiki or even the readme file. Let the client know where these rules are written.
If you can, try using real-world analogies to visualise development standard long-term benefits. My favourite parallel is a certified car repair workshop. They’ll gladly fix your car, but it’d have to be done according to their internal procedures. If you do not agree, they’d (politely) show you the door.
But why would they risk losing clients? Especially in this economy. There are plenty of less expensive workshops around… Because they believe clients are not idiots. That a customer that came to them understands the value of a proper repair service that would last for long. Much longer than a bush fix applied in one of these more “affordable” places. That the “experiments” in such establishments may end up damaging the car beyond repair. Or at least generate additional costs far exceeding the original estimates. Does it ring any bells 😉
Only by applying high standards can a workshop guarantee proper quality of service rendered. And back it up with a long, honest warranty. This is also why certified workshops insist on using only genuine repair parts, proper tools and diagnostic software, etc. All to ensure the car stays fixed long after passing the exit gate 😉 And that the customer would return to them again. Or refer to their friends.
Thinking of it, is our own line of work so different? Shouldn’t we have our own standards? Prefer a job well done instead of a bush fix? Is there anything stopping us from applying these simple rules in our daily jobs? I don’t think so!
Don’t miss any new blogposts!
By subscribing, you agree with our privacy policy and our terms and conditions.
Disclaimer: All memes used in the post were made for fun and educational purposes only
They were not meant to offend anyone
All copyrights belong to their respective owners
The thumbnail was generated with text2image
