I’ve been in the SQL Server space for a long time—my entire career, in fact—but it doesn’t necessarily mean I’m great at what I do; it merely means I’ve seen a lot. I’ve watched things go well and have experienced my fair share of spectacular failures, too. Earlier in my career, I stayed around too long in environments where things weren’t going great. I’m progressively getting better at helping improve the environment when I can
and recognizing when I’m better off elsewhere.
At this stage in my career, though, I’ve felt the urge to be better about
giving back. Not because I don’t think I’m busy enough in my current role or haven’t contributed enough over the years, but because I consider my past contributions a lot more passive than I’d like. Speaking, blogging, and answering questions on forums can be engaging for both sides, but they’re largely asynchronous and often feel like giving someone a fish. More like giving someone a dollar-off coupon for a package of frozen fish sticks—it’s still rewarding, but
I want to teach people to fish.
Earlier this year, the stars aligned, and a colleague (who we’ll call “Stef”) asked if I could be their mentor.
Like changing jobs, I had anxiety about mentoring anyone. To some extent, though, we’re all mentoring people all the time, whether we mean to or not. I suspect this is part of Stef’s reason for asking me in the first place. You’re mentoring any time you’re sharing any of these in any context:
- Knowledge
- Experience
- Skill
- Insight
- Guidance
Those sound like five synonyms for the same thing, but they’re all a little different—maybe a good topic for a future article. Today I’m going to talk in more general terms about helping Stef.
I mentioned to a more senior person in passing I had taken Stef on as a mentee. Their response surprised me at first—they expected someone at my level to be mentoring anyway. This made me really think hard about what I said earlier; how we’re all mentoring to some degree. I wanted to respond we’re likely thinking about different kinds of mentoring—a manager is going to expect me to make Stef a more productive employee for the team and/or the company, and I was already doing that. But I let it go.
Ideally, the type of engagement I think would be most beneficial for Stef will help them in their current role, but why stop there? Why not help them also be more prepared for their next role, and the role after, regardless if those roles are on a different team or at another company? This exchange comes to mind:
“What if we train them and they leave?”
“What if we don’t train them and they stay?”
There’s some grey area here; naturally, I want Stef to do well in their career, wherever it takes them. At the same time, I don’t want to usher them away from my team, either. The best plan straddles the line and combines elements from both while always keeping
their goals in mind. To be transparent, Stef’s goals weren’t initially very specific. Here’s what they said to me near the start:
I’ve heard it’s beneficial to have a good mentor as I grow in my career, and I feel like you have a lot of experience I could learn from. Plus, you’re straightforward and don’t sugar-coat [stuff], which I really respect about you.
We started by setting a regularly scheduled time to meet—once every two weeks, outside of business hours. Multiple meetings have been in person, over a good burger or some tapas.
The first few conversations were high level. “What kinds of things should I learn about next? Do I need a training plan? How can I be better with productivity and time management?” This is about the only time I’ve ever felt comfortable on either side of the question, “Where do you see yourself in five years?”
Based on their answers, I suggested multiple courses to work on independently and offline, like a PowerShell for the DBA meetup going on at the time and Brent Ozar’s then-upcoming free training in October. It’s easy and almost lazy to say go off and do these things and we’ll regroup. But again, I’m not aiming to teach Stef explicit technical things—I’m aiming to teach them how to learn the things they want to learn in a way that can help springboard their skillset and, ultimately, their career. Sometimes the technical things will happen naturally as a part of our day-to-day together, but much of it they’re going to learn by doing anyway.
It’s also easy and almost lazy to suggest reading this or that book, but I’ll be quite honest, in tech, we very seldom “read a book” anyway—there are always chapters that interest us more than others, and even certain passages with an important message to absorb. Stef asked, “What does it mean to be a DBRE as opposed to a DBA?” The question inspired
this post. “What does it mean to be a staff level engineer?” I told Stef to buy these two books:
Then I pointed out a handful of passages to read—including one highly specific to our team here at Stack Overflow.
We shifted to some more localized technical questions within Stack—why does this work this way, how should I implement configuration for this server or that application, and what are the different ways we can solve these specific problems for our unique workload? We talked about the reasoning behind certain design decisions, sometimes good, sometimes less good; importantly, discussing the reason is often as beneficial as discussing the implementation itself. I also had Stef pledge to do a very simple thing within our team every morning—a quick ritual that makes Stef feel like a sort of forger of the bond within our team.
Later, we shifted back to career-oriented discussion. I went through several stories about how I progressed through my career to this point. I explained one of the most effective tools for my own learning was to help other people solve their problems—by answering questions on Stack Overflow. Solutions there need to help the user, but to do so, you need to write them for a generic audience of varying skill levels because you never know how experienced the asker might be or future readers who will also be evaluating your answer.
I challenged Stef to drink the Kool-Aid and go out on the site and try their hand at answering a few questions—starting with problems they already had a good idea how to solve and then progressing to less familiar ground. In parallel, start with general topic areas familiar to them precisely because of their current role, but start moving into areas that might be more relevant to their
next role.
And that’s where we are right now.
There’s no perfect way to mentor someone, but it’s helpful to think about their current role, their next role within the company, and their future roles—even if it’s outside the company.
