About Me #

Who I am #

Husband and Dad of two small boys. I like video games, books, board games, legos, and playing with new technology. I hope to get my masters in mathematics eventually.

What I do #

I am a dedicated engineer for engineers. I love working on solving engineering problems, clearing brush, and doing what I can to help folks live their best lives and do their best work (usually in that order).

How I Work #

Working within the art of the possible, taking consensus driven actions, and running toward fire

Receiving Feedback #

Feedback is a gift. I encourage, anticipate, and desire regular feedback on how I can improve.

I am most receptive to feedback privately in a 1-1 with specific examples of behaviors to keep, improve, start, or stop, or otherwise change. In particular, if you are able to tie this feedback to how it impacts my growth and ability to support others it is helpful.

Communication and Work Style #

Communication Style #

Chipper and Conversational. I'll probably start a conversation by saying hi and asking how things are going, even if I need something or if there's an urgent matter. People first.

Slack Management #

For everything, I consider slack my main communication platform. Please slack, over email, if you want a response. Sending me an email is the best way to guarantee I will not respond. :) I try to schedule messages to send during the workday, but sometimes I forget.

I manage slack a bit like its own todo list--flagging messages with reminders, and following up when I've got more bandwidth or am not in some heads down work.

I try to go computers off between 4:30 PM and 8:30 PM CST and on the weekends--this is dedicated family time. If urgent, text or page me.

Meeting Preferences #

I live by the phrase 'it takes a heck of a meeting to beat no meeting at all'. I encourage regular reflection and feedback on whether or not we should be having a meeting.

Having a TLDR or an Objective for a meeting going into it would be great. Any documentation I can review is best attached to the meeting itself.

Documentation #

I encourage a writing culture and recommend all related docs are as close to their relevant reference as possible: code docs in repositories, meeting docs attached to meetings. jira as a source of centralization for reference docs for tickets and tasks.