README

What is this?

The foundation of any healthy relationship lies in solid boundaries and clear expectations. This document is intended for people who work with me or who are considering working with me, to introduce my way of being as an engineer and technical lead and to tailor expectations around my way of being in professional relationship.

Therefore, the "you" in this document refers to those who work or may work with me in a professional or collaborative relationship, especially in the practice of software engineering.

Speaking of clear expectation setting, it should take about 10 minutes to read this.

My Professional Background

I'm a software engineer with a passion and specialization in platform engineering: building the sets of services, tooling, and standards to empower engineering teams to build more consistent, secure-by-default, observable, operable solutions faster, with minimal cognitive load.

I'm effective at this because my background began in systems and network administration, which gives me the experience to support the outcomes both operators and engineers are accountable for. I've worked for early and mid stage startups, for small and large non-profits, and for giant companies like IBM/Red Hat.

What I'm passionate about in platform engineering is the enablement of joy and ease among teams that build on platforms, because people are what it's all about. The most valuable thing an effective company builds is relationships; teams with authentic, compassionate, supportive relationships among colleagues create superior work product as a consequence of those relationships. The outputs of platform engineering are tools that support such cultures and help them thrive.

What I View My Role to Be

The term "10x engineer" has been tossed about in a million contexts, but in practice what I think people get wrong about the concept is they imagine that person creates 10x the output themselves. I think the way I as an engineer scale my impact is through enabling and motivating other engineers to do our best work together.

As a high-level individual contributor, I do view my role as guiding the direction of work-product and supporting the teams that build it. High-level ICs have an instrumental role in creating and preserving the team's sense of psychological safety: to ask questions, to take risks, to name struggles, or to point out potential pitfalls. The team's confidence that they have the knowledge, trust, and permission they need to deliver comes from the quality of my leadership.

You should be able to rely upon me to support you in being your best in your work; to receive your thoughts, questions, and concerns with compassion, patience, and respect; to listen to your needs and your experiences; to advocate for and champion you outward to the rest of the company; and to genuinely care about you as a human being.
I'm a human being, flawed and wounded, growing and healing - as are we all. I view it as my job to take responsibility for my emotional experiences; to never back down from an opportunity to grow as a person, even when it's hard; to apologize and learn from my mistakes and failures; and to model the authenticity, humility, and responsibility as a beacon of permission to others.

You should be able to rely upon me to do my best every day, acknowledging that my "best" will change from day to day; to own my emotions and my experiences; and to grant you the same grace and latitude to be on your own healing and growing journey, meeting you with curiosity, compassion, and acceptance.
As an experienced builder of interconnected systems, I view my role as to bring wisdom and foresight into the design of solutions, advocating for solutions that solve present problems in ways that set the team in a better position to solve what problems come next, but still cultivating ownership and innovation from the team. It's my job to know where to allow the team to make mistakes that are learning experiences or to bring their own creativity... and where it's best I stand firm in how I know it must be done.

You should be able to rely upon me to support your learning and growth, to lend my experience and wisdom to your benefit, to share ownership and accountability for our joint efforts, and to be in my integrity in ensuring the quality of our work.
Whether my customer is an internal user of a platform or an external user of a product, it's my job to understand the needs and experience of that customer, to bring compassion for it, and to advocate for it in the design and development of my team's work.

You should be able to rely upon me to remain dutiful in my service to our stakeholders, whoever they may be.

What I Ask of You

To me, freely-given informed consent is the foundational ethic of interpersonal relationships, and in various READMEs I've seen, they have a section entitled "What I Expect from You." That's not my way; I don't wish to hold you to expectations you did not consent to.

So please consider these as my requests for our relationship. They are things I need to be at my best in showing up for you.

