ENGINEERING MANAGERS INTERVIEWS
#2 Jan Chec: I’m a Learned Extrovert
On the Agile State of Mind podcast, Jan and I talk about the transition from a Developer to a Lead, the perfectionism, and how not to overwhelm people with knowledge
Not everyone is a born extrovert yet it doesn't seem to matter when looking for a great leader. When talking to Jan Chęć, a Backend Lead at Smartpatient and my brother, I realized that the set of features we understand as typical for extroverted people may vary depending on who you talk to and maybe even where you talk to them. One might be considered an introvert at home but they might be deemed outgoing at work. One more reason not to put people in just one box for life.
I’m a Learned Extrovert
Today I am interviewing my brother and a Backend Lead in my Agile Leadership series where I deconstruct the role of an Engineering Manager.
“I’m a learned extrovert, adaptable.”
- Jan Chec, Backend Lead
Still, some practices may come at a price.
“In the beginning, when I was moderating meetings it was very exhausting for me. Even before I became a Lead, I watched people who led meetings and I thought, I don’t want to spend this amount of energy during meetings.”
You need to train yourself and then things become easier:
“It gets much better with time. Initially, you have a lot of new stuff going on.(…) Later on, you have it all figured out, you have those ready mental models to use and you don’t have to use that much energy.”
This is a great insight from someone who is in a leadership position. We might think that there are people to whom many practices like meeting facilitation, mediation, mentorship, etc. come naturally thus effortlessly! So it is refreshing to see that all those skills can be learned and mastered at any point in life. It can all be achieved through practice.
Onboarding: Do not overwhelm
Another common practice I see among the leaders I interview is that they tend to fix any broken processes on their own initiative. They go the extra mile at work to improve what is not working and understand the team context and the product. One thing Jan started to improve on his own was the onboarding process. He noticed that there were “buddies” assigned to the new joiners but they seemed to be quite reactive.
“A buddy is a person that is responsible for your onboarding, day-to-day consultations about how everything works and so on.
It’s a person that you assign to a new joiner so their onboarding goes smoothly.
They are like a glue for many different things and fills the gaps that could be there”
Jan Chec, Backend Lead
After a situation when one new joiner quitted quickly after they had started, Jan took a closer look at the onboarding process and started fixing some issues.
First of all, I introduced that the buddy should be in the same team the new joiner joins and they should be proactive and I explained to everybody what it means. And important: do not overwhelm.
If you push some information that is not relevant right now, it won’t be remembered. The info should be spread out in time. You should monitor if they have what to do and if they are blocked.
I remember when I was responsible for my teams' new joiners onboarding, back when I was a Scrum Master at Free Now, I came to the same conclusion. The buddy needs to be on the same team as the new joiner and if possible in the same role or technology. It is so much better if an iOS developer onboards an iOS developer as opposed to a Backend one. Still, it is better to have anyone from the team onboard the new member but having a buddy who can understand how you work, is gold.
Leave perfectionism behind
Furthermore, Jan noticed that striving for perfection is not helping him in his role as a leader.
My perfectionism was making it all much worse. I had to unlearn it. When being a leader you just have too many things to do to be a perfectionist. You can’t make everything perfect because you sacrifice the most important thing — your time. You have to pick what should be better and what can stay as it is.
It is interesting coming from a technology lead. That you need to leave perfectionism behind to deal with your everyday work. And sometimes even consciously settle for less, which means you need to prioritize well what you will do and how you will do it.
If you always go for the perfect solution, then you can’t explore. You don’t allow yourself to experiment. You’ll go to the top of the current peak but the whole range of mountains could have even bigger peaks, so you might need to go in different directions to see that maybe you’ll get even higher.
Also, faster isn’t often better — Jan gives us all a reminder, which is rather obvious but we often forget about it. Yet, as he says it all boils down to the situation and a given problem. While in one situation we shouldn’t sacrifice quality, in another putting a lot of effort into improving it might give little results. The point is to be able to distinguish one from the other.
Faster isn’t better often, by better I mean in quality. But sometimes the quality is not that important. The raises a lot at the beginning and in time the improvement of quality is fairly small given the effort. It’s like the 80/20% principle — 80% of the results can be achieved with 20% of the effort.
Learn about psychology
Jan also explains how understanding people better helps a lot in the job as a manager. Jordan Peterson’s “Personality lecture” from the University of Toronto is great for that.
You can understand yourself better and you can understand others better. What is common between people how they differ. E.g. some people’s values are different in a way that makes others go “How can you not understand this, are you stupid or something? This is important!”
No, they are not stupid, they are different. They have a different set of values which means that they want different things to happen.
Why is it important?
As I see it, you are an expert in a certain domain. For leadership, you lack physiological skills and some actual solutions that are useful for the company.
A cheat sheet for great books
Another tip Jan has for other leaders is to use the Blinkist application. It’s like listening to audiobooks but they are shortened to the most valuable points. The app has a library of non-fiction book summaries that last 15 minutes on average. You get the most important points from a given book — you can both listen to them or read the summary. It’s like the 80/20 rule — you get the most vital points with very little effort.
Coaching and mentoring — delay pitching in
You are not any less of a leader if you are not the first one to propose a solution. As a matter of fact, the more you empower the people and include them in the conversation, the greater leader you are.
“People learned that I will give a good enough solution right away and they don’t have to think. So I began to delay pitching in. To give time for others to think and propose something themselves. It really helped!”
This is such a common misunderstanding of the role — the leader needs to know all answers to all questions. This couldn’t be further from the truth. In fact, the greatest leaders that I know, read, and follow — they all agree that admitting that you don’t know is the breaking point in your relationship with the team. It is one of the first steps on the road to creating psychological safety for the teams. If you’d like to learn about one of the greatest examples of where admitting to not knowing much can lead you, read “Turn the ship around” book by L. David Marquet.
Jan sees a lot of benefits to delaying pitching in with the team.
I saw that the overall quality of a solution picked this way was better. Because we explored more ideas and people were actually thinking about the improvements. So even if I later gave an idea from the top of my head, they started to improve it instead of just accepting it!”
The team concluded it is safe to have different and maybe even some better ideas than the leader himself! Imagine that for your team!
Technical Lead as a hat — the role (un)confusion
Last but not least, I learned that apart from having functional leads in the organization, there is also a Technical Lead role in the teams. Therefore I asked for a clarification of what a Tech Lead does in this case:
Technical Lead is more like a hat or a role rather than a job. Similar to being a mentor or a coach sometimes. As a tech Lead, I own the decision in which direction a certain technological area will go. I am responsible for the direction of a given feature.
This has been a great chat. I learned a lot from my little brother! It is amazing how many skills we consider innate for some people can be learned and mastered throughout our whole life. I hope listening to Jan has been just as encouraging to you as it was to me. Would love to hear what you think — leave a comment to let me know!