Managing Up

No matter what your profession or what your role is in your company you alone are not going to be able to achieve everything you want or need to without the help of those who are higher on the corporate ladder than you. In the course of your career you're going to need the buy in, sign-off, and/or advocacy of your superiors to fully accomplish your goals. As such, managing up is a key skill to learn to be effective.

Here are some tips to help you be more effective when managing up.

Know what you're audience values

You're more likely to achieve your goals if they are aligned with the goals of those you need buy-in, sign-off, or advocacy from. So the first step in managing up is actually understanding the goals of your superior. Understanding their goals will help you understand how to motivate them to help you accomplish your goals. In trying to understand their goals try to find the answers to the following (in no particular order):

1. What are their near, mid, and long term plans for their customers?
2. What are the current challenges they are facing?
3. What role does your team or project play in their plans?
4. What trade-offs have they recently had to make?
5. What are the outside influences to their plans?
6. What defines success for them?

Be willing to change how you accomplish your larger goals

It's important to understand where your goals align and share commonalities and where your goals are at odds. When your goals are at odds you need to decide if (1) your goal is really crucial to your overall plan or success or (2) your goal is merely a stepping stone that can be achieved in another way which is more inline with the other persons goals.

Help to connect the dots between your goals and their goals

When your goals are complementary you need to bring that to the attention of the other person. Help them draw the lines and see the connections between your two goals. Help them understand that by helping you achieve your goal that they are really moving towards achieving their own goal.

Give options

Decisions are not often black and white. There are usually compromises and/or concessions that can be made that allow you to both deliver enough of what you are trying to accomplish to make it worth while. This is often done by providing options and their various outcomes to your superior. When doing this you want to be clear about what the concessions are and what they are getting and not getting with each option. The main goal is empowering your superior to help you.

Don't just come to a superior with a problem, come with a problem and the various possible solutions and their outcomes.

Make a recommendation that is backed by data

You need to have data that backs up the various options and their outcomes you are laying out. Hard data allows you to help them approach the problem more objectively. This is especially important when what your managing up is not something the person current envisions or thinks they want. It's important to make sure the data your bring is focused on outcomes. Good data speaks to the effects things are going to have on future projects, road maps, moral and attrition, return on investment and opportunity loss costs.

Scaling As a Leader - Learning To Trust But Verify

As a leader, regardless of what industry you're in, mastering the skill of delegation is a must. You cannot scale as a leader unless you are able to delegate the ground work to others. Successful delegation requires a certain amount of trust. But blind trust is the enemy of successful delegation.

Successful delegation means being able to trust that the person you are delegating to is capable, competent, and willing to get the job done. The best way to ensure their success is to follow the trust but verify model. In this model, you follow up with the delegate periodically to determine if:

1. The task is on track
2. The delegate is looking around corners. i.e. identifying what's coming up that's not directly in their line of sight
3. The known unknowns are being addressed
4. The delegate is working to identify the unknown unknowns

One common problem with people trying to implement the trust but verify model is micromanagement. Here are some tips for practicing trust but verify and avoiding micromanagement.

it's okay for it not to be done your way

In most cases there are many ways to solve a problem. Yours may or may not be the best way. Giving your delegate room to figure this out is important. Your primary role in the trust but verify model is to make sure that they:

1. Have thought through the problem and aren't just going off the cuff
2. Aren't making irreversible or hard to reverse decisions
3. Aren't falling behind schedule
4. Are aware of the decisions they're making, specifically with regards to long term sacrifices for short term gains

focus on the outcome

When making sure that the person you've delegated to is thinking through the problem it's important to make sure your questions are focused on the outcome of the task and not on the approach. Remember, you're not solving the problem and therefore the approach may not be the same as if you were solving the problem.

Focusing on the outcome of the task makes sure that whatever the approach, the correct result is being achieved.

understand how to measure success

As you delegate tasks or projects to others you need to be clear about what the definition of done is. Additionally, you should talk with them about milestones that can be defined and achieved before the task or project is complete. Use these milestones to measure the success of the task or project. The best way I've found to do this type of measurement is to create SMART goals.

Leading Well

