0

I would like to briefly point out that this can only reflect my view of the problem. However, since the basic problem here is poor communication culture, I am also aware that my view of the problem will tend to be incomplete. However, I will try to present it to the best of my knowledge and belief.

I have been working at my current company as a developer for 2 1/2 years. There have been several, larger projects during that time. I will show the course of two of these projects as examples

Project A:

Was my first real project after the probationary period in the company. It was about connecting several third-party systems to a SaaS solution of ours. There was a kickoff meeting, but the information was very rudimentary. There was a rough idea of the architecture (loosely coupled, etc.) and the general tenor was that we first had to see whether we could implement it that way and how it would all work.

A while later in the project, there was negative feedback in a meeting that certain features would be missed. I was not aware of any of these features. I replied that the feature would certainly be useful, but there was no specification for the project in which the feature was included. Of course, I can still add it, but it would take additional time.

Within the team (which included my manager) I then pointed out for the first time that there seemed to be concrete ideas for the project, but no exact specifications and how we would deal with that. Here I got the same answer as in the kickoff meeting, where only very roughly the purpose of the project was explained.

The same problem was repeated two more times in other meetings. At that time, I gave the feedback in my team that I obviously don't have the necessary information to implement the project and where I could get an exact specification. The answer was that the specification would have to come from our IT manager, but he would never write it down and would not have the time to do so because he was extremely busy.

In order not to be blocked any further, I decided to approach other departments on my own. However, this was basically not easy, since scheduling meetings took a long time and the other departments would have needed concrete information for concrete statements, which I did not have. When I presented an interim status in a meeting on what I had learned from the other departments, the feedback was negative. Apparently, there were already agreements with the departments mentioned, which were also the opposite of what I had agreed with the departments. However, as already mentioned, I had not been informed about the existing agreements.

The project ended after a while without any debriefing.

Project B:

At the beginning of the project, I expressed my concerns about the communication problems in the last project. I was told that there would not be those problems this time. The project would already have a working prototype that only needed to be integrated into an existing solution as a module. This was also stated in the requirements.

The first thing I noticed was that the prototype was not functional in any way. In addition, the prototype accessed third-party systems. I requested access to the third-party systems, but was told I could not get it.

I informed the relevant departments that the prototype was not functional and that I did not have access to the connected systems in order to fix the problems or even to be able to assess them. I received the feedback that I should first turn off the functionality in connection with the external systems. I pointed out that the prototype is designed in such a way that without the data from the external systems all further steps also do not work. I received only roughly the instruction to exclude this if possible everything.

I then implemented this, which took a lot of time under the given circumstances. Here again, however, it became clear at some point in meetings that concrete features were desired. These features were not included in the prototype and, moreover, could not have been implemented with the prototype's architecture. Again, nothing was on record, but I decided to integrate the prototype in such a way that we could then incorporate the features mentioned.

After the process was completed, it was communicated (again in a meeting not in written) that a large part of the functionality should now be deleted.

Again, there was never any follow-up on the project.


Recently, I had a staff meeting in which I was given feedback on what I had done well and what I had done poorly. On the negative side, to my surprise, a lot was mentioned. In addition to things that I had actually done wrong or that I had simply not solved well, the course of these projects was also explicitly mentioned. And to say it again quite concretely YES, there were absolutely points which where in my responsibility and which were criticized rightly. BUT there were also many things criticized that were consequences of the problems described above.

I described the course of the projects similarly as above. However, I received the feedback that this would ultimately not change the assessment of my performance.

I don't currently know how to deal with this feedback on a professional level.

It is not a problem for me if projects are not specified more precisely and I offer a "best effort" solution to the best of my knowledge and may have to obtain information independently in the course of this. It is also not a problem if there is constructive criticism of this solution because not all of the decisions I made were optimal. But if the criticism includes that I have not implemented specific points that are not known to me and were not communicated to me on request, then I currently see no possibility for me to better implement future projects.

I thought of a way that one the one hand protects myself from being blamed for those kinds of issues and that one the other hand might just avoid these issues as much as possible. The best way for this would be to demand everything in written in the future. This way I could proof that what I did and did not do was in accordance with what I knew at the time. It also would probably just solve most of the issues to begin with. However, from the times I have already asked for more Information during projects, I have the strong impression that this is just not how my company communicates and that I would even step on a lot of peoples toes or even be perceived of some kind of "blocking attitude" from my side.

2 Answers 2

2

In the beginning I'm stating the obvious, that looking for a company with a (hopefully) better communication culture could be an idea at this point, when it doesn't seem like there's going to be much improvement in the future in your current one. However, even in a new company you might face the same issue, so here's how I would address the problem, when I'm tasked with something unclear.

Usually there should be something like a Design Document, where requirements, and functionalities are clearly listed. The rule then is very simple, everything that's not in the design document, is not to be considered. Ask if such a thing exists and if not, take the initiative and offer to draft it yourself. Colleagues can fill in required information and finally your manager can sign off on it.

As always, having something in writing is key. This way you can not be blamed for missing anything, if it is missing in the document and it was already signed off.
On the other hand, if your manager asks why there's something missing in the DD, you can say "I need input from department XY on this" or "There are these two options but I'm not authorized to make a decision".

2
  • As I said there never where design documents and asking for more detailed specification was never taken seriously or I was basically told, that the specification needs to come from upper management and they usually never give you anything in written. This is why I said at the end, that demanding such specification would probably step on a lot of peoples toes.
    – MrTony
    Jun 12 at 15:06
  • @MrTony I never suggested that you "demand" anything. Quite on the opposite, I suggested that you volunteer to do it. "Hey boss, that's sounds like a big project. How about I draft up a design document so we got it all sorted out in one place?" Draft the outline, fill in as much as you can, ask others to fill out the missing spots. If your company doesn't value a design document, I doubt they'll accomplish any medium+ sized project. Jun 12 at 15:40
-1

This feedback sounds very critical and not helpful. Were you told any ways in which you could improve or any concrete things you could change that would make your management happier with your work? If not, I think you need to go to whoever gave you the negative feedback and ask what needs to change because you are clearly on different pages about what the process of completing a project looks like.

On another note, do your coworkers have similar issues with project requirements and lack of communication? How do they deal with it? I assume that some projects at your company have to succeed, so maybe look at what is done differently for those projects vs yours.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .