Engineers, and How to Manage Them

I've covered various aspects of an EDA company: sales, marketing, application engineers, even being the CEO. Today, it is the turn of engineering. My background is engineering. I started my career writing DRC code and the moved on to create VLSI Technology's circuit extractor. I then ran the group responsible for the graphics and data-management for all the tools. My next task was to go to France and set up a European R&D center. By that point, I no longer wrote code, so I was a full-time engineering manager. Eventually, I ran Compass Design Automation's engineering worldwide. I did various more operational management things and then joined Ambit as their VP Engineering. Cadence acquired us, which is how I ended up in Cadence the first time, although almost immediately I was the VP Strategic Marketing in the engineering group (Cadence was functionally organized in those days). All of which is to say, engineering is my comfort zone, and I know quite a bit about it both as a practitioner, a junior manager, up to running engineering teams with hundreds of engineers.

I don't have a whole load of pictures of me doing engineering through the ages. So I illustrated today's post with a few of the pictures that come up when you search for engineers on the stock photography site that we use.

Being an Engineer

I'm not going to say a lot about being an engineer. If you aren't one already, then it's too late to start. In fact, it has something in common with becoming a ballet dancer or a chess grandmaster. You have to start when you are a kid. So I can't really give any advice on becoming an engineer, just on your kids becoming engineers. That's not true for all disciplines. You can go into sales, or HR, or finance, or marketing (or writing even!) without having focused on the right things from an early age. You can be an engineer and then go to law school, but I have never come across anyone who didn't like being a lawyer and so went to engineering school from a standing start.

You (or your kids, or your nieces and nephews) don't have to have a clear career path when you start middle school, but if you don't put effort into math and science then you won't come out of high school ready to do engineering courses in college. If you are likely to end up doing a lot of programming, then learning to type fast is a really good skill to have, too. Programming and debugging involve a lot of typing.

Emotional Engineers

One surprising thing is that engineers are emotional. People say that salespeople are emotional, but I think that people confuse being emotional with expressing thoughts. A salesperson will typically not hesitate to tell you what he or she thinks of some decision, like changing their territory or their commission plan. But having had their say, they will reorganize all their meetings for the following week. Engineers, on the other hand, tend to have less developed interpersonal skills (those stereotypes about nerds are at least partially true) so they will brood. If you cancel a project, even if everyone acknowledges that it is doomed, then they will not be happy about it for a long time (although they may say less). It may be pop-sci, but I think that it may be because engineering is creative in a way that, say, sales are not. Engineering is about delivering a creation; sales have creative too, but the end product is an order and the creativity is a means to an end. So canceling a project is more like defacing an artwork.

Perhaps the most surprising emotional phase I've experienced is when we started to be successful at Ambit. Until the product was ready for customer engagement, almost the entire company was in engineering, and senior management time was entirely focused on engineering schedules (and some fund-raising). Then customer engagements started and salespeople and application engineers were hired. That was also about the time I was brought on board as VP Engineering.

The product started to sell. More sales teams came on board. Senior management's focus switched to bookings numbers and closing orders. The main time that engineering came under the spotlight was a "show stopper" at a key customer (where key was often simply defined as likely to give us an order). I actually walked into our conference room for a meeting to discover another meeting still going on, an unofficial meeting of engineering. Everyone was venting about how the company had changed for the worse. It was like the stereotypical reaction of a first child when a second child is born, and suddenly the baby gets all the attention. In a startup like Ambit, I had to point out to the engineering team, that senior management giving up poking into all the engineering schedules is a symptom of success. If the product wasn't selling due to product deficiencies, the spotlight would be back on us in engineering, and that would not be a good thing.

Managing Engineers

If you have good engineers, then I've found that you can manage with a relatively light hand on the wheel. Engineers hate to be micromanaged (probably everyone does). When I first became a manager, like most people, I was managing people whose job I could have done myself. In fact, like most newly promoted managers, I could have done their job better than they could. That was why I had been the one promoted. So one lesson I had to learn is to avoid the temptation to everything myself. If I could do something in ten minutes, or teach someone else how to do it in thirty minutes, then it would be quickest to do it myself. But that has two problems. It doesn't ever scale since I couldn't always do everything. And the people working for me would never learn how to do the technical aspects of my job, so I would never be able to take on new challenges since I would still have the old ones on my back.

When I got promoted further, I was managing projects that I couldn't do myself. In particular, I was running library projects (what we would call foundation IP today). There was no temptation to try and do the job myself, nor even try and micromanage, because I didn't know enough. In some ways, those projects were easier to manage as a result.

These were lessons I had to learn the hard way, and they were mistakes that I saw many junior managers make. I discovered a couple of "tricks" that seemed to help people make the transition. First, make sure that your newly promoted managers know that all your care about is the output of their group. You don't care if they did something themselves as opposed to having someone else do it. In fact, if anything, it is a negative if they did it themselves. The second thing is that a person who hasn't trained the rest of the team well enough to do all the technical aspects of the job is indispensable. But, in this context, indispensable means can't be promoted.

So the key message for a first time engineering manager is that their job is to get their team to do the entire job, so that they can move onto something new. If there are things that only they can do (other than managing the group) then they can't be promoted. In a way, this becomes easier as you run bigger organizations, since you are mainly managing people, not doing anything technical yourself. Indeed, if you ever run a large organization, with dozens or hundreds of engineers, there is zero opportunity to contribute technically even though you have a technical background. In fact, all senior engineering management jobs are the same: you are managing a group of managers (plus budgets and schedules).

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.