Understand you're part of a larger system, and are not the center of that system

Your team, your software, and your role are crucial for the success of your company or division. But it's important to remember that you're not THE ONLY thing that lets your company or division succeed. You're one part of a larger ecosystem. Knowing this will help you identify:

1. Your role and your teams role in the ecosystem and how best to contribute.
2. What inputs/outputs are needed from you and your team to make the larger system better.
3. Where you may be a bottleneck to the success of the system.

Do the right thing, not because you're rewarded, but because it's the right thing

Good leaders understand that you're not always going to get rewarded for doing the right thing, but you still need to do it (whatever it may be). Doing the right thing may actually mean you have to take on more work. It may mean admitting that you were/are wrong. It may result in not achieving expectations. Whatever the outcome, it's about doing the right thing because it's right in and of itself.

Make time to step away and remove yourself from the problem space

If you're constantly in the thick of things you're going to burn out, you're going to get sloppy, and you're going to miss key things. You need to make sure that you are giving yourself time to pull back and think through problems.

I'm not just talking about vacations (which are important). I'm more talking about making sure you have built in distance from the problem so you can think. For me, this often happens when I'm riding my bike to or from the office. I have 35 minutes where I don't have anyone asking for my help or input. I'm not being barraged with email or phone calls. It's just me, the road, and my bike. It allows me to take time to think through things critically.

Surrounded yourself with advisers

Good leaders understand they don't have all the answers. But they also know how to get to the right answers. They do this by surrounding themselves with advisers who are subject matter experts on problems that they will never have enough time to become an expert in. For example, the President of the United States has his cabinet and the joint chiefs. These are people whose job it is to know the answers to problems that the president is accountable for helping to solve.

Hold strong opinions very loosely

Good leaders have opinions and are willing to express them. This doesn't mean that good leaders are arrogant. Quite the contrary. Good leaders are able to recognize when their opinions are wrong and are able to adjust. But they're not afraid to go out on a limb and express what they believe is right.

Learning to Lead: Accountability

In my previous post in the Learning to Lead series I talked about leaders needing to be motivators. In this post I'd like to talk about accountability.

Responsibility vs Accountability

As a leader you're often going to be the situation of being accountable while ultimately not responsible for a creating the solution. This is particularly true for managers where they're accountable for the delivery of a project or feature but not responsible for the implementation.

The danger of being accountable for something but not responsible is that you'll either end up micro-managing or under-managing those responsible for solving the problem. There's a really fine line between micro-management and under-management. One helpful phrase I've heard and used in my career is trust but verify. This means that you'll have to delegate to others and trust them relative to their experience and skill-set but verify that they're on the right track.

There are several helpful tools that can be used to practice trust but verify.

• Project burn-down reports
• Agile stories and tasks
• Architectural design documentation
• Daily scrum
• Demo day

Solving the correct problem

Being accountable means ensuring the team is solving the correct problem. This is easier in an agile environment as it's the product managers role in sprint planning to be the voice of the customer. But that doesn't ensure that during a sprint the team isn't randomized by outside work or out of band requests.

Accountability means being able to prioritize and make hard decisions on what the right thing to work on is. Often this means coordinating with both product, management, and other senior leadership to weigh the pro's and con's of new work that comes in.

One easy way to make accountability part of your teams culture is to practice it during your daily scrum. It's up to the engineering lead and other leaders to make sure that as people go through what they're working on today at stand-up that it's the most important work that needs to be completed. If someone says they're about to start something that's lower priority than some other work the team should be calling out the discrepancy and holding each other accountable to working on the correct stories/bugs.

Raising the red flag early

Another area of accountability that I'd like to call out is being willing to raise red flags early enough for them to be acted upon. In the technology industry we make a lot of decisions and set schedules based off of estimates. Once a project is set in motion it's often uncomfortable or unpopular to raise a red flag. As a leader though, you're accountable for the overall health of the project. If your estimates are incorrect or based on incomplete data it's important to raise the red flag as the project is ultimately unhealthy.

When raising this flag the accountable party should be able to explain why the flag is being raised, as well as what it would take to remove the red flag.

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.