Jméno autora:simonustal

and deliver 80%+ of key results consistently. Many software companies have adopted the OKR system. Compared to the old-fashioned yearly SMART goals, the shorter quarterly-based objectives of OKRs are more likely to result in strategic initiative completion due to the shorter feedback loop and regular monthly updates. On the other hand, it is more challenging for a manager to handle the condensed 3-month cycle right and deliver outcomes. Scenario Practically speaking, after the OKR system is introduced to the company, most people have the impression of being on a runaway train. The Q3 goals have barely started and in two months we come to the end. We push goals over the finish line while, in parallel, we are supposed to start preparing the new Q4 objectives. Initiatives seem to have neither beginning nor end. As the result, you can find your department misses its goals by a huge margin. That’s why we decided to run an experiment, codenamed: Sprint Zero. Sprint Zero Don’t set your team up to fail, don’t give them “permission to suck.” Instead… pause, take a moment, and set up for success. The sole purpose of the initial 2-week sprint is for teams to prepare their ammunition. It makes them more confident and they might deliver 80+% of the plan. In a nutshell, during Sprint Zero, the team is asked to accomplish the following four tasks: We materialize these steps into tickets and plan them into the sprint as high-severity issues. Step 1: Team strategy The purpose is to make teams facilitate solutioning sessions. Teams explore various alternatives and choose the best strategy to achieve a given objective. The strategy is then sliced vertically into epics, representing a series of milestones. In essence, each epic reflects a delivery increment with a clear outcome and acceptance criteria. On top of that, we group epics into topics/initiatives, representing high-level objectives. To assign the topics to a given OKR quarter, we tag them with the quarterly label, such as 2020Q4. Topics can span several quarters depending on their long-term nature. To cover OKR vs Epic battle, there are initiatives that connect the dots in between. Step 2: Capacity check Having the strategy translated into epics and topics, the team checks its capacity, taking other team dependencies into account as well. We perform the check simply by having a look at the number of epics we delivered in the past OKR cycle compared to the number of the new quarter’s epics. This comparison strategy demands that teams slice epics to similarly-sized chunks of about one month of implementation time on average. The ultimate expectation is to make the team goals slightly more ambitious, yet achievable. Over-commitment often leads to burnout. In case the planned effort does not fit into the team’s capacity, the team is allowed to change the solution, adjust the scope, ask to reorganize the team’s workforce, or involve third-party companies to meet their OKRs. Step 3: Initial epics solutioning After the strategy is all set, we solution the first epics and create their child development tasks. This way, we are ready to plan the tasks immediately at the next sprint. The initial epic is usually an MVP, which can be seen as a minimalistic end-to-end working skeleton of the core feature. At this point, additional subsequent epics of the parent topic are not solutioned and have no child tasks. In fact, in our development process, each epic starts with a solutioning ticket that is auto-generated. Conversely, after each epic is completed, the team validates the objective strategy and is entitled to steer when asking the question: How confident are we in finishing all the epics of an objective by the end of the quarter? Are we in need of modifying the strategy, changing the direction, adjusting the scope, or removing some of the tasks or epics? Step 4: Backlog re-focus I cannot emphasise enough how underestimated, yet crucial this step is. In practice, when starting to work with OKRs, one might spot a team that: This situation usually happens when a team is pressed from too many individual stakeholders in parallel, having nobody capable of raising a hand or making a decision. Instead, give your teams enough time to re-focus and to triage their backlog. Invalidate tickets that are two years old and have no higher value. Get rid of low-priority items you will never come back to. Eliminate the tickets left from past objectives. In essence, verify at least 50% of your backlog is related to the new goals. Moving forward After Sprint Zero is completed, there are two indicators I closely observe to ensure we get our key results delivered. 1. Objective contribution At first, we measure the objective contribution ratio as the cycle time sum of the objective-related tasks closed during the quarter vs. the sum total of all tasks closed within the same period. Given the ticketing hierarchy above, the task contributes to the objective if, and only if, its parent epic relates to a topic that has the current quarterly label assigned. Other tasks are considered to be off-objective. The expected guide rails are that the ratio is at 50–75%, ensuring teams invest their skills into what matters most and advance us toward completing objectives. The more legacy and support-demanding the product is, the lower the ratio that can be anticipated. 2. Objectives completion Given the fact the teams have reflected the full quarter strategy into topics and epics, we can calculate the second indicator — Objectives completion % — in real-time. In essence, it is the number of all the deployed epics divided by the total number of epics. Here, the epics are related to the current quarter`s topics. Objectives completion is an indicator signaling the pace of getting objectives over the finish line and our delivery confidence, providing steering insights. For instance, we might decide to drop an epic or to change the strategy for the sake of hitting the objective. Lessons learned Sprint Zero is your friend, it is an opportunity to get the

As a founder of a small startup, managing everything falls on your shoulders. As the company grows, you find yourself busy resolving architectural issues, hiring, and managing other small priorities, leaving no time for strategy. The need for an engineering manager becomes evident. How do you identify the right fit? What expectations should you set, and what questions should you ask? If you find a promising candidate, how do you ensure they choose you over your competitors and set them up for success? This guide will walk you through the steps to identify, interview, and hire the right engineering manager for your startup. Don’t start from the middle A common mistake I see many CTOs make is starting the hiring process from an intermediate stage. They open the pipeline with a generic job description and wait for a miracle to happen. It usually doesn’t, especially when your description lacks the right appeal/mission. Define your Engineering Manager‘s triangle Define the areas you want your engineering manager to cover and to what extent. Let’s call this your EM responsibility triangle, made up of three main components: leadership, processes, and delivery. Similarly to the CAP theorem, if you expect your engineering manager to oversee all three, you might inadvertently set them up for failure. Focus on two, leaving room to address the third if needed. What happens if you omit one of the three from the immediate responsibilities? This approach helps you decide whether to hire a junior, mid, or senior engineering manager based on your specific needs. Tap into your network After finalizing your job description, don’t rush to post it online and start hiring. Rather than starting with agencies or HR recruiters (which many people have become allergic to), there’s a better approach: The 10 questions to Ask engineering managers Imagine you’re lucky enough to have potential candidates reaching out to you. Now, how do you recognize a good engineering manager during the interview process? Dig deeper into their attitude toward each component of your EM responsibility triangle with the right questions. This set of questions also applies to those promoted internally to an “Acting EM” role, as long as you have the time and resources to nurture their development (learning, mentoring, coaching). You should have a strategy for employee growth, recognizing and maximizing their potential. Dedicating 6–12 months to this growth cuts out the need to recruit externally while benefiting from their existing knowledge of the business. However, in my opinion, relying exclusively on managers from within your organization might not offer enough diversity. 1. “How much time do you desire to dedicate to coding?” The classic struggle for first-time engineering managers often comes down to the balance between coding and managing. Ask them how much time they expect to spend coding vs. managing in the role. If they want to get their hands dirty with coding 50% of the time with a team of 6+, they’re (most likely) misguided. Communicate that to do leadership right, each direct report will require 10–15% of their time. Even if someone has the potential to be a great leader, they might choose to step down and return to the developer track. Usually, it’s because they still want to be hands-on with coding. That’s why it’s important to carefully gauge the timing for facilitating a smooth transition. 2. “When faced with an urgent task, how would you support your developer in completing it as quickly as possible?” A subpar response would be deciding to do the task themselves. A better approach would be to collaborate with the developer or pair them up with someone to speed up its completion. But the most impressive answer is when the candidate doesn’t just accept the urgency at face value. Instead, they dig deeper into the reasoning behind it. Often, the perceived urgency is misguided due to a misinterpretation of the situation, or there might already be an existing solution that can be utilized. 3. “How do you prioritize the well-being of your direct reports? / What do your one-on-ones look like?” There are specific leadership criteria I look for, rooted in the “People First” principle. I want to hear that they prioritize the well-being of their direct reports through frequent one-on-ones that emphasize career growth and skill improvement. I gain deeper insight into these one-on-ones, their secret tips, and what works for them, paying attention to the proportion of time spent on status updates. If this dominates the discussion, then something isn’t right. 4. “Can you share your experiences with hiring and firing?” Optimally, the candidate should have some hiring (and firing) experience. I often see managers shying away from firing poor performers because they’re afraid of sending a negative message. A good manager recognizes when tough decisions are necessary for overall team effectiveness. 5. “How do you usually take care of a new starter in the team?” Onboarding and hiring take precedence over operational work. 6. “What’s your approach to existing workflows within a team?” It’s paramount that the candidate has been involved in the entire process of releasing a new product from start to finish. A successful product increment goes beyond just following scrum methodologies. I expect them to have experience starting from idea generation and opportunity assessment, all the way to detailed refinement. It’s important to see if they explore the ‘Why’ behind initiatives and try to understand the motivations and benefits for us or the customer before diving into the technical aspects. I also look for evidence that the candidate’s thought process doesn’t just stop once new features are deployed. Are they proactive in gaining customer feedback and putting in the effort to refine and enhance the new release, making it truly exceptional? 7. “Can you provide examples of when you’ve enhanced existing processes?” Choose someone with a continuous improvement mindset. If they accept the status quo, they’re dead. The right candidate experiments with workflow enhancements, from code reviews and testing to meetings, daily standups, and prioritizations. Without this continuous improvement mindset, processes can stagnate and

Have you ever thought about conducting performance reviews that your team actually loves? You have the power to establish a system that brings value to both you and your team.