People First

“People First” means to value people more than processes, rules, technology, product, tools, money, roles, etc.

Most people work with other people. Even when people work alone, their work likely has impact on other people. Because of that, I think it makes sense to put people as the focus, not only on the result of the work itself, but also during the process of doing work.

The Manifesto for Agile Software Development encapsulates the “People First” idea quite perfectly.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

At the heart of this manifesto are empathy, respect, honesty, collaboration, and continuous learning. They are the essence of People First.

I’m not an Agile nut by any means — I think it has nice ideas, but unfortunately in practice it’s too often done just for the sake of doing it. I think of People First as a different way of expressing the same principles in a more intention-revealing way. I believe it can also be applied to more areas than software development, even outside of work settings (community, personal development, and so on).

None of these ideas are new, nor do I claim them as my own original ideas. I’m merely grouping them in a small framework that is useful for me. This short article is my attempt to articulate it. I will use this as a reference for myself, but I hope others could benefit from it too. The following are some examples of applying People First principles from my own experience working in the software engineering industry for almost 20 years.

Software Development

A few years ago, I learned the hard way that starting non-trivial work on a proposed change without discussing with anyone first doesn't work that well. If I had mentioned it, even briefly, to anyone on my team before starting, I would have known that the proposed change would soon be irrelevant. All that hard work I did was a waste of time and effort. Regular stand ups would also have caught this early and ensured everyone’s working on the right things — which is really one of the main points of stand ups, the other one being uncovering any blocked issues.

In a similar situation, a proposed non-trivial change could be relevant, but perhaps should be done with a different approach instead. This is best discussed first with the team owning the system, before starting any work as to not waste any effort and time down the track. This would also give some context to the reviewers later. Making the review process smoother and more likely to be accepted quicker. By collaborating, it is also showing respect and empathy to other people in the team.

Another way of using empathy and respect is to help make the reviewers’ job easier and save everyone’s time. Ultimately this should work toward your advantage as well.

• Writing proper title and description in the pull request may seem unimportant, but it’s one of the things that I appreciate a lot when reviewing pull requests because when it’s done correctly (tell me things that I can’t derive from the diffs, e.g. the whys and any other non-obvious things) it should give me proper context and put my mind on the right track when reviewing the change. It significantly reduces time, friction, and back-and-forths.

• Breaking pull requests into focused smaller ones also helps making the review process easier. It should also lower risks when deployed separately from other changes.

• Annotate anything that is not immediately obvious with pull request comments: the suggested starting point for reviewing, the most important bits of the change, moving files around, whitespace changes, etc.

Leadership

Managing a team is mostly about managing the people in the team. The manager’s job is to empower the team members to be able to do their work in the best possible conditions. So it’s natural to use the People First principles here. It’s literally people first. It’s impossible to be a successful manager without being emphatetic, respectful, honest, collaborative, and wanting to continually improve things.

On the other side of the coin, when being managed as a direct report, People First could be useful as well. Relationship with your manager is a two-way street. That means you’re also partially responsible for making the relationship work. Your manager is also human. It’s probably not a bad idea to make their job easier when possible (understand their perspective/situation, offer help when you can, be flexible, etc). I’m sure they would appreciate it.

Some leaders don’t have direct reports, but often still have to either manage or collaborate with other people in a project. Individual Contributors (ICs) like staff engineers, tech lear, or other similar roles, frequently lead initiatives where they have to negotiate and get buy-ins from other people in the team or in the organisation. The people who are successful in these roles tend to be the ones that exhibit the People First characteristics when doing their work. It’s impossible to get genuine buy-ins without empathy, respect, and collaboration.

As a side note, I find the term “individual contributors” here a bit misleading, it could be misunderstood as a role suitable for people who like to work alone with no interactions with other people. But, I think those people would struggle to do a good job in that role eventually.

Product / UX

Building great products with great user experiences often mean putting yourselves in the users’ shoes. Seeing things from their perspectives. Not every user has the same needs, preferences, tolerance, abilities, values, etc. Empathy and respect are pretty much a requirement here.

With all of the above taken into consideration, the product builders will also need to balance them with business needs (or maybe to lower costs if it’s for non-profits, for example). Building great sustainable products is a common challenge.

Building a great product takes time, it’s never an overnight success. Nowadays, teams build incrementally in iterations. It’s a continuous learning process, incorporating feedback and lessons learned to keep evolving and improving the product.

Conclusion

There are probably more examples I could dig, but hopefully the above is enough to give us an idea of how we could use People First principles at work.

When faced with situations where I have to make a decision, no matter how small, I tend to come back to these People First values to get better outcomes:

• empathy,
• respect,
• honesty,
• collaboration, and
• continuous learning.