Question Details

No question body available.

Tags

project-management software

Answers (5)

Accepted Answer Available
Accepted Answer
February 2, 2025 Score: 9 Rep: 74,302 Quality: Expert Completeness: 50%

I know this might not be the answer you're willing to hear read, but most of the time (if not always), pitching the product to a new customer or introducing changes/upgrades to existing customers involves a "high-level" meeting, where the primary focal point of discussion / presentation is the value-add, and not actual day-to-day functionalities of the product.

When someone is trying to sell a product (i.e., solving a problem) in a meeting, with a very limited time in hand (upper-level business meetings tend to be very short), they are likely competing with multiple other organizations/vendors offering similar functionality, and everyone need to make an "impact" that will help the customer decide "best among the equals". Usually, rather than a bullet-point list of features and functionalities, some sort of visuals, or dashboards, and ease-of-use, learning curve - these are usually more attractive and catchy, and provide a more immersive, emotional and dramatic experience to the storytelling.

In other words, the frontend (UI/UX/Aesthetics/Visuals) is the first and most exposed part of software products and solutions, and having a better one provides an edge over other competition solutions.

Now, coming to your specific question - I understand you are looking at things from a technical point of view and your viewpoints are absolutely valuable and should be honored, however it is also important to have a good representation of the features, functionalities and capabilities in an easy-to-understand and easy-to-demonstrable way. For example, we can either measure the performance of a system by

  • Going to a console, keying in couple of system commands and see the raw stats on screen.
  • Pointing your browser to a dashboard, showing graphs for value trends, integrated with colors for thresholds and alerts for out-of-rang values.

and in most of the cases, business people will choose the later approach.

I'm not denying the fact that the backend, or the actual working of the software is important, but with a poor representation, it's not going to get you a seat in the front row.

Navigating the challenges of being a CTO in a small company, especially with limited experience in management, can be daunting. Your situation is certainly complex, but there are some steps you can take to address these issues going forward:

  1. Whenever you add / change / update a feature, plan a way to visualize the "impact" of the change - it need not always be a direct visual representation of the direct change, but as little as a visual comparison of the increase in efficiency, decrease in operational cost, increased ease of use, decreased response time - you get the idea.
  2. Whenever a change is requested just for the aesthetics or cosmetic purpose, try to understand why the existing solution is not good enough, and next time, use that understanding to incorporate that viewpoint in the solution from the beginning.
  3. Create a plan / standardize the UI/UX across the product (or the portfolio of solutions), and try to reuse the components as much as possible, so it serves the purpose as needed by the Sales / Marketing or the Product management team.

Hope these changes will help you to organize and plan your activities properly and you'll get out of the detrimental 100+ hour work-week.

February 2, 2025 Score: 4 Rep: 12,140 Quality: Medium Completeness: 30%

You need systems and protocols. I am not going to suggest which might be best, because that isn't the point. The difference between no system/protocol and a minimally funcational one is drastically positive.

Throwing mud at the wall and seeing what sticks isn't a protocol. CTO is a very odd role for this job. Having a dev as a CTO? No wonder you're in pain.

Having an actual or defacto product manager and project manager roles acknowledged. I am not going into these roles further, but it is clear that they are being pushed onto you. That is cascading the problem.

First things first. Whether Kanban or other method, get the work on a list. Simple and quick for now. The sooner the better. You can get a better system later. If you have a system and aren't using it, then use it to show the data to the bosses.

When your bosses want to reorder the work, pull up the list and ask them what to move. Include enough info such as "BUG FIX", etc. that they know that they are putting cosmetics ahead of something that is a problem.

Let it be their decision.

Stop working burn-out amount hours unless you want to burn-out.

Good luck

February 2, 2025 Score: 4 Rep: 5,429 Quality: Medium Completeness: 30%

First off, most people working more than 100 hours per week lose perspective and their judgement suffers. Remember that what management sees are only those visuals. They do not see the internals. Part of your job is to translate what the team is doing into language that top management can understand.

It is obvious that too much functionality has been put into the "next release." You and the team are trying to do too much in the time allotted. This whole release needs to be rethought and represented to top management.

The best thing to do is to take a few days off to regain some perspective. Then, develop a realistic plan of how to go forward allowing for enough time to fix the major bugs (20-30% of total project time), show a realistic release date, and prioritize what to remove from this release in order to actually meet the deadline that top management wants. Bring this to top management and ask what they want to delete from the project in order to bring a release out on the date they want. They will not want to remove anything. Your job is to stand firm and if they do not chop, you will chop. Bring in a list of unfinished items, lists of all the bugs, etc. It is their business to approve releasing with bugs unfixed.

Again, it is the job of top management to decide what to release and at what quality. It is your job to present information to top management so that they can make those decisions. That takes perspective, introspection, and time away from the project.

February 3, 2025 Score: 2 Rep: 17,521 Quality: Medium Completeness: 30%

The problem we've been carrying for some time is that upper management is overly fixated with improving the visuals, aesthetics, and frontend of our applications, which means these have been getting consistently prioritized over maintenance, security or performance concerns, which, on the other hand, have been given for granted like they should have never been concerns to begin with.

I suppose it's really the difference between a Lada and a Lamborghini.

A lot of bosses have Lada budgets yet want Lamborghini styling and engineering.

The underlying issue is that our whole economy nowadays consists of primarily non-technical people making decisions about the buying or making of highly complicated data processing machines.

Inevitably then, the non-technical buyers are drawn to the shiny baubles, and the sellers have to bauble things up to pander to these buyers.

Eventually, crooked sellers realise they can sell a Lamborghini to these pathetic buyers without an engine at all, just an audio speaker and man under the bonnet peddling - or maybe, with a little motorbike engine that's already in terrible shape and won't get a mile down the road without pushing.

If you're in a business where they're not selling technical excellence, but cut-and-shuts with no engines, you're always going to have a hard time persuading them that you should be allowed to make a nice engine for the customer. That's not what your business sells.

Your bleating about quality will only undermine their trust in your judgment, if they can see you care about all the things they don't.

If you want better engineering, move to another job, probably a staff job, because with a staff job there at least isn't the question of an exploitable discrepancy between what the seller and buyer know about the software quality, there is only the question of how well the administration of the business should function.

Bespoke outsourcers and consultancies are typically the very lowest for software quality, and COTS software makers will be highly variable (generally according to whether they are led and owned by someone with engineering pride or not).

February 3, 2025 Score: 2 Rep: 5,091 Quality: Low Completeness: 50%

We have had this situation in every company I have worked for. Upper management cant see the code. They can only see visuals. And marketing has to have new features to sell, for the conpany to survive.

But if you dont fix the bugs, then the Conpany may go down the tubes.

Suggestions

  1. Organise a meeting with the CEO
  2. Explain the sort of scenarios that may occur which would give the Company a bad name.
  3. Explain that you need more developers, because you are getting burnt out. Which would impact the productivity, eventually.
  4. Allocate at least one person to only work on bugs, no matter what. Take a stand, or you will get blamed anyway.
  5. Realise that its not your company. As an employee of a large MNC, i was doing 80hrs. One day, I said to myself. Its not my company. I dont have shares. After that, I would do the best work I could do. Then switch off. If sh*t happens, I will deal with it. You owe it to yourself to come to that realisation .