I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Great post, Scott. I think it works both ways. Management doesn't know what we know and we don't know what management knows.
How many software engineers actually know enough about their company, customers, marketing strategy, operations, opportunities, threats, strengths, and weaknesses to make intelligent suggestions?
I only have anecdotal experience to go on, rather than hard data, but, personally, I think near 100% of software engineers know enough about their company and customers to make intelligent suggestions.
I have spent years in casual conversation with Seattle techies working at Boeing, Microsoft, Amazon, Google, Expedia, Tableau, and others, because I work in tech in Seattle, attended the Seattle University Master of Software Engineering program the past four years, go to meetups, and otherwise randomly meet people at parties and neighborhood gatherings. Almost every person I have talked to eventually mentions that they carry around a laundry list of really obvious changes that could be made in their products to serve their customers better. Most of the time, software engineers are the customers of their own products.
Usually these obvious changes are boneheaded usabilty gaffes that arise from the integration of two or more systems underlying a single user flow. It might take users three pages to login to a system for instance. For one Microsoft example, go try to log in to outlook.com email. Once you land on Outlook.com, you click "Sign in." On the next page, you are only allowed to enter your email address. On the next page after that, you can enter your password. When you hit the fourth page, you are finally looking at your email. You had to load four whole web pages before you get somewhere.
I agree it goes both ways but in many companies, it is viewed as politically dangerous for software engineers to talk up the chain and there are systematic mechanisms in place that only allow directives to flow down a one-way street to the engineers without any possibility of feedback or even knowing where a decision came from. This is a sure way to insure failure, or at least to limit success.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Hey Scott, Thanks for the reply. I agree with your points, even if my experience differs from yours. You run in pretty high-end circles in Seattle compared to me in Edmonton so that could cause our differing perspectives.
I love your writing. Keep it up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great post, Scott. I think it works both ways. Management doesn't know what we know and we don't know what management knows.
How many software engineers actually know enough about their company, customers, marketing strategy, operations, opportunities, threats, strengths, and weaknesses to make intelligent suggestions?
I only have anecdotal experience to go on, rather than hard data, but, personally, I think near 100% of software engineers know enough about their company and customers to make intelligent suggestions.
I have spent years in casual conversation with Seattle techies working at Boeing, Microsoft, Amazon, Google, Expedia, Tableau, and others, because I work in tech in Seattle, attended the Seattle University Master of Software Engineering program the past four years, go to meetups, and otherwise randomly meet people at parties and neighborhood gatherings. Almost every person I have talked to eventually mentions that they carry around a laundry list of really obvious changes that could be made in their products to serve their customers better. Most of the time, software engineers are the customers of their own products.
Usually these obvious changes are boneheaded usabilty gaffes that arise from the integration of two or more systems underlying a single user flow. It might take users three pages to login to a system for instance. For one Microsoft example, go try to log in to outlook.com email. Once you land on Outlook.com, you click "Sign in." On the next page, you are only allowed to enter your email address. On the next page after that, you can enter your password. When you hit the fourth page, you are finally looking at your email. You had to load four whole web pages before you get somewhere.
I agree it goes both ways but in many companies, it is viewed as politically dangerous for software engineers to talk up the chain and there are systematic mechanisms in place that only allow directives to flow down a one-way street to the engineers without any possibility of feedback or even knowing where a decision came from. This is a sure way to insure failure, or at least to limit success.
Hey Scott, Thanks for the reply. I agree with your points, even if my experience differs from yours. You run in pretty high-end circles in Seattle compared to me in Edmonton so that could cause our differing perspectives.
I love your writing. Keep it up.