Product and Technology Leader
Results-driven leader that is obsessed with the customer experience and seeks out ways for technology to solve company problems and increase operational efficiency.
Proven track record of building high-performing teams by recruiting and developing top talent, creating a startup office culture, and remaining hands-on in all roles.
Strong focus on execution, always strive for the best solution, continually challenge the status quo, keen ability to break down large projects into meaningful and impactful milestones.
Specialties: Digital, Technology, Leadership, Talent Recruitment, Talent Development, Strategy, Product Management, User Experience (UX), Conversion Rate Optimization (CRO), A/B Testing, Software Development / Software Engineering, Quality Assurance (QA), Process Engineering
Collection of articles I’ve written about technology, engineering, and product management.
Engineering capabilities
When I first join or inherit a team, I look at the engineering capabilities that the team and applications have. There are several ways to slice and dice this list, but for the purposes of this article, I'll talk about what I've found to be the best groupings for importance and team maturity. Level 0...
Engineering principles
Principles to live by This article outlines engineering principles that I've found worth articulating to my engineering teams. Some are strictly enforced while others are mere guidelines. It's really up to the stage of the team to decide how firmly to follow these, and each team may have additional principles or patterns of their own...
Agile delivery process
A collaborative, agile approach between Product and Engineering enables quick delivery of new functionality. This 7 step process is what I've used and continue to refine. What's important to you and your teams may vary slightly. Identify need Product first has to identify the need and work through the following questions in the initial discovery...
Git branching strategies
Git is a very powerful versioning system and there is tons of information out there for more advanced scenarios. I wrote this up for one of my teams that was new to both Git and the release-when-ready model so they were running into overlapping branches fairly often. None of these patterns are set in stone...
Release when ready
Most agile teams build their processes around a single release per sprint, with one release every two weeks being most common. This typically backs into a certain number of days of development (ex. 7) and the remainder of the sprint is a code freeze on new functionality so that manual testing and bug fixing can...
Leadership advice
I wrote this article in response to someone directly asking me for leadership advice in a 1-over-1 meeting. The descriptions might be a little biased towards that particular person, but I tried to generalize it as much as possible so I could share it with other people within my company, and ultimately here. Remain calm...
Team cohesion
I once had a manager of mine ask what he should be focusing on. My answer was "adding business value and team cohesion". Two pretty broad topics but intentionally so because it's easy to ask yourself if what you're working on ties into one of those two things. Separately, I had a friend that had...
Career progression
In general, I like the leadership of each team to define specific expectations for each level of their roles. Going through this exercise many times, I've noticed a pattern / ladder that cuts across all teams, and outside of technology too. It boils down to problem solving and decision-making ability but I think there are...
Technology Vision / Core Values
Overall, I've found that I continually push for a lot of things that don't easily fit nicely into a technical checklist or well-defined process that are easier to articulate. When discussing this with a peer, they made the observation that these were more like long-term visionary points or core values that I care about. I...
Coding days
If you've read my other articles, you may have noticed a trend that I like to focus on engineering happiness, and having people do what they do best, while removing all of the other noise involved in the software development process. My favorite measure of success is looking at the number of days an individual...
Leveraging contractors
I have mixed feelings about using contractors in general, and I certainly don't like ones that live on an island that has to be well-defined and kept at arms-length. I have seen contractors be successful when they are embedded into existing teams, but you have to be careful that you don't over-invest in them as...
Managing projects at different levels
When working on projects, I've come to the conclusion that there are (at least) three distinct levels to consider in everything that you're doing. I call them "operational", "product", and "technical" and I'll break them down further here. Operational They don't necessarily need to know or care about the Product milestones. In fact, I've seen...