.

CTO: “Why did you tell the client we couldn't deliver the project by Friday?” Software Engineer: “Because we still have bugs in the payment system, and the testing isn't complete.” CTO: “The client has already been promised Friday. You can't just change the deadline.” Software Engineer: “But we haven't finished building what we promised them.” CTO: “Other developers are working under pressure too. Why is your team always making excuses?” Software Engineer: “Sir, fixing a problem properly is not the same as making excuses.” The CTO looked at me for a few seconds. CTO: “Are you saying the deadline is impossible?” Software Engineer: “I'm saying we can meet the deadline if we remove some features or give us more time to test everything.” This happened in the office where I worked around Adeola Odeku Street, Victoria Island, Lagos. We were building a business management platform for a client. The project was already behind schedule, and the CTO had promised delivery without discussing the remaining work with the development team. For almost two weeks, we had been working late. Some of us were still fixing issues after midnight because management wanted the project delivered on time. I had raised concerns about the payment module several times, but nobody wanted to listen. The following morning, the CTO called me into his office. CTO: “I heard you told the other developers not to rush the deployment.” Engineer: “I told them not to deploy something we haven't tested properly.” CTO: “You need to understand that business decisions are not always about code.” Engineer: “I understand that, sir. But when the payment system starts failing, the client won't call you to ask why we missed the deadline. They'll call us to ask why their money is missing.” He didn't respond immediately. CTO: “Are you trying to make me look bad in front of the client?” Engineer: “No, sir. I'm trying to make sure we don't give them a product that doesn't work.” He ended the meeting and told me to return to my desk. Two days later, management insisted that we deploy. We did. Within hours, the client reported failed transactions. Some payments were deducted from customers' accounts without reflecting on the platform. The support team started receiving complaints, and the client demanded an emergency meeting. Guess who was called into the meeting to explain what happened? The same developers who had warned management about the problem. After everything was resolved, I sat at my desk thinking about what had happened. I realised that in some companies, developers are expected to take responsibility for technical problems while having little say in decisions that create those problems. Management wants deadlines met, clients impressed and projects delivered. But sometimes, nobody wants to listen to the people actually building the product. You can pressure a software engineer to write code faster, but you cannot pressure a broken system into working properly.