 |
One of the biggest time wasters I’ve come across in my working life are meetings. That’s not to say meetings aren’t important, they are, but when badly run they’re torture. Meetings with your co-workers or partners or customers are very important but meetings shouldn’t be about deciding things, the decision making process at the top is much less public than anything you’ll ever see presented in a meeting format, so meetings should be about communicating what’s already been decided and taking feedback on that and/or assigning tasks to carry out the decisions that have been made. Since I moved out of technical pre-sales and into a more strategic thinking role a lot of my time and nearly all of my travel time is spent communicating to co-workers, partners and customers what has been decided and how we are going to proceed. I may have had some direct input into a few of those decisions, for a lot of others I probably won’t have, but I always attempt to dig out the ‘why this and not that’ of any of the major decisions and as a result I end up (usually) with a well run meeting. Well run doesn’t mean neat & tidy, good meetings are messy, what it means is at the end of it people are clear about where things are going and why we’ve decided to go there. In such meetings feedback is always welcome but it needs to be the correct kind of feedback. Lets say there’s an issue of some sort. A piece of functionality that needs to be added or changed to act in a different way. If you can cleanly define the issue and do it in an amount of time that doesn’t put people who don’t care too much about this peccadillo into a coma you’ve started well. That’s the easy part and being direct it’s the incredibly lazy part. Where you need to start really thinking and what you’d need to be able to communicate clearly, pictograms and cave paintings are acceptable, are things such as: -What you think the solution should be? -What alternatives have you considered? -Is your solution reactive because some other product out there does this right now? If so are you solving a real problem or just checking a box? -How flexible are you to the solution being totally, completely and entirely different than what you’ve proposed if it solves the problem? That last one is actually a major challenge with some people. If you can crack the problem but don’t do it in a way they think it should be done, they come back to you with your solution presented as a new problem. It isn’t, it’s a solution to the problem they highlighted, probably implemented in a technical way that makes sense for everything else you’re trying to achieve in the context of your product vision. You’re never going to get everything you want into a product release and have it ship with high quality and on time. The list of things you can do is dwarfed by the things you want to do. Both of those being tiny in the face of what you realistically can do. That’s why it’s important to have thought out from end to end what you’d like done before you ask for it. The easier it is to say yes to a coherent well thought out piece of feedback the greater the odds things will get done. |
| Update your feed preferences | |
