What to do as an employee when I find possible problems in areas which are not my responsibility?

Question

I am a programmer who has worked in an IT company for 1.5 years. During these 1.5 years I have only worked on one government project, which is among the worst in the 20 year history of the company. Multiple delayed deadlines and running out of budget sums it up. The company is among the biggest in the IT business in my country, it has a very good reputation and recognition.

Some problems with the project:

• Underestimation of project complexity. The development team initially consisted of 3 junior developers (me included) and 1 senior developer. Senior developer had a fight with the boss and quit the job. It was 3 junior developers working for 1.5 months until some more experienced developers were added to the project. Also, junior developers had no one to do code review for their work, for 1.5 months.

• Missed/forgotten requirements. Manager forgot about some requirements in the Jira tracking system. They were given a specific status which made them invisible;

• Architecture level problems were not recognized fast enough. I saw issues, I mentioned them to project manager, they were ignored. A few months later it became clear there were errors in the architecture. Large parts of application had to be changed.

• Lack of a lead developer, one who keeps an eye on the whole picture. There was no person who had this role since the senior programmer quit. Everyone was working on his own tasks, even the 3 new senior level programmers;

I feel that I should have acted differently and perhaps that could have saved the project from the mess it has become. Then again, I was a junior programmer and later a programmer, so worrying about architecture was not part of my duties. Should I have voiced my concerns more loudly?

Answer 1

What do you want to do?

If you want to just pick up a paycheck and move on when you find something better, keep your mouth shut and focus on brushing up your resume.

If you want to see the project succeed, then you have to step up and make it succeed (which means taking responsibility for things outside your job description).

Sitting the fence in between will only cause heartache and pain.

Make a Decision

I feel that I ... could have saved the project from the mess it has become. Then again, I was a junior programmer ... so worrying about architecture was not part of my duties.

What you should do in this situation depends on which is more important: saving the project, or sticking to your job description.

Anyone can point out issues. Every workplace (no matter how big or world renowned) is filled with things that can be improved. Most companies would like one of two types of people:

1. People who fix the problems
2. People who work with/around the problems

The type of employee that causes the most grief and heartache tends to be the person who points out problems without fixing them, and then blames those problems for their inability to get the job done. Don't be that guy. Pick which type you want to be, and go with it.

Sticking to your job description

As you say, "I was a junior programmer ... so worrying about architecture was not part of my duties." So don't worry about architecture. If your boss tells you to build the empire state building upside down, find out the best way to build it upside down without having it fall over. Sure it will be a horrible building, but boy did you do your part in making it stand up!

The project will likely go over budget and end up late if that's what you're asked to do, but so long as you properly estimate the time it will take for each step of your work, you are not part of the problem. As pointed out in a comment, you may want to look into good ways to survive a failed project, or keep that resume up to date, but at least your boss will likely be willing to give you a good reference for not contributing to the eventual disaster.

Taking ownership of the project

As mentioned in the comments by thusdaysgeek, "[This option has] greater risks associated with the potential greater rewards. You can get shot down and told it's not your job; you can be encouraged in taking on the leadership, but not given necessary resources; the project may fail even with all your efforts, and you'll take more blame. That's not to say [it] isn't a way to go, but to be aware of potential pitfalls as well."

The other option is to say, "Screw my job description, we can make this project work, and I know how to do it". If you see a problem project complexity and the time estimates given to complete it, think up a way to reduce the complexity to something manageable within that time and deliver it. Getting 80% of what was wanted done on time will at least meet the deadline and give you something to show for your effort. And who knows, maybe you will get that 80% done early and can start working on that remaining 20%.

This means you take responsibility for rallying the troops, it means you pick up slack, it means you see problems with architecture or manpower and find a way to make it work by doing it yourself or finding a way to get more from the people you have.

But overall what it means is taking 100% responsibility for the success or failure of the project. It means reporting to your boss about the status of the project, and keeping his expectations in check. It means juggling the needs of your team with the needs of your boss, and finding a way to make them both happy. It means negotiating the political landscape of your company to make sure you end up with the resources to get it done. Because it's your responsibility. And that's what a project manager is supposed to do.

That's hard. A lot harder than just voicing problems and concerns. But it's also satisfying and the way you get put in charge of bigger tasks in the future, or at least learn how hard it is to actually implement everything the way you want it done. The choice is yours which path you want to take.

Answer 2

There's a distinction between the success of the project and your role as a programmer. It's your responsibility as a programmer to help management make informed decisions by sharing information from the "eyes on the ground" perspective, but it's up to management what to do with that information.

To address your specific points:

• It is your responsibility to inform your PM as soon as you notice discrepancies is estimates vs reality.
• It is not your responsibility to worry about missing requirements. If these are part of the missed deadline, then that is on your PM.
• It is your responsibility to point out architectural problems, why they're a problem, what effect they'll have if they remain, and what effect changing them now vs later will have, and timelines for each option. Most PMs that I've met are not super technical. It's on your PM or somebody else to make the final call, but they need the technical feedback from you.
• Lack of a lead developer is hard. You can suggest some process changes -- such as daily stand up meetings -- to try to increase visibility inside the team. You can directly talk with your coworkers about certain tasks, "oh, I noticed you were working on _. I think my piece relates to that." or "I think So-and-So was doing something similar." Or "Hey guys I noticed we have 3 classes that all kind of do the same thing." Or "I need to write a new module for this feature and would like some feedback." In short you may have to step into that role a little, but be very careful not to overstep your own experience level.

At the end of the day, the success of the project is not ultimately on your shoulders. It's good to care, but it's also possible to care too much.

Answer 3

What should you do when you are in this situation again? Schedule a meeting with the Project Manager and/or your Manager as early as possible. Explain that you are seeing issues with no one being a technical lead (architect). List what those issues are. Be prepared to detail why these things are issues. Your PM and Manager should both already be aware of why, but may ask you for your reasoning behind the issues.

Come into the meeting prepared. Expect to be asked to provide analysis and documentation for each of the issues. Have a plan to remedy the situation as a whole and for each issue. Don't be surprised if one or both of them ask(s) you to take the lead on the project.

At the end of the project, it is the Project Manager's head that will be on the line for either failure or success.