Heavily inspired by http://randsinrepose.com/archives/how-to-rands/

Hello there! If you’re reading this, I’ve either steered you towards it, or you discovered it on your own — either way, you’re probably curious how best to work with me.

About Me

If you’ve already read this section somewhere else, feel free to skip down to the “Understanding Me” section.

I attended Cal Poly San Luis Obispo to achieve a Bachelor’s degree in Computer Engineering (emphasis on the Engineering part — more on that later). Cal Poly heavily emphasizes Learn By Doing, which is a value I have 100% internalized. Don’t know how to do something? Want to know the best way to learn it? Go do it! I graduated in December of 2005, already employed full time by Apple Inc (then Apple Computer Inc).

The first 3 years of my career at Apple, I was a Performance Engineer. I lived and breathed making things faster, cheaper, and more efficient (both HW and SW). This has left an indelible mark on my soul, and I currently (much to my wife’s chagrin) still apply the patterns of behavior I learned here to everything in my life. I had the awesome opportunity and benefit to experience a few amazing things during this first 3 years (including my Internship there):

  1. The Executive Speaker Series (interns only) @ Apple — where I got the privilege of hearing Steve Jobs, Jony Ive, and Bertrand Serlet (to name a few) speak directly and candidly to all the interns. During this series, Steve Jobs himself made it a point to underscore the most — indeed the only important thing at work is the people. Jony described accessible design (meaning taking machines and making them more accessible to humans on an emotional level), and Bertrand talked extensively about design patterns (boring..).
  2. The PowerPC to Intel transition. This happened right under my nose while I was an intern, though I had very little to do with it.
  3. The First iPhone. I was actively involved towards the end of the project, in my capacity as a Performance Engineer, porting aspects of the xnu kernel and performance toolchain to ARMv6. Up until this point, I was only familiar with i386 (personal and college coding-life), and a tiny bit of PowerPC (3-months of internship). I had a front row seat for how one of the most innovative companies in the world does a v1 product from scratch, in a market area they are not immediately familiar with.
  4. The i386 to x86_64 transition. This one I was actively involved with, and was my last project as a Performance Engineer. At this point, I was learning less and less day to day, and once they decided to absorb Shark into Instruments (a vastly inferior product, at the time, and maybe even still today), I decided I was done and sought out a new role.

After this first 3 years, I stopped learning new things, and desired a new, more challenging role.

I transitioned from Performance to Firmware. I moved over to the iPod Firmware Team, and supported every single iPhone from the 3GS to the 6S / 6S Plus, as well as many iPods, iPod Touches, Nanos, etc.. In this role, I was initially Just Another IC™, then a Tech Lead, then a Team Lead, then a Manager (~2 years @ Apple before leaving). I did device drivers for bare-metal firmware (EFI-based), I implemented an EFI multi-core/SMP framework, I worked on new silicon projects 6 years in a row, ported EFI to ARMv8 (64-bit), including writing the bootloader for our environment from scratch.

Ultimately, I ended up working on the first Apple Watch. I was there from the initial brainstorming sessions, to just prior to the announcement
(August 2014). This was another “v1” product at Apple, in an area they weren’t too familiar with, and was an utter disaster execution-wise (a stark contrast to how iPhone v1 went). I largely credit this project, and the director-level leadership of my Org (at the time) with my burnout and my ultimate choice to leave Apple.

That covered about 9.5 years. Apple moves frickin’ fast, and they do it well.

After that, I joined Pearl Automation (then under the pseudonym Kamama — you can probably still find me wearing that t-shirt here and there), without pay / pre-funding, to help define the v1 product we would ultimately ship there: Pearl RearVision. I joined Pearl to flex my leadership and entrepreneurial muscles — I created, recruited, and lead the Firmware Organization @ Pearl, and created and supported (simultaneously) 2 hardware products (the Car Adapter (Embedded Linux) and the RearVision Camera Module (ThreadX over bare-metal)). Not to mention all the integration with the two smartphone apps (iOS and Android), and our log collection and OTA update web backends (AWS). I also built our continuous integration system from nothing. We did all this over the course of 18 months, from scratch, with only 6 people on the Firmware team (including myself).(Sidenote: we did all this at Pearl without the team working nights or weekends more than 1 single time.)

