Poojan (Wagh) Blog

I’ve been lucky enough to find myself in a team that’s intent on finding the best circuit design for a given application. This doesn’t happen often to many people, but I feel that I’ve had more than my share of this opportunity.

The conclusion is usually that we come up with some topology (let’s call it circuit X) that optimizes all the performance criteria. I walk away wanting to generalize the experience with the lesson that circuit X is the best circuit ever, and I want to use it everywhere.

Inevitably, I find that some other topology Y is better suited for some other application. There were some specific constraints or conditions on circuit X that don’t apply to circuit Y, and as a result, circuit Y is more optimal for application Y.

Looking back on this behavior, I think the main fault is the tendency to remember only the conclusions and not the assumptions. Why do we* do this? Well, because the assumptions are where we start. The lesson learned is where we end. We’d rather remember the finish line—the victory—rather than the starting line. It’s certainly more glorifying to remember your accomplishments rather than the mundane criteria that drive us to the goal. We are also rewarded for the results, not the specification of the problem.

I’ve periodically re-learned this tendency to form generalizations by forgetting assumptions and by only remembering the conclusion of the thought process.

footnotes

* Maybe I should say I, not we: perhaps I am generalizing again.

I’ve accepted a position elsewhere. My last day of employment at Motorola will be Nov. 21^st. Before I get into where I’m going, I’d like to reflect on / point out a few things with embedded humor:

• I’m not dissatisfied with my position at Motorola. Indeed, I am in an ideal environment for someone who both likes to invent and innovate, and likes to see things ship. The role in which I found/positioned myself allowed me to investigate some really new technology, without the ridiculous schedules that plague market-reactive engineering environments. At the same time, the stuff we made actually gets shipped, tested, and developed further. It impacts customers.
• I have learned how to present and explain things to external customers that aren’t up to speed with the daily tasks of the project. I’m still not great at it, but I am comfortable doing it–and I’m better at it due to mentoring by some amazing communicators.
• I’ve learned a lot about making decisions and plans (strategy). It is always the case (and always going to be) that we can’t do everything. Figuring out what not to work on can be as essential as figuring out what to work on. It’s important to have some criteria guiding these decisions. Goal-setting is important to decision-making. You don’t have to write down the goals, but have them.
• I’ve learned that it’s always better to be pleasant and kind about technical disagreements. Okay, all disagreements. Even to the people that bug you. They usually think they’re helping. Sometimes, the other guy/gal is right. Okay, more than sometimes. It’s very easy to think that what you’re doing is optimal, because you’ve already laid out the plan and can’t see the other alternatives. An open mind is essential.
• At the same time, don’t spend time arguing with others if you’ve convinced yourself. There’s always going to be things you could do better. Accept that what you do won’t be perfect–and other people will point it out, but it wasn’t their decision to make, was it? You’re in charge for a reason. Take ownership of what you do, and you will do it better. Get someone else to write the project report, though.
• The most important thing is the business. We’re not here to have fun. We’re here to make money for the company. Almost all the time, you can have both. Question if what you’re doing is what is best for the customer/department/business. You may have to do some things that aren’t fun, but most of the time, success will follow–and that’s always fun.
• I have had the honor of being a member of very passionate groups that are doing amazing things with technology. These amazing things don’t get realized all of a sudden on a glorious day. The problems are so complex that one ends up solving very small problems for a long period of time to get incrementally closer to the goal. It’s hard work, and believing in the goal is helpful. Having a management team (and customer) that understands the labor of research is essential. Celebrating small advancements (for example, as feedback to your peers) makes for good teams.

I’m not leaving because things are bad at Motorola. In fact, it is the focus on technological work that makes me want to expand into more areas of technology. If I wasn’t happy at Motorola, I would probably be getting my MBA and be considering business instead. To all executive recruiters: I am not ruling the MBA out.

Where am I going? To a private hedge fund in Chicago. Why? Because:

• I want a change. I want to learn something new. I want to broaden my knowledge.
• I like the environment. Working in the financial industry is good. Working with technology is good. However, it’s more important to me that the firm invests in their employees. They’re willing to hire a person–okay, it’s me–because they think he’s smart. I like their attitude toward people.
• The people I know at the firm are some of the most ethical and just people I know.
• This opportunity isn’t going to come around again.
• Free lunch.

Will I be a financial analyst? No.

Will I have stock tips? No.

What will I be doing? I don’t know: stuff. Smart stuff. Mostly software initially.

Is this change necessary? Absolutely not. However, there’s no reason to wait until change is necessary to develop and grow. If you–well, not you specifically–embrace change on your terms, rather than the terms of your environment, you get to pick how you develop, and you get to pick your strengths. There’s a school of thought that states that evolution picks convenient solutions, not optimal solutions.

I sincerely plan to stay in touch with the people I’ve met at Motorola and continue to keep up with my friends from Freescale. This blog is a good way to contact me (see voicemail page to the left). Or, consider subscribing (RSS/Atom or Email).