Coaching Corner Volume 5
Welcome to Cameron's Coaching Corner, where we answer questions from readers about leadership, career, and software engineering.
In this post, we'll look at a question from TheRefsAlwaysWin about how to get a new engineer on their team to open up and get comfortable asking for help.
I've got a newish member to the team and they're still early in their career. They've got a good head on their shoulders, however, they tend to go down rabbit holes when problem solving and they don't speak up or ask for help.
They've asked me a few times about "how did I know ....", and a lot of the times, it's experience (I've been doing this for a few decades now).
How do I help them open up and ask more questions to the team and group?
Any time that you have a new member join the team, there's going to be some acclimation going on (the "storming" portion of the Tuckman Stages of Group Development Model). If the team has been together for a while, there could be some personality conflicts at play.
Pretend that you're a student who just transferred to a new school. The kids in the class have been together since kindergarten and you're the new person. It can be intimidating navigating the group dynamics since you don't have context.
For the new member to your team, the same thing could be at play, especially since they're a newer engineer, there might be some confidence issues at play.
Establish Psychological Safety
It might be cliche, but the first thing I'd do here is make sure that they feel comfortable even asking questions. Depending on the environment they've been in, they could have experienced being belittled, bullied, or otherwise put down for asking questions. In one of my first jobs, I remember my questions coming up during a performance review.
If a person doesn't feel emotionally safe at work, then it's highly unlikely for them to be successful because they will be worried/stressed about how they come off, on top of trying to learn the new codebase, problem domain, teammates, etc...
You can demonstrate this by practicing what you preach. Ask questions in your chat channels, in meetings, where ever it makes sense. Let the person know that you want them asking questions as it will help them learn faster than struggling in the corner somewhere.
Encouraging Curiosity and Questions
When I onboard a new engineer, I tell them that they should be asking questions and making all the mistakes that they can as this is the perfect time to learn.
New people have the gift of perspective, so decisions that made sense to the team at the time may not make sense to the newcomer, hence their questions can actually impact change.
I like to tell new team members that if they're not asking at least 3 questions a day, I'm not challenging them enough. No matter how much technical experience you have, there are questions to be asked about our product, the users, the problem that we're trying to solve, or team history that can (or should) be asked.
Another technique I'll use is to make sure they have a mentor that is not their boss help coach them along. By removing the boss/subordinate dynamic, this leads to the mentee feeling more comfortable asking "dumb" questions because they're not bothering their boss.
During the mentoring period, I'll check in with the mentor to see if there's anything I need to encourage or to dig into with the mentee, but overall, the results of the mentee/mentor will speak for themselves and I'll let the mentor own that relationship.
Learning How They Think
On the subject of rabbit holes, this is a super common occurrence for engineers. We get an idea, then we want to try it out to see how it works. What gets us into trouble is that it's three hours later and we're still futzing with a solution.
When I work on a "new to me" task, I give myself a time limit (generally 30 minutes) to make actionable progress. With all the available libraries, documentation, and resources that are out there, if I've not made any progress in that time, that implies one of two things:
- I'm thinking about the problem wrong (shoving a square peg into a round hole)
- I don't understand a core concept, which in turn, is impacting my decisions and troubleshooting.
In either case, it's a good idea for me to bounce ideas off of someone else to help me figure out where I've got something wrong.
Generally, speaking to the duck will help me catch the simple issues, but for more complex topics, I want a conversation with someone to help me flush out the idea/design.
When I work with engineers, I take a more Socratic approach and ask them what have they tried and more importantly why did they think that would work.
The last part is key here, by understanding why they thought it would work, this sheds light on how they think which allows me to see their assumptions and where the gaps of understanding are.
For example, if an engineer is trying to fix an issue in the CI/CD pipeline where one of the tests is failing, I might ask if they've tried running it locally.
If not, then we can dig into why they didn't try that first. This could expose flaws in knowledge (didn't know we could run them locally or how to run them locally) or in troubleshooting (I was looking at the logs, but never though to run them locally).
Regardless, of the answer, this gives me context on where I need to focus my coaching to help get them unstuck and back on track for their task.
Do you have a question about leadership, career, or software engineering? Would you like a different perspective on these topics? Drop a line at CoachingCorner@TheSoftwareMentor.com or you can fill out this form.