Engineers don't help the problem when they treat management like glorious god-like perfect beings either.
When your management is bad, there is nothing an engineer can do. They can attempt to bring their concerns to leadership, look for another job, or play the fiddle while the product burns to the ground.
Speaking of bad management, I was very surprised when he claimed that the situation where you are asked to "...make architectural decisions on the fly without knowing anything about what their problems are" he had never experienced before. In all of my experience, it was standard practice.
> When your management is bad, there is nothing an engineer can do. They can attempt to bring their concerns to leadership, look for another job, or play the fiddle while the product burns to the ground.
Well, they could step up and start fixing problems in the organization themselves. Improving communication flow between departments, building better processes, discovering metrics, these are things that you can do to help make your company better without having to get the leadership involved. Not every improvement needs grand strategy, there's often lots of low-hanging fruit that one person can own and push by themselves.
Just Friday I was sitting in on a planning meeting and realizing that while we have a front-end guy, we don't really have a decent web designer that can draw out ideas and come up with plans for implementing them. So now I'm thinking about how to go about the task of managing that information flow.
> Improving communication flow between departments, building better processes, discovering metrics, these are things that you can do to help make your company better without having to get the leadership involved.
This requires someone with a surprising amount of knowledge and ability, outside of the normal field of software development. It's a rare skill to find in anyone, let alone a highly skilled tech worker.
Ideally everyone is thinking about the processes and systems that impact them critically, but even that requires a minimum of knowledge and ability to think in systems. It's one of the most under-appreciated and ambiguous skills to learn.
It also requires that the engineer be within an organization where they have a reasonable expectations that their attempt will be well-received. I know I have spent time in organizations where attempting to go above and beyond your "place" as an engineer is punished harshly.
You could talk about all the things it 'takes' to be great at your job, or you could just come up with your own idea of greatness and chase that. Eventually you'll outgrow your current position. Whether you get promoted or find another job at that point is an implementation detail.
That's the theory, yes. In practice, many engineers are averse to unemployment, and will be discouraged from pursuing particular notions of greatness that risk it.
Unfortunately, it's not so easy. If the culture (i.e. tech is not really important, business comes first) is wrong, your effort is not gonna fix a thing.
This applies to more than just start-ups. I work for a company that regularly claims 'we are not a software company'. But... we're writing software. So yes, we are a software company.
It's amazing how often the "we're not a software company" phrase is bandied about. My employer has been around for a while, the IT department has over a 30 year history. Yet, we have the phrase repeated to us whenever we discuss using source control, developing libraries, having a web services strategy, etc. It is like saying, "We're only a youth hockey team, not a professional one, therefore we don't need to use the same equipment and strategies as the pros."
Just because you're not planning to be [put your favorite professional software company here] doesn't mean you should avoid learning their strategies for dealing with everyday problems associated with writing software - unless you don't write software at all.
In the end, the phrase is nothing more than an excuse for avoiding the risk of cultural change.
If you're working at a software shop that doesn't even use source control I suggest you get out of there ASAP. It's one thing to be missing core tools and methodologies when you're applying for your second job 1-2 years in, but if you hit the 5 year mark and have zero familiarity with source control or web services (for industries where this is valuable), etc. you're going to get passed over for interviews. Staying there may be causing irreparable damage to your career.
Saying you shouldn't use source control because you aren't a software company is like saying the janitor shouldn't have a mop because you aren't a cleaning company.
Couldn't an engineer go slumming into the world of office politics and social manipulation in order to get into the good graces of management? Might that not be a possible approach? I realize how odious it sounds and I don't know how well I could do it.
When your management is bad, there is nothing an engineer can do. They can attempt to bring their concerns to leadership, look for another job, or play the fiddle while the product burns to the ground.
Speaking of bad management, I was very surprised when he claimed that the situation where you are asked to "...make architectural decisions on the fly without knowing anything about what their problems are" he had never experienced before. In all of my experience, it was standard practice.