Some aggressions compounded from my experiences over the years with various managers, VPs, C*O’s and vision people.
1. Don’t send out anything in Powerpoint, Word or Excel formats.
Your developers always end up having to manually convert whatever formatting you think you are doing for them into something that anything else in the world can understand (hint: it’s always a text-based format). Programmers are programmers partly because they don’t like having to do manual work, when you send them a Powerpoint document full of text for a webpage you are basically telling them their only value to you is typing.
Solution? Learn HTML, Markdown, reStructuredText or any other format that is commonly acceptable for turning into HTML and tweaking. If you are making layouts and designs, do it in Photoshop.
2. When they ask for copytext or layouts don’t send ones that include features that don’t exist.
Everybody is aware of what features you are interested in seeing, you are being neither clever nor helpful by giving your developers copy or layout that needs to be modified. Not only are you wasting your time, you are wasting their time and making yourself look either ignorant of the current state of the project or insolent towards the work of your team.
Solution? When asked for copytext or a layout create it such that it works in the existing environment or in the one specifically asked for. There are plenty of places where you can put your design ideas and mockups and possible wording for future things, those places would be in a design section where they can be looked at and discussed without impeding progress.
3. If there is dispute over a target feature or long-term goal, do not continue to incorporate your side of the idea into every plan, roadmap and feature.
It’s called passive aggressiveness and it is not a battle you are going to win with your developers, they are much, much more capable of winning by not implementing the things you want indefinitely and are usually quite skilled at ignoring you in the future after the point where they’ve flipped the bozo bit on you for continuing to push what they consider to be a bad idea. If they think an idea is bad and you keep pushing it without ever convincing them you are eroding their trust in you and their respect for your intellect.
Solution? You’ve got to have the argument and the discussion and be willing to backdown once it is no longer worth it. Developers are stubborn people, but they have a strong respect for certain kinds of things and will almost always begrudingly accept your correctness if your argument commands things that they respect.
- We don’t want to make things we consider “hacks,” that is changes that don’t really fluidly play in to the overall architecture we’ve envisioned. Often when you propose a new feature you will see us glaze over for a second as we try to find a way to make what you just proposed fit into the grand scheme of things and if we don’t find something readily we usually begin opposing the idea. Your best bet for getting a feature is to understand the architecture well enough to give an example that shows how it fits in, know which places where changing the order of two words will create a huge amount of work in changing the project architecture. And if the feature just has to break things, phrase it in a way that puts the developer on your side, “how do you think we could make something like this…” will always get you a better result than “that X should really be like this.” And, for the record, hacks tend to make the code harder to change later on, so the more of these sorts of things that we cave and do the more and more likely future things will be to require big reorganizations.
- We respect versatility, if we can see other cool ways, that is the ways beyond anything we consider marketting objectives, to use this new feature we are much more likely to be interested in it. Most of the time I think we’d rather make a versatile feature and put a restrictive interface on it than to make a small feature even if it is less work — you do a lot of boring stuff while coding, it’s nice to have things that you think are cool to work on and neat concepts can definitely be a lot of fun.
- We don’t respect marketting, at least not most, anything with the smell of it will raise red flags that will make us want to shoot it down. Have you ever met a programmer who respects whoever created MySpace nearly as much as marketing people do? I wonder if the developers would tell another programmer where they work without paragraphs of disclaimer? We all want users, but we believe in things that work the way open source projects work, word of mouth, recommendation by others but when you start throwing words like virality around you just sound like you are trying to cheat a system we believe in. We want to make good systems that people actually want to use and we want you to come up with great ways of letting people know that don’t sound like hype or make us feel like our words are being twisted.