Do you have the right mechanisms in place to course correct?

As humans, none of us is perfect. Even if we can, on occasion, execute perfectly on something more often than not we all need to course correct at some point. Some examples of when we need to course correct are:

• Having incorrect or invalidated assumptions
• Starting something that has a lot of ambiguity
• Finding out about missing or hidden dependencies
• Having a plan that falls short of delivering on a specific commitment.
• Failing to accomplish a goal, milestone or key deliverable

That list isn't exhaustive and is applicable to the projects we work on, the way we interact with our peers/directs/superiors, career development and many other aspects of our lives. Having mechanisms in place to help you correct your course *before* or soon after you get off track will help you be more successful.  Here are some tips to help you setup mechanisms that enable course correction.

Be willing to change course

As humans change doesn't come easy for us. Once we set ourselves on a certain course we will naturally want to continue down that course because it's easy. This may sound obvious, but course correcting starts with being willing to change course.

What this means practically is that you have to be open to:

1. Being wrong
2. Doing more work
3. Scraping work you've already done
4. Having difficult conversations
5. Asking difficult questions
6. Being relentless about seeking the truth and proceeding with the *right* data

Ask questions that help you understand when course correction is needed

There are several questions that I try to consistently ask when checking in on the progress of something I'm working toward:

1. Where am I on track?
2. Where am I ahead of schedule?
3. Where am I behind schedule?
4. Is there anything I plan to work on that I no longer need to?
5. Do I need to re-arrange priorities?
6. Is what I'm working on right now the simplest/fastest/most efficient way to achieve my goal?
7. What information do I have now that I didn't when I started? How does that change my approach?
8. Is everything I depend on to be successful still on-track? If not, what does it take to get back on track?
9. How does the recent decision about X affect me?

Meet regularly with your key stakeholders and solicit feedback

Making sure that you're on the right course means talking with your stakeholders often. Depending on the context of what you're trying to achieve, the form of these meeting may look different. But the key is that you're meeting regularly and getting as much feedback as you can.

Some common forms these meetings take are:

• One-on-ones: This is where you are meeting with an individual regularly and asking for specific perspective and feedback. These meetings are more intimate and can typically get into a lot of depth. These typically occur weekly or bi-weekly.
• Daily project sync up: Most agile teams do this in the form of a daily scrum. The purpose of this meeting is to make sure everyone is aware of hyper local changes. Talk about what was accomplished yesterday, what you plan to accomplish today, and what you may be blocked on.
• Program status meetings: This is where you meet with the key participants of a project or program and check in on the status. In this meeting you want to focus on things that are either off track or at risk of being off track. Most often I've seen this occur weekly or bi-weekly. It's really important to have people in this meeting who can authorize change.
• Stakeholder meetings: These are regular sync ups with the people that depend on you and your work or that you depend on. These meetings are typically with people that you don't have much visibility into day to day operations with.
• Team/Org meetings: This is time with your direct team. This time is best used for vision casting, transparency, and/or checking the temperature of the team (i.e. how are people feeling).

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.

Managing someone elses software development career

In my last post I talked about how to manage your own career as a software engineer. In this post I want to talk about managing someone else's career. As a manager you have a responsibility to your directs to make sure they're aware of what it takes to get to the next level, that they're on the right path, and that they've got the right opportunities to achieve their goals.

Here are some tips to managing someone else's career in software engineering.

Understand their career development goals

Don't make the assumption that what you think they're good at is something that they want to be doing. I've had engineers that would make tremendous project managers or software development managers that just didn't want to pursue those roles. While they were good at them, it was wasn't something that they were passionate about. One of your jobs as a manager is to find out and explore what they're passionate about.

Some of your engineers may not know what their goals are. In this case you should be able to walk them through what options they have available. Help them understand not just how they can advance in their current role, but what other roles are available to them.

Identify their strengths

As a manager you should be able to discern your direct reports strengths. This is does not mean identifying just what they are great at, but also what they would be great at if they just had some coaching. As a manager you need to understand that your directs have both realized and unrealized strengths. Your goal should be to help them realize the ones that they have not already.

Identify the gaps and set some goals

This is probably the most obvious job of a manager but it's also the most over indexed one and one that is often misunderstood. At the core of this problem is helping your directs be aware of the areas that they need to improve on. This will involve having a tough conversation with them about things they're not doing well. When you have this conversation you should be prepared to help them formulate a plan to overcome these deficiencies.

Not all gaps are worth closing. There are some weaknesses that your directs may have that aren't going to be worth the investment from them to fix. Either because it's not going to help them on their desired career path or because the level of investment wont produce enough return to make it worth it. It's as important that a manager helps their directs avoid taking on the work that doesn't play to their strengths as it is to help them take on work that does.

After you've identified the gaps you should set goals to help them gain the skills they need. The key to them achieving their goals is having the right opportunities. As a manager one of your responsibilities is to identify the right opportunities for them and give them a chance to take these opportunities.

Get them visibility

It's important to make sure that as your direct reports achieve their goals that you get them the right level of visibility into their achievements. Getting them visibility helps them gain the trust of other leaders in their space. This in turn will help them get bigger and better opportunities.

