the story goes like this:

• rafal developed a prototype for projekt: kreatywa aimed at collating skills, expertise and workflows necessary for development of somewhat more advanced/interesting/profitable initiatives
• presented the idea to marcin as well as to very many artists, professionals from creative industries, businesses with stake in getting their heads around web presence
• raf set off to prepare the tech and upload more trojan software on as many instances of neural frameworks that humans come with by default and which are filling in our skulls (this is an ancient software and last upgrade was before stone age)
• marcin set off to do his stuff
• a year passed and all was well
• one afternoon marcin called up and set up a meeting to discuss the web app he had a reason to develop to support his work
• the day before planned meeting he got drunk
• called up and on the phone said: “wh…aa…….whaaa…..wha”
• called up again few days later to figure out whether raf’s at work
• showed up at the studio
• got irritated that raf seems not to understand the information that he was trying to communicate to him and which was a design of the web app he envisaged
• decided that explaining is not necessary as he knows all the requirements and
• decided it would be easier to micro-manage the project and in this case tell raf exactly what to do on the computer screen … ?!
• which misses the most important part about raf’s involvement who being who he is probably could do the talking to the computer himself and
• what is actually THE reason for communication in the first place.
• wh…aa…….whaaa…..wha?

this is one instance of a common scenario that we often see unfold in our professional practice at weAreThePlayMakers. the thing is that in order to even pretend to make an attempt at designing a web service which is going to be all clever, brilliant and user oriented the designer needs to have an understanding of the project aims, its circumstances and all lot of other details. in fact, just the choices in terms of tools used in production and vague idea of technologies powering potential web service could in fact be the decisive ones that in real terms will make or break the service before it is launched

in most cases all its needed is time allowing for clarification of taxonomies and syntax or simply speaking having the same understanding of what how where and who

marcin didn’t seem to feel he had this time but being in business of interpreting one form of communication into another our advice was to let things cool down a bit and let us do some interpreting of “analogue” signals from our brains into digital form which can be understood by the computer and which cold be displayed as per analogue signals on any device with as little as a web browser and access to the net.

which is what happen in marcin’s case. no humans were harmed in the process and since we are still working together I would bet my bagel that I could talk marcin into preparing specification using pictures because he happened to be a photographer. (why the hell would i expect him to be better at using words? is he a poet or something?!)

but the stories with happy endings are not my concern. it is the other kind of stories that i have a problem with.

the fact is: — we are all diferent — we have different skills, experiences and aims — which is why working with others could be so great and rewarding — yes miscommunication does happen — it is here to stay so get used to it — ask questions, so what they seem stupid — not everyone needs to digg your stuff so answer to others — and above all not knowing something or being wrong is okay

so according to this list not knowing what node.js is or not being able to understand web technologies is not going to kill anyone

but for sure it might lead to — unrealistic views about options and what could be achieved — how much time it would take — what would be involved — and one thing people often forget, how much it would cost?

well this seems like a pretty dreadful list and a recipe for very many disappointments. what’s more as the time passes various issues start to surface and often people are very easy on themselves and a bit harder on others

which always results in high procrastination bill someone would have to cover one way or another; which leads to stress; which often means that there will be some bad feelings paid out to those involved
which isn’t ideal but then again it is always a possibility so it does not have to be a deal breaker
however if the above is coupled with low or non existent understanding of the tech aspects behind a project which naturally reinforced with tendencies of human brains to virtually delegate to others literally one own’s responsibilities it might mean we are very likely to end up on a collision course
this is especially severe in case of creative people, start up founders founders or “natural leader” kind of people who if happen to be ignorant of the tech powering projects started with their own ideas tend to start seeing and treating tech oriented part of the team as their personal and privately owned bunch of “code monkeys”
if this happen to be a situation anyone found themselves and i myself happen to be there to then i am glad to say that we are not on a collision course anymore.

we just had one. in short:

• “we love the ideas”
• “we love learning from mistakes and are eager to try new stuff”
• “but we hate making the same mistake twice”
• “because it seems like a waste of time”
• “and we hate wasting time”
• “so thanks, but no thanks”

and thats even before we would be willing to listen to some wild theoretical adventures about ownership and any considerations on how do you actually own an idea

so no matter if you are an artist, community manager or business oriented founder of a start up and seem to struggle with some aspects of team-work or even very generally started to feel displeased with your teams or company’s ability to “get the shit done” i would like to encourage you to study and practice the awesome way of GyShIDo

it could change your life

most definitely it could save me a lot of time my time