Automatically, when people ask me, “What is the first thing you consider when you need to scale?” my response is, “By investing in people.”

However, this answer often fails to convince many fellow engineers in the room, who interpret it as merely advocating for “adding people to the problem” – more hands, less work – akin to a factory assembly line. Fortunately, the reality is far from this simplistic view, as the nature of software development requires a nuanced approach beyond just increasing manpower.

When I mention investing in people, I specifically refer to my role as a manager, where it is my responsibility to oversee the well-being of the individuals on my team. Caring for people is not a monolithic task; it involves different levels of attention, each with varying importance within the workplace.

This concept can be easily mapped onto Maslow’s Hierarchy of Needs, which outlines various human needs in a hierarchical structure, from basic physiological requirements to self-actualization.

As a leader, it is crucial to be vigilant and ensure that all layers of Maslow’s pyramid are being curated within the team.

Starting from the bottom of the pyramid, the most fundamental and, in my opinion, the most important aspect is “Psychological Safety.”

Psychological safety encompasses, among other things, ensuring the team’s physiological well-being. This foundational level is the bedrock upon which a thriving and productive team is built. Without a sense of security and basic needs being met, higher-order concerns become difficult to address.

The goal is not to view team members as mere cogs in a machine but to recognize and nurture their individual needs. As Maslow’s Hierarchy suggests, only when the foundational physiological and safety needs are met can individuals progress towards higher levels of fulfillment and contribution – reaching the pinnacle of self-actualization.

In essence, investing in people is not merely about increasing headcount but fostering an environment that addresses the holistic needs of each team member. By doing so, we lay the groundwork for a resilient, creative, and high-performing team capable of navigating the complexities of scaling in the ever-evolving landscape of software development.

All sounds quite good on the surface, but let’s get to work. How do you invest in people? What are the ways you grow engineers? There are a lot of good resources out there; I’ll share some with you. Here, I am going to share my personal experience, based on managing different teams from different cultural backgrounds.

I learned that achieving psychological safety on your team is a very long process; it is needed months or even years to build and literally minutes to destroy.

Consider psychological safety in a team environment as analogous to the process of cultivating a rice field (can’t avoid it, I am from the land of rice and oranges). In both cases, the nurturing of a supportive foundation requires time and deliberate effort to yield fruitful results.

In a rice field, the initial stages involve preparing the soil, ensuring it is fertile and capable of sustaining life. This is akin to establishing psychological safety within a team, where the groundwork is laid by creating an environment that acknowledges and addresses the basic needs of each team member, by providing regular and candid feedback, avoiding surprises on performance reviews, running blameless post-mortems, allowing engineers to make mistakes, learn, and iterate.

As the rice plants begin to sprout, they require continuous care and attention, similar to the ongoing commitment needed to maintain psychological safety, checking on engineers weekly, ensuring you block a reasonable amount of time with them, active listening, and addressing all their concerns.

Watering the rice fields, protecting the crop from adverse conditions, like giving them tools for dealing with non-constructive feedback, providing the necessary nutrients, parallel the leadership actions required to sustain psychological safety on your team. This entails actively listening to team members, offering support, and fostering an atmosphere where everyone feels valued and secure.

Much like rice cultivation, the results of investing in psychological safety take time to manifest. Patience is essential, as the roots of trust and collaboration need to deepen before the team can flourish. Rushing the process may jeopardize the quality of the harvest, just as neglecting the establishment of psychological safety can hinder the team’s creativity, innovation, and overall performance.

Growing psychological safety in a team is a gradual process, much like cultivating a rice field. It involves careful nurturing, attention to detail, and a commitment to the well-being of the foundation. The bountiful results, whether a thriving rice harvest or a high-performing team, are well worth the investment of time and care.

If you, as a manager or leader, are allowing constant attacks against you or other teams, people highlighting mistakes, even for once, your hard work will be in vain. It is crucial to constantly water the field and make sure it does not drain.

