00:00:16.050
Awesome! Yeah, so let's get started. I wanted to kick off this talk by discussing what it means to be a senior engineer because I'm sure a lot of you have that question. It's a difficult thing to answer. Most people I talk to who are entering the first phases of their careers and are really driven to move up in positions often want a bullet list of items. They want to know what they need to do to become a senior engineer, but it's never that easy to pull that together. Most people gravitate towards the technical aspects. They think, 'I need to know these libraries and Ruby; I need to do all these different things,' which is definitely important. However, if you were to talk to a lot of people in engineering leadership positions, they would say, 'Yes, that’s important, but it’s really only part of the big picture of what it means to be a senior engineer.' That's what I will delve into today.
00:02:00.680
When I'm hiring senior engineers, a big portion of it is wanting to see that they understand they can't do everything themselves. Most software today is built by teams of people; very few pieces are built by individuals. When you're working with a team, and you have a lot of knowledge in your area, your primary role becomes leveling up the team and spreading that knowledge you have. This is really important to the job description of a senior engineer, but it's not something we always talk about. So, I want to dive into that today with you. How do you start leveling up a team of engineers? You do that by teaching, and teaching becomes a bigger role and a driving force in your career as you move further into the engineering discipline. You have to become a good teacher since you want to learn how to have a significant impact on your team. Being a senior engineer is all about having that impact; you can’t write all of the code yourself. You need to work with the people around you, and you can have a much bigger impact on the codebase by teaching them to become better coders and spreading that knowledge around.
00:02:54.540
It's all about becoming a high-impact engineer, which is why they pay you the big bucks as a senior engineer. It's because you can be pulled onto a team, and you're going to make a huge difference—not just in the code you write, but in all the code the team produces. Teaching is going to become a big part of your career as you move forward, and I want to provide some guidance on how to do that. I’m guessing most people in this room didn’t go to school to become teachers. Did anyone? Oh, damn! I thought we had some boot campers here! I didn’t go to school to become a teacher; I went to school to become a coder. I hear a lot from new engineers asking how they are supposed to acquire all these teaching skills. It’s something I’d like to tackle since when I learned it, I did so by trial and error. I hope to provide many lessons learned to you today.
00:04:36.860
My background is in Computer Engineering. I started in that area at university and began working for Mavenlink right out of college. That team does exclusively pair programming, so I quickly learned how to teach and how to engage with people daily. I moved up through my career at Mavenlink and attained team lead positions, where it was my job to level up the team and deliver our features. Now, as a director of engineering, I focus even more on helping teams grow. I used to be an extremely shy person, especially in high school, and it took a lot to learn how to stand in front of people and teach them something. I want to show you that anyone can teach, and I'm hoping to help you get there today.
00:05:28.300
So, the game plan for today is to discuss eight lessons that I've learned over the past five years working in engineering, trying to level up the engineers around me. I hope this will be helpful, as we go through each lesson one at a time to see how it applies to engineering teams. The first lesson I learned is that a question from someone on your team is a huge opportunity for growth for that person. There's much more potential in a question than most people realize. When you go to work, you're sitting at your desk jamming on some code; you’re probably concentrating—maybe you have headphones on and feel really focused. At some point, someone comes by and interrupts you to ask you a question. Maybe they have a blocker, something is bothering them, or they’re trying to get information from you because you’re the most experienced person in that area.
00:05:58.630
What do most people do in these situations? They often just think of a response. They might say, 'Just merge with master and move on.' However, they basically never answered the question—they didn’t provide the context or background to the person asking. This is common among many engineers, who want to focus on their work and don’t necessarily pay attention to the interactions with their coworkers that could leverage that opportunity that the person presents with their problem. They may be highly motivated to fix it, and if you could provide them with more information around the context of the problem—even if you already fixed it—that could help them tremendously more than just telling them to merge with master.
00:06:47.280
Let’s reframe this and look at better approaches. One effective approach is to start asking questions. If you know the answer, try to help the person reach that conclusion themselves. They will learn a lot more that way and be able to use that knowledge going forward. For instance, if it’s an issue related to bundler, a great way to start is by asking, 'What does the error say? Did you read the error message? Tell me what it says.' Most people don’t read it! Then, ask them questions about the context of what's happening. For example, 'Do you understand what they mean by this error? What's happening? Do you understand the underlying context of this situation?' You can also ask them to consider what has changed because most of the code they're working on probably worked initially, and something has changed that's now causing the problem.
00:08:04.720
Hoping to assist someone towards the solution part of the process could involve narrowing down the scope of the problem. If someone feels overwhelmed, they often think everything could have caused it. So, help them to narrow it down, suggesting, 'We’ve only changed two things since the last time this worked; it has to be one of those two things.' This is just one of many approaches you could take. I encourage you to start asking questions instead of just providing answers, as this will be much more helpful to the person you’re talking to.
00:08:46.290
The next lesson is to learn to tailor your responses to your audience because everyone absorbs information differently. You’re not just talking to the same person every time; they all have unique backgrounds, experience levels, and comfort levels with the topics you're discussing. You really want to hook into that so you can have a more effective teaching moment and communication with them. One useful technique for tailoring your responses is something Max Lamberg described in his book on coaching—this is called the skill versus will matrix. This model helps you determine what teaching approach to take with someone at any given point. In this model, you essentially have two axes: one for skill, which refers to someone’s ability to accomplish a task, and the other for will, meaning their motivation or drive to do so.
00:09:23.370
These axes are split into quadrants, and depending on where someone is in these quadrants, you can figure out which teaching technique will be most effective. As you move through your career, you’ll bounce around this chart at various levels—the scenarios people often fall into are common. For example, a junior engineer is a good case; when they first enter a company, they are really excited and motivated to learn. However, they may not have had much time to build their skills yet, so they are relatively low on the skill axis but high on motivation. For these folks, you want to adopt a specific approach to teach them, as they are motivated to learn and will start figuring things out on their own, but you still need to give them a bit of guidance.
00:11:11.240
Think about providing tools and training while removing obstacles they may face as they navigate their new role. If you foresee this being a problem and they’re going to get stuck on something they're unfamiliar with, try to remove that issue ahead of time to create a more effective learning opportunity. Reducing risk is similar; see if you can mitigate any large issues that could impede their progress, thus making the learning experience smoother for them. After a month on the job, junior engineers might experience a dip in motivation because they begin to realize how much they don’t know. They find themselves overwhelmed by the code or gems, leading to anxiety. This is a common emotional cycle in entering a new codebase or job.
00:12:04.540
After their first month, junior engineers may have a similar level of skill but show decreased motivation compared to their first day. For these engineers, you want to take a more direct teaching approach. Provide clear explanations of what you want from them; help identify their motivations behind your decisions. Don't just tell them why you're making choices; explain your logic so they can use it moving forward. Develop a shared vision of success with these engineers by clearly defining what it looks like to do well in a specific area. Without high motivation levels, they may become lost, floundering, and needing direction—this will help them regain focus and confidence.
00:12:56.000
Now, let's discuss mid-level and senior engineers. Mid-level engineers are usually highly skilled and motivated. For these individuals, you want to take a lighter touch when teaching. Opt for a delegation approach where you provide less hands-on guidance, as they know what they're doing and are eager to learn. Communication of trust is crucial in this role because they may not realize how well they perform. Building their confidence with encouragement can enhance their productivity since they are both skilled and motivated. As they progress, help them establish stretch goals to foster their growth or broaden their responsibilities. Sometimes senior engineers may experience a drop in motivation, even though they are highly skilled. They may feel bored if they have been doing the same work for some time. This is common for senior engineers in long-held positions.
00:14:09.680
For these individuals, your primary teaching approach should be excitement. Instead of teaching them the technical aspects—which they already know—focus on reinvigorating their motivation. Point out challenges in their work that may have gone unnoticed or areas that could reignite their interest. Align their interests with their work to keep them engaged; for instance, if they enjoy functional programming, see how you can integrate that into their projects. If you give them repetitive tasks without variety, they may become disenchanted and fatigued. Balancing challenges with engaging and interesting work is vital.
00:15:14.600
To summarize, there’s a cheat sheet approach to teaching moments with engineers of any level. Ask yourself two questions: how skilled are they at this particular task, and how motivated are they to learn right now? Use those insights to tailor your approach to teaching. The third lesson I’ve learned is that as you start sharing your knowledge, resist the urge to take control of the keyboard. It may feel instinctual to do the typing to show someone how to do something, but doing most of the typing for someone you’re trying to teach isn't effective. In fact, if you’re doing the work for them, you likely aren’t teaching them anything. It becomes a significant red flag when you realize that they may not fully grasp what you’re demonstrating.
00:16:31.840
I would encourage you to resist that temptation as best you can. Teaching is all about empowerment. The only scenario where doing the work may be appropriate is when you set up an example for someone that they can replicate back later. This approach can help clarify, but make sure they understand what that example does; if applicable, let them type it out as well. Watch for mimicry in the individuals you work with. This occurs when people replicate existing code or behaviors without understanding them. You might hear someone say, 'Hey, I copied this line from another file because I thought it would work, and it does!' This is a huge red flag.
00:17:46.640
If you hear this from someone on a professional engineering team, it signals a warning. You need to sit down with them and explain why that code works. If they don't grasp what the code does, they may introduce bugs down the line. Understanding is critical; if they don't understand it now, it will create larger issues in their future work. While it's common to reference code from resources like Stack Overflow, that's part of the learning process when adapting to new frameworks. However, in a professional setting, you shouldn't bring practices like copy-pasting code into production without fully understanding it. Encourage your team members to ask questions about what they're using and to confirm they know why it's working.
00:18:41.460
The next lesson focuses on understanding that senior engineers need to emphasize communication skills. Teaching is all about communication skills, which are critical to your career, regardless of where you want to go in engineering. In relation to computers, human communication is poor. We often lose information when talking to one another or writing things down—the meaning and context behind our conversations can suffer. George Bernard Shaw aptly pointed out that the single biggest problem in communication is the illusion that it has taken place. I encourage anyone entering engineering to put a focus on communication. It's not something we talk about in engineering school, and it’s an area where we often overlook improvement.
00:20:16.739
You can actively work on your communication skills alongside your technical ability. For example, I am very analytical, so I measure my conversations, especially when talking to groups or teammates. When I need to communicate something important, I observe how much information is being received. Watching the audience's body language helps: I can tell whether they are engaged or confused. Ask them to repeat or rephrase what you've discussed. Are they accurately reflecting back your ideas? If not, this indicates a communication gap on your part. It’s not their fault necessarily—they might just not understand because the communication wasn’t clear. Recognizing this will help you improve.
00:21:48.960
As we move into our fifth lesson, it's important as a teacher to have realistic expectations for yourself and the individuals you're teaching. It's easy to become frustrated when you feel you've explained something perfectly, yet they still do not understand. Teaching is a marathon, not a sprint. People need time to digest information and level up in their understanding. Acknowledge the small victories, as they will provide motivation for both you and your students. Remember, not everyone will absorb every piece of information you share—that's normal. To mitigate this, build in ways to repeat important lessons; repetition can solidify understanding over time.
00:22:55.140
An additional benefit to being in the position of teaching is that it also reinforces your knowledge. When you teach someone else, you have to articulate what you know so they can grasp it. This process builds your confidence and reinforces your own understanding of the subject matter. I encourage everyone to look at your team. Who could teach something today? A new engineer, even if they've only been there a week, could teach you about their recent experiences or things they’ve learned. This fosters a great learning curve and allows them to build confidence in what they are doing—plus, they need to be able to explain their knowledge to others.
00:24:21.680
Another significant aspect of teaching is the potential for feedback. After a teaching session, if you’ve established a good rapport with the individual, they can provide valuable feedback on how you can improve as a communicator and educator. This reciprocal process benefits both parties, enhancing your learning experience as well. Lastly, I encourage you to communicate with your superiors about how you can learn more effectively. Discuss your needs for learning opportunities with your colleagues or managers. They are likely trying to find ways to make you a more effective engineer since that is their role.
00:25:57.700
Often, there are mentoring or teaching-focused practices integrated into teams, which are very effective. For example, at Mavenlink, we practice pair programming, which emphasizes teaching and the back-and-forth transfer of information. Additionally, we’ve introduced a practice called show-and-tell at the end of the day, where engineers gather to review the code they wrote that day. This process allows for consistent feedback and discussions about their approaches, fostering continuous learning and communication. With this practice, no code goes without review for long, which helps catch mistakes early, and it offers opportunities for engineers to regularly discuss their work.
00:28:27.920
Conferences are also excellent teaching opportunities. Talk to your manager about helping prepare a submission for a conference; it’s a great way to develop communication and teaching skills, and it’s beneficial for your company when you advance as a professional. Engaging in these experiences is a win-win. I hope these lessons have been helpful and save you some of the trial and error I went through while growing into the engineer I am today. Before moving on to the next talk, I'd like to leave you with this quote: 'True learning involves a permanent change in the way you see and act in the world. The accumulation of information isn't learning.' I hope today you learned something that will change how you think or behave, making it worthwhile.
00:30:03.820
I think we have time for questions if anyone has anything. Yes? Could you repeat that question? He was asking if I had seen mentoring as a great opportunity for senior engineers who may feel demotivated. Yes, I think that’s a great point. In the programming community, it’s often the opposite where teaching can lead to burnout, especially if senior engineers are continuously teaching. But mentoring others can enforce how much they know, serving as a motivational boost for their confidence and their ego. Teaching can be incredibly fulfilling for an experienced engineer, especially if they feel stuck in their own world.
00:32:12.490
I think mentorship and collaboration within the team greatly benefit everyone involved. For example, two new engineers may start at the same time with comparable skills, but one may prefer structured guidance while the other may take a more self-directed approach. Knowing their backgrounds can be key in helping identify who needs more direction. Also, remote work creates a unique situation, where using tools like persistent Google Hangouts can help make communication and engagement more manageable. Understanding body language through visual cues can enhance collaborative efforts even from a distance. Ultimately, the biggest takeaway is to seek opportunities for sharing knowledge, whether it's through teaching others or simply engaging in discussions about problems you face every day.
00:34:25.820
You want to create an environment where everyone understands that questions represent growth and learning opportunities rather than tests. When someone asks a question, ensure that both parties feel comfortable and engaged in discovering the answer together. Using principles from the skill versus will matrix can help gauge how much guidance to offer while also assessing the motivation levels of your colleagues. In every teaching moment, make an effort to frame the experience as a collaborative learning opportunity. Remember, communication is key to effective teaching and learning. Thank you again for your time!
