Note: This post is from the previous iteration of this blog.

I am a people person. I love working with people and strongly believe that putting people first is ~~nearly~~ always the right choice.

Putting people first can be challenging in software development when deadlines, bugs, egos and opinions get in the way. I have seen each one of these things at work, doing real harm to working relationships and team morale. Perhaps in the most extreme circumstances, some of this is unavoidable, but I think those situations are few and far between.

At the end of the day, I try to live by this Maya Angelou quote:

People will forget what you said, people will forget what you did, but people will never forget how you made them feel.

Every time I forget to embody this concept in the way I deal with the people I work with, whether it’s because my own ego is getting in the way or business pressure is causing me to lose sight of the big picture, I end up regretting it.

I take this issue even more seriously if I am in a Team Lead or some kind of management role. I feel like a Team Lead has two responsibilities that are equally important: lead the team in meeting business needs, and making sure the team’s needs are met as well.

Among the needs that a typical team has are some that I feel are often overlooked, such as the need for team members to feel like the business is investing in them, the need for junior team members to receive good mentorship and opportunities for feedback, the need for team members’ input to be both welcome and heard, and the need for team members to feel respected and valued, regardless of their experience level. If a team member is doing their honest best, they should not be made to feel like a burden or an annoyance – especially when you are their primary resource for assistance.

When I helped start the programming club at Salt Lake Community College and was elected as the first club president, I watched some instructional videos on leadership in order to make sure I wouldn’t screw things up. One of the lessons I learned was that creating a psychologically safe place where ideas can be shared without fear is essential.

I can attest to how true that lesson is because I have worked under managers where I basically wasn’t allowed to have a good idea or be right about anything. I started every interaction with the manager at a disadvantage because they started every interaction with the assumption that nothing I had to say was valid or worthwhile. Needless to say, it wasn’t fun and I eventually just stopped giving my input on anything.

The last thing I want on any team I work with, whether I am in a leadership role or only a team member, is for people to stop offering their ideas. No single person has all the answers, and it usually takes a team effort to find the optimal solution.

Throughout my career, I have kept a mental list of things I have observed in my own managers and which of them I do and do not want to emulate when I am in a similar role. I even muse sometimes about how if I ever have my own office in some kind of management role, I’d have a plaque on the wall that said “Be the kind of boss you always wanted”.

I would also have a picture of the Challenger space shuttle hanging on the wall to remind me of the potential costs of not listening to the people working under me (NASA engineers had warned their superiors of the problem that caused the shuttle to burn up, but they were ignored). I know that may sound a bit grim, but that is how important I think this is.

Of course, I don’t think I will ever work with stakes as high as they are at NASA, and I may or may not have any kind of management responsibilities in my next job, or the one after that, but it is the next logical step in the standard career track for Software Developers, and it’s never too soon to start preparing for that eventuality.

If you have read this far, thank you. I hope you come back for more.

Cheers!