Bernard Fraenkel, Practice Lead at Silicon Valley Software Group, started in the business world as an engineer. With his Masters in Electrical Engineering from UC Berkeley, Fraenkel’s first jobs out of school entailed developing signal processing-based products such as speech compression systems, modems, and chips for image and video compression. Fraenkel developed algorithms and validated them through simulations before implementing in firmware or semi-custom chips.
After a decade of working as an individual contributor, Fraenkel caught the startup bug and raised seed funding for his low-cost video editing product. While this startup did not succeed, one of the investors he met in the process connected him to a startup in need of a Vice President of Engineering. This step launched a new career phase for Fraenkel. Since then – for the last 20 years – he has run engineering teams in venture-backed companies ranging from distance learning to e-commerce, large-scale document storage systems, education, as well as mobile banking and digital marketing. In various leadership roles over the twenty years, Fraenkel has experienced two IPO’s and four acquisitions.
Through these experiences, Fraenkel has learned first-hand how to transition from being a technical specialist to a business leader. While he hasn’t had “official” mentors to help him navigate this transition, he is grateful to a number of CEOs and friends for their coaching. The process of creating, pitching and running a startup was the most intense learning experience, and the best preparation to become an engineering executive. Over the past few years, he has become a mentor for numerous future engineering leaders through Everwise.
Read on to learn more about Fraenkel’s experience with Everwise protégés, including mentorship tips and lessons he has learned and applied to his personal career.
You started mentoring with Everwise in 2013. How has that experience evolved?
Everwise has done a great job of pairing me with people who share a background similar to mine. The past two protégés I had were emerging leaders in the tech space. This is a topic near and dear to my heart about which I can talk quite easily. I personally went through the process of moving from “engineer” to “engineering leader,” and learned (e.g. as I built my start-up) that there are many non-engineering activities critical to building a successful product beyond just writing code.
For example, it is key to understand not just what your team is building but also why. Thinking about a product from a holistic point of view – understanding not just the technical specifications but also who the buyer is, what will motivate him/her to purchase, how to delight the end-user so that they keep on using the product, etc. is crucial. By sharing these insights with your team, you first bring alignment on the main drivers of the design. You also empower each team member to make the correct micro-decisions throughout the day. This eliminates friction during development and results in a more cohesive product. Many young engineers are not aware of this important concept, so I enjoy helping them evolve in that way.
Building on this foundation, I have developed a bit of a system over the past four years and learned the best questions to ask early on to assist protégés in discovering what they don’t know or perhaps need to think about more. I find this makes the process more fun and rewarding for both sides.
One question that I recommend every mentor ask is: “What are your motivations?” It is so important for protégés to understand what truly drives their professional career. Particularly in engineering, there is a fallacy that you need to become a manager to scale the ladder, earn more money, and/or receive more recognition. In fact, maintaining technical expertise is often more valuable. Management is a more general skill – and some of the top engineering leaders with whom I have worked were not trained as engineers. It is rare but doable. On the other hand, technology leadership is becoming more and more important as a competitive differentiator (vs marketing, sales). Smart companies thus create a dual-ladder that provides professional growth for technical leaders and technical managers. This being said, in order to be technical leader, as you step up to leadership positions, you still have to acquire some business acumen, so that you align your technical focus with the needs of the business.
Finally – and this is a long response – one should not confuse leadership with management, title, or the number of people who report to you. Even as an individual contributor, you can lead by presenting innovative ideas, unique insights, and by empathizing with your teammates, coaching them, or “selling them” on your inventions.
Understanding one’s own fundamental drivers is also critical, because it is important to understand what makes you happy in your professional life. Many protégés say they want “this job,” because it is prestigious or an obvious step up. However, perhaps that’s not the right path or the right company for them to achieve their true goals based on what actually makes them happy. Whichever way, I then enjoy helping them discover the experiences they need to acquire in order to make that leap forward.
Protégés have noted that you are “an awesome mentor” and “an invaluable sounding board.” Do you have any tips you’d recommend for other mentors?
One of the hardest things to do as a mentor is to not give the answers, but rather, to make the protégé discover them. This way, the learning is genuine and deep. We have all experienced how much more meaningful it is to figure out a solution by ourselves versus having it handed to us in someone else’s words. This requires a lot of self-restraint for the mentor, because we all want to share our knowledge and get to the point. It is something I have to work very hard not to do. However, having patience with this process – seeing the protégé connect the dots and say, “Ah, I see what you’re saying!” – is extremely rewarding.
I also recommend mentors give (small) homework to their protégés between scheduled meetings. I do this so that protégés spend time reflecting in the context of their daily life between our meetings. For instance, if we’re talking about leadership, I will ask that they prepare the following for our next session: “Tell me about three leaders that you’ve worked with. What is their leadership style? What do you like about how they lead? Which style(s) do you think might work best for you?” When we come back together, using these real-life examples, we can have a more substantive and productive conversation than we might have had without context. Having six months of structured meetings with my Everwise protégés allows us to have a bit of a journey together, and homework further facilitates that.
Have you learned anything from your protégés that you’ve brought back to your roles?
In the process of working with protégés, I have come to think a lot about what it means to be a leader as CTO or VP of Engineering. Assuming the role of mentor has really helped me formalize my thoughts on this both for myself and also to share with my protégés.
The challenge of being a technical leader is that you have to lead on the technical side and the human side. Plus, you are also a member of the executive staff. As such, you need to think about the organization as a whole versus making decisions on an individual scale. You need to translate what the business decisions made at exec staff mean in terms of technical priorities. And conversely, you need to understand how developments in Engineering, whether a project running late or an exciting emerging technology, translate to the business. For example, how will they impact the Sales team?
Perhaps most notably, the thing about being the VP of Engineering is that there are decisions that only you get to make. It is not simply the role of a Director but bigger. As a technical leader in an organization, you must be thinking two years ahead and ask, “What technologies do we need to master over the next two years in order to remain competitive? Should we begin researching these today? Are we working on a framework that is too old and must be refactored out?” As you take on this strategic mindset, you are still expected to deliver on short-term deadlines and manage day-to-day tactics. For engineers who are used to writing code and spending all of their time working against well articulated deadlines, managing these unlimited open-ended challenges can be daunting.
What’s next for you professionally?
While continuing my work at Silicon Valley Software Group, I also want to take some more time to share the knowledge I’ve acquired over the past 30 years. I have a backlog of blogs I’ve been meaning to write. In addition, I have been taking some classes on machine learning, which, in some ways is very similar to signal processing, I have started a small hands-on project in this field.
I have also been considering writing a book on the “recipes” to becoming a great VP of Engineering. I would like to share the lessons I’ve learned being a technical leader and dealing with the people side having come from a technical background. The day-to-day practices of our job differ by company, project, and team. Having five people in the same room requires very different leadership from a nationally or globally distributed team of 20. “Agility” means different things in different scenarios. I would also like to share the knowledge I’ve acquired when it comes to the duality of objectives inherent in the job: delivering products on time, within budget, and staying on top of the forward-looking research necessary to have the best technology at any given point in time. I have yet to see a book that covers these topics in a comprehensive way, so I would like to contribute to the thought leadership in this area.
Editor’s Note: Some of the above answers have been lightly edited for clarity.