Even when it appears to be blue skies and smooth sailing, storms can show up. How you react in those situations makes or breaks relationships. Integrity is everything. Every leader will get punched in the mouth at some point, what defines them is how they come back. 

This story begins about a decade ago – Pearson & Hardman had been a client of ours for over a year. During which time, we had build great credibility with on-time delivery and high quality. We then earned a larger project – migrating an old legacy application that was core to their business. 

We headed into this new frontier with confidence and Rebecca – the project leader from Pearson & Hardman – had high expectations from us.

Informulate had put together a team of 5 of our most-trusted and skilled developers and for the first few months, everything was going great. Demos looked good and features worked as desired. P & H was pleased, new features were coming out at a consistent rate, and it was a great success. Blue skies and smooth sailing.

Then we started User Acceptance Testing (UAT). For the first time, the application was set up in a test environment with real production data and we were hit with a cascade of issues. 

Initially, we thought it was just a few code bugs that we could take care of, but as the client kept testing, we kept finding more issues. Every week, more were discovered.  

Things slowed down. First by 2-3 weeks. Then 4 and 5 weeks. 

We were drowning. The planned QA timeline and budget for UAT had doubled. 

As you can expect, Rebecca and her team were frustrated at the continued extension of the timeline and the extra billing they would have to incur to finish. We were not meeting the deadlines we’d set, and while there were valid reasons for the issues, repeating the same story was starting to sound like excuses. 

Finally, Rebecca called me into a meeting – and I was dreading it. 

“Hey Rajiv, you know we like and trust your team, you’ve done great work so far” She started. 

“But I need to know what’s going on right now,” she started, “We’re five weeks past the deadline and I feel like we hear the same thing every week.”

“I understand, Rebecca. Sometimes things take longer than they should, but 5 weeks is outside the norm. Honestly, the way that development was going, this has taken us by surprise – let me dig into it in more detail and can I get back to you later this week?.”

“Of course. You know we appreciate everything you’ve helped us with before, the last year or two we’ve increased the volume of work because its been a great relationship. You and your team really seem to understand our business. But right now, I gotta tell ya – you are getting attention and it’s not the right kind. We’re still a small business and outside of employee payroll, the next biggest chunk of expenses is you.”

She was not letting up either, “The CEO is asking me questions, and I don’t know how else to respond. Budget and timeline are overshot, and we cannot keep resetting every week.”

I was chastened. Just a few weeks ago, this was a very trusted client whom we have worked very hard to build a relationship with. Who would have recommended us freely to their peers. 

And now this, so I had to get to the bottom of this. 

In my analysis, I learned of some testing shortcomings. But the smoking gun was the data. There was a lot of bad data from the old system that pre-dated our work, but we were only discovering them AFTER we had built these new features. 

Worse, there we had many different types of data integrity issues, with dozens of individual data mismatches for each type. There was no way to batch correct them or work particularly efficiently.

Now that I was caught up, I head back to Rebecca. “So Rebecca – as promised, I dug into the issues. Some of the issues are code bugs but most of it appears to be caused by bad data in the database.”

“Okay, I’m not too technical but why didn’t you guys expect that?” 

“Fair question, your database has millions of records, so it wouldn’t have been possible for us to verify integrity on every row of data in the estimation process. However, we should have warned you that data issues could have existed.” 

She wasn’t softening. “Exactly – you did the analysis. You did the estimate. You missed the deadline and now my team is paying for the overages. And I’m feeling the heat from the CEO for overseeing this. ” 

“Rebecca – I understand. While we didn’t cause the issues, it was our responsibility to set the right expectations and raise the potential risks. For projects with existing data, there are unknowns involved and I take full responsibility.”

“I appreciate you saying that, Rajiv. But what do we do now?” 

It was time to step up. “Given our history and relationship, I’m going to do what it takes to make it right. As of today, I’m going to stop any further billing on this project. We will pause UAT, I will keep the full team allocated and we will test and resolve all issues.” 

“That… sounds good. So another week you think?” 