Not only is it on the manager’s back; however, as you probably can’t deal with a whole rice field, you can’t control if a storm comes or you are going to be absent for days or weeks on PTO or sick, it is important though you build trust on your team to keep track of the field. Sometimes, engineers are not aware they are not contributing to creating a safe environment; they may be thinking they are doing the right thing by pointing out a problem or suboptimal way of implementing a Python function in a harsh manner. Then it is YOUR responsibility to reflect on the impact of his words against the team / engineer affected and guide the engineer towards a successful outcome, where the receiver feels she got better after receiving the message. The framework I reference I use is called: Radical Candor, where the rule is: Care personally, challenge directly. You can find more info by visiting www.radicalcandor.com.

Let’s do this by an example. Imagine you are encouraged to provide feedback about an object-oriented architecture. The first thing you need to keep in mind is that designing object-oriented software is hard, and designing reusable object-oriented software is even harder. You are going to need to define objects, factor them into classes at the right granular level… Most importantly, you want to avoid redesign. Embrace empathy by the scenario; it is HARD.

Patterns have four essential elements: name, problem (how to apply the pattern), solution, and trade-offs (consequences of using it instead of another). Imagine the discussion goes along the way of the trade-off, hence an anti-pattern for this particular problem.

Often, I see this scenario, and see different types of reactions from one engineer to another.

Scenario A: Engineer 1 (E1): Hey, I saw your PR for problem X. I think using the Observer pattern here is a terrible choice. Why did you even consider that? Engineer 2 (E2): Well, I thought the Observer pattern could help with the event handling and decoupling of components. What’s wrong with it? E1: It’s just not suitable for this problem. You should know better. Choose something more robust next time. E2: Okay, I get that you don’t like the Observer pattern, but it would be more helpful if you could provide some specifics or suggest an alternative. E1: You figure it out; it’s not my job to spoon-feed you design solutions.

You must be thinking that this scenario is just made for this example and almost never occurs, but unfortunately happens often than you think. What type of feedback would provide to the engineer 1 for getting to the a situation like scenario B?

Scenario B: Engineer 1 (

E1): Hey, I checked out your PR for problem X. I appreciate the effort you put into it; the overall structure looks good. However, I got a question: why did you think the Strategy pattern for solving the problem? Engineer 2 (E2): Thanks! I tried to implement the Strategy pattern to make it more flexible. Do you think that’s a good choice? E1: Well, I see where you’re going with the Strategy pattern, but I’m a bit concerned about potential scalability issues down the road. Have you considered how this might impact performance as the system grows? E2: Hmm, not really. What do you suggest instead? E1: We could explore the Command pattern. It might offer similar flexibility without sacrificing performance. E2: Ah, I see your point. I’ll look into that and make the necessary adjustments. Thanks for pointing it out.

Think about both scenarios. Essentially, they are presenting similar problems. In scenario A, E1 is already assuming E2 made the choice based on his full knowledge, so there was no sense of empathy, neither caring for getting everyone better. E1 does not provide reasons about the disagreement, which does not help E2 to elaborate different solutions, which avoid challenging the engineer directly. Additionally, and the worst is how the conversation ends up. “It is not my job…” E1 is saying I am not helping you; you are on your own, breaking any possible ground for Psychological safety.

Coaching the engineer by taking some time to reflect on radical candor (Care personally, challenge effectively) is what you as a leader must do and help E1 to get to the point where can grow as an engineer and as a professional. This does not necessarily mean that E1 is a bad person; can be too busy, overloaded, or simply cultural bias by previous experiences.

On scenario B, E1 opens for a conversation by starting acknowledging the effort by E2; this boosts morale and confidence for E2. E1 shows care. Later, assuming good intentions, prompt an open question showing genuine interest on why E2 is thinking this way. Then a healthy brainstorm sparks, opening E2 to explore broader solutions with its consequent learning and grow.

This is just a small example of how to build safety in your team; there are multiple more I would be sharing on this blog; this post is already too long :)

If you want to have a TL;DR:

  • YOU as a leader/manager are responsible to create and maintain psychological safety if you want to boost the productivity of your team and scale.
  • You don’t only scale by writing performant code.
  • Creating psychological safety is not a sprint but a marathon. Keep monitoring signals that show your team not being free to experiment or innovate. Engineers have their part of responsibility helping you create this environment. Like in the scenarios above, make sure you provide coaching on time and ensure everyone knows your priority is to provide them a safe environment where they come to work happily and feel productive!

Follow up read: kind.engineering

Bona vesprada!