Convert Yourself to Technological Enabler. It is not a role that is specific to some corporate lather, nor some concrete domain area like programming, like business, design, sales, marketing, QA. It is above specific role. It is a role to open the door for others, the possibility to work without blockers. It could be technical and it could be non-technical.
The business owner must do negotiations with others and must provide work for his/her employees. The employee should have concrete tasks to do, that are clear, that are achievable, that are small enough that are complete-able in a day or in a week or months.
A developer must think about other co-workers in a way – How the code should be organized so – many could work together – without blockers, without too many duplicate work and merges in identical files.
Multiple Different perceptives
I’ve been involved from a different perspectives in the software development process.
Code your own product
What problem one could solve for the client or the user. He/she searches to make money, save money, save time, get some feeling from the usage of the software (Facebook), or to complete some specific task. Having all kinds of stuff in mind while you start is sure way to fail.
The developer should think about the problems of others. The perfect case will be if a problem that the coder has is the same as the problem of the clients or the users. Otherwise it is not profitable. One cannot give himself money for the work. It could raise the confidence, it could raise the productivity. But, at the end, if something is not problem for others, it’s not economical. Not a great problem to be solved.
Work for clients
Sometimes clients flood with too many tasks, too little prioritization, lack of reporting systems, duplicate work and reversing the old features. It is hard to find good and paying clients. This raises the complexity of the code and makes work – hard and troublesome.
The client has users and employees.
The client that I worked for – that I was working previously – was an enabler himself – for his employees – to serve his clients. And my role was actually to make an enabling tool. How well I’ve archived the progress and the work was a matter of subjective view that we didn’t agreed. From my point of view, the client didn’t know what he wants and it ended up to too much rework of the same stuff. Having fun and enjoying work is too often – too hard to archive.
Thinking about resolving problems.
In corporate environment the modularization of the work is the key to include more people and to move ahead with a project or task. The separation of tasks in chunks is important part of the work.
- UI/UX Designer
- Business Analyses
- Developers, coders
- Organization of task flow & tools for enabling others.
Contrary to some corporate values system that promote – feature ownership, In my personal opinion – one must stop thinking about the work he does as Mine.
- My code
- My work,
- My project,
- My teem
- My product
This way one focuses on the product and less on the personal affections. One focuses on the process and less on the emotional attachments every person throws onto other people and other things.
You cannot automate people
One could try to enable them to do their work. To scale up you must enable the enablers. This is the way to scale the unscalable [at least the smart people say that].