Greatly inspired by the wonderful Mike Craig’s own user manual and Ann Yeung and Christine Sandman Stone’s Grace Hopper Celebration ‘24 session “Ready To Rock: Transitioning From Engineer to Tech Leader”.

What this is

If you’ve just met me - hi! This page should give you a taste of what it’s like working with me. If you’ve known me and have worked with me, this might tell you a little more.

My Values

  • Continuous improvement
  • Candor
  • People
  • High bandwidth communication
  • Collaboration
  • Variety

What motivates me

  • People
    • Working with people I enjoy spending time with is more important than enjoying the work
  • Impact
    • Knowing that I’m working on something with positive impact for people around me has gotten me through tasks I thoroughly disliked - like spending 3 weeks refactoring ~20 Lambda functions that were using an outdated fork of Puppeteer just so that we could upgrade our NodeJS runtime

Things that take my energy away

  • Being siloed
    • Even if I’m working on something important, if I’m the only one working on it, I struggle with motivation
  • Technical projects with no clear positive business/customer outcome
    • I don’t get joy out of working on technology for technology’s sake. I have appreciation for cool tools, but I have more appreciation for the tool works best
  • Stagnation
    • I get very frustrated dealing with the same problems and not seeing any progress or a plan for improvement

Feedback from coworkers

  • “Unflappable”
  • “The one who kept things on track, but still made jokes to lighten the mood, during an incident call”
  • “One thing I like about you - you’re always customer focused”

Communication

Methods

In order of preference:

  • (For long/complex thoughts) Google Doc / Notion page / etc
    • Something that lets me comment and have discussion threads on individual ideas
    • (Please, no mid-conversation Slack essays)
  • (For voiceovers/demos) Loom/short video
  • (For important/complex discussions) Zoom or phone call
    • Zoom better, but Zoom fatigue gets to me
  • Slack messages
    • Discuss the thing and document it to refer back to later!
  • Email (ugh!)

Style

I love gathering feedback on ideas, and working through problems live.

I love meeting people and getting to know them, but I do tend to be business first and social second!

No Hello!

Seriously, no hello!

Someone: Hi! How was your weekend?

Me: I had a wonderful weekend skipping through daisies. How was your weekend??

Someone: uh, okay. I’m really just reaching out because I want to ask about fooing the bar….

Me: Oh :( let me go find you the docs you need….

I aim to respond quickly. I almost always have notifications on, and I’ll typically check my messages as soon as I get out of a meeting. If I have back to back meetings, I’m going to answer messages in order of what is most urgent. I prefer to give you some answer as soon as I can, even if the answer is “sorry, don’t know, will try asking person X” or “I need to think on this. My gut answer is x, but I’m not sure I trust it”.

If you’re up front with what you need, I can get you a resolution faster (and your message will be higher priority!).

Thoughts… so many

I tend to think through things from lots of different angles. Teammates not using new tools built for them? Too busy to test them, overwhelmed by the new functionality, or it doesn’t actually do what they need? I’ll knock on doors to try to get a sense of the real problem.

When I have thoughts or ideas that could be controversial or sensitive, I tend to “test the waters” in individual 1:1’s. I don’t generally share those sorts of thoughts or ideas in a group setting unless I feel like I have the support/data to back it up.

If you’re my manager, if you create a space for me to speak my mind, you can expect lots of carefully placed thoughts. If you hear something that “feels off” from me, and you nudge me to elaborate, you will likely get a self-reflective and candid response.

If you’re someone I collaborate with, I’ll check in to see where you’re at, and make sure you have what you need to succeed.

Feedback

Giving it - I assume good intent, and focus on keeping it constructive.

Receiving it - because of my tendency to self-reflect, when I make mistakes, I often beat myself up before anyone gets a chance to give me feedback. I’ll likely ask for advice on how I could improve or avoid making the same mistake.

Closing the loop

Got a technical problem that I couldn’t help you with? I want to know where you landed and how you figured it out!

Collaboration

Got a system design problem you’re working on? Diagrams? I love talking through ambiguous high level ideas!

Code Pull/Merge Requests (PRs/MRs)

  • I like to leave comments noting things that I think look cool
  • I’m generally 50/50 on if I test your code, or just read it
    • Depends on the size/complexity/risk of the changes and quality of unit/integration tests
  • If I think something is a “nice to have” that isn’t worthy of making you wait >= 1 day to address, I’ll prefix with “nit” or “opt(ional)”. I expect “nits” to get addressed prior to merging
  • If I observe few or no issues, I’ll approve the MR
  • If I notice something broken that’s quick to fix, or I don’t have a chance to do an in depth review, I’ll leave comments and withhold approval
  • If I notice a lot of little things, or I have a strong opinion on a change that others might disagree with, I’ll just leave comments and not approve
  • If I notice something significant such that I don’t think the MR should be merged, I’ll request changes

Strong opinions, but herd mentality

I can be very enthusiastic and have very strong opinions, but at the end of the day, I’m going to be most okay with “whatever works best for the team”, or whatever keeps the code style consistent. On a team of space-indenters, I’ll be indenting using the tab key and have a tool convert to spaces before committing.

Working

Getting direction

For ambiguous problems with low direction, I’ll focus on breaking the problems into components and creating high-level plans. If I have little information and few avenues to get more, I opt to gather feedback via “building the wrong thing”, and have a high tolerance for changing direction based on feedback.

Setting direction

I am always looking forward - whether it’s for the next thing to work on, or figuring out the highest impact improvement that can be made. I don’t like staying in the same place or working on the same kinds of problems for a long period of time.

Polish - tolerance for squeaky wheels

When it comes to things that aren’t working well - people processes, software architecture, code organization… etc - I’ve found myself on both ends of the spectrum between “just leave it alone” and “this has to change. I do any more work until it does”.

My criteria for radically modifying something comes down to:

  • Do I have a clear vision of a better solution
  • Are the workaround(s) causing more pain than fixing the problem
  • Is there an articulable business benefit
  • Is it costing the business more for this to stay the same than it would cost to change it

Something might get added to my personal backlog if it meets one of the criteria. Once a problem meets all of my criteria, I’ll start pitching my solution to people, and after I hear enough agreement, I’ll reach a point where I’m bringing it up all the time and talking about it nonstop.

Doing the important things

Reading my work experience, you might notice I have quite a bit of cloud infrastructure experience.

My favorite types of problems? APIs. Business logic. Data modeling. Data pipelines.

My least favorite types of problems? Networks, and root causing nebulous database failures.

UI? I can code it, but make sure I have some designs to go off of… this site uses a default theme for some good reasons!

However, I also hate not having a full understanding of a system… which tends to lead to me root causing problems… and draws me to neglected-but-important pieces. I won’t be the fastest coder, but I’ll know where everything is, where to go to solve a problem, what works well, and what deserves some attention.