Mentoring
From TheCommandLineWiki
Part of The Inner Chapters Unbook.
Originally part of podcast episode number fifty-six].
Dedicated audio available from Podiobooks.
Contents |
Original Notes
- My mentors
- Tanya - professionalism
- John - importance of design
- Brandon - functional decomposition
- Trithemius - peer mentoring
- Mentoring is not leadership
- Help desk management flop
- Skills don't overlap
- Sometimes even conflict
- Good mentor helps the mentee find answers
- Mentee sets the pace
- Mentoring should improve mentees ability to find answers with confidence
- Humility is especially important
- Not about what you want to say
- Sometimes the mentee knows the answer and just needs you to ask, "What do you think?"
- Especially true of peer mentor
Transcript
I have another installment of the Inner Chapters, this week on mentoring. I mostly wanted to talk through some of the mentors I've had over the past years and I have currently, and some salient points that occurred to me with thinking about what mentorship means, both as a mentor and someone receiving that mentorship.
Now as to my mentors. I guess my first one was a lady by the name of Tanya back in college when I was working at Technology Services. And there, I pick her out not necessarily because she mentored me about the technical material at hand — I understood a lot of it, there were a lot of peer mentors, a lot of other people to learn from at the same level on the technical front, but what I think Tanya taught me or really reinforced for me for my first "real job" was to conduct it with the utmost professionalism. And I think that's what I really took away from that experience: that in interacting with my managers there (so this was the first job where I had managers other than the family business, you know, my relatives), how to conduct myself well, how to make my concerns, my questions, my comments understood and well received. When I went out, not so much for the student lab support, but when I went out to the faculty, how to address some of the non-technical issues, how to instill a sense of confidence in them that I was going to solve their problem, how to understand the anxiety that they were feeling — you know in a help desk, in a technical support rôle, people feel a great deal of anxiety, fear, and frustration when they're having a problem, especially when they're working on a project that's very important, maybe that has a deadline or that has a considerable investment to date, and they're feeling pretty bad about having problems with their word processor or their computer in general. So you want to, first and foremost, instill in them a sense of confidence that you're going to be able to solve their problem. And I look to Tanya the person who really taught me about that aspect of that job.
The next mentor that I had was at the first real job I had out of college. And this was the one where I successfully made the transition out of doing technical support and into doing programming. And as I was teaching myself a lot of the programming skills and trying to find a lot of opportunities at the small consultancy I worked for at the time, there was a trainer there (because we had a training division) named John who worked with me on I think one of the first non-trivial projects that I worked on there. And where he really helped out there was making me understand how important design is to any undertaking, any technical undertaking. There wasn't a lot that he needed to teach me about programming in and of itself, but we had a lot of thrash with — we were building an internal recruiting system because, it being a consultancy and it having some aspects of a body shop, what was very important was bringing in a lot of new people into professional services, into network engineering, and placing them out on contracts. That's how this company generated their revenue. So we were building a recruiting system for the internal recruiters as these recruiters who had never been through anything like building your own custom software before, so they didn't really understand the requirements process — no reason that they would. They'd change their minds every couple of weeks. John was the one who taught me the importance of making them understand the consequences of them doing that: that once we had started to do the design work, if they came in with any requirements change, they'd either have to be queued up as system enhancements for when the system was completed, or we'd have to go back to the drawing board. In essence, it was a very practical lesson for why they're not allowed to change their mind. We give them, you know, an adequate window for them to kind of think, mull over what's most important, then we help them prioritize. But once we start doing the design work, that's it. I mean, you need to be able to proceed from there. If there are any changes in mid-stream, John was the first person who taught me the importance of going back to the drawing board and saying, look, any of these changes may have invalidated assumptions that inform the design, they may have changed the priorities of the various design pressures that inform the design. So you have to start over from scratch. And then taught me some implicit lessons then about how you can use that for leverage back to your requirements stakeholders to go, "Do you understand that there's a nonlinear cost in you changing that one point? There may be a 2 to 3X multiplier". Because it's not just the cost to implement the feature differently or to reimplement the feature, but it's also the cost of redesigning and reintegrating in into the total system.
5:38
My next mentor was more of a peer mentor, I think, to be fair. I don't think he sees himself as a mentor, but Brandon taught me a lot more on the technical side, and there getting into, I think, some of the more what I see advanced or subtle aspects of my technical capabilities. So Brandon taught me a lot about functional decomposition. I give him a lot of credit about how I think about actually breaking a program down. So it's not enough to understand the algorithm or the functional flow of a system from start to finish. It's the act of, once you've got that all in your head, how do you start to decompose that? How do you reduce that to a simpler form? How do you find those maybe non-obvious solutions that in retrospect turn out to be easier to maintain? They don't match the requirement one for one, they're not a literal transcription of the requirement, but in the final analysis they make a lot more sense from a computer's point of view.
So he kind of broke me out of that object-oriented pitfall of thinking that well, now that we have these object-oriented tools we can just describe the problem domain exactly, and that's an adequate solution. I guess it's no coincidence that Brandon had advanced degrees both in computer science and mathematics. And in mathematics, as Epsilon Delta [unclear, 7:04]'s blog talks about, an important aspect of developing a proof is, once you have the literal, complete [unclear, 7:12] proof, you must step back and try to reduce that. I think there's an analogue in programming that not enough people follow through on. I've talked about this before, that once you have that design on the white board you're first instinct is of course to go off and program it. And that first instinct is wrong. The next thing you should do is say, "What can I take out? How can I make this simpler? Is this literal interpretation really the best, or is there a better, simpler way of going about this?" And I think Brandon is the one who really is responsible for really driving that lesson home with me and helping me understand that.
And much as Brandon's case is by example: his code was very readable, the comments were excellent, and I think one of the things he strove for (and I talked about this very early on in the podcast in talking about the practice of refactoring) is that what he strove for is that for any code block, so any method or function that you read, it should read like an English paragraph. And then each line could then drill down to its own paragraph or set of paragraphs from there, so that at any level that you are at reading the program it made sense in and of itself. And if you needed to go down a level of abstraction to more detail, your program flow supported that kind of compartmentalization of concerns. So that was an excellent way of approaching problems that Brandon taught me.
8:32
My lightest mentor I would have to say, very much in that same mode as Brandon, much more of a peer — we're definitely peers where we work — is Trithemius. I've mentioned him before. And the reason I mention him in terms of mentoring is that, I think one of the things in our professional relationship that we do very well for each other — at least I get out of our professional relationship; I like to think that that's reciprocal, of course he'll tell me otherwise as he's a sometimes listener of this show — is that we very often check each other's thinking. A lot of what we do overlaps, we do similar things, especially now that he's worked on this stand-alone product, so there's a web interface and a web server on the control panel itself, so it's a self-contained solution, and he runs into some of the same UI and information architecture concerns. He has to solve some of the same kinds of problems in the small and the embedded system that we solve on the web application in the managed environment.
And then there are obviously areas that don't overlap where he's working more directly in the firmware. But a lot of the problems can be articulated generally enough that, whether you're an embedded programmer or not, you can understand differences in approach. And so very often he'll come to me with questions of, "Here's what I'm thinking. And here's my first alternative to what I'm thinking about that". And then I think the rôle that we serve each other more often than not is sometimes there's a good, fruitful suggestion that says, "Hey, this sounds very similar to something in my experience, did you think about this third alternative that maybe you didn't think about it". And that kind of enriches the discussion, maybe broadens back out the design a little bit to maybe shake out some local optimization and find a more globally suitable solution. But more often than not we serve as sounding boards for each other, and I think that he's a very good listener, and I know I try to be a good listener for him, and try to realize that that's what he needs out of that kind of peer-mentoring relationship is: he has a question, he's working it through on his own, he's gotten too locked up in his own head, and he comes over and he just talks to me about it. And I've talked about the value of conversation before in past podcasts. So I think that can be a component of both peer mentoring and traditional mentoring.
I'm running out of steam, and thankfully I only have a couple of other points I wanted to talk about. And mentoring is a rich discussion. We may have to circle back to this later, especially if I get some feedback on this, we may have to talk about this some more. But one common mistake I've seen, and I know I've found myself falling into this mistake myself from time to time, is that mentoring is not leadership. It's definitely not the same thing. I got into doing some peer mentoring early on in my career when I was working on a help desk contract — this is the first job out of school, this is before I met the mentor I talked about, the second mentor I talked about, John, I was still doing help desk, and I very quickly got pushed into a position of leadership and thought that the skills that I was just starting to develop as a peer mentor could help with leadership, with managing and leading a group, and unfortunately in mentorship, whether it's like I said traditional or peer mentorship, very often it's about emphasizing somebody else, it's more about the personality skills, good conversation, understanding people's problems and helping find solutions. And in that case I had a problem employee, we were basically tapped with getting rid of one of the resources on the contract because the contract had come up for renegotiation, we had to cut back, and I had one clearly in mind that wasn't performing, and instead of being upfront with him and saying, "Look, this is the position that I'm put in. This is the reason why I made it. Whether you agree or you don't you have to understand where I'm coming from. It's not personal despite the personal relationship we had previously".
Unfortunately that's not what I did. I wasn't up front with him, I tried to save his feelings because there was that personal peer relationship, and that ended very badly. He felt betrayed more so than if I had been up front with him and just said, "Look, it's not you, this is what the customer is saying about what they were willing to pay for this maintenance contract. We have to cut back one in order to meet and be able to stay viable with that customer". So like I said, in that instance a lot of the things that can make you a good mentor as a peer or as a traditional mentor can be in conflict with being a leader. But it's a very easy mistake to make. Very often people imagine a traditional mentoring relationship to be someone, you know, the mentor is above the mentee, and I think that that's not true. I think that the division between peer mentoring and traditional mentoring is not as strong as most people like to think. I think that, as a mentor, you learn as much from the people you're mentoring as they learn from you. Or at least, if it's working well I think that's how it should work.
So unfortunately the empathy that you can have as a mentor, as a peer, can serve you falsely, can color your instincts and bias you in ways that make it very difficult to be an effective manager, an effective leader. So that's just something to be aware of, that you may need to compartmentalize those skills in your own mind. You may need to find a way to signal with people that you're working with if you are in a leadership position as well that "I am wearing my leader hat now, and so I must talk about things as a leader, as a manager, that aren't going to be as comfortable and easygoing as when I have my mentoring hat on". And that's a tough lesson to learn. That's what I'm still struggling with.
Fortunately I'm not as much a manager as a leader, I'm much more of a first among peers, a principal among peers. So I'm not pushed into that situation as much as I have been in the past. But if you find yourself there, then you may want to think about, as I said, about how you signal that — which rôle you're operating in and try to make it clear to the people you're working with that "I can be your mentor right now" or "I can't be your mentor right now; we're in a circumstance where I have to be your manager and I have to act appropriately".
14:32
The last point I wanted to make — and this kind of dovetails with my point about, a good mentor learns as much from the person they're mentoring as vice-versa — is that I think the best mentors help us to find answers rather than give them to us. It's very easy to have that expert-within-an-earshot experience of, you know, "Hey Bob, how do I execute that command line again?" instead of going to the man page, instead of remembering it, finding some trick, better get writing a script so you don't have to remember all the fiddly little command line bits. You have to, as a mentor in that circumstance, you have to let the mentee set the pace. You have to let them come to you. This kind of dovetails with my experience about mentoring as leadership as well. Some people that are new to mentoring want to lecture, they want to pontificate, they want to show off all the knowledge that they have and just cram it down the mentee's throat. Unfortunately, if the information being shared, the information being given out, isn't relevant to the problem the person being mentored is trying to solve at that time, it's useless. So you have to wait and see what questions and what problems the mentee has and allow them to come to you and say, "Hey, here's what I'm working on". And let them finish their thought. Let them completely describe what it is that's going on. Don't jump to conclusions. Let them finish. I think that if you do that properly you're going to improve the mentee's ability to find answers with confidence, that if you &mdash one of my favorite tricks is the, "What do you think? Does that seem like an appropriate solution to you?" So you're really not...
It's more to my point where I was talking about Trithemius as a peer mentor to me. It's not so much about, he comes to me looking for an answer; I go to him looking for an answer. It's more that sounding board effect. It's, you know, they aren't confident in the solution they have. Maybe they're 60, 70, 80%, so they're definitely on the positive side of being confident about it, but not quite. So they need a little validation, they need a little extra push to say, make the decision that that's the way to go. They're mostly there, or they're enough there that there clearly is more than a coin toss involved. So you need to have some appreciation for that. Say, "You know what, he's done his homework, this sounds good to me", so you find a way to positively reinforce the good things. If there are things to be critical of you have to be constructive. You don't want to tear them down. Humility definitely enters into the equation. I think it's arguably the most important aspect of being a mentor. I think that's part of what I've been trying to drive at all along, is that, like your first bite at the apple of management, the temptation is to say, "Well, I have the authority and I get to tell people what to do", and with a mentoring relationship the temptation may be similar. "I am the mentor, and I can tell the person I'm mentoring what to do, and I know so much more than them." Well, maybe you do, maybe you don't. Maybe you have more experience; maybe you don't. That's not really what it's all about. What it's about is helping them. And in the process if you can help yourself too, you know, find those opportunities to learn from.
And you'd be surprised. We have a young team member at work who is an amazing debugger. He's just — the forensic mindset here, how he's able to slice through and get to the exact line of code, and he doesn't always have the confidence or the awareness to realize that's what he's done. But in my experience, nine times out of ten when he says, "It seems to be this line of code", he's right, and I've come to trust that. So as a mentor to him, my challenge is to make him understand that his instincts are really, really sharp. So I give him a lot of positive feedback when he finds problems in my code that we didn't even know was there. I try to make that abundantly clear to him. I said, "Not only did you find a bug, but the line that you pointed out?" "Yeah?" "That's, you're right. That's where it was, and here's why". And we'd go through it in detail, and that improves his confidence over time. So eventually — hopefully he won't get cocky. That's, I guess, part of the problem too. I don't want to build him up so much. — But eventually when it gets to the point that he's confident, and he'll come in and say, "I'm going to make this change", and you go, "Yeah? What changes?" And he'll go, "Well, I was working on this, I found this problem, I tracked down this line. I think this is the solution. Look good to you?" And I'll go, "Yeah!" And that's all the input that he'll require to then go off and do the right thing. And that's, I would say, a good description in a nutshell of a success scenario with mentoring. Now he's a fully independent, peer member of the team. That's ultimately what you want to have come out of that.
