Moving from task-oriented EE to system-level architecture: practical tips

Thread Starter

hoyyoth

Joined Mar 21, 2020
528
I’m an electronics engineer with several years of experience in a service-style environment. Over time I’ve worked on a bit of everything:

  • Analog board design (signal chains, sensor to ADC, etc.)
  • Microcontroller and microprocessor-based designs
  • Some signal integrity simulations
  • Power supply design and debugging
Because new projects keep coming in, I usually learn just enough to get the current job done and then move on to the next one. The result is that my resume lists many domains, but I don’t feel truly deep in any of them. The only area where I’m clearly stronger is analog hardware, but in my current context that has relatively low demand.

What I really want is to move toward a more architect-type role:

  • Being involved earlier with customers and requirements.
  • Defining interfaces and partitioning the system.
  • Understanding trade‑offs between analog/digital, firmware, power, cost, and manufacturability.
  • Guiding implementation rather than just receiving a block-level task.
For people who have successfully made that transition (or who already work as system/solution/technical architects in the electronics world), I’d really like your practical advice:

  1. Which skills should I focus on building first to move in that direction (e.g., interfaces and protocols, system grounding/EMC, high‑level requirements, customer interaction, documentation, etc.)?
  2. In your experience, what responsibilities or behaviors signal to management that someone is ready for an architecture‑style role?
  3. Are there specific types of projects, internal initiatives, or roles (e.g., technical lead on a project) that are good stepping stones from “do the task” engineer to architect?
  4. Any recommended books, resources, or kinds of design reviews that helped you develop a more system-level mindset?
I’m not looking to stop being hands‑on, but I do want to grow from “jack of all trades implementer” into someone who can own the overall solution and make solid system‑level decisions. Any guidance, war stories, or concrete examples would be really appreciated.

Thanks in advance to anyone willing to share their experience.
 

MisterBill2

Joined Jan 23, 2018
27,159
I did that at a couple of jobs. Learning more is part of it, and understanding how those different segments that you have worked with go together and work together.
AND, if you would be designing systems or machines for clients (customers), developing the client contact skills , which include learning to ask those "right questions" about whatever the project would be.
AND learning to work with those engineers in the areas that you are not a master of: Hydraulics, pneumatic systems and at least a bit of kinematics. The other part of getting into whole-project design is understanding the cost versus quality aspects of it. If there is a "TEAM" at your place that creates the initial detailed concept, getting onto that team is a good way to learn.And possibly contribute.
 

WBahn

Joined Mar 31, 2012
32,702
This was one of the things I liked about working for a very small mixed-signal ASIC design house. Each project had one or two engineers working on it and we were responsible for everything from working with the customer directly to determine just what they really needed, as opposed to what they thought they needed, coming up with an approach to meet those needs, which usually involved evaluating several possibilities far enough to rule them in or out, presenting them to the customer, designing the chip schematics and simulations, verifying that the design would actually meet the customer's requirements and presenting that to them, laying out the physical chip (for what we did, this was nearly 100% done by hand), verifying the design, both electrically and physically, submitting it to the fab, designing the test system, testing the chip when it came back, and supporting the customer throughout this process, including sometimes years down the road. The results was that you got to know each project you worked on intimately and you were always learning new things that became part of your toolbox for future projects. You also learned how to interact with different kinds of customers, how to explore issues into greater depth if needed, and how to bounce ideas off other engineers or outside sources. It also left you in a constant state of wondering if you really knew what the hell you were doing and always suspicious that your design wasn't nearly as good as it could be if you just knew a little bit more.

Probably one of the strongest pieces of advice I could offer would be to seek out ways to cross pollinate. We typically had six to ten projects going at any one time and each engineer was working on two or three of them simultaneously. We were all expected to attend all design reviews -- and when I first started working there we shared office with another design firm that did some ASIC, but mostly PCB-level and programmable logic designs, and we attended each other's design reviews. Those were incredible learning opportunities, provided you went into them with that mindset instead of just going through the motions. You not only got exposed to lots of different ideas and approaches and became aware of lots of different issues that you might need to contend with at some point (just knowing that a particular issue existed was valuable), but you also got a feel for each others strengths and weaknesses so that you knew who to talk to about problems as they crept up.
 

MisterBill2

Joined Jan 23, 2018
27,159
Certainly WBahn is totally correct in his description of the benefits of working for a small company. Except for my first engineering jobs, I worked at much smaller companies, less than 20 employees total. THAT is where you can grow your skill set if you are wanting to learn and work. But nothing comes without effort, unless your very rich uncle owns the company.
 

KeithWalker

Joined Jul 10, 2017
3,603
What you describe is Project Engineering. I suggest that you first focus on learning about Project Management. There is a wealth of information available on the internet so make yourself thoroughly familiar with the requirements and methodology of how to manage projects .
You already have a wide base of electronic knowledge and experience. So for each specific project that you tackle, you can focus on learning the technical details needed to complete it.
 
Top