Navigating the Odyssey of Working in Industry

[Iforgot]

I've been at my job for a couple of months now, and it's tough job. I'm actually designing and building things that other people will use. It's a completely different beast than my PhD in experimental (UHV,rf,clean room facilities) physics. Cludge isn't acceptable... What's a guy to do?

I can't tell if I'm getting dumber, or my projects are getting harder. I always thought I was clever (at least until I started grad school) b/c coding came easy to me. But my coding and cludging intuition isn't helping me with this job.

When it comes to project design, 1) I want to build a quick crappy prototype using cheap parts, and continuously refine it (like code). 2) My boss wants me to spend serious time designing it, and making sure all parts are compatible in advance. 3) I was trained in grad school to take whatever is lying around and make do.

On the plus side, it's a boatload of awesome experience. I'm building this whole thing myself. Everything from the circuit design and optics setup, to the processing software and chassis machining. I'm also getting the chance to work on my own proposals. All these will be notches on the good old belt.

On the down side, we are a small company (#people< 6), and I'm the only one working on my project. One of my coworkers has experience with my project, and he's very helpful. But still I feel overwhelmed.

To the people on this forum, what are your experiences building a producing stuff, and just working at small companies in general?

 

[berkeman]

I've been at my job for a couple of months now, and it's tough job. I'm actually designing and building things that other people will use. It's a completely different beast than my PhD in experimental (UHV,rf,clean room facilities) physics. Cludge isn't acceptable... What's a guy to do?

I can't tell if I'm getting dumber, or my projects are getting harder. I always thought I was clever (at least until I started grad school) b/c coding came easy to me. But my coding and cludging intuition isn't helping me with this job.

When it comes to project design, 1) I want to build a quick crappy prototype using cheap parts, and continuously refine it (like code). 2) My boss wants me to spend serious time designing it, and making sure all parts are compatible in advance. 3) I was trained in grad school to take whatever is lying around and make do.

On the plus side, it's a boatload of awesome experience. I'm building this whole thing myself. Everything from the circuit design and optics setup, to the processing software and chassis machining. I'm also getting the chance to work on my own proposals. All these will be notches on the good old belt.

On the down side, we are a small company (#people< 6), and I'm the only one working on my project. One of my coworkers has experience with my project, and he's very helpful. But still I feel overwhelmed.

To the people on this forum, what are your experiences building a producing stuff, and just working at small companies in general?

That's a very good set of questions. I'll try to give my perspective on some of them.

First, what I've found to work best for me (and the company that I've been with from startup to medium size company), is to shortcut to some of the more important design answers with quick prototypes and tests, and then do the overall product planning and optimization. It's not so much using kludges in the design process, it's more like separating out possible from not-so-possible early, so that you can focus on how to optimize the possible. (I may have to make a follow-up post with examples to make this point more clear).

And since I have experience with helping to take a small (private) company to a medium-size public company, there are some important things to point out. First, early in a small company's life, it's okay to have spartan documentation and only a person or two who understand a product's design. That's enough to support the small product line and keep it successful. But as the product line(s) grow, and as the number of customers grow (hey, that's a good thing!), you really need more people, and dedicated support people, who understand the products and can help with issues that come up in Production or in the field. That is where good design documentation becomes key.

For those reasons, and others, the ISO 9000 process stuff has a number of requirements for documentation and process control. It's not so much a PITA documentation requirement, as much as a way to be sure that product designs are done and documented in a way that helps to ensure quality control and customer satisfaction. When we became big enough to need to implement ISO 9000+ controls on our processes (PDP=product development process and QMS=quality management system, I think), it was a lot of extra work, but it helped us to formalize the whole design process so that we can be sure to track what we do, and respond to customer requests and needs.

So even though you are working at a small company right now, I'd recommend a few things to you:

** Keep your design documentation on a shared server that other employees can access, preferably under document/design control (like with Perforce or Agile or WinCVS).

** Hold formal Design Reviews at critical project milestone points, typically right before you go out for layout of a PCB. Design Reviews take some extra work for you as a designer, but are super-important checkpoints, especially for a smaller company with critical projects in the pipeline.

EDIT -- I've learned very important things at Design Reviews for my designs that I've called, and I've also been able to provide important helpful hints and catch important mistakes at Design Reviews that I've been invited to...

** As part of your documentation, write up a Functional Specification early in the project, and use that as a morphing document that eventually ends up being an overall Theory of Operation document. Early on, it will mostly reflect the Marketing Requirements Document that you get from Marketing or whoever, but will gradually take on a more technical nature as you get farther along with your design. In the end, it is an invaluable technical document, for anybody who needs to understand or support or build upon your design work on the project.

** Keep a running technical log of your Design Verification Testing (DVT) and Electromagnetic Compatibility Testing (EMC Testing) work on your design, as you go through the EN 61000-4-x test suite. Include photos of your test setups in the docs. I like to just use Excel for this testing phase. Having this doc helps you to be sure that your product is robust, and also helps you remember how to do the testing on future products that you design.

As you work for bigger and bigger companies (or as your present small company succeeds and grows), these steps will become more natural, and more a part of the standard product development process. The ISO PDP/QMS process and sign-off sheets are now a standard part of my company's development process, and I think it's a good thing. You can just lose too much by playing fast and loose for too long on product development. Especially when you are successful with several generations of products in a row, and grow the company well.

Have fun!

 

[Ben Espen]

That quick crappy prototype is often called a proof of concept, and that is certainly a valuable thing to do, but once you have successfully demonstrated the proof of concept, no one really wants kludge in a product you are planning on selling.

In industry, time is often a critical factor. The upfront design work your boss is looking for is a time-saving device that allows you to incorporate the knowledge of others into your product. You can learn a lot from continuous refinement, but if someone else has already learned it, you don't need to. Your hands-on approach is a good thing, not everyone is as willing to get their hands dirty as you. Learning about the product design and management standards that berkeman mentioned will round-out your skillset for industry.

 

[AlephZero]

When it comes to project design, 1) I want to build a quick crappy prototype using cheap parts, and continuously refine it (like code). 2) My boss wants me to spend serious time designing it, and making sure all parts are compatible in advance. 3) I was trained in grad school to take whatever is lying around and make do.

I suggest what you really need to do is both 1) and 2), but keep a very clear division in your mind between "research and development" which is item 1, and "product design" which is item 2.

In an ideal world, before you get to "product design" you should know what you want the product to actually do (don't laugh, people sometimes get so excited about a general concept that they skip over that "small" detail), and you know at least one feasible and cost effective way to do it. (Knowing more than one way is better, of course.) Until you get those things nailed down, you don't really have a "project", you are still doing research.

I would suggest you use your "make do and mend" skills to the full in step 1, but keep them well away from step 2, unless you want to spend the rest of your life dealing with customer complaints once the product starts shipping.

 

[Matrix0]

I can understand the challenges and frustrations you are facing in your new job in industry. Moving from a research-based environment to a more practical and fast-paced industry setting can definitely be a big adjustment. It sounds like you are facing a common struggle for those with a background in academia – the clash between quick and dirty solutions versus thorough and meticulous design.

In industry, it is important to strike a balance between these two approaches. While it may be tempting to build a quick prototype and continuously refine it, this may not be the most efficient or cost-effective way to produce a high-quality product. Your boss is likely emphasizing the importance of taking the time to design and ensure compatibility because in the end, it will save time and resources in the long run.

I would suggest discussing your concerns and ideas with your boss and colleagues. It may be helpful to explain your background and how you were trained in graduate school to make do with whatever materials were available. This will give them a better understanding of your approach and may lead to a compromise that incorporates both quick problem-solving and thorough design.

Working in a small company can also be challenging, as you are often responsible for multiple tasks and projects. However, it also provides a unique opportunity to gain hands-on experience and take on a variety of roles. Make sure to communicate with your coworkers and utilize their expertise and guidance when needed. It is also important to prioritize and manage your workload effectively to avoid feeling overwhelmed.

Overall, navigating the transition from academia to industry can be a learning experience, but it will also provide valuable skills and experience that will benefit you in your career. Keep an open mind, communicate with your colleagues, and continue to learn and adapt to the new environment.