The team is your everything in software project
The team is your everything, even though you don’t assemble it yourself
Product is still not a CEO, he does not assemble a team for himself, so you need to learn how to work with the team that you have. For example, the head of our sales department liked to “solo” and could enthusiastically push half-hour speeches about spaceships that plow the Bolshoi Theater, while the team leaders kept silent, sighed and blunted on the phones. As a result, the utility coefficient of the meetings was objectively low, everyone came out tired and with a sense of wasted time.
I tried to gather meetings only with developers, but they began to go into the wilds that were exclusively interesting to them, and what was really important for users and for the market remained in the minds of salesmen and marketers.
The case helped. One day I missed a meeting and asked the same head of the sales department to keep a protocol. As I was later told, the role of “vice-chairman” was enough for him to express himself, and for his part he said everything briefly and clearly. Since then, I have often asked him to keep protocols — and there are fewer unnecessary speeches, and I myself can qualitatively moderate the meeting.
By the way, it is inconvenient for me to keep the protocol myself, it distracts me a lot. Although it probably helps a person who is multitasking and more unfocused to concentrate.
A product is a person at the intersection of everything and everyone, while the amount of knowledge required from him depends on who else is in the team and how competent he is. Development control can be distributed between the product and the project, the choice of strategy and positioning — between the product and the marketer (or brand strategist), and the development of the roadmap can be handled by both the product itself and the product in conjunction with the CEO, if the latter is the initiator, and not just a controlling person. Communicate, really communicate a lot and draw the boundaries of areas of responsibility and trust.
At the time, I was surprised by the fact that developers and managers often do not have the same view of the value of different features. What a developer is proud of may not impress the management department — and vice versa, what managers “brag about” to customers, developers may consider unimportant and uninteresting. I need to somehow consolidate opinions and priorities.
whom I knew as an Android developer and a lover of pranking on the topic of “ios vs android”, became a PM in a company that makes mobile applications.
PM works much less often with “hands”
As someone correctly noted on Habr, reflecting on the role of PM, it is important not to try to be a “Swiss knife man” and not try to close the functions of several departments.
In the direction of the “octopus-multi—armed” position, I sometimes “slipped” earlier – I repeat, I work in a startup where needs usually grow faster than the staff. Several times I sat down for not very burning tasks completely out of my profile – for example, I worked with hardware. It seemed to me a good opportunity to expand my skills, but now I understand that, from the point of view of management, the tasks were performed for a long time and inefficiently. Investing time so that I develop not according to the profile is unprofitable for the company. It would be better to involve contractors or interns during the search for a full-time specialist.
When I became a PM, it often seemed to me that it was easier to redo everything myself than to schedule a meeting, communicate, control alterations, check if everything was done …
But over time I realized that this loosens discipline and leads to colleagues starting to work less carefully, knowing that for them and so “everything will be fixed.” In addition, I am expanding my already rather large area of responsibility.
The former director of the Twitter development department, David Loftness, in his “90-day plan for developers who are going to become managers” said that he delayed the termination of programming work, because of this, he did not give a critical assessment of one of his team members who could not cope with his duties in time. This became an important lesson for him, and since then he began to devote a minimum of time to programming, and then on a residual basis.
Do not try to close all the “holes” with yourself — you simply will not be enough for this, but if you do not eliminate the cause of the failures, then the whole ship will go down.
Even before I started working in management, I got a good “vaccine” from trying to “do everything with my hands”. I had an example of our product in front of my eyes — before joining the company, he had his own small advertising agency in the Urals, so he came “both as a reaper and as a gambler”, understood both design and (at a basic level) coding, branding, and search promotion, in addition “burned” with the product and constantly generated new ideas…
The investor allocated modest budgets, in addition to the PMA, there were four people in the staff (me, a PR man, an administrator, an editing operator and a sound engineer) – and a dozen tasks not covered by such a composition, the same SEO… Instead of setting aside a week (or even a couple) to assemble a pool of necessary contractors, he tried to do everything himself.
There were enough skills, but there was no man. “Sprayed” on heterogeneous tasks (and also “jumping” from one to another), he did not have time to finish anything, completely launched his direct managerial duties (which caused confusion and vacillation among other employees) and in addition completely “burned out”, physically and mentally. As a result, now the startup has officially collapsed, and that manager has dropped everything and left to teach dancing. That’s the story.
My good friend Kostya, previously a former front-middle in the same company teaching a foreign language, is now headlong into game dev as a PM.