Growing your People

As engineers, there are several ways to grow our skills. The most common ones are on-the-job experience and training, meaning learning by doing and executing on new tasks, learning from interactions with others, and formal education such as courses and training.

In our experience, job experience and training have the most impact on developing your people.

Maximizing on-the-job experience

In this post, I would like to share with you three methodologies I have used to maximize and deepen the learning achieved from day-to-day tasks.

Those methodologies not only accelerate the learning but also have the side effect of building trust between your team members and you, as well as increasing their motivation.


Spell out the learning opportunity

When you give your team member a task, any task, a new feature to develop, an internal tool to build, building few reports or even simply reducing current bug level, you should explain how you see the task contributing to their growth. Not why it is important for the team but rather how and what they can learn from it.

More than that, if you teamed them up on this task with other people, share the motivation of this combination, how can they leverage this opportunity of joint work with those specific people.

Here are two examples, very different scenarios but both share the key concept of focusing on the individual learning opportunity.

Case 1

We had a feature on our backlog for supporting co-authoring scenarios in certain areas of the product. Without getting into the technical details of the implementation, the feature required understanding all the possible flows, fixing collisions, and developing a mindset of co-author scenarios (similar to developing a mindset for coding asynchronous flows). Then, once that understanding was gained, writing a small amount of code to produce the feature.

If I had given this task to someone on the team without any background on it, like most engineers they probably would have tried to code their way to a solution. This would have been a problem. The engineer would be unhappy because coding the feature without gaining the required understanding would have been a long, involved grunt-work exercise leading to frustration. And they would have missed the opportunity to learn some incredibly useful information about the product.

So here is what I told my team member:

Now that I have explained what this task is about, I want to share how I see it. This task is not about getting coding experience: you likely will not have many lines of code to write. What's special about this task are two things. One, when you finish it, you'll have a fuller understanding of all the flows in our system. A view and knowledge that no one else in the entire group has. This will position you as a "go to person" in the team for every feature that crosses several code boundaries. Second, this feature will make you develop a co-authoring mindset. A view of how the code functions when two people work on the same document together. No other feature in our backlog has these two insights.

It probably sounds trivial when I spell it out like this but if I had not considered this and shared it then my team member would likely have returned, frustrated, about being assigned to the task. And likely requested another assignment.

Case 2

My team had finished development for the coming release, but other teams had not. In the manager's meeting, we decided that my team would split up and spend the remaining 3 weeks of the project helping other the teams to complete their tasks to assure the release would be on time.

This was frustrating to my team, they automatically assume they are doomed to be doing boring left-over tasks. But there are other sides to this, and we as managers we are obligated to think about them.

I gathered my team and, after spelling out the decision, here is what I told them:

I think this is a great opportunity for us. Not only have we completed our work and accomplished all the things that were required, we now have the opportunity, for a very limited amount of time, to go and learn other areas of the code and product. Be exposed to other people design and thoughts. The learning that each one of you can gain is huge, into new areas of the code base and seeing a wider view of the product and its flows.

I also sat down individually with each of the team to discuss the learning opportunities for their specific task.

It is important to mention that there are cases where we have work to be done and there is no way to extract much growth for the individual from that work. In these cases, we must be honest and genuine about this lack of potential learning. We should not hide, or worse, try to bluff them. I simply say:

Hey, I know this work sucks and you are probably not thrilled to be doing it but I am sorry, I have to ask you to do this. Don't worry, trust me, this is temporary, and I will be taking good care of you.

This brings me to my last piece of advice.

Draw the individual road map

Ultimately everyone, including our team members, owns their own growth. But having said that, we as managers should show them that we care about their growth and are proactively mindful of it.

On one hand, we hold a list of tasks. Each one has its characteristics and challenges. Some require complicated design to be done, some are focused on the ability to integrate several systems, some require customer UX understanding or data analysis capabilities, etc.

On the other hand, we have our team members. Each one of them has a history of tasks they did which are translated to capabilities they developed and the challenges they faced.

It is the right matching between a task and a person that does the magic. When we come to assign a task, we need to first understand its characteristics and then see who in the team, based on their experience and interests, would be the best fit for that task.

This aligns with our first piece of advice. When we explain the learning opportunity, we should also always draw out the perspective view, how this task is another step of growth for that individual based on what they have done so far.

Call out good behaviors intimately

Normally, we'd recommended that leaders call out the good behavior of an individual in a team gathering, in public, as this teaches the team what we care about and gives that individual a sense of pride and recognition for their efforts.

What I would also recommend, is to call out good behavior in a 1:1 format as well, in a more intimate environment where you can expand and go deeper analyzing that behavior in a manner that is not suitable for a large audience.

For example, I had a senior engineer in the team who was very shy and I worked hard to see how I could make him more engaged in discussions and raise and present his position when needed. On one occasion, he raised a great point we weren't aware of. A discussion evolved and he didn't let go of his position and continued to convince and argue his case. It turned out he was right, and his idea saved us considerable effort later. Of course, I thanked him in our next group gathering and shared some more details on the discussion. But I also didn't skip the opportunity to provide deeper feedback in our next 1:1. Here is what I told him:

You know what, I don't think your breakthrough here was the idea you raised. I know you, you think out of the box and it is not the first time you have pointed something out that no one else noticed. But it is the first time you raised an idea, engaged deeply and didn't retreat. And this is your win. You should think back to what caused you to behave differently this time, adopt it, embrace it and make it the new you.


On the job experience is the best way to learn and grow, however, in many cases, growth opportunities are missed or not exploited to their full potential.

It is our obligation as people managers to help ensure our team members are aware of the opportunities they have for growth and are using those opportunities to their fullest extent. Sharing our point of view and lighting the path to growth opportunities we see and believe in, will have a deep effect on the individual, and on your entire team.

Penina Weiss, Microsoft for Startups CTO in Israel.