Software engineers, are you "too soft?"

More specifically, ask yourself this question:

Do you believe that you tend to be “too soft” at work?

This is a question asked by Neal Whitten, Project Management Professional (PMP), when he’s giving talks at conferences, seminars, and webinars. Neal’s concern is that most project managers are “too soft” at work and as a result they are less effective in their projects and careers. Roughly a decade ago (before I transitioned my career into IT) I attended one of these conferences, where Neal’s question and conference talk fundamentally changed the way I think about work. Even though this article is directed at software engineers, not project managers, I truly believe you can apply these concepts to your role, honestly examine your behavior to determine if you’re being “too soft,” and make changes to increase your professional effectiveness.

What does Neal mean by “too soft?”

When Neal says “too soft,” he means,

demonstrating behavior that results in being consistently less effective than what is otherwise possible (and needed for performing responsibilities).

Neal elaborates on this further, saying people who are “too soft” are:

not willing to make the tough and unpopular decisions even though their instincts warn them they’re not taking the most effective action.

Personally, I think that’s a bit wordy. Here’s how I define “too soft”:

not sticking up for what you know is right.

In the conference talk I attended, Neal handed out copies of his “Are You Too Soft” Power Snippets, which gives several examples of “too soft” behavior. I’m not too embarrassed to admit that I laminated my copy and kept it handy as I’ve transitioned jobs and careers; it’s remained relevant ever since just by swapping the job title from “Project Manager” to whatever job I have at the time! Take a look for yourself at the examples in the linked document and replace the words “Project Manager” with “Software Engineer,” replace “Project Management” with “Software Engineering,” and when an example says “project,” think of the apps, epics, or features you support as a software engineer.

Here are some examples of “too soft” behaviors:

• Holds back from providing constructive criticism to project members
• Unwilling to passionately defend the right project plan
• Puts off insisting on and driving good software engineering practices throughout the project
• Delays asking for help when needed
• Takes on too much work instead of assigning tasks to appropriate project members
• Evades taking a position on an issue rather than alienating project members
• Remiss in seeking out and obtaining needed software engineering training of both hard and soft skills

Let’s revisit the main question of this article: are YOU too soft?

• Do you hold back from providing constructive criticism to members of your team?
• How often do you find yourself unwilling to passionately defend the right approach for your project/repo?
• Do you delay asking for help, or take on too much work instead of assigning it out?
• Do you fail to regularly seek and obtain software engineering training to keep your skills fresh and relevant?

I know I personally struggle with these things, even with my fancy laminated handout!

How can you prevent yourself from being “too soft”

I think most of us (if we’re being honest with ourselves) can recognize when we’re being “too soft.” Your instincts will warn you that you’re not making the best decision or sticking up for what you think is “right.” So how can we prevent this from occurring? As I mentioned earlier, I still struggle with being “too soft,” but I can certainly give some bits of advice.

Build a habit of giving constructive criticism

First, you’ll want to start building a habit of speaking up and giving constructive criticism when you find yourself in a situation where you’re normally “too soft.” I know this can be uncomfortable, but an engineering team that can give and receive critical feedback will be much more successful than a team that skirts around issues. In many cases, your teammates badly want someone to speak up, but they’re uncomfortable being the first (or only) person to give constructive criticism. Sometimes I just need to get the ball rolling and then others will feel comfortable sharing their feedback. There are also times when I’m the only one giving constructive criticism in a meeting, but afterwards have been thanked by my teammates for speaking up. In either case, it was better for me to give the constructive criticism rather than withhold it.

Think about the following situations and how they might be improved by giving constructive criticism:

• Your team experiences the same unproductive behaviors sprint after sprint, but nobody speaks up about them in team retros
• You sit through fruitless “bike-shedding” discussions rather than speaking up and driving focus to the most important issues
• You and your teammates complain about shared infrastructure or tooling, rather than giving constructive feedback to the teams that create and maintain the tools
• Management shares some info about proposed or upcoming changes and everyone withholds critical feedback, even though they know the changes will make the software engineering organization less effective

How might the outcomes change if you started sharing constructive criticism? More productive retros, and therefore more productive sprints? Less bike-shedding? Improvements in shared libraries and infrastructure? I think it’s possible!

Of course, the key to remember is to keep your criticism constructive:

• Your feedback should have good intentions and focused on how to improve, not tearing someone down
• Try to be polite and communicate from a place of respect for others
• “Be hard on the issues, soft on the person” — you can be critical of a process, idea, or behavior without being critical of people themselves

Make use of the authority you have already been given

Second, you need to start making use of the authority you have already been given in your role. In a “Manage This” podcast episode, Neal was asked for some examples of “too soft” behavior; he immediately shared that he does FaceTime with thousands of people each year who frequently say that they have the responsibility for something but don’t have the authority to make the decisions. In response to this, Neal says,

this is just not true; you almost always have the authority — the problem is that you don’t take it.

I agree with Neal — for some reason we don’t make use of the authority we’ve already been given as software engineers. Why is that? Are we afraid we’ll get in trouble? In response to this concern Neal asks,

when was the last time you were ‘called on the carpet’ — challenged — for exceeding your authority? Was it within the last week? Within the last month? Within the last year? Was it ever??

Neal’s experience is that less than 15% of people have ever been challenged for exceeding their authority, and that most people will never experience being called out on exceeding their authority across their entire career. Neal believes you almost always have the authority, you just don’t seize it — because you’re being “too soft.” I fully agree with this sentiment! Perhaps you’ve heard the phrase, “It’s better to ask for forgiveness than permission” — this is a slight variation of a real quote from Grace Hopper, and they are valuable words to live by. In most work situations you DO have the authority, so make use of the authority and take action! It’s unlikely you’ll be “called on the carpet,” and more likely you’ll get praise for taking initiative.

Are you ready to stop being “too soft?”

By sharing constructive criticism, exercising authority, advocating for the right plan, and insisting on good software engineering practices you can enhance not only your effectiveness but also the success of your teams. Start making small changes and over time you’ll have built a habit of sticking up for what you know is right. Maybe you’ll also create a reputation as someone who speaks up and takes initiative! Are you ready to stop being “too soft?”