I’m an application architect, software engineer, and servant leader living in Denver, CO.
I believe in promoting scalability, great user experiences, and the Oxford comma.
I know many software engineers, and I wish we blogged more often. We benefit from the blogs our peers write, and we are inspired to contribute to the community. But I write code more effectively and consistently than blog posts. I hope to change that by learning from my code-writing self and introducing some classic DevOps practices into my process.
Hi there 👋, I’m Joel - a Principal Architect and Software Engineer with 15 years of experience creating products at scale in various industries.
I’m an engineer that thinks like a product leader—I’ve helped companies drive user-centric outcomes as an individual contributor, VP of Engineering, technical project manager, director of Innovation, and more. I love building products with cross-functional teams, and I especially enjoy writing code.
I have helped small businesses to fortune 50 companies identify the most significant technical and experiential requirements for their products, form hypotheses, test ideas, and bring products to life through empowered product teams discovering and delivering tangible customer value.
📚 Read: 6 Principles for Designing Software Architecture
Continuous discovery and delivery, flow-focused value streams, empowering cross-functional product teams, the inverse Conway maneuver, outcome-based roadmaps, promoting ownership and autonomy for product teams, embracing the Principles of Agile, Serverless, GraphQL, Node.js, Containerization, JavaScript (TypeScript), PostgreSQL, Infrastructure as Code (IaC), automated testing, Redshift, observability, and pursuing outcomes over outputs.
Modern product development engages empowered cross-functional teams to continuously discover and deliver value. I aim to bring thoughtful structure and outcome-based approaches to product teams.
Thoughtful structures for effective product teams often starts with creating a shared language and aligning on common patterns and processes—like making work visible—and which metrics to track, such as deployment frequency. From there, teams can regularly reflect on the strengths and weaknesses of their choices in light of outcomes and make periodic adjustments.
📚 Read: Software Project Management: 5 questions you should ask yourself and your team
To learn more about what I have done, check out some of my work.
