If you are the only engineer on a small team then: 1) You shouldn't be writing reports. 2) You should be at the meetings and a part of the team. It should be p

If you are the only engineer on a small team then: 1) You shouldn't be writing reports. 2) You should be at the meetings and a part of the team. It should be possible to say to business people there are '3 main parts i.e. web/front end, business logic, and data store' - they will understand that - and then to simply give a rough idea of timelines and complexities for each one without going into too much detail. 3) Your peers should understand this, when a team is small they have to have at least some understanding of the system. It's likely they are just bad at what they do, possibly from being inexperienced themselves. I'm going to gather that the entire things is probably full of obvious problems, which is almost universally the case for young companies managed by young people. It gets papered over when 'some thing in the corner is blowing up'. FYI larger companies are also full of bad practices, but they generally have some kind of baseline professionalism and systems that help them get through their daily operations which are baked in, and printing them money. Chalk it up to experience, learn from it, move on.