“I will be honest, Rebecca – I don’t know. We are seeing new data integrity issues as we dig deeper because the old system wasn’t designed with the better constraints we have now. I’m going to say 4 weeks and we will get back if we get done earlier”

“So you’re not billing us for a whole month?” 

“That’s right. We will get it resolved at no cost” 

With that, we dove straight into getting their system up to standard and ready to launch. Detail oriented mode on full blast. We brainstormed potential issues, created scripts to find bad data and more scripts to fix them. 

We completed the project in just over a month and relaunched UAT. This time, their testing was successful and we finally launched the application. 

Where are they now? With our collaboration, Pearson & Hardman has grown to over 3 continents and hundreds of employees. And 10 years later, we are still working together.

So – what’s the Takeaway? 

Most importantly, set your client’s expectations reasonably and don’t set yourself up for failure before you begin. Raise risks and propose mitigation. 

If we had been a little more attentive before, we could’ve done a better job setting the timeline and saved ourselves the stress of disappointing a good client. 

And if you make a commitment (even a bad one) you have to step up and make it right. 

Treat your client fairly, and assess your responsibilities objectively. If you don’t meet your own standards – make it right! 

Story by Rajiv Menon, CEO and Founder @ Informulate

(Client and character names changed for privacy)

Let’s face it – you can’t escape office politics. Even when you aspire to work with a client on innovation and transformation there are hindrances to that opportunity. 

How you handle challenges and petty politics can make or break a relationship – and your reputation. 

A few years back, Informulate had been hired by Pillard Inc. This was a huge project, one of the biggest we’d taken on at that time and we couldn’t afford to make anything less than our best impression on them. They worked with sensitive data, so there was a lot on the line for them as well. But we had helped Pillard with smaller projects before, so we had a decent relationship going in. 

Mason was part of the Pillard team and one of the requirements stakeholders on the project. Initially, he came across as positive and encouraging but little did we know he was a bit of a political player – looking for every opportunity to gain “points”.

He was not savvy with software development, but he had strong opinions on his pet projects which he wanted prioritized. He pushed hard for what the roadmap should look like, and we were having a hard time managing his expectations. 

Even with a big budget, his demands were directly clashing with the work that other stakeholders were expecting – and we had to be fair to the overall mission of the project. Our Innovation Governance methodology was based on data-driven decisions and there just wasn’t enough data to back his big bets.

On more than one occasion, in meetings, we tried to provide impartial guidance on the direction, but he wasn’t buying it. At this stage, he didn’t come out directly but through the grapevine, we heard his quotes like “Why does Informulate get to make the decisions?” and “They are just a vendor, we should be telling THEM what to do” not knowing that we weren’t making decisions but only providing a framework to make the decisions. 

Despite our attempts to reconcile, Mason was unhappy and, feeling secure about his authority over us as a vendor, decided to try and discredit us with the higher-ups. 

Blowing even the smallest issues and bugs out of proportion, he started to plant seeds of doubt with a number of top management folks on whether we were right for this job. We knew we had to be prepared to respond.

Sure enough – we were summoned into an awkward meeting with management. 

Mason: “While we appreciate the new features, Rajiv, your team has had a hard time delivering quality. I have a list here of 14 issues we discovered. Are you aware of them?”

“Sorry about the inconvenience, Mason. I’m aware of some of them but if you send me the list I can confirm the rest as well. Are any of those issues still open?”

“That’s not the point!“ Mason fires back. “Sure, your team can fix the issues but why are we paying for your team creating and then resolving issues?”

“Well, some amount of issues is normal in software development, especially for a big complex implementation like this one. But we are a high-quality team and hold ourselves to a high standard. Over what time frame are you pulling these defects from?”

“A high-quality team? Our users are complaining about these issues. It affects our credibility and adoption rate.”

“I agree that the goal is to have zero production defects, and we have code reviews, QA testing, and even your own team doing User Acceptance Testing before we take anything to production.”

“So you’re blaming us for quality issues? We are a trusted brand and if people catch wind of these issues or worse if there is a security incident – this could have disastrous consequences”

“I agree. We are proactive on security and passed your security tests. In fact, I believe there were security incidents prior to us taking over, and there hasn’t been a single one since…” 

It was like a tennis match, we went back and forth for almost an hour before and we had been made to look like fools. 

Another round of reprimanding by Mason came in the form of some emails and lists of bugs, raking us over the coals and over-emphasizing every hiccup in the roadmap. We couldn’t sit by and let this continue to happen. 

I had our internal team pull together industry benchmarks and defect counts. Then I called our own meeting of Pillard stakeholders/management. 

Compared to the industry standard of 7-14 defects per thousand lines–we didn’t have to work hard to remind them of the high standards we hold ourselves to and the quality work we provide our clients with. And they could look at our ticketing system to verify all of this independently. 

Some of the shareholders in that meeting were so impressed, they actually recommended and hired us out to other projects! 

I will be honest, it felt great – turning a major challenge like that into a victory lap in front of Mason. And we’ve used those statistics to sell even more clients. 

Long story short – we are still here working for Pillard and Mason has been moved to a different department. 

But when this kind of thing happens, you need to stand up for what you believe in. There are a couple of things to remember if you encounter something similar: 

1. Seek the truth. If you did well, you want to claim the credit. If you did badly, you should want to know so you can improve. 
2. Use complaints as a teaching experience – don’t ignore challenges. Reflect on your own work, learn what you can do better, and open the door for growth.

Story by Rajiv Menon, CEO and Founder @ Informulate

(Client and character names changed for privacy)

We’ve all had clients with big dreams and great ambitions, but what if you have so many moving parts and constraints that you need to rethink your entire methodology and approach? Don’t get me wrong we are not Process Purists by any means – believing strongly in Situational Excellence i.e. finding the optimal solution given the constraints. 

But when constraints include a fixed budget and timeline, high-quality first launch, and limited flexibility on scope – can you really run an Agile project? 

Informulate was first hired to do solution design and architecture for MasterMind, a startup in the health space, and our first task was to assess the codebase of a mobile app delivered by an offshore vendor. 

Arnold (CEO @ MasterMind) suspected that code quality may be an issue and invited Informulate in to get a second opinion. The code and architecture were indeed poor and recommended a full rewrite. Arnold agreed with a launch date in 5 months, and we seemed to be headed in the right direction. 

Ambitions and reality can be difficult to reconcile though. 

As we began designing the new architecture – Arnold, being the ambitious and passionate founder he is, wanted to not only scale the current offering but also acquire another company and integrate the solutions together. Of course, this required us to change our approach a bit but the budget and timeline were unmoved. 

As we were wrapping up architecture, Arnold felt we needed to do better market analysis and hired a third-party vendor to advise. While this, in itself, seemed like a good idea – it caused us to pause as the scope continued to shift. Arnold further shared that he wanted to enter Pilot with a major client and so quality had to be very high. 

So we had MasterMind, us, the new acquisition, and a market analysis firm all trying to coordinate toward a high-quality Pilot launch with a fixed timeline and budget. This many moving parts can be a disaster, and we knew we could not let things drift.

The pressure was on. 

We don’t always do fixed bid projects, but when we do – it has more Big Design Up Front.

So we took a step back and asked Arnold what he was optimizing for. The budget was fixed, the timeline was fixed, and quality needed to be high – the only thing that had some play was scope. And even that was being dictated by the market analysis firm. This was going to be about technical leadership, finding the right path, and providing guidance. 

We had to go into risk mitigation mode. Every “i” had to be dotted and every “t” had to be crossed. Detailed conversations and negotiations ensued, and we finalized a scope that was going to be tight but feasible. We spent almost 60% of our timeline on requirements and design before we wrote a single line of code. 

At the end of this, we delivered a comprehensive, functional, and technical specification that united all of these streams. Arnold signed off on it, and all teams began to execute the plan – knowing that every day was precious. 

The project management gods smiled and it all came together like a finely tuned orchestra – on time, and under budget. 

So what’s the takeaway? One size does not fit all. The way you do things or have always done things does not mean that’s the only way to get it done. Be open-minded, and listen to everyone in the room before deciding which path to take. 

