Yes it is important to manage people otherwise be ready for a disaster. It is always about "people factory" as Jack Welch says. Unless right kind of people are at the Job it is difficult to gain success. This is tackled by laying out a clear roles and responsibility structure in the company.
There could be deviations in org structure of startups with varied product areas. However most technology startups have similar role distributions. A typical organisation structure looks like this.
Although some roles overlap with each other during initial days, they become more and more important once company runs in its full pace.
One of the most important aspect is the way the organisation functions. It is essential for a startup in its initial days to be extremely agile since it needs to learn the way to make a successful product. That means having clarity in communication and taking leadership in problem solving inside the entire org. However once the startup forms a good base of customers and starts selling products sometimes these values dilute.
There are times when the org goes through conflicts. The most observed ones are
- among developers
- between marketing and engineering
The senior developers generally play roles of architects/ designers. Due to the layered structure of software (assuming software products area) there tend to be multiple designers who possess conflict of opinion. The negative impact of this results a poor quality of software. Often it is ignored by the management who tends to incline towards few senior developers who has joined the company during initial days and hence get more respect. However the management is unaware of the situation that is building due to tension among the developers. Unless the problem is solved the quality is degraded.
It is the onus of the CTO or the VP engineering to identify and understand such issues and promptly address it. Often a good practice is to set up a process guideline for engineering development and ensure that it is followed religiously. An example is making a software design review with review guidelines. This ensures that the design is done correctly and also undesirable clash doesn't happen between the developer and the reviewer (generally a senior architect); thereby ensuring the quality.
There are also conflicts of interest between the Marketing and Engineering org. Very often the Marketing org functions in a sales driven way and the Engineering org functions in a optimized development (lazy but efficient; there is a point I'll clarify in another blog why I chose this). Sometimes optimized development hinders the sales demands. For instance the sales would require the product to implement a feature. However the Engineering is not ready to do that as it leads to improper hack or improper customization or poor maintainability which is difficult to comprehend for the Sales org.
This is classical problem but there is a solution to it. The respective heads must have the mandate to manage product. Product Management means making as well as selling the products profitably. Often there exists a product management org separately. The crux is there should be an effort to find out the cost vs profit of product features. Essentially a profitable (which could be a short or a long term benefit) feature is what a product needs. Hence it should serve as a guideline for prioritizing its development.
There are a lot of unanswered questions here. How to handle feature requirements etc. The upcoming post mentions them.
No comments:
Post a Comment