After Pearl imploded, I decided to move to Oculus to lead a team working on the Computer Vision stack and supporting the new products. Also, I wanted to see what benefit my product-development experience and perspective could have on shaping the Core Tech Org, Oculus as a whole, and ultimately Facebook’s push into consumer hardware (a tenuous prospect, given prior to this their main expertise has been pure software / websites).

As you can tell, I’m driven. I have some good experience, and a lot of it varied across different mindsets and disciplines. And I’ve built stuff (both product and teams) from nothing, successfully.

So that’s me and my background in a nutshell.

Understanding Me

At Oculus, my team recently participated in a training session based on the Stand Out framework, by Marcus Buckingham. Very powerful stuff, I highly recommend it. Easily worth the price for the book and the assessment.

Obviously people change over time, and one big change I’ve noticed (retrospectively) occurred sometime around my jump into management. Or maybe even before that when I was Team Leading. Either way, I think I started being less of a “Pioneer” archetype, and more of a “Connector” — linking up people with people, things with things, or people with things — all with the hope of building better things. 1+1=3 is the mantra here. I became a multiplier when I took on leadership.

One thing that has stuck with me is my passion for creating/innovating. Stand Out also pegs me as a “Creator”, which I completely identify with. Creators love to take things apart, understand how they work, and reassemble them in new ways that make them better, more powerful, and/or more performant. That’s totally me in a nutshell. It’s also another word for Innovation, which may explain why I thoroughly enjoyed (for a long time) working at Apple. They put a high premium on innovation.

My 3rd category that Stand Out called out was “Stimulator.” It also mostly fits me — I feel the emotional pulse of a room, and it can and does affect me. If it’s too low, I try things to bring it up.

A recent example at Oculus is my desire to introduce more humor into everyone’s day-to-day in CoreTech. I brought the Party Parrots over, and there’s a healthy level of snark in our team chats now. So much better!

What do I do best?

I’m always looking for better ways of doing things. I love theories and concepts. I ask “why” a lot.

I do particularly well working on a small design team, working separately from the rest of the company, being paid to investigate new ways of thinking or doing. Pair that up with my love for products and firmware, and I think you can see where this is going.

Guiding Principles

People matter. A lot! Who you work with is perhaps even more important than what you work on. Both in performance and personality. I heavily bias towards hiring and working with people that have an intersection in the following three categories:
Smart, Gets Shit Done, and Knows How To Have Fun.
More on that here. We had the linked Venn diagram printed out on the fridge at Pearl.

Leadership at All Levels. Leaders are not born — it’s not some talent that you either have or don’t have. Leaders are grown, or perhaps more appropriately trained and supported. This happens (in my mind) mainly by fostering Ownership, and giving people the tools and resources they need to most effectively wield that ownership — how to work cross functionally, how to run an effective meeting, how to communicate, how to influence, how to delegate, etc. In practice, this means if you’re on my team, you may end up owning some component of our system. Don’t freak out, this isn’t permanent, we can change ownership if it’s not working out.

Bias towards action. Analysis paralysis ticks me off. Just make a decision, especially if the choices are remotely close to a 50/50 situation — you have a 50% chance of being correct, but 100% chance of being later than you are now, if you can’t just pick a direction and go. Often, it’ll take less time to make the wrong decision, find out, and revert/pivot than it will to allow yourself to be stuck in analysis paralysis for too long. Do note that this is partially against my nature, as I also like to analyze things. So this hasn’t come naturally to me — it’s something I have had to work on.

YAGNI. It stands for You Aren’t Going to Need It. How it looks in practice is this: when you design your architecture for Project X, you plan for 2 years into the future in terms of what the architecture can support, but don’t actually spend too much time building the implementation for future stuff. Let that happen organically as you need it. Don’t over-complicate stuff now, you’ll hate yourself for it later as you’ll more likely do it wrong if you do it now. A corollary to this is Future Me will be Smarter and Solve This Better.

Ship It. Back in my background, I wrote that I’m a Computer Engineer, as opposed to Computer Scientist. It was a common joke with my peers (both CPEs and CSs) that the difference is this: Computer Engineers ship stuff, Computer Scientists quibble tirelessly about what algorithm is best for the use-case and miss the deadline. Don’t do that. Ship it, even if it isn’t 100% fantastic under-the-hood. You can always improve things. This stems from the fact that my first team at Apple got our new updated Performance Tools framework about 80% done twice and the then-lead pushed hard to scrap it all and start over twice. Needless to say, I’m won’t support doing that again, and I probably won’t work with that person again. Anytime anyone utters the words “rewrite” my hairs stick up on my neck. I have yet to see something that truly needs a rewrite, as opposed to some smaller refactoring.