We certainly met our project deliverables but – where are they now?

Unfortunately, MindMaster is no more. Could the outcome have been better if he had taken a more Agile approach? Possibly. Perhaps Arnold bit off more than he could chew. Perhaps market forces shifted. Maybe he only had one throw of the dice left. 

As a leader, it is important to know what constraints you are setting for your team/s and while it might seem like unmoveable targets are the way to get the most efficiency – it may also hold you back. Remember that local maxima can be achieved with optimization and constraints but global maxima needs more creativity and flexibility to get to. 

Story by Rajiv Menon, CEO and Founder @ Informulate

(Client and character names changed for privacy)

One of the most stressful times for any software project is the day of launch. 

Let’s talk about the Launch Day From Hell.  

When the fit truly hits the shan – your mindset matters. I flashback to many years ago – I was Tech Lead on my first big Go Live. I had seen many launch issues as a developer and it’s always a stressful time but leading one is different. This was the same project that had already seen quite a bit of drama, refer to our 2 vendor fiasco story from March. 

On launch morning  I woke up feeling like I’d been run over by a truck. Headaches, body aches, exhaustion, the whole nine yards–NOT the way you’d want your big day to start.

I was excited though – going into a launch day is like walking onto the field at the world cup finals. You are prepared, you know what the goal is, but you can never know how it will unfold. 

This was a project that was in development for close to 2 YEARS. That is a lot of code that has never seen the light of day. Not to mention a large percentage of the codebase was work from another vendor which added to the risk immensely. 

On top of that, I had just traveled into town the night before, gone straight to the celebration dinner with our team and our clients, and I was still dealing with the travel tiredness. I may have felt like crap, but at least I had a strong team to support me through the day, Rajiv our CEO was on site with me as well as Jared, one of our Tech Leads.

But there was still work to be done before we launched in a matter of hours so we headed into the office to make the final touches. 

Little did I know, Murphy’s Law was in full effect that day.

As we’re setting the agenda, we get a call from another client telling us that their website is down. Definitely not what we needed right now. 

Stressful conversations ensued that I was pulled into. Client anxiety. Critical data. We discuss, Jared makes a few calls and finds out someone has deleted the production database! So off he goes to restore the database and resolve the issue.

Anyhow, Rajiv and I have to keep pushing forward, so I continue on the launch project that requires a good bit of coordination and leadership. I’m working through some final bugs and finishing touches, but most importantly I need to touch base with the client to ensure that they’re aware of the plan. 

We identified 12 open items that the CEO wanted ready in time for launch that we just couldn’t make happen with the team being pulled in so many directions. 

Dave, our client CEO, wanted things perfect. “Tristan, we’ve waited for 2 years to get this launched. We’ve got marketing material that has been singing praises of this product release for weeks. We’ve sunk 7 figures into it, it needs to look good when users come in.” 

This was going to require careful handling “Totally get it, Dave. Likewise, we want to get it perfect as well. Just that with the launch in a few hours, there is only so much we can do. I can ensure we get any user-visible items addressed right away but for things that are lower priority we can put out a fix in a few days. We don’t want to delay launch, right?”

We negotiate work-arounds so that the launch could still happen that day, and I was doing my best to keep a smile on my face. It was going to be tight. 

The pressure was building – surely it couldn’t get worse? Wrong.

Barely five minutes later, Rajiv gets a call that a different client had their legacy application hacked – and it may have credit card information. We had warned this client several times to upgrade their aging application for exactly this reason. But when it comes down to it, its still our duty to help. To say we don’t have time for this would be an understatement. It was all hands on deck, and this time – Rajiv had to take one for the team and go tackle that while I stayed focused on launch. 

How many punches can you take? I had to keep my head up and my attitude positive–there was only so much in my control, we just had to work out the issues we believed to be critical and keep putting one foot in front of the other.

Eventually, the team and I crunched through the most pressing items, and the green light for launch came like a gift on Christmas morning! Delaying launch would have been egg on all our faces. 

