Sometimes, our most dearly-held beliefs and practices are the very things that keep us from succeeding in new leadership roles.

Cool, we've got swarms of empowered ICs working on their newly ideated projects. How do you keep the team holistically moving toward the right goals, without having the superpowers of a PM on hand? You improvise and hand out some hats.

When individual empowerment is your radical idea, then you commit fully to it with the Engineer as Project Driver. All engineers, no matter their experience, are given the responsibility to take a project from start to finish and own the outcomes.

How do you teach engineers to think like PMs? You give them the awesome and scary responsibility of choosing their work. Our team learned how to think and prioritize strategically by collectively building an Idea Backlog where we dream up and prioritize impactful projects to tackle. Here's how it works.

Can a team with a recently-departed product manager learn to survive on its own? How we built a bottom-up product development culture on my team at Lyft.

If you've worked in tech long enough, you'll hear praise for Andy Grove's High Output Management, oft-praised as a touchstone of technology management (Grove is often referred to as the "Father of the OKR"). A year or so ago, I got to read his book through Harrison Metal's General Management course. What can you apply from the book when you're a tech lead, and not actually a manager?

For all the toil that went into developing the pipeline and deep learning model for my ML baby monitor project, I discovered that my model didn't actually solve the problem at hand. This kind of gap exists in the real world of ML development as well, and there's a critical insight from the field of User-Centered Design that could be the key to bridging it.

Over a year ago, I wrote a couple of blog posts about how I trained a TensorFlow model on audio clips of my crying baby so I could get some insights into his sleep patterns and behavior. I distilled this experience into a PyGotham talk titled "Can Neural Networks Make Me a Better Parent?" and it reflects some extra maturity in my machine learning knowledge, as well as some hard-won parenting wisdom and experience.

It's been several years since I've come off of my former role as an engineering manager, and with enough humble introspection I've had several insights into the mistakes I've made, and how I'm integrating those learnings into my teams nowadays.

A discussion about why I enjoy working in the XP-school of Agile. (tl;dr: I enjoy working in a pull-based work stream. I like that pair programming, TDD and other best-practice batteries are all included.)

In which we train an TensorFlow model with the tears of my little one, then deploy it on a Raspberry Pi.

How do you deal with the travails of colic and new parenthood? You plunge yourself into an ML project, of course. Here, we discuss a naive solution to detecting baby cries via an onboard microphone on a Raspberry Pi.

While it’s been pretty quiet around these parts, I’ve kept the technical blogging up over on my employer’s blog. I’ve got quite a few posts around Elixir:

I posted an article on Medium titled “Wejoinin at Ten” describing our experience developing Wejoinin over the past ten years as a long-running passion project - and talk about the directions we hope to be taking it in the next ten.

I recently published a post on the Carbon Five blog titled “Evented Rails: Decoupling complex domains in Rails with Domain Events” that takes some of my thoughts about moving a Rails app to use Domain Events - leveraging the power of Sidekiq (or your job runner of choice) to send async messages between different domains of your app.

The first question you may be asking is - why would I want to go from Rails to Java?

You’ve resolved to build your company’s Next Big Thing in Phoenix and Elixir. That’s great! You’re facing a problem though - all user authentication and access concerns are performed on your Rails system, and the work to reimplement this in Phoenix is significant.

One common pattern in Domain-Driven Design is the use of publish/subscribe messaging to communicate between domains. When Domain Events are created from within a domain, other domains are able to subscribe to these events and take action within their own domains, respectively.

I want to discuss a topic near and dear to my heart, and what I believe is at the crux of effective software design. It’s not a new functional language, it’s not a fancy new framework, a how-to guide to do microservices, nor a quantum leap in the field of machine learning.

As follows are some code snippets for using Knex.js for executing Postgres and PostGIS queries.