Focus. I believe in the power of focus. Both in how you work and what you work on. The times in my life when I experienced burnout the worst were the times when my job suffered from a lack of focus. When I get going on a task or a project (like writing this), you’ll find I will ignore emails, your messages, messages from my boss, messages from my wife asking if I remembered to feed to dogs this morning — everything becomes secondary. If you need to interrupt, that’s fine, but expect to do it in person. And be prepared for me to ask you to wait a couple minutes until I can find a good stopping point (and trust that I will strive to do that within a couple of minutes). That last little bit of time you allow me to tie off my current work saves me 25 minutes of time later restarting my mental context of what I was doing. Feel free to take this as a model and apply to your work-style as well — you’ll probably find some benefits!


I’m going to be late. It’s not because I don’t value you. I don’t buy that. As a manager, I have meetings all over campus on a variety of topics. I’m recruiting constantly, so my schedule is nuts. Chances are, I’m going to be 5 minutes late to your meeting. That’s because I just walked .25 mile from the other end of campus — you can deal with it. This is also why I fill the first 5 min of my team meeting with Banter, so I’m not tempted to give people a hard time if they’re also coming from another meeting and also end up a couple minutes late. Cal Poly knew this when they built their class schedule, so all classes started 10min after the hour, and ended on-the-hour. This allowed people 10min to cross the huge campus to their next class without being penalized for using their feet as their mode of transportation.

Ask, don’t tell. I’m stealing this from Rands, as it erks me too. “Hey Ryan, can you help with X?” goes over much better with me than “Ryan, do X.” It’s a lot easier to lead me than it is to push me. I’ll resist (even if the direction you’re pushing me is the right one). Again, I’m working on it, but it’s worth it for you to know.

I swear. Sorry, but I get excited about stuff. Sometimes that results in me swearing (positively or negatively) about something. If it happens to be code you wrote, I’m sorry, but please don’t take it personally.

Opinions are not facts. Don’t try to pass them off, especially if I know the subject area, that’ll piss me off. If it’s not too large of a meeting (see point 1), I’ll probably call you out.

Driven, but not overworked. I’m protective of my family time. This is why I disconnect when I get home from work. If you need me available for some potential emergency or late night guidance, you’ll have to plan ahead and ask me before you need it.

Putting it into Practice

We’ll have a 60 min staff meeting each week, where we’ll first share weekend stories/banter (~5 min) to build some shared experience and a better understanding of each other. After that, I’ll give you what top-down Org-level updates I’m aware of. I’ll then give you updates that relate to our Team directly. Then the product updates (if the team supports products we intend to ship). Then we usually have time to bring up issues of substance that affect the team, our Org, or $COMPANY as a whole.

I expect people to own their area, at all levels. So you’re an E3 or E4, so what? I still expect you to own each of your tasks and the communication associated with it. You don’t have to be good at it (yet), you just have to work on it. This is intending to build some leadership skills in you, that you’ll need and maybe even be thankful for later on.

I do not expect you to work on the weekends. There may be rare exceptions, and in most cases you’ll know ahead of time when this will happen. I myself set my phone down on the charger and leave it there once I get home, or 6pm, whichever is earlier.

Come to me when:

You want someone to spearhead a cross-functional HW/SW effort. I find this stuff engaging and fun, and love to do it. Plus, I think I’m fairly good at it.

You want help solving a problem I’ve solved before, or you’d like to pick my brain. I love helping others. I recently did some coaching sessions and one tidbit that came out was this: my coach asked “What makes a good day for you?” My response: “any day where I help someone, somewhere across Oculus, do something or learn something new.”

You have something existent, and you think there might be a way to make it better. Assuming you have time to allow me to dig in, analyze the problem, and see it in a new light. If you need the answer now, find someone else. If you just want to know “if” it could be better — the answer is “yes” nearly always.

Don’t come to me when:

You want a well thought-out solution to a complex problem in 5 minutes. First of all, you’re dreaming. Second of all, I’m sure there’s someone more familiar with the domain expertise who would be better to ask if you need the answer now. If you’re willing to wait for me to formulate a well thought-out answer, though, I’m happy to help.

Manager, CoreOS @ Apple