Arguing from your own Authority

As a member of a software development team, you have opinions. You need to communicate them or your product is going to take a wrong turn, the wrong task will be prioritized, or the wrong technical choice will plague your team’s collective existence until the end of time. That’s just the way it works. You have to speak up.

So, you think your idea could save the day. How do you persuade others?

Well, that’s a really hard question. It’s a big enough one that it could involve me agreeing to write a book, and a very dry, self-help style book at that. Instead, let me pick an easier question to answer. If you’re a technical leader, how should you not persuade others?

Let me tell you about a mistake I make from time to time. Afterwards, do yourself a favor and avoid making it too.

Don’t pull rank. Now, I know you’re going to tell me, emphatically, that you don’t, but think about it: do you listen to how you say things? Sometimes, do you introduce your ideas like this?:

I’d rather we don’t do that. Instead, why don’t we do [my idea]?

See the problem? No? In just a couple of words, you’ve managed to take your idea and put it behind a wall. That wall is your seniority, your perceived authority. That wall is you. Now instead of starting at the beginning, discussing the merits of an idea, you’ve made this (at least initially) about your judgement and your leadership, not the idea. It’s certainly not honestly inviting comment.

Even if you’re not a jerk, and even if you’d actually welcome debate, why not state your reasoning instead, actively inviting the team to discuss it?

One idea that I’ve seen work in the past is [idea]. I think it might apply here because [reasoning]. What do you think?

Words matter. Don’t prop your idea up like it’s a foregone conclusion. Far better to exercise some humility and let your idea stand (or fall) on its own merits than risk alienating your team or making the wrong product decision out of laziness or hubris.