I ask you give me direct, honest communication. When there are things to be said you're afraid might upset me, hurt me, or create conflict between us, I especially ask this of you. Late in my life, I came to understand I'm autistic. I often simply do not recognize the existence of what's not clearly or directly said. I do best when I have all of the information about what's present, and I don't take criticism or negative feedback personally. I care deeply about you and if there's something to be cleared between us and disrupting the flow of our relationship, I very much want us both to feel resolved about it.
I ask that you partner with me in helping manage the allocation of my time. Paul Graham once noted that time allocation for meetings and synchronous human relating requires very different strategies than time allocation for creative processes. Writing code comes best to me in a hyper-focused flow state, which takes time to drop into and time to transition out of. If I have a 30 minute scheduled conversation at 10a and a 30 minute scheduled conversation at 11a, the 30 minutes between 10:30a and 11a will be challenging for me to extract a lot of productive use from. The more we can protect uninterrupted blocks of time to allow me to drop into a flow state, the more I'll be able to be present for meetings and be fruitful in my creative tasks.
I ask that you join me in agreeing that our connection and relationship is primary and that the work we do together is an off-shoot of that relationship. The times in my career where you and I have made our focus the work, we've both let go of bringing care for one another and each other's needs, putting the work before each other, and our relationship and the work have both suffered. When we have meetings, let's drop in together and really be present. When we're problem solving, let's take all of the time we need for us both to feel complete and trust the solution that emerges will be the best. Impatience and deadline pressure make quick adversaries of colleagues. Our partnership in this work feels more important to me than the urgency of the work itself.
If you are my manager or director, I ask that you make transparent both the expectations that are had of me and the standards against which I will be evaluated in my work, so that we can have alignment and agreement. I ask that you do everything in your power to set me up for success, for as long as I believe I can be successful, I will bring my whole self to my team and my work. Hierarchy is unfortunately a necessary part of corporate structure, and with hierarchy comes power differentials, but I ask that to the greatest extent possible you treat me as co-equal parts of our company with different resposibilities for its success.
I ask you to consider creating a similar document for yourself or, if you already have, to share it with me. I care about what motivates you, what fulfills you, what discourages you, and who the whole person you're bringing to this work authentically is. You're a whole world unto yourself, and I feel curious to know what it's like to be you, so I can be the best version of me for you.

Northstar

I want the result of our work to be joy. In my favorite book, "Zen and the Art of Motorcycle Maintenance", the protagonist/narrator tells a story about his experience as a technical writer (condensed for usage here):

"I've a set of instructions at home which open up great realms for the improvement of technical writing. They begin, 'Assembly of Japanese bicycle require great peace of mind.' At first I laughed, but there's a lot of wisdom in that statement."

"Peace of mind isn't at all superficial, really," I expound. "It's the whole thing. That which produces it is good maintenance; that which disturbs it is poor maintenance. What we call workability of the machine is just an objectification of this peace of mind. The ultimate test's always your own serenity. If you don't have this when you start and maintain it while you're working you're likely ot build your personal problems right into the machine itself."

"The test of the machine is the satisfaction it gives you. There isn't any other test. If the machine produces tranquility it's right. If it disturbs you it's wrong until either the machine or your mind is changed. The test of the machine's always your own mind. There isn't any other test."

The software we build is a tool for our customers - be they developers on a platform or end-users of a product. Doing our work well means bringing satisfaction, joy, and tranquility. I want to create that with you and the chance to do that gets me out of bed in the morning.

Software Engineering Principles

There are principles I hold to in the software I design and there are principles I hold to in the practice of software engineering. I'll share them both.

In designing software and systems for platforms, you'll often hear the following maxims from me frequently:

Good solutions make simple things simple and complex things possible. A good solution to the problem we're solving for our customers makes addressing the overwhelmingly common use case as simple and approachable as possible, while still allowing more complex and distinct variations of the problem to be addressed within the design of the solution. If there doesn't seem to be an overwhelmingly common use case, consider we may not fully or accurately understand the problem we're trying to solve.
If the easiest way to do things is the right way, people will do the right thing automatically. When designing platform, we're creating solutions to problems in building, deploying, and operating software that are orthogonal to the actual problem the software is meant to address. Having to address these orthognal concerns creates cognitive load for software engineers, and they would generally rather those problems be solved for them so they can focus on their actual mission. If our solutions are the easiest way for teams to solve those orthogonal issues, we won't have to enforce uniform adoption of the platform; teams will naturally gravitate toward our solutions because of the ease it offers them.
Don't hand them a foot-gun. As platform engineers, we understand our tools, the problem they solve, and the nuances involved in them both. Teams using our platform do not and should not have to. If our tools require nuanced understanding to operate without operational or security hazards, we've not done our job well.
The output of every incident response cycle should be more automation. Operational and security incidents happen, and in our discipline we have incident response procedures to triage, understand, and rectify the defects. However, incidents also teach us about a failure state of our systems we did not adequately anticipate or mitigate. Relying on humans to simply not make the same mistake again almost certainly ensures they will. Every incident response cycle should result in automation informed by our learnings to proactively prevent similar incidents in the future.

