Rick Hawes
Former Architect Fellow at Yahoo
Impactful Engineer shares the stories and journeys of women and men who are making significant impact in the software industry. The purpose of Impactful Engineer is to inspire young software engineers to see that there are many paths they can take to move forward in their careers and grow their impact wherever they work.
Profile: https://www.linkedin.com/in/rickhawes/
Interviewed by Tony Tam
Editing by Robin Pille
Reading Time: 12 minutes
[beautifulquote align=”full”]It’s not really the task that’s interesting, because any task can be made interesting. It’s how you approach the task.[/beautifulquote]
Tony Tam: Your current LinkedIn profile says you are on hiatus. Could you tell me why you decided to take a break and how are things going for you?
Rick Hawes: It’s great. It’s fantastic! It really comes back to the thing that I’ve struggled with the most throughout my career, which is life and career balance. My career started to consume everything and I became conscious of that. I struggled against it, but I choose work that’s interesting to me, that absorbs me. It’s just a natural thing that I get deeply involved in a problem. For me, it has been important to take a step back, be conscious of the need for balance, realize when I’m tired, and take the time to go off and do the things I want to do.
There’s also a pull factor. We all accumulate these lists: the things you want to do, places you want to go. I love traveling, my wife loves traveling, so we had a long list of places we wanted to visit. By taking that time to travel, you get perspective on your life and where you are in it. You need do it when you’re healthy, when you’re vigorous. I don’t think I would be able to climb Machu-Picchu if I waited 10, or 15 years. So it’s good to be conscious of that and just go do it.
TT: Given that perspective, would you have done it earlier?
RH: In fact I did do it earlier. I think maybe twenty years ago, I took a year off as well. I really wanted to spend time with my kids when they were young. That was a great decision as well.
TT: A good friend of mine and I have talked about how as men and engineers, we never take a break, we never take time off between jobs. We tried to imagine what it would mean to take a year off and just not work. But there are opportunity costs.
RH: There is a cost. I mean, there’s no doubt about that. The opportunity cost is that your career doesn’t progress as fast, and being away for a long time makes it harder to get back into things, and so forth. Still, for me personally, it was worth it. And you can do it in other ways. You don’t have to take a whole year. You can take off some two-month stretches, and I don’t think there is any cost in that. If I really needed to be career-conscious, I would do it in two-month stretches.
TT: Good to hear. I hope one day I can make that decision as well. Let’s go back to the career side of the balance. Can you describe your journey in tech and what positions have had the greatest impact on you?
RH: Okay. We’ll start with the beginning. I’m an electrical engineer. I was really into computer signal processing, and so that’s what I studied as an undergraduate. I got my first job in the plotter and printer division at Hewlett Packard. We were doing control software for the print heads. Since all the top engineers were given the assignments of designing these things, they needed somebody to write code. That’s how I got into software. It wasn’t a conscious decision that I made, but writing software was always very easy and natural and simple for me. As a career path, it turned out to be a good choice to try to do the things that no one else wanted to do.
TT: As a young person, you may often find that you are asked to do something that is not your top choice. Do you remember your mindset when you accepted that assignment?
RH: Well, of course there was that little voice that said, “Darn, I wanted to design that circuit right there.” But I always tried to fit in and do the right thing for the team, so I had that mindset. It worked out really well because I was quickly able to establish a place of expertise on that team. They would say “Hey, the software’s not working, let’s go ask Rick.” So, doing what is needed is important. I have done that again in other parts of my career. For example, there was a time when I really focused on build systems. Instead of the big fancy features, I worked on making the build system better.
[beautifulquote align=”full”]You start thinking about engineering as a system. Instead of just programming a simple Makefile, you can turn it into something much bigger and look at the solution to solve systemic problems.[/beautifulquote]
TT: Did you choose that because that had the biggest impact on the biggest number of people?
RH: No, because no one wanted to do it!
But of course I could see the impact as well. One of my mentors had this advice: “It’s not really the task that’s interesting, because any task can be made interesting. It’s how you approach the task”. That really stuck with me. The task of making build systems work was, at the time, not considered interesting. But then when you really start thinking about it at a meta level, you realize it’s really about code quality. You want to make a system that improves the quality of the code that has come into the system. You start thinking about 100 engineers checking in code at the same time. How do you make that work and maintain productivity? You start thinking about engineering as a system. Instead of just programming a simple Makefile, you can turn it into something much bigger and look at the solution to solve systemic problems.
I think those less popular tasks are really great opportunities, and as an engineer you will come across many of these in your career.
TT: That’s great! So from printers to build systems, what was next?
RH: So I went to Stanford and got my master’s degree paid for by HP. Hewlett Packet was a great company. I expected to stay there for 20-25 years. I was working in the PC division at the time that we partnered with Microsoft. I wrote Windows drivers and did a joint venture with Microsoft, so I got to know that Windows team pretty well. Microsoft then opened a location near me, and I could see that was going to be a good jump for me.
So, that’s how I ended up being the fourth engineer working on what would become Microsoft PowerPoint for Windows. Microsoft at that time was in third or fourth place in the market. It had MS-DOS, but there was something called a graphical interface that was being developed. All these things were still just coming out.
The company started to double in size and went on this exponential growth path for the next 10 to 15 years. It’s a great thing to be on a rocket like that.
[beautifulquote align=”full”]There is a maxim that you always overestimate what you can do in a year and underestimate what you can do in 5 years. If you can string together accomplishments that build on each other, it is always surprising what a person or a team can achieve.[/beautifulquote]
TT: So, I imagine that being on a rocketship, along with your skills and attitude, helped your impact grow faster than other engineers.
RH: Microsoft at that time was a very immature company, so I wasn’t really thinking about growth paths, mentorship, impact, or any of those things. It was very much like a startup. “Let’s hire the smartest people and make the greatest products” — that was their mantra. At that time, really what I was trying to do was make the best product. The opportunity was very much there: Do a good job and you’ll get recognized and get more responsibility.
TT: But there must be more to it than just doing a good job. Why did you get further along than your peers?
RH: Well, there was the work: we had a schedule and we had a list of tasks and all this stuff to get done. So one way you could approach that would be to just go through and punch out the tasks. I was productive. I was pretty fast doing most tasks, but that wouldn’t distinguish you or get you the recognition. So what I did was notice that there was recency bias in the review cycle. So I made sure that two to three months before the review cycle, I did something spectacular. I did some big thing, completely off the task, as an extra project. I used my creativity.
TT: Okay. That’s a new thing I’ve never heard of before. Recency bias, you call it?
RH: Yeah, that’s my one hack: plan it out! Do more, and choose when to do it. Make sure that you do something special before the review cycle. Then, in the self evaluation, you can write about this extra thing that you did. That can really help you get recognized.
[beautifulquote align=”full”]The values that matter are the ones you hold to when no one is looking.[/beautifulquote]
TT: So how did your journey then lead you to Yahoo?
RH: I had a manager that I really worked very well with, and I ended up following that manager to Yahoo to take an excellent opportunity there, though it was quite a different role than what I had done before.
TT: That’s a big statement. Tell me more about what makes a manager so great that you would be willing to follow them to a new company.
RH: I think what makes a great manager is a core set of values: Doing the right thing both for the company and for the person. A company can put a lot of pressure on managers to ignore the individual situations and blindly apply policies. For example, they might force a bell curve on performance reviews. Many managers will just throw their hands up and not try to fight for their people. But the manager I followed to Yahoo was able to understand each person as a human and understand how to factor in a personal problem where someone had to take leave, rather than just fit the bell curve. The values that matter are the ones you hold to when no one is looking.
TT: It seems like you care about managers who have integrity and great values and care about people as humans.
RH: It’s so important, and I know from my own experience that being a manager requires a different set of skills and ways of thinking.
I was asked to be a manager for the first time at Microsoft. I didn’t choose that role, I was pulled into it because the team needed a manager and they asked me to do it. That’s actually happened to be about half a dozen times. Even though I didn’t ask for that role, I’m really grateful for that experience. I feel that getting that experience as a manager can really help you even if you go back to being an IC.
I am an example that proves that you can zig zag between leading teams of up to 100 people and then going back to being an IC on that team. Maybe some people are naturally attracted to one role or the other, but I’d encourage everyone to try out both sides. You will definitely gain perspective as an IC by going into the manager track. I think I was more successful at Yahoo because I could relate so well to the managers: I understood their pressures, what they have to think about, what is important to them. It also makes you a better influencer.
TT: So how did your career and your influence evolve while you were at Yahoo?
RH: So, I joined Yahoo as an IC6, Principal Architect, where I had the role of a thought leader for the technology behind Yahoo Mail. At Yahoo, I was part of a team who all were expected to think like architects. There was a Chief Architect who acted as a mentor and helped me to build a different set of skills. At Yahoo it was like the whole history of the Internet was kept there in their old legacy code, so it was a great place to learn from examples about systems and to think about how larger systems work together and how to do long-term technical planning.
TT: So being an architect is more convincing, planning, thought leadership, influencing as opposed to coding.
RH: Yeah, and you’ll find that you can only write so much code, right? Some code can be really impactful, so I could see sticking with the code. At Yahoo, they made it clear that you would have more impact by working to influence large teams. For example, most companies divide into independent product or feature teams for innovation and execution speed. Decentralization has many benefits, but one possible downside is the development of independent data warehouses. Data fragmentation leads to many ills and missed opportunities. It’s the job the architect to see where teams should work independently and where they shouldn’t.
[beautifulquote align=”full”]The people who had most influence on me as mentors are the ones that demonstrated through their values and their work that they were top engineers.[/beautifulquote]
TT: Who are the people who have had the biggest impact on your career?
RH: The people that really most influenced me are the ones who set an example. There was one engineer mentor in particular who asked me questions that I still ask others to this date. Overall, the people who had most influence are the ones that demonstrated through their values and their work that they were top engineers, and those were informal mentorships where I really just observed what they did.
TT: You mentioned that you have a few questions you picked up from one of these mentors that you now ask the people that you mentor. What questions are those?
RH: One of the questions that particular mentor asked me was, “What’s your brand?” Back then, I didn’t understand that question. What he was asking was “How do people perceive you? What do they know that you stand for as an engineer? What are your core values?” Honestly, I had not given any thought to that. He helped me to see that if you are self-reflective about who you are and what you trying to project, then you should be able to answer that. I said at the time, “I have a lot of values!” He said “That’s your problem. You have all these values and they are all good, but you have to choose three of those to start projecting them, and that becomes your brand.” I found that exercise really helpful and I thanked him for that.
I still think about it now and continue to ask myself these questions too. For me, this exercise helped me discover the importance of saying no. Sometimes you have to say no to projects that are attractive because you have a limit. I’ve figured out my priorities, and that means I’m definitely going to say no in order to stick to those. For example, I took this hiatus. I know my priorities now are that I want to travel to these places. So, even though I do like working, I have said no a lot more, and I think that’s a good thing.
TT: What aspects of your career have surprised you the most?
RH: I guess the biggest surprise is when projects fail and companies fail. I go in expecting success, because I have an optimistic point of view. Most of my mistakes are due to the fact that although we were working on good ideas, they weren’t strong enough in the context that we were in.
I remember in particular a project that I worked on in the middle of my career that was a really massive product failure. I had worked really hard on this product and I was so enthusiastic about it, but with the economic situation in the industry at that time, it failed. It was a classic case of over-engineering: it turned out we were building a skyscraper and we really should have been building a two-story building.
Experiences like that one have given me perspective. Perhaps, the most import is that project failures also provide opportunities. You can learn from your mistakes and become wiser. You also have a chance to clarify what is important to you or your team. This knowledge is very powerful for execution as you go forward. Finally, you usually have a chance to try again and succeed. Once you succeed, you have a compelling story that can shape the culture of your team.
RH: There is a maxim that you always overestimate what you can do in a year and underestimate what you can do in 5 years. If you can string together accomplishments that build on each other, it is always surprising what a person or a team can achieve. I’ve seen this adage play out multiple times. Early in my career, PowerPoint had zero market share, but over many years, the team was able to make it nearly ubiquitous. Yes, I’ve heard of “Death by PowerPoint,” but the idea that people would mock it like this is amazing given the obscurity where we started. Likewise, I’ve seen companies go from hobbies to the Fortune 100 companies. When you can make steady progress over many years, the results are always surprising.
Join Our Pre-released Reader Program
Leave feedback specific to interviews you have read and you will receive an invite from Tony to join our Slack channel to be part of our beta readers group for pre-released interviews and engage with other software engineers.
We ask our beta readers to give us feedback.
- What 1-3 things did you learn from the interviews?
- What 1-3 things are you going to follow and change your own behavior because of the interviews?
- What 1-3 things did you find not helpful at all, or changes to the interview (longer shorter), questions that should be removed or added
Fill out this Google Form to send feedback and read 2 more behind the scenes questions
(I’m experimenting on not using comments)