Now I wish I could say that launch was a landslide success but because of the codebase we inherited from another vendor, we spent the following weeks fixing several issues. We pride ourselves on responsiveness so we did not require a rollback, and we were able to keep the system running and stable. Thanks to that, even now, Dave is still a fan of our work – so you’ve got to count your wins. 

At the end of the day, I learned a couple things: first, on the most difficult of days, hope for the best but expect the worst. Soak up the criticism, uncertainty and stress but stay positive. 

Second, persevere. Focus on action – if there is something you can do – do it. Prioritize, and get yourself over the finish line. 

A messy win is better than a clean loss. 

Story by Tristan Mills, Project Executive & Solution Architect @ Informulate

Most people are awesome – but every once in a while you run into some crazy. This story is about how one person can make life hell for so many.   

Everyone thinks they’ve worked with a project manager with insane expectations, right? Well, we actually have.

Remember that story I shared a few months back about the project with the Christmas cyberattack? Well, that story didn’t get better right away.

After we finished the rewrite of the old application, our clients at Acme Hospital decided they wanted to hire a liaison to manage projects like ours. Someone with the background to work through technical concerns should anything like a cyberattack happen again.

As we were their software vendor, they asked for our feedback on potential candidates and we were more than happy to oblige. After all, this would be our point of contact moving forward, so chemistry and professional capabilities were priorities. 

Enter Phillip – a candidate with a great resume and no apparent red flags. After going through multiple candidates, Acme narrowed it down to him and we signed off. 

Unfortunately, interviews can’t catch everything. 

Phillip came on as the technical project manager, and things got stressful right away. He started throwing his weight around a little bit at first and then more pointedly. Everything had to go through him. 

We were working hard towards the next launch but were getting dragged down by constant nagging from Phillip. Despite being brand new to the project, he was acting like this was his circus and we were his monkeys.

This was an early indicator that things were not going to go well.

Progress slowed over questions about the budget (which had already been determined and agreed upon), which when answered led to further questioning.

Even worse, Phillip wasn’t one to try and solve these ‘concerns’ professionally or respectfully, but would rather wait until he had an audience. One flashpoint was when he made a royal decree that he “expects a 25% discount” for this project. When asked what was being changed, he was clearly throwing out a number with no understanding of the scope. 

As a team, we escalated this issue to Phillip’s superiors because it was reflecting poorly on us AND the company, and quite frankly made us uncomfortable moving forward. Luckily for us, they had noticed this too, and tried to rein him in. 

Unfortunately, their feedback to him did not go the way we had hoped. 

Instead of working to mend the relationship, Phillip saw this as an attempt by us to bypass him. Now, he wanted to see us fail. He would be openly disrespectful on calls. We were walking on eggshells every week. This went on for a solid 3 months – some weeks worse than others. 

But we persevered. Even with all the stress, we had a very successful launch. The team and I managed to pull off one of our biggest wins, and the success was undeniable. 

With that success, it was time to renegotiate. Rajiv set up a one-on-one with Phillip to try and reconcile the issues so we didn’t have to live with stress every day. Not to be. It essentially devolved into a shouting match that ended in Phillip telling Rajiv to toe the line or be fired.

So it was us or him. This threat was enough for Rajiv to escalate to the stakeholders the toxicity of the relationship. While they sympathized, we had no idea if anything would be done since we were basically a vendor complaining about what an employee said. 

Luckily for everyone, Phillip took care of that himself.

One fine day, the stakeholders told us that Phillip would not be joining us anymore.  

Apparently, their internal attempts to talk to him had resulted in him having a meltdown in front of HR, and he stormed out of a meeting. He was already on notice and this outburst had got him fired. Good thing too because that situation was definitely unsustainable. 

Our credibility was high after being proved right and on the back of two successful launches. We have been working with Acme Hospital for years. 

What’s there to learn here? No matter what the external circumstances – deliver to the best of your ability, and hold on to your self-respect while keeping your promises.  Also, never underestimate the value of communicating professionally even when personally attacked.

Story by Jesus Fernandez, Senior Developer @ Informulate

(Client Names Changed for Privacy)