In the practice of software engineering, I believe in:

Ownership - I trust you to hold integrity in the quality of your craft. When we each have the opportunity to own the problems in our domain and the design of solutions to address them, I trust our sense of personal integrity will naturally lend us to do our best work. With ownership comes accountability; I expect to be held accountable for my wins as well as my struggles, and I will extend you the same expectation.
Learning - When people ask me if I like my job, I tell them that I like learning something new every day. It's not always learning a new tool or technology. Most of the time it's learning though my work: whether a particular solution is the right approach, whether a particular experiment was fruitful, whether I understood the problemspace correctly, and whether the assumptions in my designs were correct. Every conversation, every commit, every log line and metric - each are a chance to learn something and improve on what's already been done.
Sustainability - I believe that the simplest definition of company culture is the set of behaviors that earn you praise and get you ahead; what a company rewards, it gets more of. Companies that praise employees who pull all-nighters or who work through their weekends create a culture of heroes and burnout, breaking human beings to compensate for failures of planning and leadership. Nobody can give 100% all of the time. Let's give each other our best but not our all.
Humility - I will approach my work with the expectation I don't know everything there is to know. I'm grateful for the opportunity to learn and discover. I'm grateful for thoughtful reviews of my code and my designs. I know that I need the people around me to support me if I'm to succeed. I'm not the main character of our company's story, and none of us are.

Known Failure Modes

I'm autistic, and I did not discover this until my 40's. I have in my decades unconsciously developed a great number of masks: strategies, personas, and scripted ways of being that through experimentation I've concluded diffuse social awkwardness and make me welcome among others. I'm still learning what they are and trying to be intentional about what I do with them. I'm also very sensitive and caring person, and I want to put others at ease. But I often miss social subtext, particularly in group settings or in relationships with a power differential. I carry a low level anxiety consistently about what social cues I've missed. I don't wish for this to create any awkwardness between us.
I try every day to keep my focus on my relationships with my team and my customers, not on the code we're working on. When my focus shifts to be about the code and shipping the solution, I can become insensitive to my team and the impact of my words and actions. Deadline pressure and urgency make this failure mode more likely. Having it called out by my team or my manager helps me reset.
In challenging times, I'm not shy to say what's unpleasant to hear because I trust naming it is the best way to address it. I always do my best to be intentional and careful with my words in doing so, free of judgment, assumption, passive-aggression, and sarcasm. I am never "brutally" honest. But at the same time, it can give those in leadership the impression that I'm sowing discontent, when my intention is to strengthen connection, deepen trust, and facilitate healing.

Outside of my Day Job

I co-founded a non-profit called SeekHealing, and I continue to serve on its board and devote a great deal of my time toward it. SeekHealing focuses on social health: the healthiness of the social context and the relationships in one's life. Social health is vital for mental health, and its absence is marked by trauma, loneliness, suicide, addiction, self-harm, and more. SeekHealing creates intentional spaces where people feel safe enough to connect deeply with each other and provides training on how to bring more authenticity, radical compassion, and connection into one's own relationships. We work to create a world that people acutally want to live in, rather than escape from.

I live in an intentional community just outside of Asheville, North Carolina. I feel deeply connected to the land we're on, and I'm continuing to learn what stewardship of it involves.

I derive a lot of pleasure from cooking and watching others enjoy my food. Live music, particularly EDM, fills my cup and I go to music festivals as often as time and money allow. I enjoy photography but struggle to make time for it. I also enjoy writing, as I'm sure you can tell from the length of this README.

EOF

Thank you for taking the time to read this. I'm grateful for your curiosity and attention, and I hope it serves us both in our relationship.

(Go back)