Up until now, the fastest way information can go from one brain to another is through sound waves, pictures, or moving pictures. It is slow, compared to the connection between synapses in the brain. This fast-moving information media is critical to building complex concepts. I believe, a single healthy mind as an authority is a major factor in a successful creative endeavor.
This article does not talk about creative works being a non-collaborative process and undermining credits of co-collaborators.
Apple is a successful company. Behind it, for at least 14 Years, was Steve Jobs as its leader and product absolute quality-gatekeeper. Every minute details of the products Apple launched during those periods are launched by his mandate. It was very fortunate for Apple that Steve Jobs, as an authority, had passion and good taste for design and quality. That quality of having an extremely dominant control over a creative domain is the quality of being an auteur.
An auteur, according to Wikipedia, is an artist who applies a highly centralized and subjective control to many aspects of creative work. It is often used to refer film directors with an extremely dominant proportion of the film's creative direction. Software development, in my eyes, is always a type of creative work where design and perfection are the focus. That is why I believe being/having an auteur is important in software development.
An auteur working on a software product must strive to expand their imagination over how the software product will turn out to be as early as possible. This is a brainstorming session in-private to explore every crevice, to make uncertain things certain. It is very useful to catch stumbling blocks early on, which in software development context are misdesigns. Therefore, in a way, you can say that an auteur is a designer. If you have a workmate seeming to have everything in their head, and people ask a lot to them about everything, that's an auteur.
One thing to note about this brainstorming session is, the fuel of ideas is experience. The mind cannot simply invent things. It doesn't matter if one's mind can cross-reference at superhuman capability if one does not have experience over the domain being worked on. Experience is something not everyone has an equal amount. It requires privilege, like having rich enough parents to easily access experience, being lucky, being born smart, finding some methods to absorb experience as much as possible in a short period, etc. This one I cannot tell what's the best way to get experience for I am still searching for the way to get experience as effectively as possible too.
There is a broad fog-of-war to uncover from a software design, from the high-level view to the minute details, from designing the data structure, the UX, to planning the protocol used.
My second favorite keyword for this is
interface, the point where two entities interact. It's not the
interface in the Java kind of way, but as in "user interfaces with the peripheral, and in turn with the user-agent, the user-agent interfaces with DNS resolver, then with the load balancer, the load balancer interfaces with the server, the server interfaces with the database", that kind of
interface. Those interfaces are the important points, the one that goes into the specification first, at the front/top page.
My first favorite keyword is data structure. Dive in from there. Translate the users needs' to data structure, its relations, and where to store them. It's called top-down view, looking from the user perspective, and all other engineering related best practice jargons. This is useful to see the big why? Why the user needs this? And more importantly, if you have already gathered requirements for your product, this is very useful to see what it missed.
Now, not everything must be known beforehand, lest your project won't run if you insist on it. Seeing while walking is fine, some stuff is not very obvious before you take the first step. What I am saying is, do not forget the big picture.
There is a risk that the auteur's attention to detail is undiscernible from micro-management, worst if the auteur himself/herself cannot discern them. Micromanagement risks turning collaborators into automatons. You, as an auteur, don't want your collaborators to have an automaton mind, dull. You may have all the details, but inform people of the goal, not the process. Once people have the same goal, they will work toward it and all your details will eventually come out on themselves.
Quentin Tarantino, famous for directing the movie Pulp Fiction, is known as super detailed. Once Jamie Foxx was asked about wanting to have creative freedom while in an interview about "Django Unchained".
"He was a tyrant! He was at this, "do not f*** my film up!"", Jamie Foxx said, referring to Quentin Tarantino's precise direction style. But he later stated, "Thousand times", when asked whether he wanted to work with the director again. Tarantino exercised the details in his mind as a vision for the whole production team. The team would then realize his vision to the best with their talents.
Now I know this is a lot harder to do in software development where minute details are mathematically precise. It is harder to frame it as a goal than a procedural process people have to go through. There's a famous story how Steve Jobs once called home Vic Gundotra on Sunday and it was about a just slightly off shades of yellow on the Google logo on the iPhone. It's really a fine art to balance getting minute details right and not micro-managing. I've had my share of sins with micro-management at precarious situations. There's indeed a temptation to go and micro-manage when you have all the details.
When there are two or more equally powerful auteurs in the room and they have opposing opinions on the same matter, they would clash. The clash will be so great that it affects the project and those involved, mostly in a bad way. One auteur may have an objectively better idea about the thing compared to the other auteur. But, this clash will likely have an equally bad result compared to following the auteur with the worse idea.
When auteurs are considered leaders, this situation a divided leadership. A project has one goal, but when leaders are going on a diverging path, the project collaborators energy is spent to mitigate that. This story has been told many times. People say that having too many "smart" people hurt a project, but I say it's the other way around. Those people are not smart enough to realize that too much conflict will never get anyone anywhere. Smart people know when to step out and complement other smart people in the same domain rather than taking a direct opposing position.
Just recently I moved to a team with at least four engineers with an auteur mindset. They all are smart. They have the capability to cover a wide range of problems end-to-end. One is the leader, single-handedly oversee the project. There is almost no occasion they are stuck on a small thing because some people have different opinions. The key to achieving those feats is by having an auteur mindset and complement each other.
Smart people who work together don't undermine each other. They complement each other.
However, in general, my position remains the same. A healthy amount of conflict is necessary for growth.
However detailed your vision is, you need other people to know it eventually. The bigger the idea, the more people needed to make it happen. Write it down.
For people to understand your idea, it needs more than just ordinary writing. It must be written thoughtfully. It must be accessible. It must be written in the most fitting format. Get other people to read and ask for feedback both for the idea and the delivery.
The biggest deterrent to writing your idea is that it feels slow. Your brain works much faster than your hand. It feels boring to write, especially for those whose hobby is thinking, whose mind is trained to think so fast. In the workplace, when you are auteur, you get asked a lot about the work, because you are one of the few who know the in and outs. Think of writing as a means to scale your capacity to communicate, so you can talk to several people at once rather than one by one. And eventually, you will forget those great ideas of yours, so writing it can save you in the future.
Since I was a kid, writing is not my thing. In primary school, I always got scolded for the lack of notes produced during school hours. It was too tiring to move pencils around. I could get past the whole 4 years of CS university with just papers an equivalent of 2 notebooks, because everything is online.
Only at the age of 24, I can truly appreciate writings. I was one of very few people who know the ins-and-outs of a project in detail. I got overwhelmed by the number of questions I got while on the job. I couldn't move or breathe. After that, writing becomes fun. I guess it is only when you are passionate about something, writing becomes something more than a chore. (unless you are passionate about writing)