• Lead Positions

    This may come as a shock, but some engineers don’t want to be promoted. They’re happy being an engineer. They want to focus on code and building, not on leading, or mentoring, or helping define process.

  • Engineering Team Roadmaps

    Most roadmaps for engineering teams commit the sin of only including new features and functionality. This does a major disservice to the engineering team.

  • Reframing Failed Projects

    The word failure comes with a negative connotation, but should it? I’ve been grappling with this question the last few weeks. If an attempt isn’t successful, is it therefore a failure? Is there no middle ground? Does failure imply a boolean?

  • Should Engineering Managers Be Technical?

    I spent the better part of two decades as an individual contributor on teams resisting the management career change until I felt I was ready. So, this is a question I can directly relate to. I’ve mentioned this topic before. I’ve seen this come up a lot lately in industry circles so I’ll share a few more thoughts. Charity Majors has written a great article capturing many of my thoughts.

  • Book Review: Ego Is The Enemy

    I’ll admit I had a lot of enthusiasm going into this book. I’d listened to a number of podcasts where Ryan was interviewed. I was excited to read him as an author. Many of his books look interesting to me. I selected Ego Is The Enemy as the first of his to read for a few reasons.

  • The Craft Of Leadership

    Being in leadership is a craft of its own. I’ve been an informal leader, a Tech Lead on a few teams, an Engineering Manager to quite a few teams, and a Director of Engineering a few times. The roles and responsibilities are different in every company I’ve been a part of. I’ve been told I stand out as a manager. I’ve been nominated for awards and recognition. The biggest testimonial I have ever received came from an engineer that said “thank you, I’ve never had a manager that cared”. I’ll never forget that.

  • Book Review - Four Habits Of Healthy People

    Matt Norman has written a concise set of stories and questions focused on four habits that are shown to help people lead healthy lives. The one thing that sticks out to me with Matt’s writing is it feels like a conversation between friends. It feels less like a teacher and student, or coach and player type of conversation. Matt mentions a peer group of men he participates in near the end of the book. Imagine the type of conversations that happen in those groups and how they evolve, and that is how this book feels. It’s inclusive and not lecturing. I really appreciate that tone and I don’t think it’s easy to pull off.

  • Book Review - Atomic Habits

    A number of people have recommended James Clear’s Atomic Habits in recent months so I was excited to pick it up. I ripped through it pretty quickly. It’s a great read! Not pretentious. Not condescending. Just a good collection of observations about habits and human behavior. There is a key sentence in the book that summarizes it perfectly in my opinion.

  • Project Success

    I want to share some thoughts about setting software projects up for success. Success can mean many different things, so I’ll discuss a couple meanings in this post. Mostly solid quality and team happiness, rather than budgets and timelines.

  • Fireside Chats

    Today, I want to share something that I began doing previously and have carried through to my current teams. I call them fireside chats. They aren’t the typical setup where someone is up on staging fielding questions. They are simply the team getting together early on Monday morning in an informal setting and just chatting. It’s an open discussion. Sometimes as the manager I field questions. Sometimes we talk about what we did over the weekend. Sometimes we talk about items that are probably better suited for a retrospective, but regardless, this is an opportunity to talk about them.

  • Offer Letters

    Taking a break from talking about team roles, I want to briefly share some points of conversation my father and I have had regarding extending offers to potential new team members. Assuming the interview process went well and the team agrees that they would like the candidate to join the team, the offer is the official “welcome to the team”.

  • Team Role - Catalyst

    Let’s talk about the one team role that isn’t always obvious. Tom DeMarco and Timothy Lister define the role of the catalyst as the person that makes the team work well together in their well regarded book–Peopleware.

  • Engineering Team Roles

    Almost all of the engineers I have worked with have played some role in defining the to do list of a project. Some engineers are more disciplined, some are more lax. Some like granularity others just want big picture. Ultimately the team has to have a shared approach. Each member having a role on the team helps the team get to that shared approach.

  • Team Role - Juggler

    Most teams have a juggler–some may call this person the Swiss Army knife. They jump around from discipline to discipline as needed. They can juggle any component of a system or work inside any technology. A jack of all trades in a way.

  • Internal Facing Projects

    I want to share a few experiences I’ve had in recent years involving projects that were for internal use and the differing attitudes I’ve seen expressed towards their development.

  • Developing Talent Is Harder Than Finding Talent

    In my last post I discussed some of my recent experiences hiring software engineers and the lessons I’ve learned. In this post, I want to proceed to the next step after a hire is made–the development of that talent.

  • My Recent Experiences Hiring Software Engineers

    We’ve all heard it said over and over again that hiring is hard. But why is it hard? What about it is hard? You post an open position. You accept resumes. You pick the best one (after looking at the Githubs) and hire that person. That doesn’t sound like a hard process. But it’s really like herding cats. Below are some of my experiences and the lessons I’ve learned along the way.