Crutches, Narnia, Ninja procrusts: three pains of a timlid in a startup

    Timlid in a startup - both Ilon Musk and Frankenstein. In the morning he constructs spaceships, and in the evening he draws a cry to the project: “Live! You cannot die! ”- and laugh unhealthily. And all this in the company of three juniors.

    Alexander Polomodov leads the development of attraction management at; previously, he was the head of development / CTO in small companies. We asked Alexander to remember the past and tell what pitfalls a team could expect to come to a startup.


    Under the cut - answers to important questions:

    • how to survive in conditions where interaction processes are not established (or do not exist at all);
    • how to put together a cool team when payroll is limited;
    • how to understand that you need to run from the project.

    1. Full of ideas, no one to do

    You come to a startup in a startup. Waiting: immediately start working on new features. Reality: hunt the developers, because a strong team is needed yesterday, but no one took care to assemble it.

    There are two possible options - heavier and easier. Painful option: money in the FOT is small. One of the best solutions in this situation is to take interns with a clean and bright head, and put all the necessary knowledge and skills into this head: draw each individual development plan, paint step by step what knowledge he will need to get, what skills in what order to work out. It's a great way, but, unfortunately, it is not yours: this is a long game, and start-ups who need to quickly show results, almost never do this.
    Characteristic phrase: “We need top experts on Angular. We pay below the market. ”
    Easy option: there is money, and you are ready to offer good market conditions.

    Typical case. Frequent practice in IT companies in this case is to put the basic requirement for the candidate to know the specific stack of technologies. A few years ago, job descriptions were constantly meeting “looking for jQuery ninjas”. The problem is that many of these ninjas seem to have come out of the Procrustean bed - they can only write to jQuery (is there no one in the new project? Well, excuse me). And if a person not only knows the specific stack perfectly, but also has a good base, then, most likely, some corporation will interrupt your salary proposal.

    Decision.When there is money for adequate salaries, you need to look for people, focusing on the availability of fundamental knowledge and hard-to-learn skills such as systems thinking. Even if a person is not familiar with a particular language or technology stack, he will master everything basic for a quarter if he wishes.

    When you can’t compete for the best specialists in salary, it’s worth hiring people with a bright head who have unsuccessfully chosen the field. Man designed chips, and now decided to change the area to a more cash? We take.

    2. CEO from Narnia

    The second difficulty that a tmlid in a startup may face is rose-colored CEOs. Plans that are already presented to clients or investors do not coincide with reality. The team is pressed in time, they need to quickly show the MVP, add features, while constantly setting hard unrealistic deadlines. New and new layers of the crutch code are accumulating, technical debt is accumulating, and the creator of the startup is sure that everything is in order - just the developers are either lazy or voiced by pessimistic forecasts.

    Often this situation arises from the sales manager. He has already sold the air castle, - and he doesn’t really care about how to build this castle now.
    The characteristic phrase: “I sold these features, they should appear by the end of the week, month, year” (underline the necessary).
    Typical case. The CEO wants a release in three days, the developer evaluates the task and tells the team what he can do in five. Explains: “The API you have to work with is a long time to integrate. If the API will work as the partner promises, I will be in three days. But, in my experience, the API of this partner often does not correspond to their promises, therefore - five days. ” The CEO replies: “The partner promises that everything will be fine. You have three days, ”and after the meeting, the CTO says:“ I don’t understand anything in development, but I almost halved the task assessment. ”

    The developer of this case tried and completed the task in four days. Anyway, there was a facac, but even if he had met the deadlines, he could not continue for a long time, this is the terminal stage of not understanding how a normal, healthy team should work.

    Decision.Discussing the timeline is normal, but it should be a reasoned discussion. The answers in the style of Tony Robbins: “A week is too long!” And “We must try harder!” Is an indicator of rose-colored glasses. To remove them is a serious test of the communication skills of the team leader.

    It's not about knocking down the price of bargaining, as in the market, where there is a lower cost and margin, which is distributed in a zero-sum game between the seller and the buyer. It discusses the engineering solution, the assessment of which you want to get into account taking into account additional factors. The developer does not bargain for himself five days of work, but gives an estimate based on his knowledge. If you put pressure on him, he will reduce the time, but most likely, he will discount all risks. And when something goes wrong, the plans will go. This is something important to convey to the CEO, and if you do not want to understand - run, fools.

    3. Technical debt at microcredit interest

    The story of the creation of OS / 360, told in the book “The Mythical Man-Month” by Frederick Brooks, is very indicative. It was supposed to be the coolest operating system of the time. IBM attracted thousands of people to the project and still missed on all points: on terms, functionality and support capabilities.

    From the book of Brooks it becomes clear that then the developers stepped on all possible rakes, and this despite the fact that they used Waterfall and quite clearly represented the stages of development. And today, with the ubiquitous spread of Agile, the team and the architectural plan for the long term are often not there - only backlog, consisting of business tasks, and a sprint of one to two weeks. So the architecture goes corresponding.
    The characteristic phrase: “Repaint this button in blue? It will take a week
    Conditionally, if in the first sprint the construction of three apartments is planned, then in the second row a hut or hut is built. Then comes the new task - to cover them with a common roof, and if you install the roof somehow, it turns out that there will be another floor above and so on.

    Where a real house would have collapsed long ago under the weight of designer errors, technical debt is formed in the design. And if at first the work on the project goes according to plan, and no one notices the crutches, then at some point it turns out that a simple feature that initially cost a developer’s day now takes twice as much. And since decomposed crutches have to be bypassed again and again and adding new ones to them, a feature will cost five times more expensive in a quarter.

    Decision.A normal manager makes decisions based on facts and figures. Come with calculations: show how much an uncovered technical debt will cost in a month, in a quarter, in a year. So you will have the opportunity to adjust the plans, including in the sprints, not only new features, but also a phased "payment of debts."

    Of course, this is not an exhaustive list of problems faced by startups, but these three are among the most acute and difficult to solve.

    Alexander Polomodov - Teamlead Weekend Intensive Curator in the Binary District; The closest course will be December 15-16.

    Also popular now: