Based off of https://managerreadme.com/
I want to be easy to work with. People operate differently, so I created this resource to help others understand my communication style and preferences, how I achieve my best work, and what I value.
I build systems that scale, teams that innovate, and products that endure. My responsibility is not just to deliver - it is to architect for the long term, to remove friction, and to ensure every decision made today does not become a technical debt story tomorrow.
As a leader, it is my responsibility to understand and empower my team. I hold myself accountable for the systems and products that I influence and aim to help those around me improve. I set clear goals and deliverables, then trust my team to own the how. Micromanagement is a leadership failure. I invest in autonomy, accountability, and the discipline to deliver. Adaptability is the difference between a product that bends and one that breaks. Open communication is the foundation of a culture with competitive advantage. We call out problems early, debate fearlessly, and celebrate our wins, big and small, because pride in craftsmanship drives excellence.
As an individual contributor, it is my responsibility to deliver quality, tested, and performant solutions. Untested code, unaddressed performance bottlenecks, and ignored vulnerabilities are failures of ownership. Every design decision has a rationale and every dependency has a cost. I document the why just as rigorously as the what. If something’s broken, I will tell you. If a path forward is risky, I will flag it. If I am wrong, I will own that too. The best teams are not the ones that never fail, they are the ones that fail fast, learn fast, and ship strong. You can rely on my word and my work. Trust that radical candor will be WELL RECEIVED!
- I admire the thinkers, the driven, and the dedicated.
- Self improvement is a priority, even during the weeks when the work is comfortable and/or mundane.
- I value clear feedback without hesitation or delay.
- There is more to software development than technical expertise, but I do admire the use of thoughtful design patterns and the willingness to have deep technical discussion. Likewise, I admire the willingness to explain and guide someone to learn more about a concept they may have never encountered before.
- Leadership comes by example.
You should be able to trust my word and my work just as I should be able to trust yours. If I am not earning your trust, help me do so by providing direct and clear feedback. I use 'Care Personally, Challenge Directly' to share clear feedback without hesitation or delay.
If you would like to schedule some time with me, I typically like to assess the urgency in advance. Reach out and we can get something on the calendar, or in some circumstances, hop into a call right away.
I am a forward-thinking person; when a mistake happens, I want to know as soon as possible to assist in the fix and to start thinking about how it can be prevented down the line. I do not intend to place blame or call people out.
In any project, the definition of "done" can vary by who you ask. As far as I am concerned, a feature or initiative is "done" when it has been verified that the changes satisfied the needs of the consumer. Often, what is actually needed is not what was originally communicated, and in some cases, feedback can come back around well after the technical work has been merged in and delivered. We must be diligent in tracking features and their feedback, incorporating tweaks into the standard SDLC.
I believe 1:1 meetings should happen and on a 2-4 week cadence. They do well to improve a relationship and provide feedback in a private and trusted atmosphere. There should be nothing on a formal performance review that is not already known from these regular and open conversations. I also believe that 1:1's can be used to resolve conflicts between any two individuals. There should be at least one work-related item for discussion when entering a 1:1, else it might be pertinent to skip the meet and prepare properly for the next.
I am a social person, so if you want to chat about the movie you saw last weekend or a great restaurant recently explored, I will happily indulge and lose track of time. Help me stay productive by having these casual conversations at strategic times: in the morning while I'm still working on a coffee, at the end of the day with the usual wrap up, or after hours. I love to chat and will even hang out in a call just to work and converse simultaneously, but this is something I can timebox so that I can also get some heads-down focus time.
I have worked on a variety of teams with different styles of reviewing code. At the core, a code review should validate the satisfaction of the project requirements while calling out any great performance or security issues, however, there are also subjective interests. I prefer when code reviews come in a single batch of comments, so I will try to do the same for you. Depending on the review, I may provide suggestions for improvement that are not direct asks. I simply enjoy discussing code - I am more than willing to approve some code changes that ignore my suggestions. I try to keep the amount of this noise down to keep velocity up, but as with anything else, let me know with radical candor if I end up driving you nuts.