3 Tough Conversations from Stakeholders and Upper Management

When you manage a team, the conversations you have change a lot. No longer are you justifying your own estimates or explaining your coding decisions. Now, you’re responsible for many different estimates, many different decisions, and many different personalities.

The way you are measured has changed, too. Instead of a singular output, now you’re answering for others. Making the case for your team, accepting their failures as your own, and not knowing all of the details is now your modus operandi.

But that’s just the beginning. New questions from upper management or the C-Suite are introduced to your daily routine. Let’s dive into a few questions or conversations that you may get asked and some strategies for answering them.

We need 2 more features in this release

“Don’t push the dates, though!” This subject appears in a lot of ways. It might be the question “Why does it take so long to do this feature?” Or maybe it’s just a pile-on where management acknowledges you’re busy, but you just have to add this new feature as well. Timelines can’t slip! They promised stakeholders or the customer.

As a developer, you have two choices. Either work extra, or miss your deadlines and deal with the consequences. Neither of these approaches are appropriate for you, the Dev Manager, now.

But there’s hope! This conversation really needs to be moved to one about scope.

One of my favorite lines, although unpolished at the time, was “Ok, what would you like to slip?” I said this to the VP of IT when he asked for me to add three features in our current sprint. Looking back at it, I wish I would have said it differently, with more finesse, but the concept is sound.

What this really is is a misunderstanding of scope. It could be that you’ve not fully educated upper management about the scope of the project and all of its requirements. Or, it literally might be too much work. Then, you have to illustrate to them what you have in the schedule.

Give them the option to figure out which features can be adjusted to meet the goal. When you illustrate this, they are likely to suggest things to move slater. Remember, they don’t know all of the moving parts. If they did, why would they need you?

It seems like your employees suck

You need to be the face of your team. Good leaders accept failure themselves, but transparently pass on success to the team. When someone above you starts singling out employees, you’ve got some things to change in your leadership style.

First, are you communicating and sharing enough about the successes of your team? The saying goes “compliment down, complain up” for a reason. But, if you only complain to your superior about your team, can you see how their view of those employees gets tainted?

Second, dig into the reasons why management has this vision. Perhaps it’s the interactions they’ve had with your employee. This could be a pointer that your employee needs some coaching - most likely in appropriate communication styles and mechanisms.

Finally, I’m sorry to say it, but if your employee sucks, you’re the one who’s failing. You’ve either failed to communicate properly (like I mentioned above), you’ve failed to coach the employee to success, or you’ve failed to cull the herd and get rid of the poor performing employee. You should acknowledge the opinion, but accept the failure as your own. Believe it or not, this will show a maturity of leadership that will change the conversation and build respect for you among the top management team.

Build your team, but don’t lose momentum

Having too much work for the team to handle can be a nice problem to have. I call it job security! But when it comes time to expand your team, the best success comes when you are directly involved. You understand your team’s strengths and weaknesses. You understand the technical needs. HR can only pre-screen so much. Hiring takes a lot of work and time from the hiring manager.

When I had to expand a team by 5 members, I spent about half my week working on hiring, interviewing, code challenge reviews and recruiting. When my boss heard about this, he was livid. “Why are you wasting so much time on all of this? I need you doing your job!” My first reaction was to retort back, angrily: “because I need to build a team for your projects!” But, luckily, I held my tongue.

It’s important to build the right team. A healthy mix of skillsets and personalities will create the strongest team. As a manager, you are responsible for creating and building the best team you can. I explained this to my boss like this: “I understand that it seems like I’m spending a lot of time up front on hiring. But, if we hire the wrong people, I’ll spend even more time writing up performance reviews or letting them go. Then, we’ll be back in the same place as now - perhaps with even worse quality code and a project with bugs in it. The more effort I put in now, the higher velocity we’ll have when I choose the right developer.”

There are some key words in there that really helped. I mentioned that I don’t want to waste time later. I tied hiring to velocity of our project. After he knew I had a reason and philosophy, he was more understanding.

Have Difficult Conversations

“Soft words are hard arguments.”

~ Thomas Fuller

As you navigate the Dev Manager path, you’ll have many difficult conversations. It’s important to take time to understand that your point of view needs to be different now. It’s not about you, it’s about them. You used to communicate 20% of the time, now you’re communicating 80% of the work day.

Conversations with upper management can be difficult, but they shouldn’t be stressful. Take a minute, put yourself in their shoes, breath, and then answer.

To move on to entry 3 of the Dev Manager Crash course, click here.