I talk to my kids about this all the time. The difference between influence and manipulation that is. It's a subtle distinction but something that makes all the difference when creating content that is targeted at a specific audience. And my audience, people creating value through software, can sometimes be manipulated while thinking they are being influenced. This fact is a large part of why I take being an influential person seriously and try my best not to cross the line between influencer and manipulator. However, I believe I can do better and further classify what I'm striving to accomplish. That next level beyond just pure influence is of being a mentor. In this article, I want to look at the 3 steps that I mentally work through when I think about mentoring.

What is Influence

We all have doubts, questions, or interests in different areas. And we naturally look to others to help make decisions about those things we have curiosity about. Yelp has made a nice business around people helping others. But how does one read and determine that a user is trying to best help them select the perfect restaurant for their next date or if it's the owner of the establishment pretending to be a former customer to "influence" them to book a reservation?

The distinction lies in who benefits.

If I'm going to influence someone, I'm going to give them information in an attempt to shape their decision for their benefit. Let that sink in for a second, "for their benefit".

Let's contrast with what I think manipulation is.

It's the act of influencing someone for my benefit. The distinction is made by who benefits from the person following guidance.

The real gray area here is about when both parties benefit from the outcome. For instance, if I produce an article for which I'm paid that also encourages a user to invest in that product to solve a feature's problem? This is a win/win situation, right? That subtlety is hard to navigate and often comes down to how authentic the source is and do they have a reputation for being manipulative or influential. Remember the differences from above.

Why Does this Matter?

This matters for two reasons.

The first one is that going back to how seriously I take my responsibility. I want you to know that I take great thought into what I create and why I create it. I do this because I love it. I enjoy helping others. I enjoy talking about technology and building things. I won't always get it right but trust that I'll do my best to deliver things as objectively as possible, and where I do have biases, Rust enters the chat, and I'll make those known up front. And if I get it wrong, call me on it, and the worst thing that happens is that we'll have an honest and healthy dialogue and you won't change my mind. But the best thing is that I see your side. Either way, it'll be authentic, civil, and positive.

The second is to give you three steps to improve your ability to influence and then to take it one step further where you start to learn to be a mentor. And make no mistake everyone needs these types of people in their lives. I have several and the most highly successful people I know have them as well. These steps will help you be the mentor for others that you want in your life.

3 Steps

For disclosure, these aren't steps made up for this article, this is my process. High level of course, but it's the way that navigates a discussion with someone when thinking about how to influence their decision for their benefit. I go through this so quickly now that it's like breathing but I do pretty much the same thing when I'm talking to someone live, on Discord/Slack, or when writing an article.

1. Listen

This sounds so obvious but how often when someone is sharing with you about what they are struggling with do we put our thoughts into their words? We mix our biases and preferences with their concerns and questions. And when we answer, we miss the mark or worse have crossed over into the manipulation realm because we start judging them.

What If someone is asking you the best approach to model their Python-coded Lambda Function in DynamoDB? However, instead of listening, we latch onto the fact that they are using Python and ignore the actual question. We allow our disklike for Python to cloud our reasoning and limit our ability to help.

When talking to someone that you are looking to mentor, close the part of your brain that is looking to respond and truly open up both ears and your conscience to the person's questions and concerns. Be present. Put yourself in their shoes. Whatever you need to do to be available. Then when you hear them, reflect on their problem or questions you think you heard so that you can get confirmation that your understanding is correct. Unit test your understanding. If you get a green, you are good to move forward. Still getting red, then it's time to refactor and ask some clarifying questions.

2. Filter through Your Experiences

Before I dig through this part, I want to make a quick detour. Being a mentor does require some experience. It's hard to influence or guide someone if you haven't been through some form of what you are advising on. Imagine getting software management career advice from someone who's been a master mechanic. While there are some parallels and human elements to be drawn from, it might not be the best option if you are trying to reach that next level on your tech career ladder. However, that does not mean you shouldn't be pumping out content. How do you get experience? Well, go experience things. Everyone has expertise in something, so start where you have the knowledge and grow from there.

Now assuming that you have the experience to dive into the questions that you are being asked and you have reflected on their ask through your unit testing, it's time to sort. What I mean by this, is that I will run that question mentally through my experiences looking for ways to relate to the situation. For instance, if someone asks me about how to deal with a peer who is constantly shooting down their ideas, I think back through all of those situations I've been through. I'm looking for positive outcomes, negative outcomes, and neutral outcomes. I'm also going to ask more refining questions to further understand the individual they are working with. Not all experience is applicable, so further sorting and refinement matters.

The same thing applies if I'm writing an article about a piece of tech. I'm looking at the problems that I've solved with it and how I can relate that problem to a broader audience that might have similar challenges. I do the filtering and sorting to make the content specific so that it's tailored to the topic I'm looking to address. This personalization so to speak allows the content to speak more directly to people than just a broad "hello world". By the way, there is nothing wrong with it, but "hello worlds" isn't the path to becoming a mentor.

There is no exact science to this part of the process. And it's ultimately as you grow where your value as a mentor will shine. The biggest tips I can give you though as you learn are this.

1. Be authentic, which means to be yourself
2. Be honest. Don't fudge here because a mentor is about reputation
3. Remember that you are both human and have some compassion. This is a no-judgment job. There might be some real truth that comes from it, but no judging.

3. Follow the Yeses

I've written about this before, but I believe this is the secret sauce to becoming a mentor. Learning to follow a person's yeses. This concept comes from the fact that people are easier to move in a direction when it's a direction they are already capable of moving towards.

Take for instance a JavaScript programmer looking to make the most out of their application that is running in a container but suffering from user pressure. You discover that many of the operations could be done asynchronously. It would be much easier and still beneficial to navigate the developer to using SQS or a queue to help relieve some incoming user pressure. That's a path that they are most likely willing to travel. Whether they choose my preference in SQS or if they decide to pick another tool path, it's still in the general direction. I'm following their "yes".

However, take that same scenario and if my response is, that you picked a slow language, this should be coded in Golang and use channels to take advantage of Go's concurrency model. That's not following their "yes". You might still need the same queuing mechanism in place at some point or even if not, it's still pivoting completely off of the direction they are heading.

That's a simple example but the same thing can be applied to people. For instance.

A person comes to me frustrated that their boss constantly takes over when they come to them with problems. They want to do the right thing, but they'd like to have more input in the outcome. If I teach them to follow their boss's yesses, here's what I might suggest.

First, understand your boss. Are they a control person, a detailed person, a delegator, or something else? Assuming they need data, then go to your boss with 3 well-laid-out plans. Give them the option then to select the plan of their choice but do your best to guide them towards the solution you prefer. It won't always work, but if you pitch three plans you are good with, you've managed to get your boss to follow their "yeses" to something you are "good with". I get it, that sounds like manipulation, but it's really the mutually beneficial influence. Over time, your boss will require less and less detail in the planning and start to trust you. Which is ultimately what you are asking me for. "How do I build trust with my boss?"

Pull that all together into the final step and follow the person's yeses that you are mentoring and that person will have a higher likelihood of succeeding in whatever they've come to you about. You want people moving in directions that they feel comfortable with. There are times that you need to get them to pivot strongly in a different way, but even then, you have to find small and measurable steps that they agree with for them to own their outcome.

Because ultimately you are there to help the person get to where they want to go, not where you want them to go.

Thoughts on the Industry

The tech industry is littered with manipulators. I think some don't even realize they are doing it and others, perhaps for different reasons. It's why I think things are sometimes upside down when it comes to how tech ends up in organizations. Selling in technology is different than in other industries. It's often sold through the engineers. People convince engineers that their tool or way solves all of their problems and those engineers convince their bosses to sign the checks. It goes back to the fact that being a content creator and influencer is something I care about so deeply. And it's why I think that taking on the role of mentor is where I like to live more than just purely influencing.

If I were to take my manipulation and influence distinction one step further. Being a mentor in tech is about using influence but through the lens of the person or people you are looking to influence. It's not pushing one thing but pulling from my experiences to help make the best recommendation for the needs of the audience.

This generation of technologists needs these types of people more than ever because the speed of information is faster than it ever has been. Navigating that data is a difficult task. Knowing what is signal and what is noise takes experience. And having a guide along the way can be invaluable. Imagine getting to the top of Mount Everest without a sherpa. That's a drastic analogy and not nearly as life-threatening, but the point is failure is lurking and experience improves the chances of success.

Wrapping Up

I've been thinking about these steps a lot lately. I've seen many posts on socials from newer technologists who are ping-ponging between the noise of boot camps vs computer science. Use AI to get ahead or you'll never make it. Only code in JavaScript if you want to be a true full-stack developer. Don't rely on the cloud, only use bare-metal Linux and build your own. So much noise and while I think some of that is well-intentioned, much of it is not helpful. And at worst it's destructive.

My goal as a writer is to offer positivity and hope on your tech journey. I've got opinions. Lots of them. I'm an open source fan, who also favors AWS, and loves compiled languages, and event-driven systems. But that doesn't mean I'm not capable of helping you out with a monolithic, closed-source, on-premise build. My love is people and tech. I try not to get too attached to "hotness" of the day but when I do, I own it. Rust has re-entered the article.

My last piece of advice is a non-functional requirement to being a mentor.

Learn the basics. Learn the science. When you have those down, you can make informed decisions about how the current new things fit in those details. And then mix the basics with modern flavor. Software is a team sport and must be done with people. So learn to love the basics but always remember, people are what makes all the difference. And finally, when working with people, applying the three steps above will make you more effective as you navigate your career.

Thanks for reading and happy building!