Managing expectations or saying no

    Teacher University of Finance Tigran Baseyan told Netologii about your experience in the corporate startup Borjomi and expectations of management.

    How many times after an unsuccessful project I thought: “Now everything will go differently, I gained experience. Such things I will no longer do. And I will not take such projects. ” Feel the pain? Do you recognize yourself?

    There is such a heading - share what you learned from experience - then with blood. I will share several expectations management techniques that I would be happy about 8 years ago at the beginning of a career in IT.

    I’m sure that the picture with Jim Carrey “Always say yes” is to blame. But we are adults and we must understand that for a business, any answer “yes” is a cost. And even worse, if you can not answer the question "Why yes?" and "How did it happen?"

    “Your expectations - your problems” - what it means to manage expectations


    From the dictionary: “Managing expectations - when you bring the picture of the world of users, the
    customer, the project sponsor and other interested parties to the maximum possible match with reality, so that a collision with it is as painless as possible.”

    Matching reality, what is it? It's about creating a single "real". That is, reducing the difference between expectations and what is happening, which occurs when:

    • The goal is not clearly formulated, that is, each goes in its own direction.
    • No communication between team members, leader, customers.
    • Everyone sees implementation in their own way.

    In this article, I will consistently talk about each item and give practical tools that will help resolve restrictions in these areas.

    If you reformulate the pain above, then managing expectations is:

    • Creation of common and understandable goals.
    • Creation of a single platform for communication between all interested parties.
    • Synchronization of what the team is working on and how.

    SMART: how to set project goals


    Six months ago, I switched to a corporate startup - and was not ready for the fact that all hypotheses should be tied to a specific goal and formulated by smart. I used to work, relying on my intuition, although often it let me down. And that was one of the most memorable Aha moments.

    A correctly formulated goal allows you to cut off the unnecessary, to create a single language of communication between team members.

    The most common problem when setting goals is their abstractness:


    The other day I was talking with my former colleague, who set himself the goal of "improving the home page of the site." It seems like a goal, like a goal, but it is not very clear from it what it means to improve what needs to be done and when, how to measure the result.

    To turn an abstract goal into a specific one, it is convenient to use goal setting methodologies. There are many, the simplest and most popular is SMART.

    The methodology includes five basic characteristics that each goal must meet:


    Specific


    The goal must be specific. Concreteness - a clear understanding of the result to be achieved.

    Bad example: "Make the interface better." In this case, it is not clear why the current interface is bad, what needs to be improved. What metric above?

    A good example: “Increase the conversion to the target action from 1% to 3%." Such a concrete formulation immediately gives an understanding of the amount of work, alternative tasks, for example, which tools to apply.

    Measurable


    The goal must be measurable. Each goal should have some measure of dimension. With its help, you can understand whether you have achieved the desired result or not.

    In the example above, this value is conversion indicators for the landing. If we talk about other examples, then often we want to go on a diet or go to the gym. But it is not clear how many times you need to go to achieve the goal. Is one time enough or not? Here it would have worked better “To conduct 10 trainings in the gym until January 31, 2019.”

    Achievable


    The goal must be achievable. Reachability of a goal affects motivation. It is not necessary to set yourself very simple goals, because interest in this case also disappears. But no matter how you want it, your brain is unlikely to be serious about the goal “To be on the moon by February 1, 2019”. But the goal of “Publish an article by February 1, 2019” seems far more attainable and makes this interesting.

    Relevant


    The goal should be meaningful to you. Significance in the SMART methodology is the value of the contribution that will bring the solution to this problem in achieving the strategic goals of the company.

    Time bound


    The goal should be limited in time. The goal of “Learn English” will be much less effective than “To pass TOEFL certification by at least 95 points by December 15, 2019.” When a time mark appears, to which you want to get a result, the brain autonomously builds a conditional timeline. You understand that for passing certification you need to learn, for example, 800 words. The brain understands that it is unrealistic to do this in 3 days, so you need to make a plan.

    Do not overestimate goals


    Recently I heard in one conversation:
    - I have set a plan for X rubles for this month, I think they can make about 70%.
    - What for?
    - There are several reasons: first, a larger plan means the initial one is easier to do. Heard about OCD? So this is a cool topic for management, Google is working on it. It is necessary to set the KPI higher so that a person does not fulfill more than 70 percent.


    If you hear such a conversation from the head of the sales department, you can easily imagine that in this way he motivates his team to rise and work. But if we talk about IT projects and products, then this approach is ineffective and harmful. First, you can read about OCD on the page .

    OKR (from the English Objectives and Key Results - goals and key results) - a method that is used in management to manage projects. It allows you to synchronize team and individual goals and provide effective control over the implementation of tasks. The OKR method was developed by Intel. After it became widespread in a number of large technology companies, including Google, LinkedIn, Zynga.

    In general, a technique to promise / put a higher plan to make a standard is a slippery path:

    • With the perfect performance of the work, you are not able to achieve the goal that is unattainable by definition. Such work cannot inspire. So - this will lead to the fact that your team will begin to stress, get tired, and then burn out.  
    • Customers will be waiting for just the optimistic scenario, although it is unrealistic, which means they can not explain in any way that everything went right, just the goal was overstated.


    I saw another option for setting plans / goals, making them inflated for the team and underestimated when presented to customers. But the risks in this approach are the same as in the previous statement. You risk losing the team if you do not fulfill the overestimated plan.
    Bottom line: to set plans that are realistic to implement and for which you can vouch.

    Communications at work


    SMART can diagnose and synchronize the start of work on a project by creating a common point - the point of origin. But everyone has their own speed, so we need tools to synchronize the work.

    Set the origin point


    At the beginning of the article, we focused on creating a field for effective communication by setting the right goal. And what about the decision, what should be the goal?
    Learn the questions below:

    • “Why does he decide everything? I also want to".
    • Why don't they value me?
    • “I did everything very well, it just didn’t work before.”
    • "I immediately said that this idea would not fly."

    The problem with such statements is the lack of association with the goals and objectives of the team. Thus, the notorious team spirit and does not smell in such "teams." Read more about seven examples of the value of teamwork on the site . I'll give you an example of a study by Uri Hasses:

    Professor at the Princeton Institute of Neuroscience Uri Hasses during his researchdiscovered the unexpected brain activity of story-sharing participants. “Not only the similarity of brain activity in all listeners is surprising. Moreover, the storyteller had very similar brain activity - despite the fact that he was telling the story and the others were listening, ”says Hasses. Sharing opinions, stories can improve employee productivity. They can begin to feel, think and do the same as the characters in the stories they hear.

    Purpose and Communication


    What is the reason for the synergy of teamwork and how is this related to setting goals? And the connection here is nowhere closer. Healthy team communication leads to the creation of the so-called “Team Crystallization”. A crystallized team is a group of people so strongly connected that the whole becomes larger than the sum of its constituent parts.

    The benefits of teamwork will be as follows:

    • In general, a team has more experience and knowledge than each individual member.
    • A team is more effective than individuals regarding errors and eliminating their consequences.
    • The decision made by the team is more likely to be approved by those who have to implement it.
    • Team members are more likely to identify with their own actions and contribution to the decision made by the team. The likelihood that they will perceive the decision of the group as the right one is higher.
    • Team members learn from each other and stimulate each other in the process of mutual learning.

    You must use the command to create a common goal, then you can build a starting point - not the fact that it will be true. But at least - your team will believe in it and go with you in the same direction.

    How to work with development cycles?


    I will not dive into the psychological side of the issue and understand the different development management models. Instead, I will analyze the communicative component of teamwork and look for answers to two questions:

    • Why am I waiting for one, and the team is doing the other?
    • Why do we understand the problem the same way, but we can’t solve it?

    The key concept for parsing errors is communication. How are we used to working in teams? The classic development cycle looks like this: come up with, develop, measure the result.

    The length of these cycles is from 1 week to 4 weeks according to Agile. In such circumstances, there is no time left for communication between team members - we are all in a hurry to realize the goals. And all would be fine, but why does part of the work go “to the table”?

    To effectively work on a project and interact with a team, it is important to answer the questions:

    • What will benefit and what will not?
    • How to prioritize the backlog, how to set tasks to work on?
    • What to do?

    And a logical step in any development methodology will be to enter the world of backlog prioritization. How to do this - use the RICE technique? Or ICE? And if our product is just being created and we really don’t know anything?

    HADI at work


    I will present you another tool that I actively use as part of the training process, work in startups, and in life.

    Check team assumptions as quickly as possible? If you have a goal, the team generates ways to achieve it - hypotheses. The list of hypotheses is growing every day: if at the beginning it is only 1–2, then by the end of the week it may already be 20–30.
    How to prioritize them? Two tools will help here:

    • HADI cycles
    • team assessment of “faith and complexity” of working with a hypothesis

    About it later.

    HADI cycles are one of the tools of the methodology with which startups are “pumped”. The essence of HADI is simple. Almost any action affects some specific metric. If the changes are “screwed” to the indicators in advance, that is, to formulate hypotheses, the entire process of changes will be controlled. In a word, you will understand how your actions influenced the result, and you can quickly test ideas by discarding non-working ones.

    Hypothesis


    The control cycle begins with a hypothesis: if we do X, then it will affect Y, during T. We use SMART to form a hypothesis. “We assume we will make a landing and get new customers. This formulation is written in the cell H - hypotheses.

    Actions


    How do we get customers? What needs to be done for this? You need to order a design, make up, lay out a landing page, set up an advertising campaign. This action plan is written in cell A - action.

    Data


    How many customers do we expect? If 100 new customers come, is that good, will we be happy? What about 50? What about 10? But just one? And not one? Sometimes it turns out that even if no client has come, you still do not consider the hypothesis to be confirmed. There were no customers, but there were applications, it just did not work out to process them correctly. What will you look at and what will you measure to confirm the hypothesis? This will be the number of applications, calls or sales, and for what period? We write this in cell D - data. In cell I with conclusions we write at what value of the metric the hypothesis is considered confirmed.

    Incites


    What will you do if the hypothesis is not confirmed? Most likely, look for another way to achieve the same result, get 20 new customers. That is, formulate and begin to test the following hypothesis. And if confirmed? You will also test the following hypothesis, which leads you further to the goal. The answers to these questions also need to be formulated in advance before taking action. They supplement cell I - conclusions.

    HADI tables


    After the hypothesis is formulated, team members evaluate the complexity of its implementation and the belief in success from 1 to 10. Everyone must substantiate their opinion. After putting down all the grades, the table needs to be sorted by increasing complexity and decreasing faith. As a result, those hypotheses that the team needs to work on will be at the top.


    HADI is a tool for quick experimentation on a project, not a team punishment


    Examples of tables from the Carrot Quest case

    HADIH - HADI Hybrid


    In our work, as part of a startup, we used a hybrid HADIH, the main difference was that each line within the hypothesis ended not only with a set of Insights, but with new Hypotheses that stemmed from the received insights. These new hypotheses at the end of the iteration were included in the general backlog of hypotheses, prioritized by faith and complexity. Thus, as part of the work on the current hypothesis, we could generate related hypotheses for new iterations

    How iterations were built


    In my team, I took the following approach to organizing iterations and meetings:

    1. At the very beginning of the implementation of the methodology, we held a 2-hour session with all team members and the customer to create the maximum number of hypotheses for the product. All hypotheses were digitized and entered into the table, the team and I filled in the columns H, A, D. As a result, each hypothesis turned out in SMART format.
    2. The next meeting was with the team and the tracker - he used different development techniques and helped by asking questions. Each hypothesis was evaluated by faith and complexity. At the same time, I added to the assessment “Implementation time” to consider the capacity of the team for a week
    3. We held a meeting every Friday to complete the current iteration and start the next. At the meeting, we supplemented the table with insights and new hypotheses, shared the results of the work, made a decision on scaling any hypotheses.

    Do you need to manage expectations?


    There are many methods of managing expectations in the project work, but the problems of differences in expectations during the course of the work, when demonstrating the results, are symptoms of another, more serious problem.

    You can read many smart books on how to maneuver between requests, land expectations, not accept requests, but for me it all lies in the area of ​​team decision-making and open communication.

    It is necessary to organize teamwork so that everyone understands the goal, including the customer. It is necessary to create conditions under which your team will start working, will look for ways to achieve the global goal.

    I promise that it will be uncomfortable at first, and then too, growth is always painful.

    Netology courses for interface designers:


    Also popular now: