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

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.

The True Cost of Software Development

One mistake I've often seen made when planning for a software project or planning the road-map for a team is not taking into account the total cost of development. We often fall into the trap of planning our software based on one key data point; development effort. While development effort is likely the most volatile variable that goes into the cost of a project, it is by no means the only variable.

 

Planning isn't free

There are three major areas of planning that need to be accounted for when considering the true cost of a project. The first is in defining what the customer needs. This will involved someone (or multiple people) being the advocate for the customer. Likely this will involve a certain amount of research and a certain amount of customer interaction.

The second is in identifying upstream and downstream dependencies. Before you introduce change into your system, you need to understand how that change will affect people that depend on your system and on the systems you depend on. For instance, will your changes cause you to put more load on another system? Will they cause you to be able to handle less or more load on your existing system? Do they require your existing consumers to do additional work or is there work they can stop doing? It is likely that you will have to make some change in your system to account for these dependencies.

The last area is in defining key performance indicators. These are metrics that allow you to know if your software is working correctly or not. If you don't account for defining these then you won't be able to truly measure whether or not your software is successful.

System Architecture (or high level designs) aren't free

Often we think about a project start as the time when the developers start writing code. But this is incorrect. The old adage "measure twice and cut once" applies to software development as well. To build the right system, one that works for your customers, you need to have a solid design. True software costing accounts for the design and the time it takes to review the design.

Development

I don't think I need to state the obvious, but I will for completeness. You need to account for the actual development effort in the total cost. Usually this is done in dev weeks. This could be one dev for 12 weeks or 3 devs for 4 weeks, depending on the parallelization that the project allows for.  

Bug Fixes and Stabilization aren't free

Before you put any code into production you should be testing that code in a production like environment. Many teams have an integration or pre-prod environment which is built as a smaller scale replica of production. The very best teams have a way to drive production like traffic in this environment to help root out the bugs that seem to only be able to be found in production (like race conditions, threading issues, memory or other problems of scale).

Deploying Software isn't free

Hopefully by now your organization has started to, if not fully, embraced the DevOps movement. Irregardless of whether you have full continuous integration setup or a fully manual deployment there is some cost associated with the deployment of your code. In a fully automated environment it may be the cost of updating the automation. In a more manual deployment scenario it'll be the cost of validating and pushing the bits to production.

Maintenance and Operations isn't free

Once your software is in production, you have an implicit contract with your customers (if not explicit) to make sure that software is running. This involves routine maintenance as well as the operational cost associated with keeping the system running smoothly and responding well to changing usage patterns. Inevitably hardware fails, systems get more load than we expect, and bugs exist in the system that require intervention. Accounting for this cost is crucial in understanding the total cost of software development.

Documentation doesn't write itself

The last area that I want to call out is documentation. This is often forgotten about until it's too late. Your code should be as close to self documenting as possible, but your users will need a guide to the feature or the product. Don't forget to account for this in your costing.