my cto .readme

Me in an ice cave for clicks.

Well, it’s been an insane few weeks. We announced our $3.5 million seed raise (essay coming when I catch a fucking break), I’m working to completely become sober (sucks ass), and parts of our product roadmap died on arrival when the Trump admin took office.

We also lost a team member in a particularly hard way. I can’t and I won’t really talk about it, but I cannot understate how much this broke me as a “manager”, and also as a person. Not just sadness, but straight up sobbing at my therapist’s for weeks.

Startups are complex. There is a fuck ton of money, pressure, and time spent together. Some people resonate cohesively, and others explode, and will take you out with them. You need to really know who you’re getting in the plane with — who you’re trusting your company with, and how they think about what you need to do to make this worth their while.

I’ve had to think a lot about team fit: what defines who makes someone ‘good’ for a team? How does someone even find a company where they fit in? It’s the beginnings of these questions that’s leading me to enforce a mandatory .README at Faura.

In a startup engineering environment, technical skills don’t matter (as much as soft skills). Being coachable, honest, and having a good reputation with your team is everything. If you can write shit code and take feedback to make it better, that’s way more beneficial than someone who can write great code but fights with the team 24/7.

One technical blog put it well, “It doesn’t matter if you’re right, if you can’t convince anyone of it”.

That’s great that we know that, but how do we actually screen candidates for that flexibility? The average job interview is about exchanging mutually agreeable buzzwords. We also don’t want to rely solely on referrals and inbound, because networking nepotism never builds a cohesive team.

One way we’re aiming to change the hiring process at Faura is by reducing the strain of our technical assessments. Instead, we’re requiring all potential candidates to go through the .READMEs of the entire Faura team, and to submit their own as part of their final round. The goal is that whoever is joining knows exactly what they’re getting into, and vice versa.

It also, in a time when software engineer interviews are continously run on ever-increasing mountains of requirements (such as Leetcode, take home interviews, DSA questions, and more), mandating something that tells us more about you beyond the code lets us get to know the people we’re actually working with.

Startups are basically guaranteeing that you will be fighting for your financial freedom for a certain number of years, and that you and everyone else on your team need to work in co-ordination to reach a coherent sense of movement. A startup team is not like a FAANG where if a junior engineer doesn’t pull his weight, it can easily be passed off to someone else and hidden.

For the next couple of positions, we’re adopting a mandatory reviewal of our .READMEs, a draft of your own, and an easy take home that could be re-adapted into a portfolio project. Then, we sit in a call where we extend the capabilities of your take home as a mock ‘System Design’ and technical skills assessment round, and discuss the .READMEs.

There is no perfect interview process for software engineers. Your own organization has to figure out what needs to be ‘maximized’, and opt for that. You should never just rip another company’s process, because a hiring process should be specific to your engineering team. It will never be one-to-one with what another company needs.

I’m going to adapt and change this process as we go, and for now — it feels good.

For posterity, I’m including my mangerial .readme below.

You can also find it live, in all of its glory here.

return AMANDA’S .README

Outside of work, I:

think about technology all of the time. I LOVE planes (Boeing is enemy #1), robots, boats (cargo ships / car carriers / LNG tankers specifically), trains, and more. Best inventions of our earth are the Space Shuttle, and the Airbus A380. I think about software, design, hardware, social media, computers, machinery [from small kitchen appliances, to mini-splits, to car transmissions] continuously.
Write essays about the impact of tech on our world. I also love poetry [Richard Siken is my favorite poet], philosophy, ethics, and non-fiction books. I spend most of my time outside of Faura reading and learning about the world. Share cool things with me :-)
Built a tiny house out of a jail trailer from the 1970’s. I love construction, working on cars, designing my own clothes and focusing on fashion, or just doing anything creative.
Get involved with a lot of non-profit projects. I come from the non-profit world, and really enjoy giving my time to other founders or orgs to help them better understand technology.

You should know that I:

I am on the autism spectrum! You may have not guessed, but it looks different in women than in men — so I might not be similar to the people who you know that have it. Please don’t make comments such as, “No one can tell”, “Wow, my friend’s cousin’s lizard has autism”, “Do you think the vaccines did it”, and more. I’m letting you know for the sole reason that it changes how I communicate, and manage.
hate being on unnecessary calls. I also hate being called without notice, unless it’s serious or an emergency. If you need something or want something, please schedule it more than 24 hours notice in advance. That being said, it’s totally fine day of to say, “hey I need time to discuss this more in detail”. I would like to keep all of my calls relatively bundled and predictable.

Traits I value in others:

Attention to detail, and holding a strong standard of workmanship.
Brevity, and the ability to know what information is correct on hand.
Strong research skills.
Empathy and ability to voice their side, but not to pick unnecessary fights.
Understanding of what battles to pick.

What I want to work on:

Things that actually matter and impact people’s lives. Code is important, because it forms the back-bone of how we interact: with clients, homeowners, and everyone in between. Everything else is important, because it facilitates good code. Process, debate, and everything in between that we may go through stands solely to facilitate this. At some point, there’s diminishing returns in all discussions. My goal is to always know where that line is, and to avoid it.
Our team’s relationship, so that we can lean on each other as needed. The people we work with are the people we trust. I, nor will Faura, make the right decision 100% of the time. The best we can do is give our best diligence, effort, and observations on what we see. We will make good decisions, bad decisions, and all of them in-between. What matters is being able to turn to the team about where we stand, know that everyone will give their best effort to come to an answer, and to make a gut decision based on that answer.

What I don’t want to do:

Micromanage you. We have a team that encourages autonomy and communication — we communicate and give you freedom because we think the best way to run a team is to hire smart people and get the fuck out of the way. The rule applies here, as well. Please let me know if work is going to be late, if you’re not going to be showing up to meetings, or something important has otherwise changed since the last time we discuss it.
Manage drama, or relationships between people. I’m not interested in playing office politics, and people who are ‘politically’ minded won’t enjoy Faura. This is also why we may encourage people who have conflicts with each other to directly address it, and improve the relationship. A small team only works if everyone feels comfortable, and feels able to move forward cohesively. This of course does not apply in situations of harassment, discrimination, or bullying. But in general, I will encourage you strongly to work with other people and to route your communications directly to them.
Guess about what you’re feeling, what you want, or things you may need. As I have mentioned, I am on the spectrum and will not be able to pick up on subtle cues. I value direct, real time information. If you are feeling overwhelmed by your work, please tell me so I can take things off of your plate. If you are feeling not challenged, or like you’re not being heard — I want to know that as well.
Spend time over-engineering, or being in hypotheticals. A programming artifact that exists and is in production is better than one that does not exist, or is delayed by hypotheticals of a company that exists in a future beyond our fundraising runway. As CTO, I need to sharply balance the needs of now with the needs of the future. It’s not always a steadfast rule, but I try to build systems and teams that fit for the next 1 year of a company.
Spend time reviewing things that are not well-done. The above being said, it’s possible to build correctly-engineered systems that are still high quality. The work we do is not ‘throwaway’, and we should aim to build things that will as a long time, feasibly. I do not want to look at shit, fresh out of ChatGPT code. I want to build products that we feel proud of, that we know are safe to scale and can handle the pressure of what we’re putting on them. It’s a fine line to know what kind of system to build for the place we are now, and may be. But we should never ship terrible code, and we should hold others accountable for teaching that and building it into our products.

Where I can go wrong:

I might not pick up on social cues, or unsaid things. This is why I value direct communication, and I aim to give direct communication.
I come from an iOS developer / front-end background. I’m less knowledgable about back-end, but I’m getting there! I work to research my opinions to make sure I’m not basing them off my own experiences, but I value being given direction on best practices in production environments.

return Things I want to share

https://open.spotify.com/playlist/0eJpPNvFcrqvJttDz8wSRa?si=85b9dcd62e364b99