NEXT CONVERSATION
Matt Esterly
EVP
Director of Engineering
at
Anedot, on...
Bar-raiser developers.
Leveling-up as an engineer.
The keys to building self-managing teams.
And what managers can learn from dirt-biking in the backcountry!
First, can you tell me a little bit about what problems Anedot is solving?
Anedot is a donation platform for nonprofits (Anedot is an anagram for donate!). We work with organizations from clean energy, to churches, to higher education, to political organizations to raise money legally. We fix fraud issues by having a good onboarding process to make sure organizations are legit.
We have tools that allow nonprofits to build highly optimized fundraising pages. These pages can be used to get your community together, maybe an event, and then drive towards donation pages where you can accept donations for your nonprofit - recurring donations or one time donations. We own a fairly deep tech stack in the payment area; we’re a payment processor like Stripe, but we don't have a public API.
What brought you to Anedot, what attracted you?
The chance to help nonprofits was huge for me. I've been involved with various youth nonprofits in my local area and so I love that part.
The tech stack is Ruby on Rails back-end and React front-end, which I love. It was a small team (at the time) with a clear product plan and a lot of growth potential. Plus, I really hit it off with the team. It just fit like a glove.
We took the team from around 6 to 20 in a couple years. We started with a really, really great core team and then brought in a couple of bar-raiser developers that were true catalysts for our growth.
Tell me what you mean by ‘bar-raiser’ developers?!
Good players want to play with other good players.
In the engineering process there's not just one answer, there's a series of trade offs that allow you to get the best outcome. And that sort of thing needs high-performing smart people to bounce off each other and beat out the best solution.
Working on hard problems with smart people is a great motivator, because then you can really do anything. People like getting pushed. I mean, I like working hard and most people I work with like working hard. It’s great when I’m pushed to see a way I could do something better.
We like to say Anedot will make you a better engineer. Actually a colleague said it best: "I just want to hire folks that are better than me, because that's the only way I'm going to get better."
How do you identify a good developer – especially bar-raisers?
That is always a hard thing!
We want high-performing self-managing engineers; folks that are looking to break down problems into small shippable pieces and get them done with minimal oversight. Note: this usually means pursuing people that are currently working!
We want to find busy people that are solving cool, challenging problems, and are interested in technology. We look for curiosity, a sense of urgency, best practices, and quality.
To that point….it may be an odd thing to say, but you have to make sure that they can code. You need to have a code challenge as part of your assessment, even though they're far from perfect. When pursuing busy people that are currently working, targeted code challenges are a better fit, even though I like the longer take-home challenges.
What’s your approach to leading a great engineering team?
If I had to sum it up: trusting people and creating the team that I wanted to work on 15 years ago or so.
Our goal is to make self-managing engineers. It's not that we don't have managers, but the manager is there to stay just ahead of the team and then stay out of the way. We make sure that everything's set to roll and the important team interactions are taking place, but we prefer developers to lead decisions over micromanagement. Low bureaucracy, high ownership, just enough project management.
It’s important to encourage teams to ask challenging, important questions at the outset of any endeavor: “Do we have the right problem? Should we even do this? How should we do this?” Particularly for the harder problems, or any sort of architectural problems, it’s valuable to do some upfront collaboration before you start.
Then it’s really about encouraging good decisions over trying to own the decision as a manager. This ranges from how the team wants to solve the problem, to how often we need to meet on a particular project that an engineer or team is tackling.
Really, my goal is to help people self-manage, and then just give them the tools to stay organized and be creative and effective.
What are some of the ways you ensure your developers are staying engaged and motivated?
One thing is to align folks’ interests with future projects or epics. We created a poll for our engineers where we asked them to stack rank their interest across all the areas of the app that needed development: “Here are all the areas in the company roadmap. Which ones are you most interested in?”
We hire new engineers for the features that our current team has ranked lower in interest. If they are unsure what interests them most, we provide a couple of opportunities to sink or swim. Part of being a manager is helping people figure out where the best fit is for them on the team. Let's just try you in a couple different positions and it's okay to fail in one of them while we’re finding the right match.
Ultimately, that alignment to long-term interests is a great motivator.
How do you encourage high performance on your teams?
I believe that software engineering is a career, not a job. That means continuously taking courses, reading books, following open source projects, and learning about new tools and technology. I don't expect everybody to be coding open source on the weekends, but I do expect that you're somehow expanding your knowledge to either go deeper or broader and pursue a natural curiosity. We facilitate this with a monthly “curiosity allowance,” but also expect you to be a professional; there should be some personal time devoted to improving your trade. Success comes naturally when you're doing all those things.
We use the term “level up” a lot because whatever level you are, you can always get a little higher. Of course it makes sense to connect this to interests. I’ll ask our engineers: “What do you want to do long term?” and then work with them to connect what they can do now to learn, grow, and improve to reach those goals.
What’s it like for you when an engineer isn’t able to level up to where you need them to be?
Back country enduro dirt bike treks in the mountains are my getaway. We go as a group and working together as a team is really important. You need a group that are all at a similar level and contributing, because calling a tow truck is not an option in the middle of nowhere. You’ve got to have people who can keep up, who can keep their bike running. That being said, there are different roles to fill. Some people are better at keeping the bikes running, some set the course, some cook the meals!
It’s the same with software. A lot of our developers are making new stuff and experimenting like crazy - that’s what makes our solutions unique and innovative. But it’s important to value the folks who like to do the maintenance, keep the lights on, because that’s what provides the stable platform to play in.
It tears me up if someone’s not a good fit, but ultimately you have to do what’s best for the team. Everyone needs to carry their own weight.
What are some of the approaches you’ve developed to accomplish all of this while managing remote teams?
We have always been fully remote! I like to joke we're hipster remote - we were doing it before it was cool.
First off is to be super positive. I realized a while back that everything I was doing with my body language when listening was saying, “I don't care,” but everything inside me cared! So, I’ve been adjusting my body language and simply trying to smile more. It’s also important to get good at writing – and use a lot of emojis to make sure people know you're happy :).
That being said: we also encourage people to work with others directly. Go hash it out. Let's not battle each other over text messages in GitHub. A lot of times people pair for 20 minutes and they've got an agreed solution.
We ensure that we have a feedback loop to address how work is going, but also to ensure folks are taking care of themselves and growing. It’s about developing a relationship with each employee and feeling out where they can contribute best. Some folks don’t want to chat about personal stuff; some folks need time to hash out work challenges. It’s about responding to each uniquely.
On Friday stand ups, we talk about what we're doing on the weekend, like you would in a normal office as part of our stand up. We make it intentional. Our team has grown, so we may have to keep it short, but we keep it real as well.
