Learning to Lead: Motivating People To Solve a Problem

In my previous post in the Learning to Lead series I talked about how being able to facilitate a conversation is an important leadership quality. In this post I'd like to talk about motivation and how the ability to motivate sets great leaders apart from the rest of the pack.

Many people's first reaction to motivation is to think about compensation. While compensation is an important motivator, it's not the ultimate motivator. If you haven't already, go watch the surprising truth about what motivates us. It debunks the myth that money is the ultimate motivator and is a great introduction to the type of things that will motivate once money isn't a worry any more.

I truly believe that the ability to motivate is one of the things that truly sets great leaders apart. Being a good motivator is not about being a cheerleader or always being positive and perky. While those things are occasionally required, motivation is about so much more than your attitude or presentation. Motivation is about being able to call others to action. In the tech industry this is especially important because lack of motivation has a direct correlation to loss of productivity, slipped schedules, and quality code (i.e. buggy and/or unmaintainable).

In my experience as both a software development engineer and as an engineering manager, there are three key areas to focus on when trying to motivate individuals or a team.

Impact

Engineers should understand the impact of what they're working on. This comes in the form of understanding the short term, mid-term, and long term benefits to their customers and their team. They should have enough information to understand why their work is important and to empathize with those that need it to be completed. Most engineers thrive on knowing that their work is being used by other people. It's much the same as an musician being motivated by knowing that others are listening to their songs. Or an author being motivated by knowing that someone is lost in their narrative.

Interesting

This may sound obvious but the work that's being done should be interesting. If your engineers feel that what they're doing is busy work, repetitive, or monotonous they're not going to be motivated to complete it. In this case you need to learn to correlate the current work they're doing with something that is of interest to them. Often I've seen lack of interest when a team is in bug fixing mode or just about to ship a product. In this case it's important to emphasize how what they're working on now enables them to work on the next big thing.

Another way to help make the work interesting is to find a tie between it and their career development. Maybe it gives them exposure to a broader set of skills or technologies. Maybe it allows them to check a box on their career goals or will help prepare them for being promoted to the next level.

Relate

The engineer needs to personally relate to the problem in some way. The best way I've found to help engineers relate is by dogfooding their own software. Using their software everyday in their personal lives will help them see what others are experiencing. It will help them want to fix the pain points that otherwise wouldn't be important to them.

Learning to Lead: facilitating conversation

In my previous post in the Learning to Lead series I talked about how earned trust is the cornerstone to leadership. In this post I'd like to look at another aspect of a good leader; facilitating conversation. Being able to facilitate a conversation may not be at the forefront of the qualities you attribute to good leadership, but I think it should be. Being able to facilitate a conversation shows a level of maturity that's needed in order to lead people successfully.

Ensuring the purpose is known 

Every conversation has a purpose and I'm still surprised at how often I've seen two people arguing with each other simply on the basis of not having a shared understanding on what the purpose of the conversation is. A good conversation facilitator will be able to articulate in a meaningful way the purpose of the conversation. Often this can be accomplished by stating what the desire outcome is right at the beginning. For example, "Today we're here to talk about FOO and make a decision about BAR with regards to FOO."

Getting people to participate

One of the keys to being a good conversation facilitator is getting people to participate in the conversation. This can often be difficult for a variety of reasons like people being uncomfortable talking in large groups, not wanting to speak up, having a lack of confidence, being intimidated by their peers, and etc. A good leader is able to encourage participation in the conversation without it being awkward.

Some tips for conversation facilitation:

• Ask open ended questions. This discourages one word responses and encourages meaningful conversation.
• Don't be afraid to let the room be silent. Often people trying to facilitate conversation will talk and talk and talk so as to avoid silence. Not everyone is an off the cuff thinker. Silence allows people to process what they've just heard and formulate a response. The key is figuring out when it's been silent long enough the the conversation needs help.
• Recap. This is useful at the beginning of the conversation as well as the end. At the beginning of the conversation it's often helpful to recap what the goals of the conversation are. For example, "when we finish today we should have a plan of record for...". At the end of the conversation a recap is useful to make sure everyone heard the same thing.
• If you know someone is passionate about a particular topic but not eager to put forth their opinion, you can try to gently guide them into the conversation. This can be as simple as saying "Tom, you and I were talking about something similar the other day which makes me believe this is something of interest to you. I'd love to hear your opinion on ..."
• Be direct and ask someone else to respond to a particular comment or statement. This can be especially useful when someone is steam rolling the conversation. For example, "Harriet, what are your thoughts on what Bill just said? Do you agree or disagree that..."

Avoiding derailment

Tangents are unavoidable, especially if you've got any "talkers" in the group. But tangents don't have to derail the conversation. A good facilitator is able to keep the conversation on topic. One common reason a conversation gets derailed is if someone else has an agenda that's not part of the purpose of the conversation. A good facilitator is not afraid to steer the conversation back on topic. This can often be accomplished by saying "Jess, that's a great point but I'm not sure that this is the correct venue for it. Let's set aside some time specifically to talk about that so we can use this time to talk about ..."

