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

Managing your software development career

One of the things I wish I had done better as a Software Engineer was manage my career. I was in the role of software engineer for over a decade but it wasn't until the last 5 years of that portion of my career that I started to take control. For the first 6 or 7 years of my career I naively believed that if I just did a great job my career would advance. I trusted that my management team and senior leaders would recognize my achievements and I would make my way up the leadership ladder.

While there's nothing wrong with having that much trust in your leadership team, in my opinion, it isn't the right way to manage your career because you have very little ownership of your success or failure. You're career should be a reflection of your capabilities and your desire to succeed. Not everyone wants to move up and not everyone is capable of moving up, but most are.

Here are some tips to help you understand how to navigate your software development career.

 

Start the conversation with your manager

No matter how good your manager is, you have to assume that he or she is unaware of your desire to make it to the next level. Starting the conversation with your manager helps them understand that you want to grow as an engineer. 

One important thing to be aware of is that when you have that conversation you're going to need to be prepared to hear about both the good and the bad about where you're currently at. You need to approach that conversation objectively and with a desire to close the gaps. Getting to the next level in your career is mostly about closing the gaps between where you're at and where a person at the next level already is.

Understand the responsibilities

No one is ready to move on to the next level until they're already over performing at their current level and have begun to perform the duties and responsibilities of the next level. Because of that, understanding the responsibilities of your current level and that of the next level is key to growing and achieving your goals. In particular you should understand:

1. What the expected technical capabilities should be
2. What the volume of code that you should be producing is
3. What the expected level of autonomy is
4. What the scope of influence should be. I.e. what influence you should have on your team, across teams, and within your org
5. What your role should be with respect to your roadmap and the teams day to day activities

Create an achievements doc

If you're anything like me you're not going to remember the important details about your everyday achievements. What I like to do is to keep an achievements doc where I can keep track of the details of my achievements. I don't write in it everyday but I try to re-visit it once a week and make sure that I put my big achievement of the week into it. I like to keep track of what I deliver, who I influenced, and other big decisions I made or contributed to.

I try to keep track of the following information for each achievement:

• What the problem was
• What the proposed solution was
• What the alternatives were i.e. what were the trade-offs
• Why the solution chosen was the correct one
• What the impact the solution had on the business, the team, operations, and/or efficiency

That last point is important. You're going to need a way to measure each of your achievements. Having data to back up what you do is the best way to have an objective conversation with your management.

 

Expand your influence

One thing common to every role is that the more senior you get the more influence you should be having. As a junior engineer you're sphere of influence is largely limited to yourself and your work. As you grow and develop you're sphere of influence expands from just yourself to your team. The more senior engineer you become your influence expands outside of just your team to your org. Expanding your influence means identifying what the sphere of influence should be at your current level and what it should be at the next level.

Get a mentor

As a growing engineer you need an outside influence. You need an objective voice to help you see both your strengths and your weaknesses. A mentor is someone that can help you see the obstacles to your career growth. They can help you grow your existing skills and identify new skills that you need to gain.

Create goals

The last step in career advancement is to create a set of goals. These goals should represent a mix of things it takes to be successful in your current role as well as things it takes to show that you're already working at the next level. Your goals should be SMART (specific, measurable, achievable, relevant, and time bound) and should be something that you review directly with your manager periodically (at least once a quarter). Goals are your best way to make sure you're on track for career advancement. 

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.

Saying thank you goes a long way.

I don't do PSA type posts often but today's post is a break from more in-depth subject matter. I was reminded recently that I need to say thank you more often to the people in my life. No one said this to me or called this out. But I was having a conversation with someone that was clearly exhausted from busting their butt and when I said I appreciated their hard work (and meant it) their face lit up. It was almost as though a weight was lifted off their shoulders. Their exhaustion seemed to matter and make a difference. That was all the reminder I needed. I was reminded how important it is to just stop and tell someone that you appreciate them.

How many times have you busted your butt to finish a project on time, help out a co-worker, or generally do something awesome or thankless for your team only to have the act go unrecognized? In my opinion, this is a big problem in the technology industry, but one that doesn't need to exist. This is especially important if you're a manager of individual contributors.

All too often we have very packed roadmaps and very busy schedules. As an industry it's not uncommon for us to be queueing up the next big thing before we even have the current thing we're working on out the door. This is great from a delivery perspective and can be helpful in providing a sense of urgency. But what often gets lost in the transition is taking a moment (and I really mean just a moment) to recognize the hard work of those around you.

As managers in the tech industry we often make the mistake of believing that as long as our employees are well paid that they're happy. But a well paid employee who isn't getting recognized isn't getting fully compensated. They're lacking the ability to feel like they matter. A simple thank you goes a long way in making someone feel like a valued member of the team.

Saying thank you can come in many forms. The most obvious is verbal public recognition. But it can also be a small note in an email. Or bringing donuts for your teams daily scrum or planning meeting.

The end of a project isn't the only time to say thanks. You should be saying thank you when you see something that you appreciate. Saying thank for the small things also lets people know you're paying attention. This could be noticing someone be extra helpful in helping a co-worker to solve a problem. It could be for someone doing a better job than you in communicating to the team. It can be someone who's just always on top of things and doesn't let them drop on the floor.

My advice to you is to take the opportunity to stop for 1 minute and thank the people on your team that are busting their butts each and every day to make the team successful.

You probably need more data to make your decision

In most software projects that I have been involved in there's always come at least one time during the course of the project where we've hit a crossroads and the right next step isn't clear. Usually there are two or three competing paths that each have merit on their own.

In these situations its typical for people to start relying upon conjecture. The conversation starts to turn from we should to I think.  What's the problem with I think? It means:

• The data the decision is being made on is coming from you and not your users.
• The conversation starts becoming more subjective and less objective.
• There is more risk that you build the wrong thing.

In many situations our experience is going to be enough to make a decision with incomplete information. But you need to be aware when the cost of making decisions based on conjecture can affect the success of the project itself. When there's a lack of data about something that affects the direction of the software using the term I think should be a red flag. Here are three key questions you should ask before proceeding:

If I make the wrong decision, am I able to go back and change it?

If you're building software that others are building on top of then it's likely that their business now relies on the decision you've made. In this case once you've released the software it's going to cost a lot of money and time to go back and change it. If you have a large user base it's even likely that some users will be unwilling to change their use.

What's the cost associated with the decision?

Does your decision require you to make significant purchases in hardware or other software? Do you have to bring on additional people on to the project to complete it? How much additional time will be spent building the proposed solution?

If I build this solution, what am I not able to build?

It's possible that deciding to do X means that you cannot do Y or Z. It's important to understand these trade-offs before you start down a particular path.

So how do you turn the conversation from I think back to a confident we should? Answering those three questions is a good start. But you need to also start the conversation with your users. In agile the product owner is the proxy between you and your users. Product owners are usually in touch with the actual users and can provide a more objective opinion on what your users will really need or want. Bring your product owners up to speed on the context and the ramifications of the decision. Let them help you get the right data to minimize your risk of building the wrong thing.

Generic Software Solutions Are Unicorns

How many times have you been working on a platform and recognized the need for some underlying technology that ties together several disparate components in your system. The conversation usually goes something like this.

We've been building component A for some time and we need to build component B and C. A's been doing well but has a lot of warts and tech debt that we'd like to fix. If we only had a generic system X then we could build B and C faster and reduce redundancy between A, B, and C. 

On the surface that reasoning seems sound. You're not dreaming up an ideal system and looking for problems it can solve. You have real world problems you're trying to solve for components A, B, and C. So what's wrong with setting out to build a generic system to solve your problems?

You aren't providing business value along the way

By building a new generic system instead of refactoring your existing system you're increasing you're opportunity loss costs. Every day that you spend building software that doesn't get into customers hands is a day of missed opportunity for feedback. You aren't able to get feedback on whether your solution actually fits the customer need. You aren't able to get feedback on what the unknowns in your system are that only come out in production. You aren't able to get feedback to validate the many assumptions you've had to make along the way. Building successful software requires a closed feedback loop between you and your customers. The longer you go without closing that loop the more risk you are adding that you're building the wrong thing.

Generic systems come with too many unknowns

A generic system needs to be able to solve problems it doesn't even know about. But often, these aren't problems that you have today or will likely have in the near future. Building your system in such a way that it can be delivered in small pieces that provide immediate business value allows you to make sure you're solving the correct problems today, and building a foundation that can be refactored and abstracted tomorrow to solve different problems that are unknown today.

It's easier to do the wrong thing than it is to do the right thing

When building a system for which you don't know the full requirements it's easier to do the wrong thing than it is the correct thing. That's because you're possibilities are almost infinite on what you could build, and at best you just have a educated guess as to what you will need to build in the future. This means that you're going to have to make assumptions that can't be validated. It's very possible that you make design decisions based on these assumptions that are difficult to go back and change. Building only the components you need today ensures that your system only needs to change for the problems you have, not the ones you think you're going to have.

Refactoring existing systems allows you to get the more generic solution that you need 

As you build the systems and components you need, you'll be able to start identifying the parts of your system that are needed across components. These common components are the real foundation of the more generic solution you need. Building them to solve your specific problems today means that they will only do what they need to do (i.e. you won't have spent time building features that aren't used). This will create a virtuous cycle of refactoring and adding more functionality as you need it. You'll get the correct level of abstraction for your components because you'll only be abstracting them when you have a real world need for the abstraction.

Successfully Shipping Software

It's unfortunate how much software gets written and never actually ships and is used. This can't be wholly avoided because there are times when priorities do change. There are times when projects do need to get shelved due to more pressing needs. And if you're working at a company that values risk taking then projects will get canceled in an effort to fail fast. 

As a software engineer not shipping due to changing priorities or having to shelve something in favor of a more pressing project were two of the most demoralizing things. Especially when I had worked on a project for N weeks or (even worse) N months.

Being able to ship software fast is one of the big benefits of Agile software development. Agile encourages you to ship at the end of every sprint. In the ideal world this would mean putting something in users hands that can be used at the end of every sprint. In reality, this is usually not the case. Often, you ship a series of smaller end-to-end pieces into production which at some point you'll tell your users about.

Here are some things to consider which will increase your likelihood of shipping software your users will use and decrease the chance that you'll build the wrong thing.

Understand your problem

While this sounds like a no-brainer, it's actually one of the things that I see get missed the most. Understanding your problem is not about requirements gathering. You gather requirements about a known problem space. One reason software projects can fail and never ship is because the problem was based on an idea that was never validated. You should always be able to tie your problem back to something a user has asked for.

Identify your milestones

Many software teams identify milestones from the beginning and move forward linearly in time till shipping. This is not a pit of success in that it's easier to miss a requirement than it is to not miss one. It's better to start with the last milestone and ask the question "what needs to happen right before this to achieve this milestone".  Then you keeping going backwards in time asking that question and defining new milestones. Eventually you'll get to a requirements gathering milestone. You'll have achieved either defining all your milestones, or identifying ambiguity that would have likely derailed or delayed your project had you started defining milestones the other way around. 

Know your risks and how they can be mitigated

Every project comes with risk. Being able to identify what risks are associated with your project will help you determine how your project will succeed in the event that one or more of your risks are realized. Some common risks to software projects include:

• Upstream/downstream software dependencies (often internal software being developed by another team) being late or failing to ship all together.
• Hardware/software purchases that need to be made.
• Making sure you're able to deploy to production.
• Not having user documentation.
• Not having a marketing plan for a new feature or product.
• Getting started with performance testing or security reviews late (or not realizing you need to do them at all).

Make sure you know what you need to measure

Milestones are great to help you know whether your project is on track. But they won't help you once your software is released. You need to identify the ways that you should measure your software to understand it's health. You should understand both your customer facing metrics (like the number of failures, the latency of requests, or etc) as well as your internal metrics (cost, performance, system health, etc). Talk to your product owners and your sales teams to understand what they need to measure about the software in order to aid them in their jobs.

Have an exit criteria for success

What is your definition of done? This doesn't mean you won't maintain or make changes. It just means that you've successfully delivered what you wanted to deliver. This should be a checklist of items that's been validated on both the business and technical sides of the house.