Intro:
This document is designed to assist managers and teams in crafting high-quality OKRs that maintain focus on executing the company's strategy and achieving ambitious results.
It is recommended to use these quality checklists during quarterly planning when formulating OKRs for the new period.
They will help you find potential areas of improvement and strengthen your OKRs.
We are a brokerage platform operating in a dynamic and complex domain. This specificity comes with a set of challenges. On the one hand, it entails a high variability of scenarios and potentially significant risks associated with errors. On the other hand, it has short development iterations with frequent delivery cycles.
In this article, we will share how we maintain the quality of our numerous backend services, which provide essential information to our trading terminals.
In the world of IT services, the idea that operations must run 24/7 is often taken for granted. However, for business-to-business (B2B) services, this assumption needs to be rethought. By reconsidering the need for around-the-clock processing services, companies can achieve significant benefits in efficiency, security, and sustainability.
Sometimes it seems that jokes about management implementing Agile to do more with less aren't far from the truth. I've rarely seen development teams understand Agile as anything more than a set of ceremonies, most often associated with Scrum.
In my experience, attempts to optimize team performance often boil down to changing the internal processes within the team itself. Meanwhile, critical decisions are made outside the team, remaining in a waterfall model. This creates a disconnect: on one hand, company management strives for the flexibility of Agile, while on the other, they continue to follow rigid patterns, limiting the team and preventing it from fully realizing its potential.
Hi! My name is Slava. I am currently working as a leading Product and Senior Project Manager at Uzum Bank. One of the leading digital banks in Uzbekistan.
We are growing fast. Really fast. Speaking in numbers, our interest income has increased x10 over the past year (!).
And, as in any similar projects with rapid growth, we constantly lack qualified personnel. So I and my colleagues always have a lot of work to do.
I have two teams with completely different products, and I also manage some projects as a project manager. And I have my own small business – an online tea and coffee shop. And in conclusion, I am the father of two small children)
So, I hope this makes it clear to you that I have faced all the problems, such as working at night, lack of sleep, working in a noisy environment, calls with crying children in the background, calls during breakfast on the wheels, when I take a child to kindergarten (never do that!) etc. and so on and so forth XD
You can ask me: how do you manage to do everything?
The answer is simple: I don't XD
But. This forces me to build a system that helps me quickly switch between different types of tasks, focus quickly and complete them over and over again.
So, today I want to tell you about one of the things, that can completely ruin your day. And sometimes – whole week. It's called "context switching".
Modern product development demands more and more sophisticated designs. This in turn leads to the increased complexity of both demand and implementation. Business is flooding the architecture and development teams with the new and changed requirements. Development teams are struggling to understand what the business demand is and find the best product increment strategy. One of the widely adopted conversational methods is the Use-Cases. This guide is intended to shed light on the process of the requirements development and maturing.
In the software development industry, a lot of time and resources are spent on meetings. Many managers have calendars filled with meetings most of the time.
According to a study by Atlassian, the average worker spends up to 31 hours a month on unproductive meetings. That's about 8 hours a week, which is equivalent to a full work week for one employee out of a team of five people every month. If we convert this into working days, it means that on average four people are working, and one is constantly in meetings. This does not take into account additional time spent on informal discussions and ad-hoc meetings, which further reduce the time available for direct work on product creation. Thus, developers actually spend less than half of their working day on direct development, which is a worrying sign for any organization striving for innovation and efficiency.
Personally, I don't like meetings. I always try to minimize communication if an issue can be resolved without a face-to-face meeting. I apply this rule both at work and in life. For example, I prefer to refuel my car using an app, and I try to order food and other services without needing confirmation from an operator, and I did this even when such an approach was not so common. If I need to find a place, I will open a map in the app, instead of asking passers-by for directions.
My reluctance to waste time or be inefficient has resulted in our software development department carefully monitoring the time our developers spend on meetings. On average, a developer has only 2 hours and 15 minutes of mandatory meetings per week, including four 15-minute stand-ups, a 30-minute one-on-one meeting with a manager every two weeks, and 60 minutes for various meetings such as planning and demonstrations. The rest of the time, about 5 hours and 45 minutes, is spent on other activities in MS Teams, including chats and individual calls. Although we believe that this time should also be optimized, we focus mainly on key meetings to ensure that every minute spent is valuable.
In this article, I will consider the approaches I use and the ideas that motivate me to minimize the costs associated with meetings.
This text is a compilation of author’s experience, written to provide new juniour/middle teammates the basis to start developing computational intensive or/and ML based systems. It will take you about 5-10 minutes for reading.
This week, I was reflecting on a recent one-on-one chat with a manager in my division about keeping our backlogs clean and dealing with those tasks that just keep getting pushed back.
I jot down my thoughts and decided to share them with you. It's a common issue, right? Tasks hanging around, always getting postponed. Let's talk about the mess this creates in our backlogs and how to handle it the right way.
Check out my latest article where I dive into the art of backlog hygiene. Trust me, your team will thank you for it!
Launching a startup often means navigating through stringent constraints, particularly in the early stages where resources are limited. For technical founders, who usually possess deep expertise in certain technical domains, the inclination might be to hire a team of senior engineers—considering you often end up with only one expert in each domain, it might be risky to delegate entire segments to junior specialists.
This situation typically leads to a small team where each member is more skilled than the founder in their respective field. This raises an important question for the technical lead: what role should you play in this team?
While the apparent answer might be task setting and quality control, prompting engineers to do what they love (coding), a less obvious but crucial role emerges. As a leader, your primary responsibility could be to prevent your team from engaging in unnecessary or potentially detrimental tasks, a concept known as "overengineering."
In this article, I will explore the critical role of a technical lead in steering a team away from overengineering and ensuring that their efforts align effectively with the startup's goals and resources.
Today, many companies are transferring their development processes to Agile frameworks. In this article, I discuss how the concept of a Project and the position of classic Project Manager are transferred in accordance with the Agile paradigm.
Multidisciplinary project emerges when multiple teams with different expertise areas join to create a product. Despite the fact the product development is not something happining merely my a wish, product leads often perceive it as an easy walk. Usually this easy walk becomes a crash course. Let's uncover what leads to crash and what is necessary to succeed.
- Continuous Improvement is also a Project, a meta-Project, a maintenance that usually lasts longer than the main development project.
- If you can fit into the Sprint boundaries with your development cycle, then the concept of Retrospective as it is formulated in SCRUM may also suit you. But if you are bigger and not oriented on CI/CD, then be ready to make a hybrid of SCRUM with classical Project Management – thanks God SCRUM is good embeddable (proven by SAFe) !
- What is left out in when we run retrospectives quarterly? – Plan and Check. The placeholder of classical SCRUM Retrospective is quite suitable for that purpose, surrounded, of course, by some additional groomings, providing required action plans and decompositions up to sprint-length steps.
I am a Project Manager. 14 years of project management, 5 years in agile framework, last 4 years in product companies, last 3 years in ABBYY, mobile technologies. I would like to share my practical experience, how we have organized the planning in ABYY Mobile Technologies having SCRUM development.
“SCRUM — you get too little, and you need to add the missing.” The story about how we adjusted the Planning procedure for yearly roadmapping and budgeting, how we have organized the SCRUM‑planning for the feature‑driven development with product development cycle 2–3 months and more.
This article describes the new Nginx Unit web server. In it you can learn more about the web server itself, its installation and configuration: how to use listeners, routing, how to install TLS certificates. The article will show how easy it is to work with it and that huge configs are slowly becoming a thing of the past.
CTO: Balancing Leadership and Architecture.
As a CTO, effective leadership goes beyond technical architecture. Conducting regular performance reviews is a crucial part of managing teams.
Note: The performance review schedule may vary depending on the specific
company's policies and guidelines.
For early-stage startups, lacking CTO expertise in conducting performance reviews is common. In my experience, I've tailored grades to encompass all aspects of professional iOS development, keeping project-specific needs in mind. Being the first in the team can offer significant growth opportunities. However, acknowledging any lack of people management skills and compensating through continuous growth is essential.
I've compiled my insights on structuring the iOS development department, conducting performance reviews, and most importantly, emphasizing the significant distinctions between developers' levels based on well-defined criteria.
I have been working in Agile since 2017 in several projects.
And I would like to note here a couple of moments from real experience through the eyes of developer role in project.
Hope it will be helpful for you!
The problem
Unfortunately, when fulfilling their planned business goals, the departments of the organisation rarely take into account such a metric as solution code quality. And usually developers has no time for normal code review process.
Background
As a product manager with over a decade of experience, I'm always looking for new ways to enhance my skills and help other product managers advance in their careers. One area that many companies focus on during the job interview process is analytical and creative problem-solving. And as product managers, we encounter these types of challenges on a daily basis. It's important to stay sharp and continuously develop our problem-solving abilities. That's why I made it a habit to practice a logic puzzle every day. But I also wondered if there was a common approach to solving these puzzles. That's when I discovered TRIZ – the Theory of Inventive Problem Solving. In this article, I'll provide an overview of what TRIZ is and how it can be applied in product management. Then, I'll apply TRIZ principles to solve a series of logical puzzles, showcasing the power and effectiveness of this methodology. So whether you're an experienced product manager looking to enhance your skills or someone who enjoys a good brain teaser, read on to discover the power of TRIZ!
If you find TRIZ to be a useful tool for problem-solving and innovation, there are many resources available to help you delve deeper into the methodology. The TRIZ Journal, for example, offers enough information on TRIZ, including case studies, articles, and other resources. You can also find books and online courses that provide a more in-depth look at TRIZ and how it can be applied in different industries and contexts. So if you're interested in learning more, there are plenty of opportunities to expand your knowledge and apply TRIZ to your work.
If you regularly use a static code analyzer, you can save time on guessing why the new code doesn't work as planned. Let's look at another interesting error — the function broke during refactoring, and no one noticed that. No one — except for PVS-Studio that can automatically scan the project and email the report to us.
