I wrote this out in 2022 but never published it. A colleague from back then had a lot of input into this but he wrote out a different thing, continuous to this, which with his permission I might publish at a later date. I have left my previous position recently and things I have read, viewed and heard throughout my onboarding process (in the new org) made me think of this draft. I lightly edited it for clarity, removed a couple of context-dependent and added “users” to the list of folks for whom we want to produce value (which I feel was a chance omission). Otherwise I have left it as-is, as a testament of my thinking back then.

Engineering Culture

Our engineering culture is a high-trust, high-agency, low-touch culture of professionals that strive to daily produce value for users, stakeholders, other team members and themselves.

Our end goal is to always have a dream team of professionals, best folks to work with, folks that you would have with you in your own startup. For that we also apply the so-called “keeper test” but we make it cut three ways:

Managers are always asking “is this team member a keeper”
The team member is always asking two other questions:
- Am I a keeper for this manager? Would they fight for me if I said I was leaving? Would they invite me to their next challenge?
- Is this manager a keeper for me? If invited, would I follow them to their next role? Would I invite them into my startup?

Whenever the answer is “no” to any of these questions, we are committed to communicating it clearly, understand the gaps and working together to try to flip the answer back to a resounding “yes” within a reasonable time.

We believe that everyone is replaceable but no one is fungible. Everyone brings their own strengths and weaknesses, and in long term product development, it’s the repeated learnings through many iterations of building and operating software that pays off.

End-to-end ownership of outcomes

Assume that your task is always end-to-end ownership of:

Understanding the requirements and verifying them
Finding the right place to make the changes
- We are the only part of our civilization where if things are not spelled out 100% of the time, they do not work. So everything is in the code - go read the code.
Testing the changes and derisking them in a conversation with a code owner
Driving the QA review and approval - it’s your responsibility to communicate with QA and have them test the changes
Driving the code review and approval - it’s your responsibility to find time with the code owner to review and (hopefully, eventually) approve the change
- You are your first reviewer
Merging the code and planning and scheduling the release per the team’s release procedures
Verifying that the code is running correctly in production and closing the ticket

Autonomy - unblock yourself

Read the code, it is always the most up to date source of truth.
- Ask around about what code is responsible for a thing as it may be hard to guess.
Make changes where needed:
- Changes are respectful: they are always in the same style as the rest of the code, they are never jarring, they are documented in the same manner, and follow the same naming conventions.
- Changes are tested: unit tests and coverage needs to be unchanged

Independent

You are here to:

Help your manager and the team
Learn from your manager and other team members

Hiring pledge

We pledge the following:

During this process, I have shared my challenges with utter frankness so that there are no surprises.
Our onboarding is minimalist to non-existent. Your colleagues and I will help whenever we can but you are expected to find your way around without much if any hand holding. This is not a waste of time: it promotes self-reliance and immediately inserts you into our high agency culture.
If the company and you are not a good fit for each other, we mutually commit to finding that out as soon as possible and parting ways.

Last modified on 2023-12-15