Solicit feedback

Part of helping your direct reports grow is getting them good feedback from their peers as well as other leaders in their space. In the course of their day to day they may not have the time or opportunities to debrief on the things they have completed. As a manager you should be periodically checking in and helping them to get this very valuable feedback.

Be able to articulate their achievements

The last key to managing someone else's career is being able to articulate their achievements. This is key because you're likely to have to be their proxy at some point and your ability to articulate their achievement is paramount to their success. At a minimum you should understand:

1. What the problem was
2. Why solving the problem was important
3. What trade-offs they had to make along the way
4. What the impact of solving the problem was

The importance of team identity

Does your team have an identity? Something that defines them? Something that they can rally around when things get tough? Something that allows them to put a stake in the ground and affect change? Having a team identity provides many benefits that will make your directs happier at their jobs, more productive, and more efficient in their interactions.

Resiliency to change

Identity at it's simplest form means there's a sense of oneness or sameness. For example, my body is constantly changing. The cells I have today, the blood flowing through my veins, and the hair on my head is not the same as it was 10 years ago. But I am still me. When a team has an identity, they are able to be more resilient to change. People can come and go on the team without affecting the team as a whole. Team charters can change without causing a panic. Team identity is the glue that holds things together.

Stability when the crap hits the fan

When a team has identity they have the ability to weather a storm. They have the ability to lean on each other and be honest about mistakes because there's a shared value system. Teams that have an identity tend to help each other out when someone is struggling. Sometimes that takes the tough form of helping someone recognize they don't fit in with the team identity. But more often, it gives people a way to rally around their peers and help them be better.

Allows for a sense of ownership

When a team has an identity the members on the team feel a sense of ownership in keeping the identity in tack. People want to be involved, want to be included and want to be associated with positive results. A team with identity is more likely to have folks who are willing to step up and own the hard problems because "that what this team does."

Gives you a frame of reference from which to engage

When your team has an identity and things happen that are out of character, you have an easy way to engage and address the problem. You won't be fighting an uphill battle just trying to convince people that a problem exists. People will recognize that "this isn't us" or "this isn't how we do things" or "we don't make these kinds of mistakes". You'll be able to focus on working towards a solution much easier.

Making The Leap From Individual Contributor To Management

A few years ago I made the switch from being an individual contributor (IC) to being a manager. At the time of my transition I was a principle software engineer and engineering lead on a team of developers building mobile apps and frameworks for iOS and Android.

The last few years of being an IC I was the engineering lead on several projects at several different companies. My time as an engineering lead gave me greater exposure to mentoring, project management, and product management. I started coding less and taking more accountability and responsibility for the vision of the projects I was working on as well as the delivery as a team.

Growing Others

As an engineering lead I started taking on more responsibility for growing other engineers on my team and across the company. I worked with engineers and their managers to identify areas of growth both technically as well as from a career perspective. I also worked with them on their social dynamics and team interactions, trying to help them work more effectively with their teammates and those in the company they didn't personally get along with.

From a career development perspective I mainly focused on helping them to make the connection between their contributions on the project, the work they pick up, growing their skills, and stretching as individuals. I found that I really enjoyed this part of mentoring more than any other aspect. As I saw people being successful putting to practice things we'd talked about and worked on I felt very fulfilled. Surprisingly, this fulfillment was equal to or greater than the fulfillment I had when I delivered a complex solution I had solved in code.

Managing The Project

I've been a very big fan of agile software development for a long time. Early in my career I worked with several people who helped me understand that what you're building changes as the ambiguity is removed from a project. The system that you use to manage your project life-cycle has to be able to account for this change.

As an engineering lead I usually took on the role of scrum leader. This meant that I was managing the sprint, everything from daily stand-up to sprint planning meetings. I found that I enjoyed planning the sprints and found myself taking every opportunity that presented itself to expand my scope of planning, owning the project schedules and plans for large features and projects.

Future Of The Product

As an engineering lead I would attend meetings with management and product to talk about the direction of the product. We'd focus on the current project and talk about where the product was heading, what road blocks we saw getting in our way, and what areas of the product were emerging that we hadn't envisioned or that had been to ambiguous previously.

In these meetings I found that I was able to bring a different perspective. It's not that my being more technically focused was the game changer, but more that I discovered that I was able to translate some of the more technical details into something that was actionable by product management.

Making The Leap

At an employee moral event a few years ago I was having a casual conversation with one of the directors at the company I was at and I jokingly mentioned that I thought I could handle managing one of his teams that was currently without a manager. After that event he reached out to me and asked if I was serious about wanting to give managing a team a try. I thought about it for a few weeks, talked to my wife, and decided to dive in.

I've found that management is very fulfilling. I'm able to stretch myself in ways that I couldn't as an IC. I'm able to have a larger impact on my organization, my project, and my team. Along the way I've learned a lot about humility, about being a better listener, effective coordination, and how to build a collaborative environment.

I still write a lot of code at home on personal projects. I'm still a software engineer at heart. But I've also discovered that I'm a good people manager. I've find more satisfaction in the success of my direct reports than I ever thought possible. I've learned more about myself, my gaps, and skills I never thought I had.