We engineers often resent managers who interfere in our choice of tools. It may be hard for us to admit that our managers have the best interest of the company in mind.
Suppose you're starting a new project. You and your colleagues are designing a new box with a new processor, new operating system, new featuresnew everything. You've already chosen your processor and operating system; now it's time to pick the programming and debugging tools and get started.
You and your coworkers pick the Brand X compiler because you've used it before and it has a nice IDE. The vendor's support has been pretty good in the past and the code it produces is reasonably tight and fast.
You're ready to place the purchase order when you get a call from upstairs. Management wants to see you. The meeting room is full of neckties and the executives all want to know whose development tools you'll be using. More specifically, they gently suggest that you really ought to use the tools from Brand A. You see, they've all just returned from an exclusive technology-executive summit and are now firm believers in a new kind of product-development strategya strategy Brand A and its new tool chain exemplifies. So you see, old boy, you really should tear up that purchase order and get on board with Brand A. Thanks for coming, that's a good engineer, now run downstairs and build us something.
Sound far fetched? Not if you've been there already. And if you haven't yet experienced this kind of top-level management diktat it's likely that you will. And here's the real heresyI think it's often a good idea.
Wait, let me explain. In most companies, the speed at which new products reach production (in other words, the speed at which you work) is hugely important. The productivity of the engineering staff drives many, and perhaps most, of the company's other decisions. It changes the effects of competition, of pricing, of market conditions, of advertising, and pretty much everything else. Managers are supposed to be interested how you and your colleagues develop products and in how that development affects everyone else toiling away for the firm.
What happens in engineering affects almost everyone else and gives them a vested interest in what you're doing. It even, some might argue, gives them the right to ask that things be done differently. The marketing, accounting, shipping, quality-assurance, and manufacturing people all have to work around your schedule and make their own plans based on rumors floating out of the lab and regular progress reports. Your code might have to pass through others' QA, legal, and version-control processes. Your schematics might have to pass international standards or compliance testing. Your bill of materials will certainly go through the accounting and manufacturing departments.
In short, engineering is not an island. It is (or should be) an integral part of a larger system, so the calling conventions and interfaces with other departments should be efficient, modular, and bidirectional. And subject to update from time to time. Development tools, like benefits packages, IT systems, and office locations become a corporate decision rather than something one person gets to pick.
You might be fond of Brand X tools because they're good and reliable and familiar. But if Brand A really does offer something for the managers, the accountants, the QA team, or the compliance testers then it's worthwhile to consider that alternative. Market pressure isn't getting any easier and it won't be long before your management starts looking hard at your development procedures and tools.