something about the fact that the value of a monetery unit is in flux really bothers me. A dollar doesn't have the same value at the end of an equation as it did at the beginning (just standard fluctuation), whereas a volt doesn't change!
@Caleb Kraft It's funny because there are "natural constants" that we use in engineering that are actually only local constants to our particular region of the universe. But, the semiconductor industry has from time-to-time invented new ways to adjust the price of a component. Take the infamous "gold adder" from the late 1970s. Many of our packages used a relatively large amount of gold which could cause fluctuations in the raw materials cost to produce a package component. So, we instituted a gold adder which was initially tied to the price of gold. Funny thing is that when the price of gold stabilized and new pricing came out, many companies kept the gold adder and used it as an excuse for "high component prices."
Of course, this was the same time when it was financially advantageous to borrow money to buy "things" because the net cost of borrowing was lower than the inflation rate of your salary (which was going up to keep pace with inflation). Managing projects during this time was difficult because the average stay with one employer was significantly less than the time to complete the project.
@Max The Magnificent there is a certain logic to accounting. BUT, there are a LOT of nonsensical rules that are imposed by the way we collectively make politically-driven laws. Once I held some new product investment purse strings for a large multinational semiconductor company. At the time, there was a Financial Accounting Standards Board (FASB pronounced faz-bee). There was an accounting rule under FASB 86 that said that we were to expense our investment until we had proof that the new technology would work. Then we were mandated to capitalize the investment. How do you draw the line for a new semiconductor process, or a never-before-implemented circuit? This is just one of the reasons why many companies just can't seem to complete their tax filings as you and I must every year.
@Henry: ...but just fail to file and you'll find out what strange can be...
Actually I'm a bit of an anal retentive re Taxes ... it's like the fact that I always drive at the speed limit so I never worry when I see a police car hiding at the side of the road -- there's a filing cabinet just outside my office that holds all my tax records and receipts and stuff since I moved here in 1990 -- plus my accountant has copies -- I'm so squeeky clean it's embarrasing LOL
@Max The Magnificent Squeeky clean huh? I'd say that you demonstarte a fine sense of what battles are a loosing proposition from the start. I know one fellow who is a multi-millionair several toems over. He's been in na never-ending series of tax disputes for more than 15 years. He's spent MORE on his legal cases than he would have spent had he simply paid ...
Henry, you know an argument can be made that most of the grief that engineers are currently going through is due to what I might term the "misreading" of certain ratios. Engineers are certainly the largest percentage of the more highly compensated portion of a company's workforce that is also "mobile" (read: used to getting fired regularly, unlike upper management). The ratio of an individual US engineer's salary to that of his Asian counterpart is also high, with the correlation that replacing a US engineer with an Asian one will result in a saving that propagates to the bottom line very quickly. There is also the premise that the expense of employing any particular engineer needs to be charged directly to the project that he is working on RIGHT NOW (perhaps even to the extent of "debiting" his entire annual compensation against a project that lasts only a few months), resulting in a situation that it becomes next to impossible to justify keeping ANYONE "on staff" any longer than the project he is working on lasts, even if it did take a decade or more to acquire the expertise necessary to do the work required, whereas the manager who supervises his work is probably budgeted against a much longer timeframe. Add to this the tendency of many accounting systems to reflect only costs and totally ignore value (like the term "spreadsheet management" that I used in an earlier blog) and I would make the following point: it's not that engineers aren't comfortable or familiar with the use of simple ratios to manage the businesses they work in, it's really that they're so used to being on the wrong end of ALL these ratios that affect their longevity in a negative way that they're really loath to hear much more about them, it can only be more bad news that they don't want to hear!
@JeffL_2 "misreading certain raios" is on way of stating a major mart of the problem. I'd be a bit more blunt: finance often doesn't understand that "an engineer" isn't fungible. An experienced analog engineer is NOT the same as a junior digital designer. Making that connection is up to management, which is where the buck stops. But it's also important for practicing engineers to understand HOW their employer applies ratios - are engineers viewed as a commodity? If so, plan your exit accordingly.
I'm neither a big fan nor a detractor of off-shoring engineering activities. I recently had a conversation with a semiconductor company that has a "design team" in India. Now those engineers are fine for what they are - junior digital engineers. But, they are developing analog-digital converters for use in systems that are reliant on multi-channel, synchrous sampling within a few pico-seconds. They don't understand WHY the ADCs need to have a sampling clock to drive sampling. In this case, THESE ENGINEERS are interchangable parts. But they shouldn't be interchangable - the parts that they create don't work in many of the systems for which they were designed. This is both an enngineering and management failure.
I once argued (unsuccessfully) that moving a microcontroller design responsibility wholesale to an offshore design team was a strategic mistake. My arguement wasn't based on country of origin, but rather on the experience level of the offshore team that was being built. Offshoring can be a good approach for some companies, but often the decision is driven by financial considerations that turn out to be invalid. I've monitored results from numerous offshore teams (incouding those here in the US for foreigh comanies) and the results are pretty uniformly disappointing. But once the host country team has been dispersed, there's little chance of reconstituting the activity fast enough to remedy the now-failing situation.
Some companies, like SUN, develooped the "you're only emplyed as long as you are on a current project" attitude. I thought it was a fyndamentally flawed approach to managing employees. Sometimes is was used to "gently" mget rid of an employee who was no longer wanted. But it also had a terrible impact on engineers' attitude as projects started getting close to completion. The last several monthys of a project tended to have the lions' share of schedule misses as employees were busy looking for another "job" inside the company.
It's management's job, and perhaps their most important job, to find the most valuable employees and make certain that they are used to best advantage over the long haul. It's also theur job to termiate employees humanely when the employee's skills no longer fit the company's mission.
In the yUK, TAX rules amount to over 11500 pages, VAT more than 800, the all that EU rules stuff. Not checked to see if it's less or more now (10 years but greater is a distinct probability), no interest in that BS whatsoever!
Cash flow is King to any company. I was never motivated in accounts any less than 3 to 6 months apart. Guess what happens?
Maths, physics, chemistry and electronics. GOOD fun stuff.
A day job and others doing the S&M and beans would be great right now!
In my version of reality, management/finance and engineering are two different worlds. Being in the engineering side, my impression is that management can't seem to grasp reality, all too often.
The recurring example is related to obsessing over just those ratios.
If there's a job to be done, which usually entails something not quite trivial, and something that needs to be completed in a timely manner, engineering has to get going on it. Management likes to stall the effort until they have their dollars all lined up, which makes sense from their perspective as far as that goes. But then, when they finally give the go-ahead to engineering, they expect engineering to rush the work through by some ridiculous deadline. There has to be a better way. There has to be a way of making funds available early, so the work can be done correctly, getting people to work on it as soon as their schedule permits.
I've been at this for decades. It's no surprise at all to me that so many programs seem sluggish and ponderous. Engineering has to find ways to sidestep management, or programs end up being just that. Sluggish, ponderous, unresponsive.
Yeah I have an idea. Put an engineer in charge of finance. They understand numbers much better, and actually understand that profit takes time. And a whole bunch of other stuff about math that a finance major couldn't possibly understand. Like the ability to think about more than profit.
My version of reality is WAY better than your version -- in my version I'm a superstar and everybody loves me and there's always hot bacon and cold beer close to hand .... I'm sorry, what were we talking about?
Being aware of all current legislation's features really brings business to the next level. Year ago I hired skilled engineering managers to investigate and to improve my organization. The result was amazing. I also got a good help from Internet based Cash Advance Loan Store and now my profits are stably increasing.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.