Contact
Let’s talk about what you’re trying to build.
I’m always interested in a good engineering problem: scaling an engineering organization, modernizing a complex platform, fixing slow delivery, building a new product, or bringing in experienced technical leadership.
Fig. 700-1
Need an engineering leader who can still go deep?
I don’t see engineering management, architecture, delivery and people development as separate jobs. They influence each other.
I work across people and organization on one side, systems and architecture on the other, with product thinking and hands-on technical depth connecting them.
Engineering leadership
People
- Mentorship
- Team growth
- Ownership
- Leadership
Delivery
- Execution
- Visibility
- Planning
- Risk
Systems
- Architecture
- Reliability
- Cloud
- Scale
Business outcome
Hands-on technical depth runs through all three.
We should probably talk if you’re dealing with…
- Your engineering organization is growing faster than its processes.
- Leadership doesn’t have enough visibility into engineering delivery.
- Technical debt is starting to control the roadmap.
- A legacy platform needs modernizing without stopping product delivery.
- You’re building a new engineering organization or product team.
- You need stronger technical leadership without losing hands-on credibility.
- You want engineers to take more ownership and make more decisions.
- Architecture decisions are becoming business decisions.
Where I can help.
I’m most useful where engineering, product and the business have to move together, and where the team needs to get stronger while it ships.
- Scaling engineering teams
- Engineering execution
- Platform modernization
- Architecture
- SaaS & product engineering
- Cloud systems
- Complex business workflows
- Distributed teams
- Technical strategy
- Engineering leadership
- Developing engineers
I work with companies through Yippify, on scoped projects or ongoing engineering leadership.
What you’ll get from me.
- I ask why.
- Before choosing technology.
- I stay technical.
- Leadership shouldn’t cost technical credibility.
- I make engineering visible.
- Leadership shouldn’t be surprised by engineering.
- I develop people.
- The goal is engineers who make good decisions without me.
- I think in tradeoffs.
- An architecture choice is also a choice about cost, delivery dates, reliability and who can maintain it.
- I build for what comes next.
- Today’s ticket gets closed in a way the team can still live with next year.
I want engineers who can challenge me, make decisions, lead others, and eventually take over parts of my job. A team that needs me for every call is a team I’ve built badly.
Read how I think about mentorshipI’ve sat on both sides of the engineering conversation.
As a co-founder and CTO, I watched technical decisions turn into cost, hiring, product and customer decisions, usually sooner than anyone expected. I still lead with that in mind.
A technical decision eventually becomes a
- Cost decision.
- Hiring decision.
- Product decision.
- Customer decision.
- Business decision.
Let’s talk.
You don’t have to decide from a website whether I’m the right person. That’s what a conversation is for.
You don’t need a polished pitch. If there’s an interesting engineering, product or organizational problem worth discussing, send me a note.
Replies go to the email address you provide.
- Experienced enough to lead.
- Technical enough to understand the details.
- Practical enough to ship.
- Secure enough to develop people who may one day replace me.