When the going gets tough – the tough get going. This next story is probably up there for the craziest experience I’ve ever had on a software project.  

Have you ever been on a project where everything you do is scrutinized and the slightest misstep could be your last one?

A few years ago, I started on the United Credit project where things were immediately weird. On my very first call with the client, a direct competitor, we’ll call them Digital Works, joined us as well. 

Dave, our client CEO at United Credit, let us know that this was a sizable project that he intended us and Digital Works to divide the work. This was not typical, and I wasn’t sure that Rajiv, CEO at Informulate, and the rest of our team were aware that this was the plan. 

We hopped on a solo call with Dave to explain our concerns and hesitations, and to make sure that he knew this was likely not the best way to approach the project. The division of labor, while he might have been doing it to make it easier, could actually cause more headaches down the line. 

Dave explained that he had been burned by a previous vendor who left him with an unfinished codebase after 18 months, so his decision to hire two software companies was intentional and gave him some insurance in the situation.

We understood, his mind was made up and the project commenced! 

Right off the bat, we picked a development framework to use, and our friends at Digital Works immediately disagreed. What started off as a difference in opinion devolved into an all-out headbutting match with neither side compromising. 

This was exactly the nightmare I had feared.

There was only one way to resolve this: pitch our frameworks to the client and see which one they preferred. We felt confident in our approach; it was modern, innovative, and met current industry standards while Digital Works preferred an older framework that they were comfortable with, but was outdated years ago.

It got more heated than I think anyone anticipated. In the end, our approach was stronger, and Dave decided in our favor. Of course, that was the first of many battles. 

We broke up the feature set between the two teams and got to work. Over the next four months, we knew we would be scrutinized so we made an extra effort on quality throughout the project. Practically every meeting was stressful. 

As deadlines drew near, client testing revealed a couple of dozen bugs for us, which we resolved quickly. 

For our competitor, it was a disastrous story.

Their code was barely functional, and client testing revealed over six hundred defects. We knew right away that there was no way they were going to on time or on budget. The Digital Works team was in way over their heads. They clearly needed our help, and Dave appointed us to review their code. 

We knew there would be a blowback, but we went ahead and helped them identify and resolve issues. This dragged on for another three months, and Digital Works chafed under the oversight from a competitor.

This added more fuel to the fire, and the meetings got more toxic, less productive, and very expensive. 

Fun times must end though and eventually, Dave made the decision to cut Digital Works from the project altogether. Great! But then our team had to inherit all of their broken code and it took almost six extra months to clean up/repair it all. 

Now, six years later, United Credit is still going strong and our partnership has taken their digital transformation to the next level.

All in all, there was a lot we learned. First, if you’re not a technical person, it can be hard to vet vendors, even harder if you have trust issues from past vendors burning you. 

Even though this experience was stressful for all concerned, Dave got the result he wanted – even though it cost twice as much. I mean, imagine if Dave had hired only Digital Works? He’d have been burned twice on the same project and remained in software purgatory for who knows how much longer.

So all’s well that ends well… I guess! It was a real nightmare, but now I feel better equipped to handle tough situations.

Story by Tristan Mills, Tech Lead/Solution Architect @ Informulate

(Client and competitor names changed for privacy)

Life comes at you fast – especially in the software world. People think that being a software developer is a well-paid job, you get to work from home, all easy-peasy–but that’s only half the truth. 

Production issues, last-minute changes to requirements, late-breaking discoveries, security challenges, budget overruns, and clients changing their minds make it so there is never a dull moment. As a developer, I’ve had to react to some pretty crazy situations. 

What’s a worst-case scenario on a software project and – what if it comes to pass?  

This is one of the craziest situations I’ve had to deal with – cyber-attack on vacation and an immovable launch date.  

I joined the Acme Hospital project about 9 months before a cyberattack took place. They’re a large enterprise with thousands of employees and an older legacy application that they wanted upgraded. However, their codebase was in much worse shape than we had thought. Our team started the rewrite a year ago and launched Phase 1 of work (about 25% of legacy code) and it was – not a slam dunk. First-time launch for a client rarely is – we discovered all kinds of bugs while integrating with the current codebase, dealing with the client’s IT department was a major pain, and on top of everything they had high-security requirements since we were dealing with HIPAA sensitive data.

