Editor’s Note: We’re doing a theme-week (starting mid-week, yes) here at Engineer Blogs about how engineering roles change as the company changes. Obviously there are some differences in what an engineer is expected to do in a fledgling company versus a near-death company. Our writers will detail a company (or multiple companies) they have worked in and how their role fit in with their organization.
Let’s talk about the principle of Established. The very word inspires… nothing. It raises images of crusty librarians, besuited commuters in trains escaping the teenaged family, judges in wigs, stasis.
Yet those very images are perfect camoflage for the turmoil going on behind the scenes – and turmoil is interesting whichever way it is bubbling.
So, yes, I’d like to write about my experiences at an established company. How established? Very established. My company’s founder worked alongside Henry Ford himself, supplying him with parts made in a clever new way. His family built up the firm in the usual way; through clever expansion and disastrous overreaching, by buying and being bought, by diversifying and by divesting to the point where we are now. I am working on a product that is essentially 80 years old.
How dull.
How, in fact, not dull; it isn’t the whole picture! It’s the turmoil behind the scenes that I’m involved in. We’re talking tempering and annealing of steel alloys, plastics extrusion, friction control, vibration fatigue resistance, mechanical, chemical and corrosion resistance. We’re talking about sealing systems and–astounding though it may sound for such a mature product–development! I’m working on releasing my next patent in the field as we speak.
So how does such an established company go about its design and development on such an established product in this day and age? Well, I’m not sure that it would be the official company line, but we do this by mixing small and large, fresh and grizzled. In terms of technology, we’re a very lean team. Our development budget is sufficiently generous (most years) to work on developing new solutions to old problems. Other times we’re optimizing performance and cost. If we need additional capital or external testing, we can get it if we and the project we’re supporting can justify it.
Talking about projects, we have a good project selection methodology. It involves a director who gives us “go / no-go” decisions firmly without being overly unwieldy; this is all done through a workable project management system. My biggest budgetary issue is time: being a lean “core” within a global company, we’re pulled in many non-developmental directions. Most of my time is spent supporting customer projects with product tweaks and delving into quality complaints. In general, we “find things”; we rediscover the science behind existing products which went walkabout with the personnel changes. Anything the firm grew, diffused or shrank (steel alloy grain structures, for example), we try to make them discoverable again, this time forever.
I have the comparative luxury that very little of our design work is outsourced. I can utilize 75% of an in’house CAD designer’s time in the same office without any questions. When we do go to a third party solution, the suppliers we need for development are generally well integrated with our team. However, when I think back to checking drawings, it’s often a case of needing a second or third run before we’re happy – I miss things because it’s immensely difficult to focus on each task at hand with such a high background level of “urgents”.
In many ways, my company reflects its environment. The auto industry is inherently conservative. We often hear questions around the theme “who is using this already?” One rather perceptive (if slightly worrying) comment I’ll never forget:
“The winners in the field are those who won the race to be second; let others do the back breaking development work, then rapidly optimise and commercialize.”
Against that background, it’s sometimes amazing that we do any development work at all, but we do.