Welcome to my README! This document is an introduction to me and my management style. It is not meant to be exhaustive; nor is it meant to replace face-to-face conversations between us. It's just my README: an introduction with some examples of how to to interact with my API.
Though my title is Engineering Manager, don't let that fool you. I am an engineer at heart with 30+ years of experience writing software professionally. For the last decade or so, I've been building web applications with Ruby, Rails, and RSpec. I'm particularly fond of building simple, well tested software. So, go ahead and hit me up with technical questions. You'll make my day!
I'm also a veteran practitioner of agile software development. My first daily standup was in 2001. I test drove code for the first time that same year. Got questions about Scrum, from planning with epics and user stories, to running an effective standup or retrospective? Got questions about Extreme Programming, from TDD, to pairing, to incremental design? I can probably help.
At a high level, my role is to ensure the success of our team. I define success as a combination of happiness, career growth, and adding value to the organization. Specifically:
- I am here to help you focus on your strengths, improve your skills, grow your career, and enjoy your work.
- I am here to provide context and to align our team with the rest of the organization.
- I am here to represent the team, ensure the team is getting what we need from other teams, and vice versa.
- I am also here to (occasionally) write some code - hopefully while pairing with you!
These are in rough order of prioritization. If you aren't successful and happy, then our team is not successful (or happy). If our team is struggling, I probably won't be writing much code.
I have three guiding principles for our team:
-
No superheroes.
If one of us does all the heavy lifting, the rest of us won’t develop any muscles. -
No cowboys.
We need to be aligned on principles, processes, and approaches. -
No surprises.
We should be the first to know when there is a problem.
Beyond the guiding principles, which I view as table stakes for our team, I expect thoughtfulness, collaboration, mentorship, and agility.
As software engineers, we are paid to think. But, I know from personal experience how easy it is to lose sight of things outside your editor. So, I invite you to think deeply about all aspects of your work, not just the code.
- Understand what you are building and why
- Consider who you are doing it for and what their needs are
- Task out your work
- Put yourself in the shoes of an engineer reading your code and tests months from now
- Understand the trade-offs you are making in your design decisions
- Pay attention when your tests are hard to write
- Explain why a test is important by naming it well
- Explore the unhappy paths
- Ask yourself what “done” really means
- Daydream about how to make everything better
Above all, think!
Software development is a team sport. In order to meet our goals, we’re going to need to collaborate both within our team, and with other teams. To get there we need kindness, openness, and honesty. Your kindness will help create a trusting, safe space for open and honest communication.
Here are a few ways we can collaborate:
- Clarify user story requirements during our planning meeting
- State what's blocking you during our daily standup (or before then!)
- Whiteboard designs with your teammates prior to working on a story
- Actively participate in retrospectives
- Thoughtfully review a pull request
- Sit with another engineer and work on a problem together
- And, above all, assume positive intent
Mentoring is the act of paying forward the time and energy that others invested in you on your way to where you are today. It is a force multiplier. It magnifies the contributions you make through the actions of those you mentor.
I expect the entire team to mentor one another no matter seniority, experience, or proficiency, because you will never learn something more quickly than when you sit down to teach it to someone else.
There are many ways to mentor. Here are a few ideas to start:
- Write a commit message that explains why, not just what
- Document some code with tests
- Host a brown-bag
- Get involved in a guild
- Kindly provide feedback in person
- Sit with another engineer and work on a problem together
- And, above all, take on a growth mindset
Mentoring isn’t hard. And, it’s not about who knows the most. I’ve mentored many people with more advanced technical skills than mine by being open to sharing what I do know. And, I learn from people with less experience than me every day by being open to learning all the time.
As I mentioned above, I have a ton of experience with agile software development. But, beyond the specifics of the process, I'm truly passionate about developer agility: the ability to reliably deliver value quickly.
Doing so requires that teams be able to nimbly navigate their codebase — adding new features, removing defects, pruning dead code, and refactoring what's left for simplicity and clarity. To do so requires structurally simple (well factored) code and a solid foundation of fast, reliable tests.
Developer agility also requires fast, reliable tooling, from work item tracking systems, to source control repositories, to continuous integration and deployment pipelines, because agility dies the moment you have to rerun the build four times due to a flaky test.
Every software development team is unique. As such, every team needs to discover together the practices that work best for them. But, there are industry-wide best practices which the vast majority of teams should be using. And, there are other practices that have proved quite useful to me during my career.
My expectation here is that we will work together to discover the practices that work best for our team, and that we will reflect and learn and apply our learnings along the way.
For more on this topic, I've created a separate document on agiility.
I love learning. And, as hard as it is sometimes, I find personal growth to be extremely rewarding. I sincerely hope we share this gene.
We will have one-on-one meetings on a cadence that makes sense for the two of us. This will be a private, safe space where we can reflect and plan. I will often have things to discuss. But, this is your meeting. I defer to your agenda. In fact, I recommend that you jot down some notes before the meeting. Send them to me ahead of time, if you want. I’ll do my best to prepare beforehand.
If you have feedback for me, be it praise or criticism, please share it in whatever way works best for you (in person, in writing, through my manager, during a 360 review, etc.). You have my promise, I’ll listen and do my best to learn from it and grow.
I will provide you feedback in the same spirit of learning and growth. More often than not, my feedback will be positive. Sometimes it will be critical. I will work hard to ensure that it is always constructive. In the unlikely event that there is an issue with your performance, I will let you know in the private safety of a one-on-one where we can work on a plan together.
My schedule pre-pandemic was roughly 10am to 6pm. I'd often work later, but rarely earlier. That way I got to see my kids off to school and skip rush hour. I also had a habit of getting back online after my kids were in bed. It wasn't uncommon to find me online after 10pm. What can I say? I'm a night owl.
Now, however, my schedule has shifted. I'm able to work a little earlier—around 9am—since my commute is about 30 feet. And, I rarely work after 5pm. This way, I get both breakfast and dinner with the family. (Frankly, I'm not sure I want to go back to the office...)
As for your schedule, I used to espouse core hours for the team to enable high bandwidth communication. But, with the team so geographically dispersed, it makes less sense to set aside core hours where everyone is available. So, do what works best for you. And, update your calendar to show what your working hours are. Plus, be sure to set boundaries if you're working from home. Slack is omnipresent. You shouldn't have to be.
Finally, there are times when I'll need to arrive late or leave early to take care of my kids or go see the dentist. This is my life. I expect yours has similar constraints. All I ask is that if you are going to be unavailable, please put it on your calendar and let the team know in advance.
If you haven’t already, I highly recommend that you read these books:
- Practical Object Oriented Development in Ruby by Sandi Metz
- Extreme Programming Explained by Kent Beck
- Radical Candor by Kim Scott
These are my guideposts for how to write and test object-oriented software, how to run a software development team, and how to manage people.
Finally, I have a couple of quirks that are helpful to understand.
The first is that I can come across as having very strong opinions. That’s because I do. So, be prepared to challenge me when your idea is better than mine. Show me a better way, and I will likely change my position and argue just as strongly for yours.
Second, I'm wordy (as you can tell!). And, I can take over a meeting or conversation. Please don't let my voice drown out yours. Like I said above, I value feedback. Remind me kindly to make space for others. It's critical to the success of our team that we are all able to share our thoughts.
Finally, I bring my whole self to work. I can be emotional. In a good way. I've been known to tear up — especially when giving praise. Honestly, I find it embarrassing, but I've learned to embrace it because that's who I am. I care deeply. And, sometimes it comes out in ways I cannot control.
I mention these things here as a way of helping you better understand me. You'll undoubtedly see these quirks in action. Now you'll know what to expect.
We'll make time to get to know each other better in person as we work together. But, for now, that's it. That's me in a nutshell. I'm glad you're on the team. Now, let's do something amazing together!