People first

I have not written anything on this website in many years. I have had the pleasure and great privilege of being completely lost in my work on impactful projects over the past six years. The work has been challenging, and the people have been great. I write this as a reminder to myself that what makes a great team and organization is people.

Manage with empathy and put your people first. As an individual contributor, make yourself indispensable to your team. Teams can do extraordinary things when they are empowered and supported.

Manage with people first in mind

  • People want “deep work” – meaningful problems and meaningful decisions.
  • People want to be treated with respect – flexible schedules and a lot of autonomy.
  • People want their accomplishments acknowledged – fair compensation and a clear career path.
  • People want to grow – managers and mentors invested in their future.
  • People want time for themselves and their families – sensible hours and long-term planning.

Leaders have a big responsibility to focus on the needs of others before their own. The trust that you build with a people-first approach will buy you a lot of goodwill, and you can then, in turn, get more from your team.

Making yourself indispensable to your team

As an individual contributor (non-manager role), there are skills that software engineers need, no matter the context. These skills can make you indispensable to your team and help you grow into a leadership role.

Presence

Presence isn’t just clocking in. It means being there for others and benefiting from your colleagues being there for you. An indispensable team member:

  • can be easily reached during regular business hours for their time zone unless the time is blocked off on their calendar.
  • shows up to all meetings on time and ready to engage.
  • responds to all code review requests within 24 business hours.
    • asks questions when they don’t understand the code changes.
    • offers advice, suggestions and encouragement in code reviews.
    • When someone reviews their code, engages with the reviewer and addresses their concerns.
  • when they get stuck on a problem, they ask questions and get support from their colleagues.
  • actively uses the company’s communication channels (e.g. Slack) to help their colleagues, give their opinions, ask questions, and answer questions.
  • monitors production environment logs and alerts for bugs and performance issues.

Ownership

Great teams are full of leaders – people who know what they’re working on and why they’re working on it and can get projects to the finish line. They

  • understand the real-world problem they are trying to solve. If they don’t know why they are doing something, they actively engage with their manager, and colleagues to understand better.
  • break down the project they are working on into smaller milestones and communicate their progress.
  • communicate risks and help reduce the scope of a project if the timeline is unrealistic.
  • remove roadblocks, get unstuck, help people make decisions, and push projects to the finish line.
  • think about the state of their codebase and actively work to improve it.

Software Design

The first step is to find a solution; often, the first solution is suboptimal. Iteratively, the solution is then refined. A talented and experienced engineer knows when to stop. They know that:

  • not all code is created equal. I often ask myself: How do I make my code easier to read? How do I make it easier to change in the future?
  • conversely, there is no perfect code. They have the wisdom to ship the working code and improve it later if necessary.
  • They write automated tests and ask others to do the same.
  • They evaluate trade-offs (refactor or not? their code or a third-party solution?) and understand why they made a decision.
  • They evaluate the software design of the entire codebase and help their colleagues make good decisions.

Delivering solutions

Beautiful code is only worthwhile if it ships or solves a real problem.

  • Sometimes, the solution involves writing no code.
  • Sometimes, the solution does not need to solve all use cases (80/20 rule).
  • Solutions should be broken down into small changes that are easy to understand, easy to review and less risky to merge.