Comment Just went through this a few months ago. (Score 0) 447
Interestingly enough, I just did this about three months ago. My company does product development specifically with embedded systems. A few years back we started a new division that has been growing pretty well. Originally, the head of the division served as engineering manager, product manager, business development coordinator, etc. We finally outgrew that mode and decided to hire on a full-time engineering manager. Since I run the software team, the person we hired would become my direct boss and I got to look through resumes, sit in on all of the interviews, etc.
One point I'd like to make is that this is generally a great thing. My work life has become a hundred times more enjoyable now that I have a boss whose sole job is managing our various engineering teams.
Coordination between hardware design, layout, software, manufacturing, and all of the other teams is paramount to being successful. Nothing sucks more than having a newly designed board land on my desk and finding out that I don't have enough time to validate it before we need to go to manufacturing. So for me, one of my big things was finding a boss that had experience managing this type of communication and scheduling. I was _really_ glad to here my future boss talk about the importance of staying in a beta cycle until everyone on the engineering team signed off on the design. Someone who understands that no matter how desperatly you want to release a product, if you ship with bugs or you ship too soon, you are just asking to eat up your development resources for the next year debugging units in the field instead of at your desk. This is ultimately more expensive for the company as well as a serious moral killer.
Another thing that I really value is the wall that my new boss erects between me and marketing, sales, etc. It's nice to be able to give an honest schedule estimate and not see the whince-face. So I had a ton of questions during the interview process about his ability to handle schedule pressure coming from above (marketing) and below (engineering). I knew that I wasn't interested in hearing any "we are hear to sell product, so what marketing wants, marketing gets" type speeches. Therefore, I was impressed with the thoughtful response given along the lines of; "marketing needs to drive product strategy, but engineering needs to drive product schedules."
Finally, I really wanted someone with experience in our field. I know people will say things like "projects are projects, doesn't matter what the industry a successful manager can handle anything." This may be true in some fields, but embedded development is tough. I needed someone who understands that I'm not dancing when I say that a given task should take about two weeks, but if the CPLD hasn't been verified yet, it might take six weeks instead. Someone who understands that when the scopes and logic analyzers start coming out, he better expect the schedule to start slipping as well. I can't tell you how many due dates I've blown by thinking I had a bug in my code only to find some sort of timing issue on a board, or a bug in the silicon. Yes, those of us who do embedded development often do find bugs in the silicon we work with. Especially when we start working with new processors.
Anyway, my advice is to look at this as a good thing. Then think about the parts of your job that are painful and concentrate your questions there. For me, those questions mainly centered around his or her ability to communicate scheduling and efforts between several different teams and prior experience in my field.
Best of Luck,
--Greazy
One point I'd like to make is that this is generally a great thing. My work life has become a hundred times more enjoyable now that I have a boss whose sole job is managing our various engineering teams.
Coordination between hardware design, layout, software, manufacturing, and all of the other teams is paramount to being successful. Nothing sucks more than having a newly designed board land on my desk and finding out that I don't have enough time to validate it before we need to go to manufacturing. So for me, one of my big things was finding a boss that had experience managing this type of communication and scheduling. I was _really_ glad to here my future boss talk about the importance of staying in a beta cycle until everyone on the engineering team signed off on the design. Someone who understands that no matter how desperatly you want to release a product, if you ship with bugs or you ship too soon, you are just asking to eat up your development resources for the next year debugging units in the field instead of at your desk. This is ultimately more expensive for the company as well as a serious moral killer.
Another thing that I really value is the wall that my new boss erects between me and marketing, sales, etc. It's nice to be able to give an honest schedule estimate and not see the whince-face. So I had a ton of questions during the interview process about his ability to handle schedule pressure coming from above (marketing) and below (engineering). I knew that I wasn't interested in hearing any "we are hear to sell product, so what marketing wants, marketing gets" type speeches. Therefore, I was impressed with the thoughtful response given along the lines of; "marketing needs to drive product strategy, but engineering needs to drive product schedules."
Finally, I really wanted someone with experience in our field. I know people will say things like "projects are projects, doesn't matter what the industry a successful manager can handle anything." This may be true in some fields, but embedded development is tough. I needed someone who understands that I'm not dancing when I say that a given task should take about two weeks, but if the CPLD hasn't been verified yet, it might take six weeks instead. Someone who understands that when the scopes and logic analyzers start coming out, he better expect the schedule to start slipping as well. I can't tell you how many due dates I've blown by thinking I had a bug in my code only to find some sort of timing issue on a board, or a bug in the silicon. Yes, those of us who do embedded development often do find bugs in the silicon we work with. Especially when we start working with new processors.
Anyway, my advice is to look at this as a good thing. Then think about the parts of your job that are painful and concentrate your questions there. For me, those questions mainly centered around his or her ability to communicate scheduling and efforts between several different teams and prior experience in my field.
Best of Luck,
--Greazy