Another way conversations can get derailed is if you've got someone that rambles. What I've often found is best is to tackle a rambler head on. You can do this by jumping in and saying "That's a great point Sue, I'm curious to hear what other people think about the topic as well." Occasionally you have to be blunt and say something like "Greg, the latter part of what you're saying isn't really pertinent to the conversation at hand, let's stick to this topic now and we can get back to the latter part of what you're saying at another time."

Learning to Lead: It Starts With Trust

In my previous post on being a Senior Software Engineer I talked about one of the characteristics that defines the role is being able to get people to want to follow you. At it's heart the problem is one of trust. People don't want to follow someone they don't trust. What does it take to gain trust? Fully answering that question would probably take a novel. But at a high level I believe there are five key aspects to earning the trust of others.

Honesty

Any conversation about trust needs to start with honesty. At it's core honesty is about NOT deceiving others. As a software engineer that means you're able to:

• Say I don't know when you don't have the answer.
• Remove personal bias when evaluating a solution. When you can't remove the bias, it means communicating that bias clearly.
• Give credit where it is due (i.e. don't take credit for others achievements).
• Publicly recognize the achievements of your team.
• Provide clear, constructive criticism when someone is not doing something well.

Integrity

Being a leader means having a known set of guiding principles that you hold yourself and others to. The key is that you hold yourself to them FIRST. It's also important that the value of these principles is understood by others. It helps if others agree with these principles, but even if they don't knowing that you're holding yourself to your own standard helps earns trust.

Respect

The key to gaining the respect of your peers is to start with respecting them. In the technology industry this means valuing others skills and abilities. Not just the skills and abilities that you find value in, but also the skills and abilities that THEY find value in. Respect involves holding others achievements in high esteem.

Transparency

In my opinion transparency as a leader in the technology industry is not about making sure everyone knows everything you know. That can actually be detrimental to the team. It can add unneeded stress on those that don't have the context or the maturity to deal with the information.

Instead transparency as a leader is about making your motivations known. Help people to understand why. Why you're asking them to do something, Why something is the correct priority. Why somethings not the right direction for the team or project.

Fallibility

The last key aspect to earning trust is being able to admit when you're wrong. Everyone is human and humans make mistakes. Being able to admit when you're wrong sets the tone that it's okay to acknowledge your humanity. Once you're able to admit you're wrong you can start to correct the problem.

Senior Software Engineer

One thing I've noticed throughout my career that's been pretty consistent is the desire of software engineers to be given the title Senior Software Engineer. I've seen many people claim the title without truly understanding what it means or what the role entails.

The Misnomer

Often I've seen people given the title or claim the title based on the number of years of experience they have or based on the fact that they have more technical chops than their peers. Being a senior software engineer doesn't have anything to do with years of experience, but instead is about maturity as an engineer. While the two may be correlated (highly so in many cases) there is not a causation relationship. I've seen just as many tenured developers who were no more senior than their counterparts fresh out of college. It's also not only about your technical ability (while that is a large part).

If years of experience don't define a senior engineer and being the most technical person doesn't then what does? In my opinion a senior engineer is someone who manifests most, if not all, of the following characteristics.

Language/Platform Agnostic

A senior software engineer may have language or platform preferences but they're able to deliver on any platform. This is because they understand system metaphors, abstractions, and compositions well enough to know how to learn what they don't know quickly. They identify the correct metaphors, abstractions, and compositions needed to be successful and realize that the syntax and libraries are just implementation details.  

Able to identify and articulate trade-offs

Building software is always about trade-offs. They are able to take schedule and scope into account when building a solution. They understand and are able to clearly articulate risks. For example, a senior engineer knows that with a fixed schedule scope must be variable. They're able to identify and clearly articulate what the proper scope is and what features are at risk.

They're about shipping software

First and foremost, a senior software engineer is able to deliver software. They deliver software in large volumes. This is largely to do with their ability to understand and quickly get through boilerplate code in order to focus on the real problems. They understand that unshipped software isn't making the business better.

Able to get people to want to follow them

Solving complex and ambiguous problems is a requirement of being a senior software engineer. But being able to solve those problems isn't sufficient for the title. A senior software engineer is able to successfully lead a team. They're able to motivate people to solve a problem, hold people accountable to solving the right problem, and get down to the level of other less experienced developers in order to stretch them and help them achieve goals that are beyond their current abilities. 

Able to simplify a complex problem

Senior software engineers are able to see through complex problems and break them down into smaller, easier to solve, problems.

Understand the correct amount of engineering required to solve the problem

Senior engineers don't over engineer solutions and likewise they don't under engineer solutions. They understand that software is meant to solve a particular set of problems while needing to stay maintainable in order to increase the lifespan and usefulness of the product. They recognize that the elegant solution is not always the correct solution. They also have the ability to take a complex problem and identify the potentially fragile portions of a solution and design around them without over generalizing a solution or making the solution less useful in solving the problem at hand.

They recognize that everything doesn't have to be "built here"

This one is pretty straight forward but difficult in practice. Senior engineers recognize when a particular problem is not part of the groups core competencies and look for external solutions. While a particular problem may be interesting, unique, or fun a senior software engineer is able to recognize when solving that problem in house doesn't add any business value or add burdensome tech debt.