So 3 months before the incident in question, we were in planning meetings with Sharyn (the client manager) and my Team Lead Shaloo, and told them the situation: 

• The longer we maintained the old codebase – the higher the risk,
• The launch date was already scheduled and unmoveable, so we needed to make decisions right away in order to plan, and
• If we could immediately convert all the code to our new codebase, we could control the project.

But the client chose not to adopt this plan. We didn’t have great credibility with them because of the bugs from Phase 1, and they didn’t want to increase the budget for a full rewrite. So we ended up scoping only about 50% of the rewrite. 

So the decision was made. Shaloo drew up the plans for the rewrite, we finished software design, estimated the scope and got approval to move forward. 3 months in, with 3 weeks to go for launch, and we were looking pretty good: my development tasks were over, and QA was going over and testing everything. We should’ve been able to reclaim some credibility with a smooth launch now, and we were feeling good. Right? Wrong. 

The week before Christmas we got a call: the old codebase had been hacked. 

Not just that, but a bunch of data had been deleted from the database. And of course, that wasn’t all; the client’s entire team was on vacation and we were left with just a skeleton staff. The launch date was only 3 weeks out. As they say in the movies – it was the perfect time to panic. 

Escalations were made, leaders were called and vacation plans were impacted. I won’t pretend we all had perfect responses but after a few minutes of frantic questions, we gathered what had happened: bad actor/s had used a SQL injection attack to drop tables and mess with the data. As bad news goes – that wasn’t terrible. So they didn’t have unrestricted access to the server, and we could block it by taking the offending feature from the legacy codebase down. But what would users do if we took parts of the legacy application down? We didn’t have this complex feature in scope for the rewrite. 

Time for our internal team to huddle. Rajiv (our CEO), Shaloo, and I ran through the scenarios. This looked really bad for everyone – especially the managers who are our internal stakeholders. We had made the recommendation to upgrade and they refused. But this was an important project with high visibility – and the blowback would affect us too. On the flip side, if we take on more scope, we may not be able to deliver quality.

Damned if we do and damned if we don’t.

Rajiv turned to me, “Jesus, do you think you can rewrite that feature in 2 weeks?” 

It was my turn to panic, “Wait, we just spent two and a half months writing 25% of the code, and you want me to do an equivalent amount of work in 2 weeks?” 

“I know it’s a big ask, and we don’t need to rebuild everything exactly as it was done in the old app – but we need to do the minimum to make sure the feature is functional enough at launch. If we don’t do this we can’t launch and if we can’t launch all the senior executives at Acme are going to get involved. People who trust us may be impacted as well. So I ask again – do you think it’s possible?” 

It was time to put up or shut up, “I think – it’s possible.” Cue the superhero music.

From there it was non-stop action. Shaloo and I dove deep to get detailed requirements and design this feature out in a day or two. We got approval from Sharyn to go full tilt. Rajiv moved all other priorities off my plate to make room for this. QA was ready to jump on things. With a do-or-die spirit, the team really pulled together. 

So even though we had a lot to do, the mood was good because the target was clear. And I kid you not – I worked 12-14 hours a day for 3 straight weeks. So how did it turn out? 

It was probably one of the big successes I’ve been a part of. The launch was better than Phase 1 because we better understood the old codebase and environment. We turned our stakeholders into fans, and I earned serious bragging rights. Not bad, right? 

So what’s the takeaway? Be a team player.

Can you be the person on the team that people turn to when the chips are down? 

If you can do it – step up. 9 times out of 10 – we usually find reasons to not put ourselves under pressure because we don’t want to be the fall guy if we risk it. There were many reasons not to attempt a Hail Mary here but I knew Shaloo and Rajiv had my back even if I failed. The risk was high, we had good arguments to make, but the reward was high too – dare I say we saved a career or two and made friends for life. 

Story by Jesus Fernandez, Senior Software Engineer @Informulate