[rsd79]

Hi!

I have engineer's background and very much still feel like an engineer, but for over 10 years I have been managing a team of up to 50 developers within an organization with several hundreds of staff. Let me try to explain the "whys" below. Once you see the wider picture you might look at all this with less negativity, but it's also fine if you find it unacceptable - there are valid reasons why people leave corporations to work on something in smaller scale and what you describe fits a lot of these reasons.

Larger companies focus much more on avoiding the risk of breaking something than on the speed of implementing new features. The painful process you are going through is probably a result of earlier experiences of having requirements dropped into the backlog by random people. In your relatively small startup team you did not experience it, but in large corporations just by pure chance you can get hundreds of requests from all over the place. Each of them has costs associated with it: implementation, testing, change management (in order to keep track of stuff for a chance of a team resigning en masse) and the virtual cost of the risk of breaking stuff in production. Especially in a project which seems to be widely used by other teams.

The 4 pages long form is there to make sure that you really need the stuff done - otherwise you would not waste your time to write all that.

The two managers approving the change are there to prevent stupid stuff from being worked on just because somebody sits next to the developers and has various "ideas" and "needs". They are not there to discuss your idea with you, but rather to make sure it does not go against the project's priorities, which are unknown to you.

The lack of R/W access to the repo is to keep control over what happens in the project. It's not that they don't trust you, it's that you have no idea what they need outside of your small feature. After few months they need to be able to know (more or less) why something is present in the code, regardless of you being there or not.

You are not allowed to speak to the engineers, because they will be working on your feature around the end of Q1 2020, so you'd be wasting their time now. They have a backlog of other stuff to do and won't remember your input after few months anyway.

What can you do? Notify your manager about there being a blocker for your task and find something else useful to be busy with in case your blocker will land below a hundred of other blockers from other people. Remember that your personal efficiency is not equivalent to organization's efficiency and learn to handle several tasks at the same time while waiting for blockers for most of them to be resolved. Do not mistake it with multitasking (actually working on multiple things simultaneously), it's just an efficient scheduling of available resource - yourself - in the context of an organization working in unison.

PS. For most of the my time managing developers I've been working really hard to make sure people from across the organization do not interrupt them in their work. Once you put yourself in the skin of the engineers you are not allowed to talk to you will understand that at least some of the stupid mechanisms you've encountered are there for exacly that reason. You should respect that as an engineer.