When Not to Ask For Advice

Golden Rule: Don’t ask people what they want if the decision has been made

I guess this seems like common sense in hindsight, but the impacts that I've witnessed for ignoring this rule have been significant impacts on any team or individual involved. This year, I've been on both sides of this mistake, and in both cases, the results were not pretty. 

What I am talking about is the scenario where decisions are predetermined regardless of the wishes and desires of an individual or team. This might be for any number of reasons. It might be that process is changing to accommodate interactions with other groups, new tools are being adopted, a management or organisational change might be happening, a new idea is being discussed, or maybe we're just asking someone if they “want” to do something. Whatever it is, if you give people even a “hint” that they have a say, then that comes with an implied level of responsibility for you to respect their recommendation, whatever it is (within reason). I'm sure this would be compounded over time if the team is used to being run by committee and they somehow get the impression that the decision is optional.

The concept of not asking if the decision is predetermined is not all that different to dealing with kids. While kids aren't technical experts, they do have thoughts and opinions of their own. If you ask a child what they want to wear to the shops, most parents will know that they are in store for a super-hero costume or fairy costume or the like. Going back from that is like trying to un-break an egg, and equally as messy. If instead you suggest they can wear the red dress or the blue shirt, in most cases you'll get one of the two options. If you need them to wear the red dress, then just tell them that they need to wear the red dress that day and be done with it.

For technical people such as in Software Development, one of the key things that people value is respect. People like to feel like they are the expert in their field, that they are the “go to guy” (or girl), that their ideas are valuable. In general, that their opinions, recommendations and advice is treated with the respect that their expertise deserves.

Depending on how it's delivered, asking a technical person their opinion can imply that you are not only interested in their opinion, but you are prepared to make a decision based on their expert advice. If that is not the case up front, then just don't ask. That might seem harsh on the surface, but really, it's not. There are many things that people are just fine to go along with if that is what is required by the company, even if they don't agree with it. Most people realise that being in employment means they are there to serve the needs of the organisation even if it's not what they “want” to do. 

When we seek someone's opinion in the situation where a specific outcome is required, there are really only two outcomes; they either come up with the option that matches the desired outcome, or they don't. It's awesome in the first case as now they feel like they have control of what is happening (be careful not to let that bite you later if you get caught), but if they don't come up with the option that you need, well, you've created a problem for yourself. You can take their recommendation into account and change the desired outcome which might not be an option, or you disregard the advice and show that you are deliberately disrespecting their recommendation. For any professional person, that's hard to swallow.

Even though a decision may have been made, the team or individuals impacted may need to be consulted to work through any challenges and issues that might arise. If you aren't the only one directly communicating the decision, it's important to be very clear with them that the decision has been made and what is needed is to to work on the details of what needs to be done in order to implement the decision. If they aren't totally clear (because you gave them the impression that the options were still in negotiation), there is a good chance that that will come through in how they deliver the message. As I said before, even the hint that a decision is not  final, is where the problem creeps in.

Summary

Another way to put this is that the use of a collaborative style of leadership when a more directive or even an autocratic style is required, can really backfire.

2012 Reflections - Multiple Hats = Delegation

2012 Reflections - Multiple Hats = Delegation

2012 was a hectic year for me. Probably the most challenging so far, even more so than the "Felix" year, but I might post on that another time.

Early in 2012, I was asked to help out with some product management tasks as the existing Product Manager had been taking time off due to an operation. Of course I accepted, who wouldn't?  After over a decade in software development, I was more than interested to get some exposure to different roles, and I get to do it from the relative safety of my current role.

Shortly after, it became a full time appointment by default as the Product Manager of the release, as the previous Product Manager left with short notice. It was a short term assignment until they filled the role with a permanent Product Manager. No problem, the project was already in full swing and wasn't due till later in the year. I still had my existing roles and responsibilities as a Technical Manager, but now I also had essentially a marketing position as well. Right time and place I guess.

The difficult part was that I was totally new to the role, so I didn't know what I didn't know. The state of “Unconscious Incompetence” came to mind. There was no hand over and no one assigned to help out. At the same time, we're transitioning the product to another group overseas, which introduced a host of other challenges. The Product Management role required tasks to be completed that I had never previously had experience with before including business cases, product definitions, licensing changes, EULA revisions, sales presentations, price increases, reviewing marketing documentation, supporting collateral, a host of internal tools and documentation requirements etc. Fortunately, there were some areas that overlapped, for example, I was responsible as a Product Manager for defining requirements for new features, and from a Technical Manager's point of view, overseeing the architecture, design and implementation. It was these overlaps which I found the most rewarding as I could leverage my previous skills in both roles. I'm sure by the end of my tenure, I climbed up the ladder as far as "Conscious Competence" in most areas, and I'm sure I still remain blissfully unaware in "Unconscious Incompetence".

I was conscious throughout this period of a pod-cast from “Manager Tools” that covers a topic called the Juggling Koan. Basically this describes that there are big balls and little balls (responsibilities or tasks) and it is your responsibility as a manager make sure that you focus your time on the big balls, and that means dropping some of the smaller ones. In the case where I'm responsible for 2 separate full time positions, that's a lot of big balls and even more small ones.

Staying back, working harder, faster and more efficiently, are the first things that are ticked off, but at the end of each week, there are just more things to do than anyone has time to work through. I think the art to this is try not to drop the balls, but to find other ways of getting them done, and that invariably involves relying on other people, sometimes other people who you aren't on your team.

Fortunately, I had a few good people who I could rely on to do some of the tasks that I just didn't have time for, either from the Technical Manager role or from the Product Manager role. I tried my hardest to ensure that as many balls were done as possible in any way possible, and some I was fortunate to be able to cut corners on or even cut out completely due to the overlap between the two roles. At one point, I was filling in for the Project Manager while he was away, fulfilling the duties of the Technical Product Manager, as well as the other two roles I had. I was able to get through quite a bit given the massive overlap between those roles, but I'm sure that there are still many things that I didn't do that I probably should have.

Some of those balls that drop to the floor just disappear as they might have a limited time or just weren't important enough, but others just pile up, and there is a part of me that still can't stand things being left undone. Looking back, of course there were some things I could have done better, but in general, there wasn't too much more I could have done. 

It was a totally awesome experience getting exposure to the business side of software development, but it also challenged me in more ways than I could imagine. I don’t regret any of it, but I'm glad it's over.