{r10} Autonomous teams
{r20} Customer centricity
{r30} Data driven organization
{r40} Decentralized recruitment and staffing
{r50} Engineering maturity
{r60} Innovation process
{r70} Innovation strategy
{r80} IT Architecture
{r90} Operational maturity
{r100} Organizational design
{r110} Organizational health
{r120} Organizational maturity
{r130} People process maturity
{r140} Product execution
{r150} Productivity and efficiency
{r160} Product strategy
{r170} Project management practice
{r180} Project tracking and monitoring
{r190} Quality assurance maturity
{r200} Quality strategy
{r210} Recruitment process maturity
{r220} Risk management
{r230} Staffing process maturity
{r240} Strategic focus
{r250} Tech-Business communication maturity
{r260} Tech communication maturity

{c1} Organizational structure

{q1001} The teams in your tech organization have all the necessary skills to deliver end-to-end customer facing features.

{r100} Organizational design
{w5}

{a1}
You have teams which are not enabled to deliver end-to-end customer features, which is a critical problem for your tech organization that you should tackle with top priority. This prevents it from being efficient and deliver customer value effectively.
Also this usually leads to additional problems, like pressure from the business and perception that your tech organization is not delivering results, low motivation of your technical staff, because they are constrained by your organizational design and cannot demonstrate their potential and skills, long release cycles, high attrition rate, blaming culture primarily due to the interdependencies between the teams and significant frustrations of your managers.

{a3}
You have teams which are not fully enabled to deliver end-to-end customer features, which is a serious problem for your tech organization that you should tackle with high priority. This prevents it from being efficient and deliver customer value effectively.
Also this usually leads to additional problems, like pressure from the business and perception that your tech organization is not delivering results, low motivation of your technical staff, because they are constrained by your organizational design and cannot demonstrate their potential and skills, long release cycles, high attrition rate, blaming culture primarily due to the interdependencies between the teams and significant frustrations of your managers.

{a5}
You have teams which are largely enabled to deliver end-to-end customer value. Keep in mind though, that even few missing skills to fully enable them can dramatically impact the ability of your tech organization to deliver customer value effectively and effectively. The effect is strongly exponential. Imagine a team for example, which has all the skills except the ability to deploy their features. This single skill is missing from your team might slow down significantly the whole release, as the team depends on external teams for the deployment of their features. This applies to any other missing skills. Also this usually leads to additional problems, like pressure from the business and perception that your tech organization is not delivering results, low motivation of your technical staff because they are constrained by your organizational design and cannot demonstrate their potential and skills, long release cycles, high attrition rate, blaming culture primarily due to the interdependencies between the teams. While your teams are to a large extent cross-functional and you might not experience severely all these negative effects, make your priority to fully enable the teams in your tech organization to be completely autonomous, and as a result deliver customer value efficiently and effectively. This will make your tech unit stand out as an exceptional Engineering organization, with motivated engineers and managers, praised by the business and recognised by the broader tech community.

{a6}
You have teams which are greatly enabled to deliver end-to-end customer value. Keep in mind though, that even few missing skills to fully enable them can dramatically impact the ability of your tech organization to deliver customer value effectively and effectively. The effect is strongly exponential. Imagine a team for example, which has all the skills except the ability to deploy their features. This single skill which is missing from your team might block the whole release, as the team depends on external teams. This applies to any other missing skill. Also this usually leads to additional problems, like pressure from the business and perception that your tech organization is not delivering results, low motivation of your technical staff because they are constrained by your organizational design and cannot demonstrate their potential and skills, long release cycles, high attrition rate, blaming culture primarily due to the interdependencies between the teams.
As your teams are to fully cross-functiona and autonomous, you should not not experience these negative effects. Still, make sure that you monitor this characteristic of your tech organization so that your teams remain cross-functional.

{q1002} In your organization, you have people who need to do tasks very different from their core expertise on their own initiative.

{r120} Organizational maturity
{w3}
{i}

{a1}
People in your tech organization are largely not doing tasks which are very different from their domain expertise, which is a good sign for your tech unit. This means that you don’t have significant functions which are missing or that are not executing at the desired level – great news for your tech team.
If in future you identify cases of people who are doing tasks which are very different from their domain expertise, this signals for an organizational dysfunction. Usually, this means that either you have some function which is missing, or that the function is not operating at the desired level. Usually in these cases, people in other teams try to compensate for the gap. Keep in mind though that they are not experts in these other domains, so their efforts might result in even bigger problems. Also working on other domains takes from their capacity and as a result the ability to deliver on their commitments. You don’t have such cases, so make sure you continue to monitor this closely, to keep the good status.

{a3}
The fact that you have some cases of people who are doing tasks which are very different from their domain expertise, signals for an organizational dysfunction. Usually, this means that either you have some function which is missing, or that the function is not operating at the desired level. Usually in these cases, people in other teams try to compensate for the gap. Keep in mind though that they are not experts in these other domains, so their efforts might result in even bigger problems. Also working on other domains takes from their capacity and as a result the ability to deliver on their commitments. In many cases these dysfunctions are outside of the engineering organization. Because of this, when necessary, involve an executive who is responsible for the respective domains and work together to figure out a solution and a plan to implement it.

{a5}
The fact that you have many cases of people who are doing tasks which are very different from their domain expertise, signals for a significant organizational dysfunction. Usually, this means that either you have some function which is missing, or that the function is not operating at the desired level. Usually in these cases, people in other teams try to compensate for the gap. Keep in mind though that they are not experts in these other domains, so their efforts might result in even bigger problems. Also working on other domains takes from their capacity and as a result the ability to deliver on their commitments. In many cases these dysfunctions are outside of the engineering organization. Because of this, when necessary, involve an executive who is responsible for the respective domains and work together to figure out a solution and a plan to implement it.

{a6}
The fact that you have many cases of people who are doing tasks which are very different from their domain expertise, signals for a significant organizational dysfunction. Usually, this means that either you have some function which is missing, or that the function is not operating at the desired level. Usually in these cases, people in other teams try to compensate for the gap. Keep in mind though that they are not experts in these other domains, so their efforts might result in even bigger problems. Also working on other domains takes from their capacity and as a result the ability to deliver on their commitments. In many cases these dysfunctions are outside of the engineering organization. Because of this, when necessary, involve an executive who is responsible for the respective domains and work together to figure out a solution and a plan to implement it.

{q1003} In your teams, you have people who need to do tasks very different from their core expertise, because they are asked to do so.

{r120} Organizational maturity
{w5}
{i}
{n} here we won’t repeat the outcomes, because they are largely identical with question 2. The only area which we’ll add is the authoritative element.

{a1}
N/A

{a3}
At any cost avoid requesting people to do activities unrelated to their domain expertise, if they are unwilling to. These cases signals for significant organizational dysfunction, but if you try to compensate with authoritative top-down approach, you’ll make the things even worse. If the problems are very critical, as a short-term solution find people who volunteer to fill in the gap – at least this will ensure that they are committed to do the job and will decrease the risk of attrition. As a mid-term plan, aim to fix the organizational dysfunction which cause these cases.

{a5}
At any cost avoid requesting people to do activities unrelated to their domain expertise, if they are unwilling to. These cases signals for significant organizational dysfunction, but if you try to compensate with authoritative top-down approach, you’ll make things even worse. If the problems are very critical, as a short-term solution, find people who volunteer to fill in the gap – at least this will ensure that they are committed to do the job and will decrease the risk of attrition. As a mid-term plan, aim to fix the organizational dysfunction which cause these cases.

{a6}
At any cost avoid requesting people to do activities unrelated to their domain expertise, if they are unwilling to. These cases signals for significant organizational dysfunction, but if you try to compensate with authoritative top-down approach, you’ll make things even worse. If the problems are very critical, as a short-term solution, find people who volunteer to fill in the gap – at least this will ensure that they are committed to do the job and will decrease the risk of attrition. As a mid-term plan, aim to fix the organizational dysfunction which cause these cases.

{q1004} The ratio of Engineering Manager to engineers in your organization is between 1:5 and 1:8.

{r100} Organizational design
{w5}

{a1}
Having a healthy ratio of IC to manager is a very critical prerequisite for you in order to build a strong tech organization. Make it a top priority for you and consider a temporary hiring freeze for all IC positions until you reach a healthy ratio of IC to manager. .
Not doing that will be a major blocker for building a strong engineering organization and can result in very negative consequences like high attrition rates, low motivation of your staff, inability to deliver results.

{a3}
Having a healthy ratio of IC to manager is a critical prerequisite for you in order to build a strong tech organization. Make sure you set as a priority hiring the necessary additional managers in order to achieve that ratio across the whole tech unit. Not doing that will be a major blocker for building a strong engineering organization.

{a5}
Having a healthy ratio of IC to manager is an important prerequisite for you in order to build a strong tech organization. Make sure you hire the necessary additional managers in order to achieve that ratio across the whole tech organization.

{a6}
You have a good ratio of IC to manager. This is an important prerequisite of building a strong tech organization.

{q1005} In your organization, one Product Manager works with one team only, which is end-to-end responsible for the implementation and delivery of the features prioritised by the PM.

{r100} Organizational design
{w2}

{a1}
If you have teams which doesn’t have Product Managers, you should make it a top priority for you hiring the needed Product Managers. Otherwise, even if you build the most efficient teams, there is a high chance that they won’t execute the right thing.
On the other side, having several PMs working with one team is not always necessarily bad. You might have for example one PM responsible for each feature, and then one team working on several features, interacting with the corresponding PM for each one of them. If this is your setup, make sure that each feature has a well identified PM who is its primary point of contact. Still keep in mind that while this setup is OK, your tech organization will be more efficient if every team works with one PM only. The primary reason lies within the PM team itself. Imagine if you are a Product Manager responsible for several features, and you interact with several different teams in order to drive their implementation, track their status and etc. It won’t be the most efficient setup for you as a PM. It will be much easier and more efficient if you interact with one team only. Also, usually one PM is responsible for one client area. So if your PMs are working with several different teams, this is a strong indicator that your teams are not formed around the right client areas.

{a3}
If you have teams which doesn’t have Product Managers, you should make it a top priority for you hiring the needed Product Managers. Otherwise, even if you build the most efficient teams, there is a high chance that they won’t execute the right thing.
On the other side, having several PMs working with one team is not always necessarily bad. You might have for example one PM responsible for each feature, and then one team working on several features, interacting with the corresponding PM for each one of them. If this is your setup, make sure that each feature has a well identified PM who is its primary point of contact. Still keep in mind that while this setup is OK, your tech organization will be more efficient if every team works with one PM only. The primary reason lies within the PM team itself. Imagine if you are a Product Manager responsible for several features, and you interact with several different teams in order to drive their implementation, track their status and etc. It won’t be the most efficient setup for you as a PM. It will be much easier and more efficient if you interact with one team only. Also, usually one PM is responsible for one client area. So if your PMs are working with several different teams, this is a strong indicator that your teams are not formed around the right client areas.

{a5}
To a large extent your teams are working with one Product Manager.
If you have teams which doesn’t have Product Managers, you should make it a top priority for you hiring the needed Product Managers. Otherwise, even if you build the most efficient teams, there is a high chance that they won’t execute the right thing.
Having one Product Manager per team is an important prerequisite, in order to make your tech organization efficient.
The primary reason lies within the PM team itself. Imagine if you are a Product Manager responsible for several features, and you interact with several different teams in order to drive their implementation, track their status and etc. It won’t be the most efficient setup for you as a PM. It will be much easier and more efficient if you interact with one team only. Also, usually one PM is responsible for one client area. So if your PMs are working with several different teams, this is a strong indicator that your teams are not formed around the right client areas.
Because of that, it’s really good that you’ve achieved a state where one Product Manager works with one cross-functional team. Make sure you achieve that for all of your teams.

{a6}
One Product Manager is working with one team.
If you have teams which doesn’t have Product Managers, you should make it a top priority for you hiring the needed Product Managers. Otherwise, even if you build the most efficient teams, there is a high chance that they won’t execute the right thing.
Having one Product Manager per team is an important prerequisite, in order to make your tech organization efficient.
The primary reason lies within the PM team itself. Imagine if you are a Product Manager responsible for several features, and you interact with several different teams in order to drive their implementation, track their status and etc. It won’t be the most efficient setup for you as a PM. It will be much easier and more efficient if you interact with one team only. Also, usually one PM is responsible for one client area. So if your PMs are working with several different teams, this is a strong indicator that your teams are not formed around the right client areas.
Because of that, it’s really great that you’ve achieved a state where one Product Manager works with one cross-functional team. Make sure you continue to maintain that.

{q1006} What is the average age of defect in your tech organization? Answer N/A if you don’t measure it.

{r120} Organizational maturity
{w2}

{a0}

It is strongly advisable that you start measuring the average age of defects in your tech organization. The average age of defects is a side effect of your organizational maturity. For example, if you have a well functioning cross-functional teams which can deliver end-to-end customer features, usually this will result in very small average age of defects. Inefficient organizational design inevitably results in long waiting times before defects get resolved and delivered to the customers. This average age of defects can be a strong guiding light and support in your efforts of building a strong tech organization.

{a2}
The fact that you are measuring the average age of defects in your tech organization is a strong signal of its maturity. The fact that you have reached an average age of less than 3 days means that you have achieved a very high level of efficiency and organizational maturity for your stage of the company. Make sure you continue to evolve your organizational design with the evolution of your company, to ensure you keep that excellent state!

{a10}
The fact that you are measuring the average age of defects in your tech organization is a strong signal of its maturity. Still you can further improve its efficiency and decrease the average age of defects. Keep in mind that the average age of defects is a side effect of your organizational maturity. For example, if you have a well functioning cross-functional teams which can deliver end-to-end customer features, usually this will result in very small average age of defects. Inefficient organizational design inevitably results in long waiting times before defects get resolved and delivered to the customers.
Some teams have the practise to prioritize fixing higher priority defects, and postponing the fixing of the lower priority defects for the future. Such teams might argue that they have small average age of top priority defects, and bigger average age only for the lower priority ones. This is definitely better compared to having big average age for all defects, but still having a large bulk of bugs, planned to be fixed in the future, is a signal for a Lean waste. These bugs will require maintenance, reporting, triaging, and other activities, which add cost to your tech organization. Also these activities will decrease its productivity, as they will take from the capacity of your teams. So tech teams should aim at decreasing the average age of all defects, not only the higher priority ones.
This average age of defects can be a strong guiding light and support in your efforts of building a strong tech organization. Good job that you are measuring it. Make sure you continue your efforts to improve your tech organization, which will result in further decrease of the average age of defects.

{a11}
The fact that you are measuring the average age of defects in your tech organization is a good signal of its maturity. Still you can further improve its efficiency and significantly decrease the average age of defects. Keep in mind that the average age of defects is a side effect of your organizational maturity. For example, if you have a well functioning cross-functional teams which can deliver end-to-end customer features, usually this will result in very small average age of defects. Inefficient organizational design inevitably results in long waiting times before defects get resolved and delivered to the customers. Some teams have the practise to prioritize fixing higher priority defects, and postponing the fixing of the lower priority defects for the future. Such teams might argue that they have small average age of top priority defects, and bigger average age only for the lower priority ones. This is definitely better compared to having big average age for all defects, but still having a large bulk of bugs, planned to be fixed in the future, is a signal for a Lean waste. These bugs will require maintenance, reporting, triaging, and other activities, which add cost to your tech organization. Also these activities will decrease its productivity, as they will take from the capacity of your teams. So tech teams should aim at decreasing the average age of all defects, not only the higher priority ones.
This average age of defects can be a strong guiding light and support in your efforts of building a strong tech organization. Good job that you are measuring it. Make sure you continue your efforts to improve your tech organization, which will result in further decrease of the average age of defects.

{q1007} What is the average time between the moment a feature is implemented and the moment when it is deployed in production? Answer N/A if you don’t measure it.

{r120} Organizational maturity
{w2}

{a0}
It is extremely important that you start measuring the average time between the moment a feature is implemented and the moment when it reaches your customers. This is a very strong signal for the efficiency of your tech organization. Not all defects are critical, so measuring the average age of defects is a good support for your effort in transforming and improving your tech organization. But the features that you deliver to the customers are one of the most important aspects of any tech organization. Not measuring the average time to deliver that is a serious flow that you should fix on priority. All your improvement efforts should inevitably result in smaller and smaller times between the feature implementation and its delivery to the customers. Also please note that measuring it is important even if you have fixed release train. It is quite possible certain features to be implemented, but to miss the release train due to quality problems, for example. So having fixed release train does not diminish the value of measuring and improving the average time between feature implementation and release to customers.

{a5}
The fact that you are measuring the average time between the moment a feature is implemented and the moment when it reaches your customers
is a strong signal of the maturity of your tech organization. The fact that you have reached an average time of less than 5 days means that you have achieved a high level of efficiency of your tech organization. Keep in mind that with the increased scale of your company it will become harder and harder to keep that time low. Make sure you continue your efforts to continuously improve your tech organization, which will result in further decrease of the of that time even when your tech organization grows. An increased time for feature delivery in future will inevitably signal to you that there is a significant opportunity to improve the efficiency of your tech organization.

{a6}
The fact that you are measuring the average time between the moment a feature is implemented and the moment when it reaches your customers
is a good signal that you are working on improving the efficiency of your tech organization. Make sure you continue your efforts to further improve your tech organization, which will result in significant further decrease of the of that time. Keep in mind that growing tech organization is not an excuse for long feature delivery times. With continuous and focused effort to improve the efficiency of your tech organization, you can continue to decrease that time even when your tech organization grows. A long time for feature delivery inevitably should signal to you that there is a significant opportunity to improve the efficiency of your tech organization. Good job on measuring that. Make sure you continue your efforts on further decreasing that time.

{q1008} What is the average throughput of the teams in your tech organization? Answer N/A if you don’t measure it.

{r120} Organizational maturity
{w1}

{a0}
Continuously measuring and improving the throughput of the teams in your tech organization is something which signals for a very high level of maturity of a tech organization. Make sure you set as a goal to start measuring and improving it. This is one of the few ultimate metrics that signals for the overall maturity level and efficiency of your tech organization. Here is a good practical example how you can start measuring it: https://topstrengthener.com/2019/02/01/measuring-and-improving-the-productivity-of-your-tech-organization-in-its-transformation-journey/

{a1}
Continuously measuring and improving the throughput of the teams in your tech organization is something which signals for a very high level of maturity of a tech organization. Great job that you are doing that! This is one of the few ultimate metrics that signals for the overall maturity level and efficiency of your tech organization.
Here is a good practical example, which might inspire further improvements: https://topstrengthener.com/2019/02/01/measuring-and-improving-the-productivity-of-your-tech-organization-in-its-transformation-journey/

{q1009} Responsibilities for every person, team or structure in general in the organization is clearly defined. There is no case where a responsibility is split or unknown.

{r100} Organizational design
{w5}

{a1}
The fact that responsibilities in your tech organization are largely undefined is a serious impediment for your efforts of improving it. You should set it as a priority to define them. You can start with lightweight definition and evolve it when needed. Make sure you engage your tech leaders when you prepare it, to ensure their buy-in. Keep in mind that if you push forward the efforts on improving your tech organization without first defining clear roles and their associated responsibilities, this will most likely result in chaos and will bring frustration among your staff.

{a2}
The fact that responsibilities in your tech organization are to a large extent undefined is a serious impediment for your efforts of improving it. You should set it as a priority to define them. You can start with lightweight definition and evolve it when needed. Make sure you engage your tech leaders when you prepare it, to ensure their buy-in. Keep in mind that if you push forward the efforts on improving your tech organization without first defining clear roles and their associated responsibilities, this will most likely result in chaos and will bring frustration among your staff.

{a3}
The fact that responsibilities in your tech organization are not fully defined might be potential serious impediment for your efforts of improving it. You should set it as a priority to clearly define them. You can start with lightweight definition and evolve it when needed. Make sure you engage your tech leaders when you prepare it, to ensure their buy-in. Keep in mind that if you push forward the efforts on improving your tech organization without first defining clear roles and their associated responsibilities, this will most likely result in chaos and will bring frustration among your staff.

{a5}
It is good that the responsibilities in your tech organization are to a large extent defined. Make sure you continue your efforts of further defining them. You can apply lightweight definition for the missing responsibilities and evolve it when needed. Make sure you engage your tech leaders when you prepare it, to ensure their buy-in. Keep in mind that if you push forward the efforts on improving your tech organization without defining clear responsibilities for all your roles, this can result in chaotic or overlapping activities, and as a result you risk to bring frustration among your staff.

{a6}
It is great that the responsibilities in your tech organization are largely defined. Make sure you continue your efforts keeping that state, as your tech organization evolves. With its growth, many of your existing roles will become more complex and you’ll need to reevaluate and redefine their associated responsibilities.

{q1010} You have complaints from teams in your organization that they’re blocked on the delivery of their features.

{r100} Organizational design
{w4}
{i}

{a1}
The fact that you don’t have cases of complaints from the teams in your tech organization that they are blocked on the delivery of their features signals very strongly that you have achieved a very high state of autonomous teams, which can deliver customer value end-to-end. Focus your efforts on further improvement of their efficiency and keep in mind that you’ll need a focused effort to sustain that good state with the growth of your tech organization. As it evolves, the level of complexity will increase dramatically, which in turn might result in many more potential interdependencies between the teams, which you should try to avoid as much as possible.

{a3}
The fact that you have cases of complaints from the teams in your tech organization that they are blocked on the delivery of their features signals that you should continue your efforts on building autonomous teams, which can deliver customer value end-to-end.
Focus your efforts on further eliminating these dependencies. Keep in mind that as your tech organization grows, the level of complexity will increase dramatically, which in turn might result in many more potential interdependencies between the teams. This will even further decrease the ability of your tech teams to deliver results. Make sure you tackle this problem on priority.

{a5}
The fact that you have many cases of complaints from the teams in your tech organization that they are blocked on the delivery of their features signals that you should immediately focus your efforts on building autonomous teams, which can deliver customer value end-to-end. Team interdependencies are a serious blocker for the productivity of your tech teams and overall organization. Make sure you tackle this problem on a very high priority.

{a6}
The fact that you have many cases of complaints from the teams in your tech organization that they are blocked on the delivery of their features signals that you should immediately focus your efforts on building autonomous teams, which can deliver customer value end-to-end. Team interdependencies are a serious blocker for the productivity of your tech teams and overall organization. Make sure you tackle this problem on a very high priority.

{c2} Autonomous teams

{q2001} Your teams are fully responsible for their features and independent for their implementation, from the requirements gathering, till the deployment on production and market success of the feature.

{r10} Autonomous teams
{w5}

{a1}
The teams in your tech organization are largely not autonomous. That prevents them from delivering customer value efficiently and with good quality. Make sure you focus on making the teams autonomous. Identify the major reasons which prevents them from being such, and work hard to fix the root causes. Then periodically reevaluate, to keep track of your progress. Keep in mind that if you don’t have largely autonomous teams, that will deprive your tech organization from delivering strong results and impact.

{a3}
The teams in your tech organization are to a large extent not autonomous. That prevents them from delivering customer value efficiently and with good quality. Make sure you focus on making the teams autonomous. Identify the major reasons which prevents them from being such, and work hard to fix the root causes. Then periodically reevaluate, to keep track of your progress. Keep in mind that if you don’t have largely autonomous teams, that will deprive your tech organization from delivering strong results and impact.

{a5}
You’ve built a tech organization with largely autonomous teams. Continue to work on making them fully autonomous, especially as you scale. This will allow the teams in your tech organization to deliver customer value efficiently and with high quality!

{a6}
You’ve built a tech organization with strongly autonomous teams. Great job! This allows the teams to deliver customer value efficiently and with high quality!

{q2002} Quality problems in features implemented by certain teams, don’t prevent other teams to deploy their features in production, if they don’t have quality problems.

{r10} Autonomous teams
{w3}

{a1}
The fact that your teams are to a very large extent blocked by quality problems in other teams signals that you have built a tech organization with teams which can’t deliver efficiently end-to-end customer value due to many interdependencies to other teams. Set as a high priority for you and the tech leadership team to fix these interdependencies. This is a mandatory prerequisite if you want to build truly autonomous teams. Doing so will have a great impact on their efficiency and the overall strength of your tech organization.

{a3}
The fact that your teams are to a large extent blocked by quality problems in other teams signals that you have built a tech organization with teams which can’t deliver efficiently end-to-end customer value due to many interdependencies to other teams. Continue to fix the remaining interdependencies to build truly autonomous teams. This will have a great impact on their efficiency and the overall strength of your tech organization.

{a5}
The fact that your teams to a large extent are not blocked by quality problems in other teams signals that you have built a tech organization with teams which can deliver end-to-end customer value, without many interdependencies to other teams. Continue to fix the remaining interdependencies to build truly autonomous teams. Keep in mind that this will become more and more difficult as your tech organization grows, this will have a great impact on the teams’ efficiency and the overall strength of your tech organization.

{a6}
The fact that your teams are not blocked by quality problems in other teams signals that you have built a tech organization with teams which can deliver end-to-end customer value, without interdependencies to other teams. Great job and continue to focus on keeping your teams autonomous as your organization evolves and grows.

{q2003} Your teams are able to automatically request and get access to all external systems required to fulfil their jobs, through automated self-service portals and services, without the need to contact and go to specific teams or persons to request these permissions manually.

{r10} Autonomous teams
{w2}

{a1}
You’ve built teams which are to a very large extent not able to automatically request and get access to external systems required to fulfil their jobs, through automated self-service portals and services. Rather, they need to contact and go to specific teams or persons to request these permissions manually.
While your tech team is small, this might not be a big problem, but as your organization grows, you’ll see that the lack of such automated self-service portals will start to decrease more and more the overall efficiency of your tech organization and wouldn’t allow the tech teams to deliver their features without dependencies on external units.
You must work on resolving this through automating that access requests, access control and overall interactions.
A common mistake that many tech leaders make is to focus on resolving dependencies only within the tech organization. Many dependencies lie also outside of your tech unit, like for example financial and HR systems, IT access systems, etc. Make sure you automate these dependencies and interactions.

{a3}
You’ve built teams which are to a large extent not able to automatically request and get access to external systems required to fulfil their jobs, through automated self-service portals and services. Rather, they need to contact and go to specific teams or persons to request these permissions manually. While your tech team is small, this might not be a big problem, but as your organization grows, you’ll see that the lack of such automated self-service portals will start to decrease more and more the overall efficiency of your tech organization and wouldn’t allow the tech teams to deliver their features without dependencies on external units.
You must work on resolving this through automating that access requests, access control and overall interactions.
A common mistake that many tech leaders make is to focus on resolving dependencies only within the tech organization. Many dependencies lie also outside of your tech unit, like for example financial and HR systems, IT access systems, etc. Make sure you automate these dependencies and interactions.

{a5}
You’ve built teams which are able to a significant extent to automatically request and get access to external systems required to fulfil their jobs, through automated self-service portals and services, without the need to contact and go to specific teams or persons to request these permissions manually. Continue to fully automate that interaction, as this will allow the tech teams to deliver their features without dependencies on external units. One mistake that many tech leaders make is to focus on resolving dependencies only within the tech organization. Many dependencies lie also outside of your tech unit, like for example financial and HR systems, IT access systems, etc. You’ve done a good job to fix most of those dependencies. Continue the good job and automate the rest of them.

{a6}
You’ve built teams which are able to automatically request and get access to all external systems required to fulfil their jobs, through automated self-service portals and services, without the need to contact and go to specific teams or persons to request these permissions manually. This is great, as this will allow the tech teams to deliver their features without dependencies on external units. One mistake that many tech leaders make is to focus on resolving dependencies only within the tech organization. Many dependencies lie also outside of your tech unit, like for example financial and HR systems, IT access systems, etc. You’ve done a great job to fix those dependencies!

{q2004} Any team member in your team can design and run an experiment in production, see the results and action upon them.

{r10} Autonomous teams
{w2}

{a1}
You’ve enabled to a very low extent team members in your team to design and run an experiment in production, see the results and action upon them. That significantly decreases the capability of your tech organization to test hypotheses fast. Keep in mind that this can be very detrimental for your company overall, as this greatly decreases its capability to find good product market fit or improve its existing market position. Your considerations for not enabling the team members for conducting experiments might be related to security or reliability concerns. If that’s the case, an alternative approach is to eliminate these risks, e.g. gradual roll outs, automatic fallbacks in case of problems, automated way of detecting production problems, both on technical metrics as well as business metrics, etc.
If your competitors are testing hypotheses faster, chances are high that they’ll get ahead of your company in terms of business situation and market position. This will most likely result in big pressure for the tech team. Initially pressure usually goes to the product team, but it is quickly identified that the actual bottleneck is the capacity to design and run experiments. Make sure you focus on that and achieve a state where it’s easy for anyone in your tech organization to design and run experiments.

{a3}
You’ve enabled to a very low extent team members in your team to design and run an experiment in production, see the results and action upon them. That decreases the capability of your tech organization to test hypotheses fast. Keep in mind that this can be very detrimental for your company overall, as this greatly decreases its capability to find good product market fit or improve its existing market position. If your competitors are testing hypotheses faster, chances are high that they’ll get ahead of your company in terms of business situation and market position. This will most likely result in big pressure for the tech team. Initially pressure usually goes to the product team, but it is quickly identified that the actual bottleneck is the poor ability to design and run experiments. Make sure you focus on that and achieve a state where it’s easy for anyone in your tech organization to design and run experiments.

{a5}
You’ve enabled to a large extent team member in your team to design and run an experiment in production, see the results and action upon them. That contributes to a large extent for the agility of your tech organization – you can test hypotheses fast and deliver features based on the market response. Also you don’t restrict that capability for the product managers only, which is great. One thing that you have to be very careful about is the security of your product or service. Usually large enablement of experimenting in companies is related to larger access rights for multiple people, so make sure you keep track and evolve your security strategy. Also, you should keep in mind that enablement of experimentation usually leads to larger product backlog, as the product managers can experiment much faster, and as a result speed up the definition of product backlog. You should make sure you improve the efficiency of your tech organization in parallel, not allowing it to become a bottleneck, not being able to deliver the increased amount of features in your product pipeline.

{a6}
You’ve enabled to a large extent any team member in your team to design and run an experiment in production, see the results and action upon them. That contributes to a large extent for the agility of your tech organization – you can test hypotheses quickly and deliver features based on the market response. Also you don’t restrict that capability for the product managers only, which is great. One thing that you have to be very careful about is the security of your product or service. Usually large enablement of experimenting in companies is related to larger access rights for multiple people, so make sure you keep track and evolve your security strategy. Also, you should keep in mind that enablement of experimentation usually leads to larger product backlog, as the product managers can experiment much faster, and as a result speed up the definition of product backlog. You should make sure you improve the efficiency of your tech organization in parallel, not allowing it to become a bottleneck, not being able to deliver the increased amount of features in your product pipeline.

{q2005} Your organisation has decentralized team budgets split per domain (travel, conferences, education, entertainment, etc.), and any employee can automatically request approval for such an expense through a self-service system, which request, if under certain defined and known limit, to be approved only by the direct engineering manager without the need for further approvals.

{r10} Autonomous teams
{w2}

{a1}
Your organisation has implemented to a very low extent decentralised budgets and
enablement of employees to automatically request approval for expenses through self-service systems. You should make sure you focus on resolving and automating these external dependencies, as well as decentralising your budgets. That is a very important prerequisite in order to help the tech teams in your organization to be autonomous and highly efficient.
As your organization grows, a central approving body will have vague context about the individual purchase requests from team members. The managers of the requesters will be in the best position to assess the need. You should target to allocate to the managers in your organization respective budgets, approval limits and control over the type of the expenses, and target to automate that process and control the overall budget spent, rather than each individual expense.

{a3}
Your organisation has implemented to a very low extent decentralised budgets and enablement of employees to automatically request approval for expenses through self-service systems. You should make sure you focus on resolving and automating these external dependencies, as well as decentralising your budgets. That is a very important prerequisite in order to help the tech teams in your organization to be autonomous and highly efficient.
As your organization grows, a central approving body will have vague context about the individual purchase requests from team members. The managers of the requesters will be in the best position to assess the need. You should target to allocate to the managers in your organization respective budgets, approval limits and control over the type of the expenses, and target to automate that process and control the overall budget spent, rather than each individual expense.

{a5}
Your organisation has to a large extent team budgets split per domain (travel, conferences, education, entertainment, etc.), and in most of the cases employees can automatically request approval for such an expense through a self-service system. That speaks very high for you as a tech leader – you’ve focused also on resolving and automating external dependencies, which is great. Make sure you continue to work on automate these external interactions. That will even further help the tech teams in your organization to be autonomous and highly efficient.

{a6}
Your organisation has team budgets split per domain (travel, conferences, education, entertainment, etc.), and any employee can automatically request approval for such an expense through a self-service system. That speaks very high for you as a tech leader – you’ve focused also on resolving and automating external dependencies, which is great. That even further helps the tech teams in your organization to be autonomous and highly efficient.

{c3} Recruitment and staffing

{q3001} You track the actual recruitment vs. your hiring plan – both at individual team level, as well for the overall organisation.

{r210} Recruitment process maturity
{w5}

{a1}
To a very large extent you are not tracking the actual recruitment versus your hiring plan. We strongly encourage you to start doing this. This is a very important prerequisite in order to effectively improve your recruitment process. Without a good tracking, you won’t be in a good position to answer questions like do you need to increase your recruitment capacity, or do you need to optimize your recruitment process. We would encourage you to apply this tracking to all teams, as well to track it at overall level for your organization. Applying it to individual teams will help you detect cases which require improvement, e.g. specific teams which have very big deltas between actual vs. planned. These teams might need attention and support, for example additional recruiters, or recruitment staff with special skills. If you track the actual vs. planned recruitment only at the global level for your overall organization, you might miss these cases which need attention and support.
In parallel you should track this also at the level of your organization. This will help you monitor and improve the overall recruitment process of the whole tech organization.
The chapter “Recruitment, Staffing placement, and Forecasting “ of the book “Building Tech” can be of great help in that direction, containing many examples and proven practices about implementing such tracking and a robust overall recruitment and staffing process.

{a3}
To some extent you are already tracking the actual recruitment versus your hiring plan. We strongly encourage you to continue doing this. This is a very important prerequisite in order to effectively improve your recruitment process. Without a good tracking, you won’t be in a good position to answer questions like do you need to increase your recruitment capacity, or do you need to optimize your recruitment process. For a small tech teams, this tracking can be done at a central level only. Once your team grows to more than 100 people, we would encourage you to track it at overall level for your organization, as well for the individual teams also. Applying it to individual teams will help you detect cases which require improvement, e.g. specific teams which have very big deltas between actual vs. planned. These teams might need attention and support, for example additional recruiters, or recruitment staff with special skills. If you track the actual vs. planned recruitment only at the global level for your overall organization, you might miss these cases which need attention and support.
In parallel you should track this also at the level of your organization. This will help you monitor and improve the overall recruitment process of the whole tech organization.
The chapter “Recruitment, Staffing placement, and Forecasting “ of the book “Building Tech” can be of great help in that direction, containing many examples and proven practices about implementing such tracking and a robust overall recruitment and staffing process.

{a5}
You are tracking to a large extent the actual recruitment versus your hiring plan, which is good. This is a very important prerequisite in order to effectively improve your recruitment process. Without a good tracking, you won’t be in a good position to answer questions like do you need to increase your recruitment capacity, or do you need to optimize your recruitment process. We would encourage you to apply this tracking to all teams, as well to track it at overall level for your organization. Applying it to individual teams will help you detect cases which require improvement, e.g. specific teams which have very big deltas between actual vs. planned. These teams might need attention and support, for example additional recruiters, or recruitment staff with special skills. If you track the actual vs. planned recruitment only at the global level for your overall organization, you might miss these cases which need attention and support.
In parallel you should track this also at the level of your organization. This will help you monitor and improve the overall recruitment process of the whole tech organization.
The chapter “Recruitment, Staffing placement, and Forecasting “ of the book “Building Tech” can be of great help in that direction, containing many examples and proven practices about implementing such tracking and a robust overall recruitment and staffing process.

{a6}
You are doing a good job by tracking the actual recruitment versus your hiring plan. This is a very important prerequisite in order to effectively improve your recruitment process. Without a good tracking, you won’t be in a good position to answer questions like do you need to increase your recruitment capacity, or do you need to optimize your recruitment process. Make sure you continue to apply this tracking to all teams, as well to track it at overall level for your organization. Applying it to individual teams will help you detect cases which require improvement, e.g. specific teams which have very big deltas between actual vs. planned. These teams might need attention and support, for example additional recruiters, or recruitment staff with special skills. If you track the actual vs. planned recruitment only at the global level for your overall organization, you might miss these cases which need attention and support.
In parallel you should continue to track this also at the level of your organization. This will help you monitor and improve the overall recruitment process of the whole tech organization.
The chapter “Recruitment, Staffing placement, and Forecasting “ of the book “Building Tech” can be of great help in that direction, containing many examples and proven practices about implementing such tracking and a robust overall recruitment and staffing process.

{q3002} You have less than 10% deviation between the hiring plan and the actual recruitment. List your specific deviation in percentage. If you don’t know it, list is on top of your head.

{r210} Recruitment process maturity
{w2}

{a3}
You have significant deviation of your actual vs. planned recruitment goals for some roles. This should be a strong signal for you that you must analyze and revisit your whole recruitment strategy and process for these roles. While deviations are relatively frequent in companies with aggressive growth plans, if they are larger than 20%, you would most probably need to implement significant improvements or changes. Make sure you analyze the reasons why you have that deviation, before you take any improvement steps. For example, some companies have problems with the reputation of their engineering brand, so instead of hiring even more recruiters, you might plan effort in improving your engineering brand. Other companies have enough recruiters, but with different skillset. For example, frequent mistake that companies do is to use junior recruiter to hire for very senior technical positions. Other potential reason might be simply the lack of talent with specific skillset in given markets. Make sure you do a good analysis to find the root cause for your deviation, before you undertake any changes or improvements.

{a5}
The fact that you have a bit more than 10% deviation of your actual vs. planned recruitment goals means that you put a good effort to manage your recruitment process. Keep in mind though that this depends to a large extent on your recruitment goals. Tech organizations with small growth plans find it easier to manage their modest recruitment goals, and as a result the deviation between actual and planned recruitment goals, compared to companies with aggressive growth plans. If your tech organization grew on average with less than 30% for the last two years, having a deviation of your actual vs. planned recruitment goals higher than 10% should be a signal for you that you must analyze carefully your recruitment strategy and process. While large deviations are relatively frequent in companies with aggressive growth plans, for example doubling the size of their tech team every year, for companies with less aggressive growth plans, such deviations are a signal that they need to implement improvements or changes in their recruitment process. Make sure you analyze the reasons why you have that deviation, before you take any improvement steps. For example, some companies have problems with the reputation of their engineering brand, so instead of hiring even more recruiters, you might plan effort in improving your engineering brand. Other companies have enough recruiters, but with different skillset. For example, frequent mistake that companies do is to use junior recruiter to hire for very senior technical positions. Other potential reason might be simply the lack of talent with specific skillset in given markets. Make sure you do a good analysis to find the root cause for your deviation, before you undertake any changes or improvements.

{a6}
The fact that you have less than 10% deviation of your actual vs. planned recruitment goals means that you manage the recruitment process effectively. Keep in mind though that this depends to a large extent on your recruitment goals. Tech organizations with small growth plans find it easier to manage their modest recruitment goals, and as a result the deviation between actual and planned recruitment goals, compared to companies with aggressive growth plans.

{q3003} Candidates who pass the whole interview process often reject their offers.

{r210} Recruitment process maturity
{w5}
{i}

{a1}
Very small part of the candidates who pass the interview process reject you offers. This is a good sign for your recruitment process! Make sure you monitor this metric and if in future you identify a larger portion of candidates who reject offers, to analyze the reasons for that. In most of the cases, this is due to some of the following reasons: lack of clarity about their role or its responsibilities, lack of clarity about their team, misalignment between the expected title and the proposed one. The offered compensation can also be a reason, even though that companies usually check for compensation expectations upfront which mitigates that risk. Make sure you work with your recruitment team conduct together a thorough analysis about the top reasons because of which candidates reject your offers. The chapter “Recruitment, Staffing placement, and Forecasting “ of the book “Building Tech” can be of great help for such analysis. Only after you firmly identify the causes, you must plan initiatives to fix them. Examples can be conducting a market research and based on it adjusting your compensation ranges, defining clear responsibilities for the different roles in your tech organization, decentralizing your recruitment process and start hiring for specific teams, etc. You are doing a good job now in that direction, so for the moment just keep that knowledge in your pocket, and use it whenever needed in future.

{a3}
Some significant part of the candidates who pass the interview process reject you offers. You should analyze the reasons for that. In most of the cases, this is due to some of the following reasons: lack of clarity about their role or its responsibilities, lack of clarity about their team, misalignment between the expected title and the proposed one. The offered compensation can also be a reason, even though that companies usually check for compensation expectations upfront. Despite that, when the gap between the expected compensation and the ranges for the position is small enough, companies often continue with the interview process, and that gap reveals very late, when offer is extended. Make sure you work with your recruitment team conduct together a thorough analysis about the top reasons because of which candidates reject your offers. The chapter “Recruitment, Staffing placement, and Forecasting “ of the book “Building Tech” can be of great help for such analysis. Only after you firmly identify the causes, you must plan initiatives to fix them. Examples can be conducting a market research and based on it adjusting your compensation ranges, defining clear responsibilities for the different roles in your tech organization, decentralizing your recruitment process and start hiring for specific teams, etc.

{a6}
Very significant part of the candidates who pass the interview process reject you offers. Make sure you make a good analysis to identify the root causes and immediately plan activities to fix them. In most of the cases, this is due to some of the following reasons: lack of clarity about their role or its responsibilities, lack of clarity about their team, misalignment between the expected title and the proposed one. The offered compensation can also be a reason, even though that companies usually check for compensation expectations upfront. Despite that, when the gap between the expected compensation and the ranges for the position is small enough, companies often continue with the interview process, and that gap reveals very late, when offer is extended. Make sure you work with your recruitment team conduct together a thorough analysis about the top reasons because of which candidates reject your offers. Otherwise you are wasting effort to attract people to apply, to conduct the whole interview process, only to lose the candidates at the very end. The chapter “Recruitment, Staffing placement, and Forecasting “ of the book “Building Tech” can be of great help for such analysis. Only after you firmly identify the causes, you must plan initiatives to fix them. Examples can be conducting a market research and based on it adjusting your compensation ranges, defining clear responsibilities for the different roles in your tech organization, decentralizing your recruitment process and start hiring for specific teams, etc.

{q3004} You are hiring for individual teams, rather than hiring for the overall tech organisation and then placing the candidates.

{r40} Decentralized recruitment and staffing
{w5}

{a1}
The practice of hiring for individual teams in your tech organization is largely not established. That usually works as soon as your tech organization is very small, less than 20 people. If your tech team is larger, especially if it is bigger than 100 people, hiring for the overall tech organization rather than individual teams has significant drawbacks.
This doesn’t allow the candidates to get a good understanding about the specific team that they will join and to meet their potential future teammates during the interview process. Because of this, the candidates can’t project themselves in their potential teams, build rapport with their future colleagues and as a result that greatly decreases the chances that they will accept your offer.
Make a priority to achieve a state where you are hiring for individual teams, rather than for your overall tech organization. Until you achieve such state, you’ll see a lower acceptance rate for your offers. Some companies try to compensate that with various means like increased compensations, higher than the market ranges, significant investment in building engineering brand which to attract potential candidates, etc. While such measures will most probably increase your offer acceptance rates, if you start hiring for individual teams, this will further significantly increase the percentage of your accepted offers. So don’t look at that practice as a substitute of your other efforts, but rather see them as a complementary activities and practices, which if implemented correctly, will help you hire strong talent.

{a3}
The practice of hiring for individual teams in your tech organization is not well established. That usually works as soon as your tech organization is very small, less than 20 people. If your tech team is larger, especially if it is bigger than 100 people, hiring for the overall tech organization rather than individual teams has significant drawbacks.
This doesn’t allow the candidates to get a good understanding about the specific team that they will join and to meet their potential future teammates during the interview process. Because of this, the candidates can’t project themselves in their potential teams, build rapport with their future colleagues and as a result that greatly decreases the chances that they will accept your offer.
Continue firmly with the effort to achieve a state where you are hiring for individual teams, rather than for your overall tech organization.

{a5}
You are hiring primarily for individual teams, which is good. This allows the candidates to get a good understanding about the specific team that they will join and to meet their potential future teammates during the interview process. The candidates can project themselves in their potential teams, build rapport with their future colleagues and as a result that greatly increases the chance that they will accept your offer. Even in the cases where they find out that they don’t like their potential future team, or if they identify that they share very different values and culture with their future teammates, it will be beneficial both for the candidates and the company to identify this early. In the cases where such differences or misaligned expectations are identified after the candidates join, this causes a frustration and each attrition shakes the stability of your tech organization. It’s much easier to separate with a potential candidate during the interview process, compared to a later stage when the candidate is already an employee. Continue with that effort to achieve a state where you are hiring for individual teams across the whole tech organization.

{a6}
You are hiring for individual teams, which is great. This allows the candidates to get a good understanding about the specific team that they will join and to meet their potential future teammates during the interview process. The candidates can project themselves in their potential teams, build rapport with their future colleagues and as a result that greatly increases the chance that they will accept your offer. Even in cases where they find out that they don’t like their potential future team, or if they identify that they share very different values and culture with their future teammates, it will be beneficial for both the candidates and the company to identify this early. In the cases where such differences or misaligned expectations are identified after the candidates join, this causes frustration and each attrition shakes the stability of your tech organization. It’s much easier to separate with a potential candidate during the interview process, compared to a later stage when the candidate is already an employee. Keep up the good job of hiring for specific teams, rather than for the overall tech organization.

{q3005} If you hire for individual teams, you have a mechanism to ensure consistency for the acceptance bar across the tech organization.

{r40} Decentralized recruitment and staffing
{w3}

{a1}
To a very large extent you’re lacking a mechanism for ensuring consistency for the acceptance bar across your tech organization. This is not good, as in addition to the obvious fact that this doesn’t ensure the same acceptance criteria for your overall tech organization, irrespective of the team that the candidates apply, it has also other drawbacks like for example:
● Make the transfer of people between teams more difficult
If your teams don’t have consistent acceptance criteria, it is be possible for example Senior Engineer in one team to match the criteria of mid-level engineer in other team. In this case, transfer of the engineer will be very difficult, as it will require demotion.
● Difficult implementation of a good performance evaluation process
Such process will largely depend on performance criteria, but lacking consistent requirements for skills and experience during your acceptance process is major blocker to build a good performance evaluation process.
Ensuring such consistency is not trivial and becomes fairly difficult to implement, especially in larger tech organizations, having more than 500 engineers. Nevertheless, it pays off greatly. Unless your tech organization is very small, less than 20 people, focus your effort to ensure acceptance consistency for all teams in your tech organization.

{a2}
To a large extent you’re lacking a mechanism for ensuring consistency for the acceptance bar across your tech organization. This is not good, as in addition to the obvious fact that this doesn’t ensure the same acceptance criteria for your overall tech organization, irrespective of the team that the candidates apply, it has also other drawbacks like for example:
● Make the transfer of people between teams more difficult
If your teams don’t have consistent acceptance criteria, it is be possible for example Senior Engineer in one team to match the criteria of mid-level engineer in other team. In this case, transfer of the engineer will be very difficult, as it will require demotion.
● Difficult implementation of a good performance evaluation process
Such process will largely depend on performance criteria, but lacking consistent requirements for skills and experience during your acceptance process is major blocker to build a good performance evaluation process.
Ensuring such consistency is not trivial and becomes fairly difficult to implement, especially in larger tech organizations, having more than 500 engineers. Nevertheless, it pays off greatly. Unless your tech organization is very small, less than 20 people, focus your effort to ensure acceptance consistency for all teams in your tech organization.

{a3}
To some extent you’re lacking a mechanism for ensuring consistency for the acceptance bar across your tech organization. This is not good, as in addition to the obvious fact that this doesn’t ensure the same acceptance criteria for your overall tech organization, irrespective of the team that the candidates apply, it has also other drawbacks like for example:
● Make the transfer of people between teams more difficult
If your teams don’t have consistent acceptance criteria, it is be possible for example Senior Engineer in one team to match the criteria of mid-level engineer in other team. In this case, transfer of the engineer will be very difficult, as it will require demotion.
● Difficult implementation of a good performance evaluation process
Such process will largely depend on performance criteria, but lacking consistent requirements for skills and experience during your acceptance process is major blocker to build a good performance evaluation process.
Ensuring such consistency is not trivial and becomes fairly difficult to implement, especially in larger tech organizations, having more than 500 engineers. Nevertheless, it pays off greatly. Unless your tech organization is very small, less than 20 people, focus your effort to ensure acceptance consistency for all teams in your tech organization.

{a5}
You’ve built to a significant extent a mechanism for ensuring consistency for the acceptance bar across your tech organization. This is good, as in addition to the obvious fact that this ensures the same acceptance criteria for your overall tech organization, irrespective of the team that the candidates apply, it has also other benefits like for example:
● enabling for easier transfer of people between teams
If your teams didn’t have consistent acceptance criteria, it would be possible for example Senior Engineer in one team to match the criteria of mid-level engineer in other team. In this case, transfer of the engineer will be very difficult, as it will require demotion.
● Easier implementation of a good performance evaluation process
Such process will largely depend on performance criteria, but ensuring consistent requirements for skills and experience during your acceptance process is an important prerequisite to build a solid performance evaluation process.
Ensuring such consistency is not trivial and becomes fairly difficult to implement, especially in larger tech organizations, having more than 500 engineers. Nevertheless, it pays off greatly. Continue with your effort to ensure acceptance consistency for all teams in your tech organization.

{a6}
You’ve built a mechanism for ensuring consistency for the acceptance bar across your tech organization. This is very good, as in addition to the obvious fact that this ensures the same acceptance criteria for your overall tech organization, irrespective of the team that the candidates apply, it has also other benefits like for example:
● enabling for easier transfer of people between teams
If your teams didn’t have consistent acceptance criteria, it would be possible for example Senior Engineer in one team to match the criteria of mid-level engineer in other team. In this case, transfer of the engineer will be very difficult, as it will require demotion.
● Easier implementation of a good performance evaluation process
Such process will largely depend on performance criteria, but ensuring consistent requirements for skills and experience during your acceptance process is an important prerequisite to build a solid performance evaluation process.
Ensuring such consistency is not trivial and becomes fairly difficult to implement, especially in larger tech organizations, having more than 500 engineers. Nevertheless, it pays off greatly, so keep up the good job!

{q3006} Candidates know in advance in which team they’ll be working on and their responsibilities within the team.

{r210} Recruitment process maturity
{w4}

{a1}
When the candidates don’t know in advance in which team they’ll be working on and what will be their responsibilities within the team, this greatly decreases the chance that they will accept to join your tech organization. Starting a new job is a very important decision, and it will be much more difficult for any person to make that decision without knowing such important details like their team or their specific responsibilities. Not knowing the team also means that the candidates won’t know their new teammates, which additionally decreases the chances that they will join your tech organization. You must work on redesigning your recruitment process, so that applicants have that information when applying. Ideally, it should be already available in the job posting itself.

{a2}
To a large extent candidates to join your tech organization don’t know in advance in which team they’ll be working on and what will be their responsibilities within the team. This greatly decreases the chance that they will accept to join your tech organization. Starting a new job is a very important decision, and it will be much more difficult for any person to make that decision without knowing such important details like their team or their specific responsibilities. Not knowing the team also means that the candidates won’t know their new teammates, which additionally decreases the chances that they will join your tech organization. You must work on redesigning your recruitment process, so that applicants have that information when applying to any team in your tech organization. Ideally, it should be already available in the job posting itself.

{a3}
To some extent candidates to join your tech organization don’t know in advance in which team they’ll be working on and what will be their responsibilities within the team. This greatly decreases the chance that they will accept to join your tech organization. Starting a new job is a very important decision, and it will be much more difficult for any person to make that decision without knowing such important details like their team or their specific responsibilities. Not knowing the team also means that the candidates won’t know their new teammates, which additionally decreases the chances that they will join your tech organization. You must work on redesigning your recruitment process, so that applicants have that information when applying to any team in your tech organization. Ideally, it should be already available in the job posting itself.

{a5}
To a large extent candidates to join your tech organization know in advance in which team they’ll be working on and what will be their responsibilities within the team. This is good, as it greatly increases the chance that they will accept to join your tech organization. Starting a new job is a very important decision, and it will be much easier for any person to make that decision when they know such important details like their team or their specific responsibilities. Knowing the team when applying also means that the candidates will know their new teammates, which additionally increases the chances that they will join your company. Continue the work on your recruitment process, so that all applicants have that information when applying to any team in your tech organization. Ideally, it should be already available in the job posting itself. This will further increase the percentage accepted offers.

{a6}
To a very large extent candidates to join your tech organization know in advance in which team they’ll be working on and what will be their responsibilities within the team. This is very good, as it greatly increases the chance that they will accept to join your tech organization. Starting a new job is a very important decision, and it will be much easier for any person to make that decision when they know such important details like their team or their specific responsibilities. Knowing the team when applying also means that the candidates will know their new teammates, which additionally increases the chances that they will join your company. Continue the work on your recruitment process to maintain that state.

{q3007} Candidates are interviewed primarily by team members of the team they are applying to join.

{r40} Decentralized recruitment and staffing
{w4}

{a1}
It is a very good practice to design your interview process in a way that candidates are interviewed primarily by team members of the team they are applying to join. This allows the members of the team to evaluate their potential future teammate, and at the same time it allows the candidates to get first-hand information about the team, to build rapport with their potential future teammates. Both the candidates and the interviewers can mutually evaluate if they share the same culture, values and behaviors. And most importantly, this allows the team members to have input for the hiring decision – if you are expected to work with a new team member, it is very desirable that the interview process is designed in a way that allows you to have a say for the hiring decision. You must redesign your recruitment process so that candidates are interviewed primarily by team members of the team they are applying to join. Keep in mind that until you make that happen, your acceptance rates will be lower. Needless to say, that is very unfortunate – you are spending money and time to attract talent, then you are investing in interview process, only to lose candidates at the very end. Once you improve that part of the recruitment process, you’ll see a noticeable increase of the accepted offers percentage.

{a3}
It is a very good practice to design your interview process in a way that candidates are interviewed primarily by team members of the team they are applying to join. This allows the members of the team to evaluate their potential future teammate, and at the same time it allows the candidates to get first-hand information about the team, to build rapport with their potential future teammates. Both the candidates and the interviewers can mutually evaluate if they share the same culture, values and behaviors. And most importantly, this allows the team members to have input for the hiring decision – if you are expected to work with a new team member, it is very desirable that the interview process is designed in a way that allows you to have a say for the hiring decision. You must continue to design your recruitment process so that candidates are interviewed primarily by team members of the team they are applying to join. Keep in mind that until you make that happen for all teams in your tech organization, your acceptance rates will be lower. Needless to say, that is very unfortunate – you are spending money and time to attract talent, then you are investing in interview process, only to lose candidates at the very end. Once you improve that part of the recruitment process, you’ll see a noticeable increase of the accepted offers percentage.

{a5}
It’s good that you’ve built the good practice candidates to be interviewed primarily by team members of the team they are applying to join. This allows the members of the team to evaluate their potential future teammate, and at the same time it allows the candidates to get first-hand information about the team, to build rapport with their potential future teammates. Both the candidates and the interviewers can mutually evaluate if they share the same culture, values and behaviors. And most importantly, this allows the team members to have input for the hiring decision – if you are expected to work with a new team member, it is very desirable that the interview process is designed in a way that allows you to have a say for the hiring decision.
You must continue to design your recruitment process so that candidates are interviewed primarily by team members of the team they are applying to join, for all the teams in your tech organization. As you continue with that effort, you’ll see a further increase of the accepted offers percentage.

{a6}
It’s great that you’ve built the good practice candidates to be interviewed primarily by team members of the team they are applying to join. This allows the members of the team to evaluate their potential future teammate, and at the same time it allows the candidates to get first-hand information about the team, to build rapport with their potential future teammates. Both the candidates and the interviewers can mutually evaluate if they share the same culture, values and behaviors. And most importantly, this allows the team members to have input for the hiring decision – if you are expected to work with a new team member, it is very desirable that the interview process is designed in a way that allows you to have a say for the hiring decision.
You must continue to maintain that state of your recruitment process so that candidates are interviewed primarily by team members of the team they are applying to join, for all the teams in your tech organization. This will become more complex, as your tech team grows, but it is an important prerequisite in order to have high percentage of accepted offers.

{q3008} If you are hiring for individual teams, the primary responsibility for the hiring decision is within the tech leader of the team and the interviewers from that team.

{r40} Decentralized recruitment and staffing
{w4}

{a1}
Once you design your interview process in a way that candidates are interviewed primarily by team members of the team they are applying to join, next step to focus is the hiring decision to be taken within the teams the candidates apply to. It is a very unwanted practice the hiring decision to be taken outside the team the candidates are applying, as effectively that means that the manager of the team or the domain area is not empowered to build the team itself in the first place. In this case, it is arguable what part of the responsibility for the success and the delivery of the team lies with the manager, and what part – with the person who has taken the hiring decisions.

{a3}
Once you design your interview process in a way that candidates are interviewed primarily by team members of the team they are applying to join, next step to focus is the hiring decision to be taken within the teams the candidates apply to. It is a very unwanted practice the hiring decision to be taken outside the team the candidates are applying, as effectively that means that the manager of the team or the domain area is not empowered to build the team itself in the first place. In this case, it is arguable what part of the responsibility for the success and the delivery of the team lies with the manager, and what part – with the person who has taken the hiring decisions.

{a5}
It is good that to a large extent for your tech organization the primary responsibility for the hiring decision is within the tech leader of the team and the interviewers from that team. This supports the establishment of commitment and accountability for the success of the teams, as their managers and technical leads are the ones who are building the teams in the first place. Continue with the effort to establish that practice for all teams in your tech organization.

{a6}
It is great that for your tech organization the primary responsibility for the hiring decision is within the tech leader of the team and the interviewers from that team. This supports the establishment of commitment and accountability for the success of the teams, as their managers and technical leads are the ones who are building the teams in the first place. Good job, continue with the effort to maintain that practice for all teams in your tech organization.

{q3009} In your tech organisation, every team is coming up with their resource requests based on their product and engineering roadmaps.

{r40} Decentralized recruitment and staffing
{w5}

{a1}
The teams in your tech organization are not coming up with their resource requests based on their product and engineering roadmaps. Keep in mind that that works only for small organizations, usually less than 50 engineers. For bigger tech teams, especially when they have more than 200 engineers, you should focus on decentralizing the resource requirements to your teams. The first reason is that keeping this process central for large organizations will require huge effort for your central management leader or body. The second reason is that the process won’t be as accurate as if decentralized – the larger your tech organization is, the further away your central tech leader or management body will be from the detailed resource requirements for each team. And the third reason is that decentralizing will empower the managers of the teams, will send a strong message for trust in them, and as a result will increase their commitment.

{a3}
To a large extent the teams in your tech organization are not coming up with their resource requests based on their product and engineering roadmaps. Keep in mind that that works only for small organizations, usually less than 50 engineers. For bigger tech teams, especially when they have more than 200 engineers, you should focus on decentralizing the resource requirements to your teams. The first reason is that keeping this process central for large organizations will require huge effort for your central management leader or body. The second reason is that the process won’t be as accurate as if decentralized – the larger your tech organization is, the further away your central tech leader or management body will be from the detailed resource requirements for each team. And the third reason is that decentralizing will empower the managers of the teams, will send a strong message for trust in them, and as a result will increase their commitment.

{a5}
To a large extent the teams in your tech organization are coming up with their resource requests based on their product and engineering roadmaps. That’s good, as it brings significant benefits. The first is that keeping this process central for large organizations will require huge effort for your central management leader or body, so the decentralization allows the tech leader to focus on more strategic topics or work on more important priorities. The second benefit is that the decentralized process ensures better accuracy of the resource requirements, compared to a central process – the larger your tech organization is, the further away your central tech leader or management body will be from the detailed resource requirements for each team. And the third benefit is that decentralizing empowers the managers of the teams, sends a strong message for trust in them, and as a result increases their commitment.

{a6}
The teams in your tech organization are coming up with their resource requests based on their product and engineering roadmaps. That’s good, as it brings significant benefits. The first is that keeping this process central for large organizations will require huge effort for your central management leader or body, so the decentralization allows the tech leader to focus on more strategic topics or work on more important priorities. The second benefit is that the decentralized process ensures better accuracy of the resource requirements, compared to a central process – the larger your tech organization is, the further away your central tech leader or management body will be from the detailed resource requirements for each team. And the third benefit is that decentralizing empowers the managers of the teams, sends a strong message for trust in them, and as a result increases their commitment.

{q3010} In your organisation, you have a mechanism to prioritize the resource requests from the individual teams.

{r230} Staffing process maturity
{w2}

{a1}
While you work on decentralizing the staffing process so that the individual teams in your tech organization come up with resource requests based on their product and engineering roadmaps, you must also ensure that these requests get prioritized in a proper way. In order to achieve this, you must make sure that global priorities are set for your whole tech organization and the teams are well aware of them. This will enable you to properly prioritize the different resource requests, based on these priorities.

{a3}
While you work on decentralizing the staffing process so that the individual teams in your tech organization come up with resource requests based on their product and engineering roadmaps, you must also ensure that these requests get prioritized in a proper way. In order to achieve this, you must make sure that global priorities are set for your whole tech organization and the teams are well aware of them. This will enable you to properly prioritize the different resource requests, based on these priorities.

{a5}
It is good that to a significant extent you’ve created a mechanism for prioritizing the resource requests for the different teams in your tech organization. Make sure that his process is based on global priorities, set for your whole tech organization, with teams strongly aligned and well aware of them. This will enable you to properly prioritize the different resource requests, based on these priorities.

{a6}
It is good that to a large extent you’ve created a mechanism for prioritizing the resource requests for the different teams in your tech organization. Make sure that his process is based on global priorities, set for your whole tech organization, with teams strongly aligned and well aware of them. This will enable you to properly prioritize the different resource requests, based on these priorities.

{q3011} Each recruiter or recruitment team in your organisation works only with specific team.

{r210} Recruitment process maturity
{w2}

{a1}
A very good practice that you should focus to establish is your recruiters to work with specific teams. This will allow the recruiters to get a deep understanding of the corresponding team, and as a result will enable them to present the team well to potential candidates. Very often candidates have specific questions about the teams, like domain area, future roadmap, composition of team members, technologies used, etc. The ability of the recruiters to answer these questions will determine to a large extent the willingness of the candidates to apply.
A frequent counter argument is that recruiters should specialize per technology, e.g. backend, mobile, etc., rather than a team, and serve multiple teams, recruiting candidates in that technology domain. First, it is naïve to think that a non-technical person can get a deep understanding of a technology, especially if their job is recruitment, not software engineering. Second, the potential candidates expect from the recruiter to provide them with details about the company and the team, not about the technology. Candidates are smart enough to plan asking technology related questions during their technical interviews. Aligning your recruitment team per technology rather than per team, will miss you from the opportunity to engage better with potential candidates when you try to attract them for your tech organization.

{a3}
A very good practice that you should focus to establish for your whole tech organization is your recruiters to work with specific teams. This will allow the recruiters to get a deep understanding of the corresponding team, and as a result will enable them to present the team well to potential candidates. Very often candidates have specific questions about the teams, like domain area, future roadmap, composition of team members, technologies used, etc. The ability of the recruiters to answer these questions will determine to a large extent the willingness of the candidates to apply.
A frequent counter argument is that recruiters should specialize per technology, e.g. backend, mobile, etc., rather than a team, and serve multiple teams, recruiting candidates in that technology domain. First, it is naïve to think that a non-technical person can get a deep understanding of a technology, especially if their job is recruitment, not software engineering. Second, the potential candidates expect from the recruiter to provide them with details about the company and the team, not about the technology. Candidates are smart enough to plan asking technology related questions during their technical interviews. Aligning your recruitment team per technology rather than per team, will miss you from the opportunity to engage better with potential candidates when you try to attract them for your tech organization.

{a5}
To a large extent you’ve established the good practice your recruiters to work with specific teams. This allows the recruiters to get a deep understanding of the corresponding team, and as a result enables them to present the team well to potential candidates. Very often candidates have specific questions about the teams, like domain area, future roadmap, composition of team members, technologies used, etc. The ability of the recruiters to answer these questions determines to a large extent the willingness of the candidates to apply.
A frequent counter argument is that recruiters should specialize per technology, e.g. backend, mobile, etc., rather than a team, and serve multiple teams, recruiting candidates in that technology domain. First, it is naïve to think that a non-technical person can get a deep understanding of a technology, especially if their job is recruitment, not software engineering. Second, the potential candidates expect from the recruiter to provide them with details about the company and the team, not about the technology. Candidates are smart enough to plan asking technology related questions during their technical interviews. Continue your effort to align your recruitment team per team, rather than per technology, for all teams in your tech organization. This will ensure better engagement with potential candidates when you try to attract them for your tech organization.

{a6}
To a very large extent you’ve established the good practice your recruiters to work with specific teams. This allows the recruiters to get a deep understanding of the corresponding team, and as a result enables them to present the team well to potential candidates. Very often candidates have specific questions about the teams, like domain area, future roadmap, composition of team members, technologies used, etc. The ability of the recruiters to answer these questions determines to a large extent the willingness of the candidates to apply.
A frequent counter argument is that recruiters should specialize per technology, e.g. backend, mobile, etc., rather than a team, and serve multiple teams, recruiting candidates in that technology domain. First, it is naïve to think that a non-technical person can get a deep understanding of a technology, especially if their job is recruitment, not software engineering. Second, the potential candidates expect from the recruiter to provide them with details about the company and the team, not about the technology. Candidates are smart enough to plan asking technology related questions during their technical interviews. Continue your effort to align your recruitment team per team, rather than per technology, for all teams in your tech organization. This will ensure better engagement with potential candidates when you try to attract them for your tech organization.

{q3012} How many days it takes on average for a candidate to go through the interview process, from the application till the offer extension? Reply with N/A if you don’t know.

{r210} Recruitment process maturity
{w2}

{a0}

{a9}
It’s good that you’ve achieved a state where you finalize the whole interview process in less than 10 days. Fast process is always greatly appreciated by candidates and is a strong signal about the agility and swiftness of your tech organization. Keep in mind that this will become more difficult as your company grows. Make sure you track the recruitment metrics and evolve your recruitment and interviewing processes in order to keep that good state.

{a19}
It’s good that you’ve achieved a state where you finalize the whole interview process in less than 20 days. Work further to speed it up, as fast process is always greatly appreciated by candidates and is a strong signal about the agility and swiftness of your tech organization. Keep in mind that this will become more difficult as your company grows. Make sure you track the recruitment metrics and evolve your recruitment and interviewing processes in order to further improve the speed.

{a20}
You must work on speeding up your interview process. Fast process is always greatly appreciated by candidates and is a strong signal about the agility and swiftness of your tech organization. Keep in mind that the opposite is also true: if the fist interaction of your potential future employees with your tech organization is through a lengthy process, it will be difficult to convince them that your tech organization is fast moving and agile. They’ll have exactly the opposite first impression. Make sure you put a strong effort on decreasing the time from the moment the candidates apply till the final hiring decision to less than 10 days.

{q3013} You customize your interview processes based on the needs and the requirements of the different functions e.g. backend engineer, UI engineer, DevOps/SRE, infrastructure engineer etc.

{r210} Recruitment process maturity
{w4}

{a1}
It is highly encouraging that you start customizing your interview process based on the needs and the requirements of the different functions in your tech organization. One size fits all approach doesn’t work. For example, if you design your interview process towards hands-on experience, and as a result include few coding interviews for software engineers, that will hardly apply for a manual quality assurance candidate. Same goes for other profiles with specific needs, like Product Management, Data Science, BI, etc. You must carefully analyze the specific needs for each role and design your recruitment and interview process accordingly. Until you do that, it is highly probable that your recruitment success rate will be lower.

{a3}
It is highly encouraging that you continue customizing your interview process based on the needs and the requirements of the different functions in your tech organization. One size fits all approach doesn’t work. For example, if you design your interview process towards hands-on experience, and as a result include few coding interviews for software engineers, that will hardly apply for a manual quality assurance candidate. Same goes for other profiles with specific needs, like Product Management, Data Science, BI, etc. You must carefully analyze the specific needs for each role and design your recruitment and interview process accordingly. Until you do that, it is highly probable that your recruitment success rate will be lower.

{a6}
It is good that you’ve customized your interview process based on the needs and the requirements of the different functions in your tech organization. One size fits all approach doesn’t work. For example, if you design your interview process towards hands-on experience, and as a result include few coding interviews for software engineers, that will hardly apply for a manual quality assurance candidate. Same goes for other profiles with specific needs, like Product Management, Data Science, BI, etc. You are encouraged to continue analyzing the specific needs for each role and design your recruitment and interview process accordingly. As you continue to do that, you’ll see increasing recruitment success rates and satisfaction from application candidates.

{q3014} The teams in your organization have well defined on boarding process for new hires, which is constantly improved.

{r230} Staffing process maturity
{w2}

{a1}
Having a good onboarding process is a very important prerequisite in order to ensure smooth joining of your new employees and making them productive fast and efficiently. Also, this is not a one-off effort; as your tech organization grows, it will become more complex, projects will become larger, teams will grow and new domains will be formed, the technological challenges will become bigger. As a result, you should continuously improve your onboarding process. One simple example is that every new joiner provides feedback about the onboarding when it finishes and is in charge to make or drive the necessary improvements. See what works for you, and make sure you establish a good onboarding process and continue evolving and improving it.

{a3}
Having a good onboarding process is a very important prerequisite in order to ensure smooth joining of your new employees and making them productive fast and efficiently. Also, this is not a one-off effort; as your tech organization grows, it will become more complex, projects will become larger, teams will grow and new domains will be formed, the technological challenges will become bigger. As a result, you should continuously improve your onboarding process. One simple example is that every new joiner provides feedback about the onboarding when it finishes and is in charge to make or drive the necessary improvements. See what works for you, and make sure you continue with your effort to establish a good onboarding process and continue evolving and improving it.

{a6}
It is good that the teams in your organization have well defined on boarding process for new hires, which is constantly improved, as this is a very important prerequisite in order to ensure smooth joining of your new employees and making them productive fast and efficiently. Also, this is not a one-off effort; as your tech organization grows, it will become more complex, projects will become larger, teams will grow and new domains will be formed, the technological challenges will become bigger. As a result, you should continuously improve your onboarding process. One simple example is that every new joiner provides feedback about the onboarding when it finishes and is in charge to make or drive the necessary improvements. Whatever solution works for you, make sure you continue with your effort to continue evolving and improving your onboarding process as your tech organization grows and evolves.

{c4} Product strategy and roadmap

{q4001} Your products or services have clearly defined client personas, with clearly defined needs.

{r20} Customer centricity
{w5}

{a1}
It is very important that your tech organization knows for whom it is building products and services. One feature can bring tremendous value to certain target customers, and negligible to others. Knowing your target customers is a mandatory prerequisite if you want to ensure that your tech team is delivering customer value.

{a3}
It is very important that your tech organization knows well for whom it is building products and services. One feature can bring tremendous value to certain target customers, and negligible to others. Knowing your target customers is a mandatory prerequisite if you want to ensure that your tech team is delivering customer value.

{a5}
It is good that you’ve built a tech organization which largely knows for whom it is building products and services. One feature can bring tremendous value to certain target customers, and negligible to others. Knowing your target customers is a mandatory prerequisite if you want to ensure that your tech team is delivering customer value. Continue with the effort to ensure a very good understanding of your target customers throughout all teams in your tech organization.

{a6}
It is great that you’ve built a tech organization which largely knows for whom it is building products and services. One feature can bring tremendous value to certain target customers, and negligible to others. Knowing your target customers is a mandatory prerequisite if you want to ensure that your tech team is delivering customer value. Continue with the effort to maintain a very good understanding of your target customers throughout all teams in your tech organization.

{q4002} It is clear how your products or services satisfy the needs of the different client personas.

{r20} Customer centricity
{w4}

{a1}
After knowing your target customers, it is very important to know what needs your product or service satisfy for them. By knowing the needs that you satisfy and the value that you deliver to your target customers, you’ll be able to ensure the right prioritization throughout the teams in your tech organization, as well as to ensure that they are delivering the maximum value to your customers.
Also, this has one very important additional benefit. Usually the motivation of the tech organization is impacted very positively, when its members know for whom they are building software and especially why they are building that software, meaning what value they are delivering to the customers. Particularly in the cases when the product or service is aligned with a broader mission related to noble initiative or cause, knowing how it impacts positively the target customers can boost the motivation of the engineers and the product managers significantly.

{a3}
After knowing your target customers, it is very important to know what needs your product or service satisfy for them. By knowing the needs that you satisfy and the value that you deliver to your target customers, you’ll be able to ensure the right prioritization throughout the teams in your tech organization, as well as to ensure that they are delivering the maximum value to your customers.
Also, this has one very important additional benefit. Usually the motivation of the tech organization is impacted very positively, when its members know for whom they are building software and especially why they are building that software, meaning what value they are delivering to the customers. Particularly in the cases when the product or service is aligned with a broader mission related to noble initiative or cause, knowing how it impacts positively the target customers can boost the motivation of the engineers and the product managers significantly.

{a5}
Your teams largely know what customer needs your product or service satisfies. By knowing the needs that you satisfy and the value that you deliver to your target customers, you are able to ensure the right prioritization throughout the teams in your tech organization, as well as to ensure that they are delivering the maximum value to your customers.
Also, this has one very important additional benefit. Usually the motivation of the tech organization is impacted very positively, when its members know for whom they are building software and especially why they are building that software, meaning what value they are delivering to the customers. Particularly in the cases when the product or service is aligned with a broader mission related to noble initiative or cause, knowing how it impacts positively the target customers can boost the motivation of the engineers and the product managers significantly.

{a6}
Your teams largely know what needs your product or service satisfy for them. By knowing the needs that you satisfy and the value that you deliver to your target customers, you are able to ensure the right prioritization throughout the teams in your tech organization, as well as to ensure that they are delivering the maximum value to your customers.
Also, this has one very important additional benefit. Usually the motivation of the tech organization is impacted very positively, when its members know for whom they are building software and especially why they are building that software, meaning what value they are delivering to the customers. Particularly in the cases when the product or service is aligned with a broader mission related to noble initiative or cause, knowing how it impacts positively the target customers can boost the motivation of the engineers and the product managers significantly.

{q4003} There is a product strategy defined, communicated and applied.

{r160} Product strategy
{w5}

{a1}
It is very important that you implement a product strategy that outlines how the business vision is reflected in your product or service. The product strategy answers key questions like why we are building that product, for who, what needs are fulfilled, that is the value that is delivered, how that is aligned with the business strategy and the company vision.
Also, a solid product strategy plays a key role in guiding your product organization for important product decisions or direction. In contrast, lack of product strategy often results in frequent changes of product directions, random and conflicting priorities, misalignment with the business strategy and company vision.

{a3}
It is very important that you implement a solid product strategy that outlines how the business vision is reflected in your product or service. The product strategy answers key questions like why we are building that product, for who, what needs are fulfilled, that is the value that is delivered, how that is aligned with the business strategy and the company vision.
Also, a solid product strategy plays a key role in guiding your product organization for important product decisions or direction. In contrast, lack of product strategy often results in frequent changes of product directions, random and conflicting priorities, misalignment with the business strategy and company vision.

{a5}
To a large extent you have a product strategy that outlines how the business vision is reflected in your product or service. The product strategy answers key questions like why we are building that product, for who, what needs are fulfilled, that is the value that is delivered, how that is aligned with the business strategy and the company vision.
Also, a solid product strategy plays a key role in guiding your product organization for important product decisions or direction. In contrast, lack of product strategy often results in frequent changes of product directions, random and conflicting priorities, misalignment with the business strategy and company vision.

{a6}
To a very large extent you have a product strategy that outlines how the business vision is reflected in your product or service. The product strategy answers key questions like why we are building that product, for who, what needs are fulfilled, that is the value that is delivered, how that is aligned with the business strategy and the company vision.
Also, a solid product strategy plays a key role in guiding your product organization for important product decisions or direction. In contrast, lack of product strategy often results in frequent changes of product directions, random and conflicting priorities, misalignment with the business strategy and company vision.

{q4004} There is a product roadmap defined for your product or service.

{r160} Product strategy
{w4}

{a1}
It is very important that you implement a product roadmap for your product or service, which outlines how your product strategy will be implemented, what are the corresponding milestones and their content.
In some cases, primarily with new products or services, there are many unknowns that need to be resolved, and the open questions are more than the known features that need to be implemented. Even in that case, a product roadmap will be very useful. In this case, it can contain for example the main market hypotheses that need to be tested to validate the product strategy, the main risks that need to be explored, etc. The product roadmap is very important bridge between the larger product strategy and the daily deliveries of the teams, so make sure you build a good one.

{a3}
It is very important that you implement a solid product roadmap for your product or service, which outlines how your product strategy will be implemented, what are the corresponding milestones and their content.
In some cases, primarily with new products or services, there are many unknowns that need to be resolved, and the open questions are more than the known features that need to be implemented. Even in that case, a product roadmap will be very useful. In this case, it can contain for example the main market hypotheses that need to be tested to validate the product strategy, the main risks that need to be explored, etc. The product roadmap is very important bridge between the larger product strategy and the daily deliveries of the teams, so make sure you build a good one.

{a5}
Continue with your effort to implement a solid product roadmap for your product or service, which outlines how your product strategy will be implemented, what are the corresponding milestones and their content.
In some cases, primarily with new products or services, there are many unknowns that need to be resolved, and the open questions are more than the known features that need to be implemented. Even in that case, a product roadmap will be very useful. In this case, it can contain for example the main market hypotheses that need to be tested to validate the product strategy, the main risks that need to be explored, etc. The product roadmap is very important bridge between the larger product strategy and the daily deliveries of the teams, so make sure you continue with your effort to build a solid one for all teams in your tech organization.

{a6}
You’ve implemented a product roadmap for your product or service, which is great. A solid roadmap outlines how your product strategy will be implemented, what are the corresponding milestones and their content.
In some cases, primarily with new products or services, there are many unknowns that need to be resolved, and the open questions are more than the known features that need to be implemented. Even in that case, a product roadmap will be very useful. In this case, it can contain for example the main market hypotheses that need to be tested to validate the product strategy, the main risks that need to be explored, etc. The product roadmap is very important bridge between the larger product strategy and the daily deliveries of the teams, so it is great that you’ve put the necessary effort in order to build a solid one for all teams in your tech organization.

{q4005} There is a clear link between the company vision and business strategy, from one side, and the product strategy, from the other.

{r160} Product strategy
{w4}

{a1}
It is important to establish a strong link between the company vision and business strategy, from one side, and the product strategy, from the other. Otherwise it will be challenging for the members of your tech organization to relate their work to the overall company objectives, mission and vision. Also, if such a link is lacking, the rest of the company might view the tech organization as disconnected from the business realities, not supporting the business goals and even as misaligned from the company goals, vision and mission. Very often, these perceptions will be true. Even in the cases when they are not accurate, the lack of a clear link between the product strategy and the company vision and business strategy, will prevent your tech organization from clearly demonstrating such alignment.

{a3}
It is important to establish a strong link between the company vision and business strategy, from one side, and the product strategy, from the other. Otherwise it will be challenging for the members of your tech organization to relate their work to the overall company objectives, mission and vision. Also, if such a link is lacking, the rest of the company might view the tech organization as disconnected from the business realities, not supporting the business goals and even as misaligned from the company goals, vision and mission. Very often, these perceptions will be true. Even in the cases when they are not accurate, the lack of a clear link between the product strategy and the company vision and business strategy, will prevent your tech organization from clearly demonstrating such alignment.

{a5}
It is important that you’ve established a link between the company vision and business strategy, from one side, and the product strategy, from the other. Otherwise it will be challenging for the members of your tech organization to relate their work to the overall company objectives, mission and vision. Also, if such a link is lacking, the rest of the company might view the tech organization as disconnected from the business realities, not supporting the business goals and even as misaligned from the company goals, vision and mission. Very often, these perceptions will be true. Even in the cases when they are not accurate, the lack of a clear link between the product strategy and the company vision and business strategy, will prevent your tech organization from clearly demonstrating such alignment. Continue with your effort to make that link stronger. It will have a very positive effect in further aligning the tech organization with the rest of the company and ensuring it is delivering high customer value.

{a6}
It is important that you’ve established a strong link between the company vision and business strategy, from one side, and the product strategy, from the other. Otherwise it will be challenging for the members of your tech organization to relate their work to the overall company objectives, mission and vision. Also, if such a link is lacking, the rest of the company might view the tech organization as disconnected from the business realities, not supporting the business goals and even as misaligned from the company goals, vision and mission. Very often, these perceptions will be true. Even in the cases when they are not accurate, the lack of a clear link between the product strategy and the company vision and business strategy, will prevent your tech organization from clearly demonstrating such alignment. Continue with your effort to maintain that strong link. It will have a very positive effect in further aligning the tech organization with the rest of the company and ensuring it is delivering high customer value.

{q4006} There are product goals or product OKRs defined, monitored and tracked, for a period between 1 and 6 months (e.g. quarterly OKRs).

{r140} Product execution
{w3}

{a1}
It is important that the product roadmap is split into more granular product goals. This will enable the teams to link the longer-term product strategy and roadmap, to the shorter-term goals and their daily work. Also, having such short-term goals will enable the product team to adapt and update the product strategy and roadmap, based on the learnings accumulated while delivering the granular short-term goals. It is not so important if you’ll use OKRs or other technique – you can choose whatever approach suits you. But make sure that you start defining such granular product goals.

{a3}
It is important that the product roadmap is split into more granular product goals. This will enable the teams to link the longer-term product strategy and roadmap, to the shorter-term goals and their daily work. Also, having such short-term goals will enable the product team to adapt and update the product strategy and roadmap, based on the learnings accumulated while delivering the granular short-term goals. It is not so important if you’ll use OKRs or other technique – you can choose whatever approach suits you. But make sure that you start defining such granular product goals for all teams in your tech organization.

{a5}
It is good that to a large extent the product roadmap is split into more granular product goals, for the teams in your tech organization. This enables the teams to link the longer-term product strategy and roadmap, to the shorter-term goals and their daily work. Also, having such short-term goals enables the product team to adapt and update the product strategy and roadmap, based on the learnings accumulated while delivering the granular short-term goals. It is not so important if you’ll use OKRs or other technique – you can choose whatever approach suits you. But make sure that you continue defining such granular product goals for all teams in your tech organization and continuously improve the process to best suit your needs.

{a6}
It is good that to a large extent the product roadmap is split into more granular product goals, for the teams in your tech organization. This enables the teams to link the longer-term product strategy and roadmap, to the shorter-term goals and their daily work. Also, having such short-term goals enables the product team to adapt and update the product strategy and roadmap, based on the learnings accumulated while delivering the granular short-term goals. It is not so important if you’ll use OKRs or other technique – you can choose whatever approach suits you. But make sure that you continue defining such granular product goals for all teams in your tech organization and continuously improve the process to best suit your needs.

{q4007} There is a clear link between the product/service OKRs and the product features delivered by the engineering teams in every release.

{r140} Product execution
{w3}

{a1}
It is of utmost importance that you create a clear link between the product goals and the features that are continuously delivered from your tech organization. If such a strong link doesn’t exist, there is a high risk that the product strategy, roadmap and goals will be just wishes, not materialized through the execution of the engineering teams.
One very easy suggestion to support establishing such link is to use the same project management system for the product goals or OKRs, and the product features. This way you can link every feature directly to a product goal within the same system, and if such link is missing for a given feature, this will be a very quick indication that this feature is not aligned with the product goals.
Whatever approach you choose, make sure you establish such link for all teams in your tech organization.

{a3}
It is of utmost importance that you create a clear link between the product goals and the features that are continuously delivered from your tech organization. If such a strong link doesn’t exist, there is a high risk that the product strategy, roadmap and goals will be just wishes, not materialized through the execution of the engineering teams.
One very easy suggestion to support establishing such link is to use the same project management system for the product goals or OKRs, and the product features. This way you can link every feature directly to a product goal within the same system, and if such link is missing for a given feature, this will be a very quick indication that this feature is not aligned with the product goals.
Whatever approach you choose, make sure you establish such link for all teams in your tech organization.

{a5}
It is of utmost importance that you’ve established a clear link between the product goals and the features that are continuously delivered from your tech organization. If such a strong link doesn’t exist, there is a high risk that the product strategy, roadmap and goals will be just wishes, not materialized through the execution of the engineering teams.
One very easy suggestion to support establishing such link is to use the same project management system for the product goals or OKRs, and the product features. This way you can link every feature directly to a product goal within the same system, and if such link is missing for a given feature, this will be a very quick indication that this feature is not aligned with the product goals.
Choose whatever approach fits your tech organization, but make sure you continue with your effort to establish a strong link for all tech teams.

{a6}
It is of utmost importance that you’ve established a clear link between the product goals and the features that are continuously delivered from your tech organization. If such a strong link doesn’t exist, there is a high risk that the product strategy, roadmap and goals will be just wishes, not materialized through the execution of the engineering teams.
One very easy suggestion to support establishing such link is to use the same project management system for the product goals or OKRs, and the product features. This way you can link every feature directly to a product goal within the same system, and if such link is missing for a given feature, this will be a very quick indication that this feature is not aligned with the product goals.
Choose whatever approach fits your tech organization, but make sure you continue with your effort to keep a strong link for all tech teams.

{q4008} The engineering team is strongly involved in the feature identification and refinement process, rather than the product team “dropping” defined features to the engineering team for execution.

{r140} Product execution
{w3}

{a1}
You must work towards involving your engineering teams in the feature identification and refinement process.
Usually strong engineering teams possess good knowledge about the product or service they are building. As a result, they can provide a very valuable input to the product managers, for possible improvements of existing features or addition of new capabilities.
Also, quite often technological advancements can be a source of strong competitive advantage for any product or service. The people in your tech organization who are closer to such technological advancements are your engineers. If you don’t enable them from the possibility to input that information to the product organization, you risk depriving your company from a very serious competitive advantage.
Also, involving your engineering teams during the feature identification and refinement process has another strong advantage. It ensures that your engineers understand well the features and the value they bring to the customers, as well as it allows them to raise any concerns early enough during the process of refinement. All this ensures strong alignment of your engineering teams with the product goals and high commitment during their implementation and delivery.

{a3}
You must continue to work towards involving your engineering teams in the feature identification and refinement process.
Usually strong engineering teams possess good knowledge about the product or service they are building. As a result, they can provide a very valuable input to the product managers, for possible improvements of existing features or addition of new capabilities.
Also, quite often technological advancements can be a source of strong competitive advantage for any product or service. The people in your tech organization who are closer to such technological advancements are your engineers. If you don’t enable them from the possibility to input that information to the product organization, you risk depriving your company from a very serious competitive advantage.
Also, involving your engineering teams during the feature identification and refinement process has another strong advantage. It ensures that your engineers understand well the features and the value they bring to the customers, as well as it allows them to raise any concerns early enough during the process of features’ refinement. All this ensures strong alignment of your engineering teams with the product goals and high commitment during their implementation and delivery.

{a5}
It’s good that you work towards involving your engineering teams in the feature identification and refinement process.
Usually strong engineering teams possess good knowledge about the product or service they are building. As a result, they can provide a very valuable input to the product managers, for possible improvements of existing features or addition of new capabilities.
Also, quite often technological advancements can be a source of strong competitive advantage for any product or service. The people in your tech organization who are closer to such technological advancements are your engineers. If you don’t enable them from the possibility to input that information to the product organization, you risk depriving your company from a very serious competitive advantage.
Also, involving your engineering teams during the feature identification and refinement process has another strong advantage. It ensures that your engineers understand well the features and the value they bring to the customers, as well as it allows them to raise any concerns early enough during the process of features’ refinement. All this ensures strong alignment of your engineering teams with the product goals and high commitment during their implementation and delivery.
Continue to work in that direction to ensure strong involvement of your engineering teams in the feature identification and refinement process for all teams in your tech organization.

{a6}
It’s great that you work hard towards involving your engineering teams in the feature identification and refinement process.
Usually strong engineering teams possess good knowledge about the product or service they are building. As a result, they can provide a very valuable input to the product managers, for possible improvements of existing features or addition of new capabilities.
Also, quite often technological advancements can be a source of strong competitive advantage for any product or service. The people in your tech organization who are closer to such technological advancements are your engineers. If you don’t enable them from the possibility to input that information to the product organization, you risk depriving your company from a very serious competitive advantage.
Also, involving your engineering teams during the feature identification and refinement process has another strong advantage. It ensures that your engineers understand well the features and the value they bring to the customers, as well as it allows them to raise any concerns early enough during the process of features’ refinement. All this ensures strong alignment of your engineering teams with the product goals and high commitment during their implementation and delivery.
Continue to work in that direction to maintain the strong involvement of your engineering teams in the feature identification and refinement process.

{q4009} Every product feature has associated definition of done and clear business impact that can be measured.

{r140} Product execution
{w5}

{a1}
You must create definition of done and clear business impact for every feature that your teams deliver. The definition of done is a very important indicator and can bring a lot of valuable information, like for example what is the right amount of effort that they must invest, what are the necessary non-functional capabilities that must be developed, e.g. security or quality.
If such information is missing, teams can overengineer or underdeliver the features, as well as they might miss very important non-functional requirements.
The business impact is an indicator if the feature has delivered the intended customer value. If you don’t define business impact for your features, it will be very difficult to quantify their impact, as well as to make sound decisions if certain features have achieved their goals or need to be further improved.

{a3}
You must create definition of done and clear business impact for every feature that your teams deliver. The definition of done is a very important indicator and can bring a lot of valuable information, like for example what is the right amount of effort that they must invest, what are the necessary non-functional capabilities that must be developed, e.g. security or quality.
If such information is missing, teams can overengineer or underdeliver the features, as well as they might miss very important non-functional requirements.
The business impact is an indicator if the feature has delivered the intended customer value. If you don’t define business impact for your features, it will be very difficult to quantify their impact, as well as to make sound decisions if certain features have achieved their goals or need to be further improved.

{a5}
To a large extent you’ve created definition of done and clear business impact for every feature that your teams deliver. The definition of done is a very important indicator and can bring a lot of valuable information, like for example what is the right amount of effort that they must invest, what are the necessary non-functional capabilities that must be developed, e.g. security or quality.
If such information is missing, teams can overengineer or underdeliver the features, as well as they might miss very important non-functional requirements.
The business impact is an indicator if the feature has delivered the intended customer value. If you don’t define business impact for your features, it will be very difficult to quantify their impact, as well as to make sound decisions if certain features have achieved their goals or need to be further improved.
Continue with your effort to define clear definition of done and business impact that can be measured, for every feature that the teams in your tech organization deliver.

{a6}
To a large extent you’ve created definition of done and clear business impact for every feature that your teams deliver. The definition of done is a very important indicator and can bring a lot of valuable information, like for example what is the right amount of effort that they must invest, what are the necessary non-functional capabilities that must be developed, e.g. security or quality.
If such information is missing, teams can overengineer or underdeliver the features, as well as they might miss very important non-functional requirements.
The business impact is an indicator if the feature has delivered the intended customer value. If you don’t define business impact for your features, it will be very difficult to quantify their impact, as well as to make sound decisions if certain features have achieved their goals or need to be further improved.
Continue with your effort to define clear definition of done and business impact that can be measured, for every feature that the teams in your tech organization deliver.

{q4010} There is a clear prioritisation framework which is applied.

{r140} Product execution
{w5}

{a1}
You must set a clear prioritization framework which is applied when prioritizing new features. There are numerous prioritization frameworks available, you can adopt the one that suits best your specific needs. But not having such jeopardizes the ability of your tech organization to deliver customer value, as each product manager will have to apply their own method of prioritization, which is not necessarily aligned with the rest of the product organization, and more importantly – not aligned with the overall product strategy, roadmap and goals.

{a3}
You must set a clear prioritization framework which is applied in all teams when prioritizing new features. There are numerous prioritization frameworks available, you can adopt the one that best suits your specific needs. But not having such jeopardizes the ability of your tech organization to deliver customer value, as each product manager will have to apply their own method of prioritization, which is not necessarily aligned with the rest of the product organization, and more importantly – not aligned with the overall product strategy, roadmap and goals.

{a5}
You’ve set a prioritization framework which is largely applied by the teams when prioritizing new features.
Having such framework enables your tech organization to deliver customer value. Also, it mitigates the risk each product manager to apply their own method of prioritization, which is not necessarily aligned with the rest of the product organization, and more importantly – not aligned with the overall product strategy, roadmap and goals.
Continue with your focused effort to set clear prioritization framework for all teams in your tech organization.

{a6}
You’ve set a prioritization framework which is largely applied by the teams when prioritizing new features.
Having such framework enables your tech organization to deliver customer value. Also, it mitigates the risk each product manager to apply their own method of prioritization, which is not necessarily aligned with the rest of the product organization, and more importantly – not aligned with the overall product strategy, roadmap and goals.
Continue with your focused effort to maintain clear prioritization framework for all teams in your tech organization.

{q4011} The teams in your tech organization have a defined and functioning mechanism of prioritising between product and engineering backlog. Examples of engineering backlog are working on the tech platform of your product for increased scalability or improved reliability.

{r140} Product execution
{w2}

{a1}
A mistake which tech organizations frequently make is to neglect the engineering backlog, while focusing predominantly on their product backlogs.
This is a very serious risk, as often the engineering backlog is even more important for the products or services, than the product backlog. For example, missing to scale your software system might jeopardize the growth plans for your whole company – your software system simply won’t be able to handle more transactions. Such mistakes can have a devastating effect, especially on fast growing companies with ambitious growth plans.
It is very important that you set a prioritization framework which effectively balances between the product and engineering backlogs. This will ensure that you’ll invest the right amount of effort and allocate the right capacity in order to deliver maximum value to your customers.

{a3}
A mistake which tech organizations frequently make is to neglect the engineering backlog, while focusing predominantly on their product backlogs.
This is a very serious risk, as often the engineering backlog is even more important for the products or services, than the product backlog. For example, missing to scale your software system might jeopardize the growth plans for your whole company – your software system simply won’t be able to handle more transactions. Such mistakes can have a devastating effect, especially on fast growing companies with ambitious growth plans.
It is very important that you set a prioritization framework which effectively balances between the product and engineering backlogs. This will ensure that you’ll invest the right amount of effort and allocate the right capacity in order to deliver maximum value to your customers.

{a5}
It is great that you have a framework to balance the product and engineering backlogs. The lack of such framework is a mistake which tech organizations frequently make. Very often they neglect the engineering backlog, while focusing predominantly on their product backlogs.
This is a very serious risk, as often the engineering backlog is even more important for the products or services, than the product backlog. For example, missing to scale your software system might jeopardize the growth plans for your whole company – your software system simply won’t be able to handle more transactions. Such mistakes can have a devastating effect, especially on fast growing companies with ambitious growth plans.
It is good that you’ve set a prioritization framework which effectively balances between the product and engineering backlogs. Continue with your effort to enhance and apply it for all teams in your tech organization. This will ensure that you’ll invest the right amount of effort and allocate the right capacity in order to deliver maximum value to your customers.

{a6}
It is great that you have a framework to balance the product and engineering backlogs. The lack of such framework is a mistake which tech organizations frequently make. Very often they neglect the engineering backlog, while focusing predominantly on their product backlogs.
This is a very serious risk, as often the engineering backlog is even more important for the products or services, than the product backlog. For example, missing to scale your software system might jeopardize the growth plans for your whole company – your software system simply won’t be able to handle more transactions. Such mistakes can have a devastating effect, especially on fast growing companies with ambitious growth plans.
It is good that you’ve set a prioritization framework which effectively balances between the product and engineering backlogs. Continue with your effort to enhance and apply it for all teams in your tech organization. This will ensure that you’ll invest the right amount of effort and allocate the right capacity in order to deliver maximum value to your customers.

{c5} Engineering strategy, roadmap and maturity

{q5001} Your tech organization has clear engineering roadmap for the next 1 year.

{r240} Strategic focus
{w5}

{a1}
Frequently tech organizations are swamped by urgent tasks and daily operations. This often results in strong skew towards short-term activities, at the expense of neglecting the longer-term priorities, goals and roadmap to achieve them.
When organizations fall in that trap, their members often question the priority and validity of urgent activities, as they can’t clearly relate them to the overall priorities and goals of the organization. It rather seems for the members that whatever comes tomorrow, will be again high priority and urgent, despite its direction. Often that results in complacency, indifference and low commitment.
Some tech organizations have shorter term strategies, for example 3 or 6 months. We recommend to have a longer term strategy because of few important reasons:
● implementing your strategy might require hiring talent with specific skillset. If you set as a strategic goal to highly improve the security of your system, and to achieve that decide to build a security team inhouse, it is not very likely that you will be able to find and hire talent, onboard the people and implement your security goals in just 3 or even 6 months. Strategic decisions are usually longer term and require more time to implement, that’s why you need a longer term strategy.
● if you have a short-term strategy, there is a chance that it will overlap with your quarterly planning and goals. These must be very separate – your strategy should project a picture how you see the engineering organization 1 or even 2 years ahead. Your quarterly planning should project a picture how are you implementing that strategy.
Another drawback if you lack longer term engineering roadmap is that it can result in your tech organization often swinging in different directions, for example from overinvestment in quality to almost no quality activities, from very strong focus on security to completely neglecting security, from excessive attention to code coverage, to completely lack of tracking and improving code coverage. There are numerous other directions that you can take and abandon, if you don’t have the longer-term engineering strategy and roadmap that can guide you, as you mature and grow your tech organization.
Make sure you set as a very high priority creating such strategy and roadmap. Its positive impact will be invaluable for you. And its lack is a significant barrier for building an awesome tech organization.

{a3}
Frequently tech organizations are swamped by urgent tasks and daily operations. This often results in strong skew towards short-term activities, at the expense of neglecting the longer-term priorities, goals and roadmap to achieve them.
When organizations fall in that trap, their members often question the priority and validity of urgent activities, as they can’t clearly relate them to the overall priorities and goals of the organization. It rather seems for the members that whatever comes tomorrow, will be again high priority and urgent, despite its direction. Often that results in complacency, indifference and low commitment.
Some tech organizations have shorter term strategies, for example 3 or 6 months. We recommend to have a longer term strategy because of few important reasons:
● implementing your strategy might require hiring talent with specific skillset. If you set as a strategic goal to highly improve the security of your system, and to achieve that decide to build a security team inhouse, it is not very likely that you will be able to find and hire talent, onboard the people and implement your security goals in just 3 or even 6 months. Strategic decisions are usually longer term and require more time to implement, that’s why you need a longer term strategy.
● if you have a short-term strategy, there is a chance that it will overlap with your quarterly planning and goals. These must be very separate – your strategy should project a picture how you see the engineering organization 1 or even 2 years ahead. Your quarterly planning should project a picture how are you implementing that strategy.
Another drawback if you lack longer term engineering roadmap is that it can result in your tech organization often swinging in different directions, for example from overinvestment in quality to almost no quality activities, from very strong focus on security to completely neglecting security, from excessive attention to code coverage, to completely lack of tracking and improving code coverage. There are numerous other directions that you can take and abandon, if you don’t have the longer-term engineering strategy and roadmap that can guide you, as you mature and grow your tech organization.
Make sure you set as a very high priority creating a good engineering strategy and roadmap. Its positive impact will be invaluable for you. And its lack is a significant barrier for building an awesome tech organization.

{a5}
Frequently tech organizations are swamped by urgent tasks and daily operations. This often results in strong skew towards short-term activities, at the expense of neglecting the longer-term priorities, goals and roadmap to achieve them.
When organizations fall in that trap, their members often question the priority and validity of urgent activities, as they can’t clearly relate them to the overall priorities and goals of the organization. It rather seems for the members that whatever comes tomorrow, will be again high priority and urgent, despite its direction. Often that results in complacency, indifference and low commitment.
Another drawback if you lack longer term engineering roadmap is that it can result in your tech organization often swinging in different directions, for example from overinvestment in quality to almost no quality activities, from very strong focus on security to completely neglecting security, from excessive attention to code coverage, to completely lack of tracking and improving code coverage. There are numerous other directions that you can take and abandon, if you don’t have the longer-term engineering strategy and roadmap that can guide you, as you mature and grow your tech organization.
It’s great that you’ve made an effort to create an engineering strategy and roadmap. Make sure you set as a very high priority to further evolve and improve it. Its positive impact will be invaluable for you. And not doing this could become a significant barrier for building an awesome tech organization.

{a6}
Frequently tech organizations are swamped by urgent tasks and daily operations. This often results in strong skew towards short-term activities, at the expense of neglecting the longer-term priorities, goals and roadmap to achieve them.
When organizations fall in that trap, their members often question the priority and validity of urgent activities, as they can’t clearly relate them to the overall priorities and goals of the organization. It rather seems for the members that whatever comes tomorrow, will be again high priority and urgent, despite its direction. Often that results in complacency, indifference and low commitment.
Another drawback if you lack longer term engineering roadmap is that it can result in your tech organization often swinging in different directions, for example from overinvestment in quality to almost no quality activities, from very strong focus on security to completely neglecting security, from excessive attention to code coverage, to completely lack of tracking and improving code coverage. There are numerous other directions that you can take and abandon, if you don’t have the longer-term engineering strategy and roadmap that can guide you, as you mature and grow your tech organization.
It’s great that you’ve created an engineering strategy and roadmap. Make sure you set as a very high priority to further evolve and improve it, as your organization grows. Its positive impact will be invaluable for you.

{q5002} Your tech organization has a process to balance between product and engineering roadmaps and goals.

{r240} Strategic focus
{w2}

{a1}
Not having a process to balance between product and engineering roadmaps is a significant risk for your tech organization. It can result in skew towards either heavily product driven scope and neglecting the engineering, or the opposite – predominantly engineering scope and as a result your product or service to starve for new features and improvements. To avoid that risk, make sure you have a well justified and thought through process for balancing between the two types of effort. Some companies are allocating a fixed percentage of their tech capacity, for example 70% for product and 30% for engineering scope. Other companies have common capacity and prioritization of both efforts. Whatever approach you choose, make sure you implement it urgently.

{a3}
Not having a good and working process to balance between product and engineering roadmaps is a significant risk for your tech organization. It can result in skew towards either heavily product driven scope and neglecting the engineering, or the opposite – predominantly engineering scope and as a result your product or service to starve for new features and improvements. To avoid that risk, make sure you have a well justified and thought through process for balancing between the two types of effort. Some companies are allocating a fixed percentage of their tech capacity, for example 70% for product and 30% for engineering scope. Other companies have common capacity and prioritization of both efforts. Whatever approach you choose, make sure you adopt it urgently for the whole tech organization.

{a5}
To a large extent you have a working process to balance between product and engineering roadmaps, which is good, as not having it is a significant risk for your tech organization. It can result in skew towards either heavily product driven scope and neglecting the engineering, or the opposite – predominantly engineering scope and as a result your product or service to starve for new features and improvements. To avoid that risk, make sure you adopt that process for all teams in your tech organization.

{a6}
To a significant extent you have a working process to balance between product and engineering roadmaps, which is good, as not having it is a significant risk for your tech organization. It can result in skew towards either heavily product driven scope and neglecting the engineering, or the opposite – predominantly engineering scope and as a result your product or service to starve for new features and improvements. Make sure you continue to maintain and evolve that process for your whole tech organization.

{q5003} You have a clear security strategy – how much to invest in security, why, how, who, when and what.

{r240} Strategic focus
{w3}

{a1}
You must set as a priority to define a security strategy for your tech organization. Based on the overall priorities of your company and the domain of your product or service, you must define how much you need to invest in security and in what areas. Some products and services, like for example payment providers or managers of sensitive customer data, need to invest much more compared to other products and services. In any case you must be proactive and prepare a security strategy, which to outline how much you should invest in security, in what areas, and in what activities, to outline and prioritize the top security risks, outline if you should make security assessments and how often, if you should involve external companies in any of these activities like penetration testing, etc. If you don’t do so, you risk either your company to be extremely exposed to security vulnerabilities, or in rarer cases to spend significant cost in security activities, without actual need for all of them.
Also, it will be highly desirable to design as part of your security strategy an incident response process. It will help you to quickly react in case of unfortunate events like security breaches or malicious attacks.

{a3}
You must set as a priority to define and details a security strategy for your tech organization. Based on the overall priorities of your company and the domain of your product or service, you must define how much you need to invest in security and in what areas. Some products and services, like for example payment providers or managers of sensitive customer data, need to invest much more compared to other products and services. In any case you must be proactive and prepare a security strategy, which to outline how much you should invest in security, in what areas, and in what activities, to outline and prioritize the top security risks, outline if you should make security assessments and how often, if you should involve external companies in any of these activities like penetration testing, etc. If you don’t do so, you risk either your company to be extremely exposed to security vulnerabilities, or in rarer cases to spend significant cost in security activities, without actual need for all of them.
Also, it will be highly desirable to design as part of your security strategy an incident response process. It will help you to quickly react in case of unfortunate events like security breaches or malicious attacks.

{a5}
Good job that you’ve defined a security strategy for your tech organization. Based on the overall priorities of your company and the domain of your product or service, it should define how much you need to invest in security and in what areas. Some products and services, like for example payment providers or managers of sensitive customer data, need to invest much more compared to other products and services. Make sure your security strategy outlines how much you should invest in security, in what areas, and in what activities, to outline and prioritize the top security risks, if you should make security assessments and how often, if you should involve external companies in any of these activities like penetration testing, etc. If you don’t do so, you risk either your company to be extremely exposed to security vulnerabilities, or in rarer cases to spend significant cost in security activities, without actual need for all of them.
Also, it will be highly desirable to design as part of your security strategy an incident response process. It will help you to quickly react in case of unfortunate events like security breaches or malicious attacks.

{a6}
Good job that you’ve defined a security strategy for your tech organization. Based on the overall priorities of your company and the domain of your product or service, it should define how much you need to invest in security and in what areas. Some products and services, like for example payment providers or managers of sensitive customer data, need to invest much more compared to other products and services. Make sure your security strategy outlines how much you should invest in security, in what areas, and in what activities, to outline and prioritize the top security risks, if you should make security assessments and how often, if you should involve external companies in any of these activities like penetration testing, etc. If you don’t do so, you risk either your company to be extremely exposed to security vulnerabilities, or in rarer cases to spend significant cost in security activities, without actual need for all of them.
Also, it will be highly desirable to design as part of your security strategy an incident response process. It will help you to quickly react in case of unfortunate events like security breaches or malicious attacks.

{q5004} You have a well-defined way to monitor and track the engineering maturity of your projects.

{r50} Engineering maturity
{w3}

{a1}
It is important that you establish a mechanism to monitor and track the engineering maturity of the projects in your tech organization. Usually this means tracking different KPIs in the areas of project management and delivery, quality, efficiency, innovation. Also, such tracking should include people related metrics like NPS, attrition, employee engagement, etc.
You should adapt this tracking per your needs, for example some teams include areas like risk management, security, or any other that is relevant for their domain.
Establishing a simple, robust and reliable mechanism to monitor and track the engineering maturity of the projects in your tech organization will help ensure that they deliver their goals. If they struggle to do so, your monitoring process will detect this early and will enable you to intervene and help the projects to get back on track. Missing to implement such tracking, you’ll detect this problem only when it’s already too late for correction.

{a3}
It is important that you establish a good mechanism to monitor and track the engineering maturity of all projects in your tech organization. Usually this means tracking different KPIs in the areas of project management and delivery, quality, efficiency, innovation. Also, such tracking should include people related metrics like NPS, attrition, employee engagement, etc.
You should adapt this tracking per your needs, for example some teams include areas like risk management, security, or any other that is relevant for their domain.
Establishing a simple, robust and reliable mechanism to monitor and track the engineering maturity of the projects in your tech organization will help ensure that they deliver their goals. If they struggle to do so, your monitoring process will detect this early and will enable you to intervene and help the projects to get back on track. Missing to implement such tracking, you’ll detect this problem only when it’s already too late for correction.

{a5}
It is good that you established a mechanism to monitor and track the engineering maturity of the projects in your tech organization. Usually this means tracking different KPIs in the areas of project management and delivery, quality, efficiency, innovation. Also, such tracking should include people related metrics like NPS, attrition, employee engagement, etc.
You can adapt this tracking per your needs, for example some teams include areas like risk management, security, or any other that is relevant for their domain.
Establishing a simple, robust and reliable mechanism to monitor and track the engineering maturity of the projects in your tech organization will help ensure that they deliver their goals. If they struggle to do so, your monitoring process will detect this early and will enable you to intervene and help the projects to get back on track. Missing to implement such tracking, you’ll detect this problem only when it’s already too late for correction.
Make sure you continue to evolve the process of monitoring and tracking of your projects and apply it for the whole tech organization.

{a6}
It is good that you established a mechanism to monitor and track the engineering maturity of the projects in your tech organization. Usually this means tracking different KPIs in the areas of project management and delivery, quality, efficiency, innovation. Also, such tracking should include people related metrics like NPS, attrition, employee engagement, etc.
You can adapt this tracking per your needs, for example some teams include areas like risk management, security, or any other that is relevant for their domain.
Establishing a simple, robust and reliable mechanism to monitor and track the engineering maturity of the projects in your tech organization helps ensuring that they deliver their goals. If they struggle to do so, your monitoring process will detect this early and will enable you to intervene and help the projects to get back on track.
Make sure you continue to evolve this process and apply it for the whole tech organization.

{q5005} The members of your tech organization are invited frequently to speak at tech conferences and meetups.

{r50} Engineering maturity
{w2}

{a1}
An important indicator of the maturity of your engineering organization is if its members are speakers of renewed conferences and meetups.
The lack of such participation signals that you must invest a lot in building and growing strong engineering talent. Usually when you don’t invest enough in that direction, you’ll observe additional signals like lower ratings in the areas of professional development, growth and learning, in the employees’ surveys for example, or lower employees’ satisfaction, higher attrition rate, etc.
The caveat here is that if you try to shortcut that problem by setting participation at conferences as a goal, you won’t achieve that goal. The reason is that you won’t fix your underlying root cause, which is insufficient focus on professional development and growth of the members of your tech organization. Participation in conferences is a side effect – when you’ve built a strong tech organization in which exceptional engineering experts thrive and grow, they will be naturally recognized by the broader tech community and invited to conferences and other events. So, make sure that you put a very strong focus in that area. Building an exceptional engineering talent is a fundamental prerequisite in order to have a strong tech organization.

{a3}
An important indicator of the maturity of your engineering organization is if its members are speakers of renewed conferences and meetups.
Insufficient participation signals that you must invest more in building and growing strong engineering talent. Usually when you don’t invest enough in that direction, you’ll observe additional signals like lower ratings in the areas of professional development, growth and learning, in the employees’ surveys for example, or lower employees’ satisfaction, higher attrition rate, etc.
The caveat here is that if you try to shortcut that problem by setting participation at conferences as a goal, you won’t achieve that goal. The reason is that you won’t fix your underlying root cause, which is insufficient focus on professional development and growth of the members of your tech organization. Participation in conferences is a side effect – when you’ve built a strong tech organization in which exceptional engineering experts thrive and grow, they will be naturally recognized by the broader tech community and invited to conferences and other events. So, make sure that you put a very strong focus in that area. Building an exceptional engineering talent is a fundamental prerequisite in order to have a strong tech organization.

{a5}
An important indicator of the maturity of your engineering organization is if its members are speakers of renewed conferences and meetups. Such participation is a signal that you are building experts which are recognized by the broader engineering community and is eloquent testimony that you’ve built an engineering organization in which exceptional engineering talent grows and thrives.
Keep up the good work and continue to further invest in growing strong experts. Building an exceptional engineering talent is a fundamental prerequisite in order to have strong tech organization.

{a6}
An important indicator about the maturity of your engineering organization is if its members are speakers of renewed conferences and meetups. Such participation is a strong signal that you are building experts which are recognized by the broader engineering community and is eloquent testimony that you’ve built an engineering organization in which exceptional engineering talent grows and thrives.
Keep up the good work. Building an exceptional engineering talent is a fundamental prerequisite in order to have strong tech organization.

{q5006} You have adopted high engineering standards which you constantly measure and improve.

{r50} Engineering maturity
{w4}

{a1}
Adopting high engineering standards is also a must-have if you want to build a good tech team. Remember that strong experts want to work in an environment in which such high standards are adopted and applied. Otherwise, it will be difficult for you to hire and retain such experts, which in turn will reduce your ability to build strong tech team.

{a3}
Adopting high engineering standards is also a must-have if you want to build a good tech team. Remember that strong experts want to work in an environment in which such high standards are adopted and applied. Otherwise, it will be difficult for you to hire and retain such experts, which in turn will reduce your ability to build strong tech team.

{a5}
You’ve built a tech organization which has adopted good engineering standards. Make sure you continue your effort on enhancing your engineering practices and to constantly improve them. Remember that strong experts want to work in an environment in which such high standards are adopted and applied. Otherwise, it will be difficult for you to hire and retain such experts, which in turn will reduce your ability to build strong tech team.

{a6}
You’ve built a tech organization which has adopted high engineering standards which are constantly improved. Make sure you continue your effort evolve them, and ensure they are applied for all teams. Remember that strong experts want to work in an environment in which such high standards are adopted and applied. Otherwise, it will be difficult for you to hire and retain such experts, which in turn will reduce your ability to build strong tech team.

{c6} Project management

{q6001} Your tech team knows what project management framework it is using, they can name it and provide a basic description of it.

{r170} Project management practice
{w5}

{a1}
The teams in your tech organization must be well aware of the project management frameworks they are using. This is a very important requirement in order to continuously improve the project management practices applied by the teams. Make sure they get a good understanding of the project management framework they are using and get a good knowledge of its fundamental principles and foundation.

{a3}
The teams in your tech organization must be well aware of the project management frameworks they are using. This is a very important requirement in order to continuously improve the project management practices applied by the teams. Make sure all of them get a good understanding of the project management framework they are using and get a good knowledge of its fundamental principles and foundation.

{a5}
The teams in your tech organization are largely aware of the project management frameworks they are using. This is a very important requirement in order to continuously improve the project management practices applied by the teams. Make sure all of them get a good understanding of the project management framework they are using and get a good knowledge of its fundamental principles and foundation.

{a6}
The teams in your tech organization are largely aware of the project management frameworks they are using. Good job, as this is a very important requirement in order to continuously improve the project management practices applied by the teams.

{q6002} Your team members can provide information about why you are using that specific project management framework, over other options.

{r170} Project management practice
{w3}

{a1}
It is very important that the members of your tech organization to be well aware why certain project management framework is used. Every project management methodology has its own benefits and application, depending on the domain, the type of the project and other factors. But whatever the framework is, if your teams don’t understand its benefits, most probably they won’t be able to adopt it successfully and take advantage of it.

{a3}
It is very important that the members of your tech organization to be well aware why certain project management framework is used. Every project management methodology has its own benefits and application, depending on the domain, the type of the project and other factors. But whatever the methodology and the framework is, if your teams don’t understand its benefits, most probably they won’t be able to adopt it successfully and take advantage of it.

{a5}
The members of your tech organization are largely aware why certain project management framework is used. Every project management methodology has its own benefits and application, depending on the domain, the type of the project and other factors. But whatever the methodology and the framework is, if your teams don’t understand its benefits, most probably they won’t be able to take advantage of it. Make sure you continue to train and educate your teams about the fundamental principles and advantages of the project management framework that you’ve adopted, in order to ensure that it is successfully implemented.

{a6}
The members of your tech organization are largely aware why certain project management framework is used. Every project management methodology has its own benefits and application, depending on the domain, the type of the project and other factors. But whatever the methodology and the framework is, if your teams don’t understand its benefits, most probably they won’t be able to take advantage of it. Make sure you continue to train and educate your teams about the fundamental principles and advantages of the project management framework that you’ve adopted, in order to ensure that it is successfully implemented.

{q6003} For every project in your tech organization, you can easily tell if it is on track or not.

{r180} Project tracking and monitoring
{w4}

{a1}
It is important that you adopt a project management framework that will allow you to easily and reliably track and monitor the progress of the projects in your tech organization. This will enable the teams to communicate clearly the status of the projects to their stakeholders and to take corrective actions when needed.
Lacking a way to monitor and track the projects in your tech organization will significantly reduce its ability to deliver strategic programs and projects successfully.

{a3}
It is important that you adopt a project management framework that will allow you to easily and reliably track and monitor the progress of the projects in your tech organization. This will enable the teams to communicate clearly the status of the projects to their stakeholders and to take corrective actions when needed.
Lacking a way to monitor and track the projects in your tech organization will significantly reduce its ability to deliver strategic programs and projects successfully.

{a5}
It is important that you’ve largely adopted a project management framework that allows you to easily and reliably track and monitor the progress of the projects in your tech organization. This enables the teams to communicate clearly the status of the projects to their stakeholders and to take corrective actions when needed.
Lacking a way to monitor and track the projects in your tech organization will significantly reduce its ability to deliver strategic programs and projects successfully, so make sure you continue to establish that practice in all the teams of your tech organization.

{a6}
It is important that you’ve largely adopted a project management framework that allows you to easily and reliably track and monitor the progress of the projects in your tech organization. This enables the teams to communicate clearly the status of the projects to their stakeholders and to take corrective actions when needed.
Lacking a way to monitor and track the projects in your tech organization will significantly reduce its ability to deliver strategic programs and projects successfully, so make sure you continue with the effort to maintain and improve that practice in all the teams of your tech organization.

{q6004} If a project in your tech organization is not on track, you can tell what the delay is, compared to the original plan, as well as how many resources you need to add and when, in order to catch-up the delay.

{r180} Project tracking and monitoring
{w3}

{a1}
A well-functioning project tracking and monitoring allows you to identify if a project is on track, as well as to plan corrective actions – for example reducing the scope or adding additional resources. You are strongly encouraged to implement a project tracking and monitoring process. Otherwise, the ability of your tech organization to successfully deliver projects will be at significant risk.

{a3}
A well-functioning project tracking and monitoring allows you to identify if a project is on track, as well as to plan corrective actions – for example reducing the scope or adding additional resources. You are strongly encouraged to implement a solid project tracking and monitoring process. Otherwise, the ability of your tech organization to successfully deliver projects will be at significant risk.

{a5}
A well-functioning project tracking and monitoring allows you to identify if a project is on track, as well as to plan corrective actions – for example reducing the scope or adding additional resources. Continue with your effort to implement a solid project tracking and monitoring process, which is applied for all projects. This will strengthen the ability of your tech organization to successfully deliver projects.

{a6}
A well-functioning project tracking and monitoring allows you to identify if a project is on track, as well as to plan corrective actions – for example reducing the scope or adding additional resources. Continue with your effort to keep a solid project tracking and monitoring process, which is applied for all projects. This strengthen immensely the ability of your tech organization to successfully deliver projects.

{q6005} You have a defined risk management practice which you apply in your projects.

{r220} Risk management
{w2}

{a1}
You don’t use risk management in your tech organization. While there are certain projects, for which risk management process is not necessary, it is important that you know for which projects and in which situations you should apply risk management, and how you should apply it. Keep in mind that any project state might change and start requiring a robust risk management. Triggers can be compliance related work upon tight deadlines in case of acquisition or merger, very tight market window in which certain project has to be delivered, very critical capability which is crucial for your overall product or service. It is better to develop the thinking process based on which to define if you need risk management for any of the projects in your tech organization, to what extent you must invest in it, and how this should be done. Also keep in mind that excessive focus on risk management is not the solution. Some projects bring inherently less risk than others and investing too much in risk management will lead to increased cost and delayed delivery for these projects, due to the additional risk mitigation and avoidance activities. Developing a risk process strategy will answer the question how much you should invest in risk management for any of the projects in your organization, in order to deliver maximum value to your customers.

{a3}
To a significant extent you don’t use risk management in your tech organization. While there are certain projects, for which risk management process is not necessary, it is important that you know for which projects and in which situations you should apply risk management, and how you should apply it. Keep in mind that any project state might change and start requiring a robust risk management. Triggers can be compliance related work upon tight deadlines in case of acquisition or merger, very tight market window in which certain project has to be delivered, very critical capability which is crucial for your overall product or service. It is better to develop the thinking process based on which to define if you need risk management for any of the projects in your tech organization, to what extent you must invest in it, and how this should be done. Also keep in mind that excessive focus on risk management is not the solution. Some projects bring inherently less risk than others and investing too much in risk management will lead to increased cost and delayed delivery for these projects, due to the additional risk mitigation and avoidance activities. Developing a risk management strategy will answer the question how much you should invest in risk management for any of the projects in your organization, in order to deliver maximum value to your customers.

{a5}
To a significant extent you have a defined risk management process which is adopted in the projects in your tech organization. While there are certain projects, for which risk management process is not necessary, it is important that you know for which projects and in which situations you should apply risk management, and how you should apply it. Your risk management strategy will help you in that. Keep in mind that any project state might change and start requiring a robust risk management. Triggers can be compliance related work upon tight deadlines in case of acquisition or merger, very tight market window in which certain project has to be delivered, very critical capability which is crucial for your overall product or service. It is good that you have started to develop the thinking process based on which to define if you need risk management for any of the projects in your tech organization, to what extent you must invest in it, and how this should be done. Continue with your effort to define risk management strategy for all projects in your tech organization.
Also keep in mind that excessive focus on risk management is not the solution. Some projects bring inherently less risk than others and investing too much in risk management will lead to increased cost and delayed delivery for these projects, due to the additional risk mitigation and avoidance activities. Developing a solid and robust risk management strategy will answer the question how much you should invest in risk management for any of the projects in your organization, in order to deliver maximum value to your customers.

{a6}
To a large extent you have a defined risk management process which is adopted in the projects in your tech organization. While there are certain projects, for which risk management process is not necessary, it is important that you know for which projects and in which situations you should apply risk management, and how you should apply it. Your risk management strategy will help you in that. Keep in mind that any project state might change and start requiring a robust risk management. Triggers can be compliance related work upon tight deadlines in case of acquisition or merger, very tight market window in which certain project has to be delivered, very critical capability which is crucial for your overall product or service. It is good that you have developed the thinking process based on which to define if you need risk management for any of the projects in your tech organization, to what extent you must invest in it, and how this should be done. Continue with your effort to apply risk management strategy for all projects in your tech organization.
Also keep in mind that excessive focus on risk management is not the solution. Some projects bring inherently less risk than others and investing too much in risk management will lead to increased cost and delayed delivery for these projects, due to the additional risk mitigation and avoidance activities. Maintaining a solid and robust risk management strategy will answer the question how much you should invest in risk management for any of the projects in your organization, in order to deliver maximum value to your customers.

{q6006} For your project management practice, you try to A) fix the scope and manage resources and time in order to deliver the defined scope, or B) fix the delivery timeline and manage the resources and the scope in order to meet the deadline or C) fix the resources and manage the timeline and scope in order to maximize the delivery within the available fixed resource. Answer with N/A if you don’t have a standard project management approach and each team has its own method.

{r170} Project management practice
{w2}

{aA}
The projects in your tech organization try to fix the scope and manage resources and time in order to deliver the defined scope. While the situation in your business domain might require such practice, you are encouraged to reconsider it critically. The business reality in many companies is that the scope is changing quite rapidly, based on market conditions, industry shift, competitors’ moves, availability to new technologies or resources, etc. All of these factors lead to continuous re-definition and re-prioritization of the scope. Analyze deeply your project management process and consider if you should not update it, so that it is more applicable for a fast-changing scope, rather than fixed scope and flexible resources or time.

{aB}
The projects in your tech organization try to fix the delivery timeline and manage the resources and the scope in order to meet their deadlines. This is quite often reality in many companies, which deal with fast changing scope and strict market deadlines. Keep in mind that in these conditions, it is very important that you focus on critically analyzing the efficiency of your projects, and how quickly they can adapt to new scope. This blog post can help you a lot for the first item: https://topstrengthener.com/2019/02/01/measuring-and-improving-the-productivity-of-your-tech-organization-in-its-transformation-journey/

{aC}
The projects in your tech organization try to fix the resources and manage scope and time.
Usually such practice is applied when project cost is the most critical aspect of your projects. While that might be the case for your business domain, you are encouraged to analyze if that practice needs improvement and possibly change. For example, for many business domains delivery in certain market windows is critical. In this case, the tech teams rather fix the time, and manage their resources and scope, in order to ensure delivery within the required market window. For other projects it is critical to deliver certain features to the market, so they rather manage their resources and deadlines, to ensure delivery of their features.
Analyze deeply your project management process and consider if you should not update it, to better suit the needs of your projects.

{aN/A}

{q6007} You have often complaints from the business that features and not delivered on time.

{r170} Project management practice
{w4}
{i}

{a1}
The fact that you almost don’t receive feedback from the business about delayed features delivery speaks a lot about the excellence of the project management practice in your tech organization. This is a signal that you’ve developed a process which ensures timely delivery and a good transparency towards the business. Tech organizations are the engine for product or service companies, so the timely delivery of features from your tech organization ensures that the company delivers its intended products or services to its customers. Keep up the good work!

{a3}
The fact that you rarely receive feedback from the business about delayed features delivery speaks a lot about the good project management practice in your tech organization. This is a signal that you are on your way to develop a process which ensures timely delivery and a good transparency towards the business. Tech organizations are the engine for product or service companies, so the timely delivery of features from your tech organization ensures that the company delivers its intended products or services to its customers. Continue with your focused effort to improve the project management practice of your tech organization, in order to further ensure timely delivery of features and minimize the complaints from the business about project delays.

{a5}
The fact that you often receive feedback from the business about delayed features delivery is a signal that you must significantly improve the project management practice in your tech organization, as well as the transparency towards the business and the rest of the company. Tech organizations are the engine for product or service companies. Missing to ensure timely delivery of features from your tech organization compromises the ability of your company to deliver the intended products or services to its customers. Also, it has an impact on almost any department within the company. The marketing teams need timely information about project deliveries, to align their market campaigns. Very often they deal with very strict market windows, for example because of business seasonality. If an e-commerce site doesn’t deliver its new features for the Christmas peak, it will have significant business impact. If a fitness application doesn’t have its new features ready for January, this will hurt the business significantly. This applies not only for the marketing teams, but any other team in the company.
Continue with your focused effort to improve the project management practice of your tech organization, in order to further ensure timely delivery of features and minimize the complaints from the business about project delays. This is a critical prerequisite in order to position the tech organization as a highly performing unit which brings critical positive impact to the company.

{a6}
The fact that you very often receive feedback from the business about delayed features delivery is a signal that you must significantly improve the project management practice in your tech organization, as well as the transparency towards the business and the rest of the company. Tech organizations are the engine for product or service companies. Missing to ensure timely delivery of features from your tech organization compromises the ability of your company to deliver the intended products or services to its customers. Also, it has an impact on almost any department within the company. The marketing teams need timely information about project deliveries, to align their market campaigns. Very often they deal with very strict market windows, for example because of business seasonality. If an e-commerce site doesn’t deliver its new features for the Christmas peak, it will have significant business impact. If a fitness application doesn’t have its new features ready for January, this will hurt the business significantly. This applies not only for the marketing teams, but any other team in the company.
Put a very strong effort to improve the project management practice of your tech organization, in order to ensure timely delivery of features and minimize the complaints from the business about project delays. This is a critical prerequisite in order to position the tech organization as a highly performing unit which brings critical positive impact to the company.

{c7} Quality

{q7001} Your tech organization has clear quality strategy – how much you should invest in quality and why.

{r200} Quality strategy
{w5}

{a1}
Quality must not be a self-goal. If you invest a lot in quality, the cost of your product or service will increase, as well as the time needed to release new features. If you don’t invest enough in quality, your clients might suffer, and as a result your business also. To avoid any of these undesired scenarios, you must create a quality strategy, which should answer important questions like how much the company should invest in quality, what are the types of the quality activities that must be applied, and at which stages of the product development lifecycle, etc.

{a3}
Quality must not be a self-goal. If you invest a lot in quality, the cost of your product or service will increase, as well as the time needed to release new features. If you don’t invest enough in quality, your clients might suffer, and as a result your business also. To avoid any of these undesired scenarios, you must create a good quality strategy, which should answer important questions like how much the company should invest in quality, what are the types of the quality activities that must be applied, and at which stages of the product development lifecycle, etc.

{a4}
To some extent you have a defined quality strategy. This is good, as quality must not be a self-goal. If you invest a lot in quality, the cost of your product or service will increase, as well as the time needed to release new features. If you don’t invest enough in quality, your clients might suffer, and as a result your business also. To avoid any of these undesired scenarios, continue your effort to establish a good quality strategy, which should answer important questions like how much the company should invest in quality, what are the types of the quality activities that must be applied, and at which stages of the product development lifecycle, etc.

{a5}
To some good extent you have a defined quality strategy. This is good, as quality must not be a self-goal. If you invest a lot in quality, the cost of your product or service will increase, as well as the time needed to release new features. If you don’t invest enough in quality, your clients might suffer, and as a result your business also. To avoid any of these undesired scenarios, continue your effort to establish a good quality strategy, which should answer important questions like how much the company should invest in quality, what are the types of the quality activities that must be applied, and at which stages of the product development lifecycle, etc.

{a6}
To a very large extent you have a defined quality strategy. This is great, as quality must not be a self-goal. If you invest a lot in quality, the cost of your product or service will increase, as well as the time needed to release new features. If you don’t invest enough in quality, your clients might suffer, and as a result your business also. To avoid any of these undesired scenarios, continue your effort to maintain a good quality strategy, which should answer important questions like how much the company should invest in quality, what are the types of the quality activities that must be applied, and at which stages of the product development lifecycle, etc.

{q7002} There is a clear link between the level of investment in quality from one side, and the Business Strategy and Product strategy of the company from the other.

{r200} Quality strategy
{w4}

{a1}
Some of the primary inputs which you should start making sure to guide your quality strategy are the business and product strategies. For example, some companies emphasize a lot on quality and reliability in their product or service offerings. It is important the tech organizations of such companies to reflect that in the quality strategy, by planning the necessary quality activities and processes.
For other companies, extensive quality is not part of the pillars of their business strategy canvas. Tech organizations in such companies should not plan extensive quality activities, as this will deteriorate the business performance of these companies.
One very important thing to note is that usually the business realities in the companies are very dynamic, and things might change overnight. For example, a new startup might come with innovative idea, for which the willingness to pay of the customers to be very high. As a result, they might be willing to accept some shortcomings in the quality of the product or service. In the near future though, many other companies might come up with similar products or services, and when that happens, usually clients become much more demanding in terms of quality. Not to mention that such increase in the demanded quality usually is combined with increased price sensitivity, as the increased competition often leads to lower prices. So, the tech organizations have the conflicting demands to increase the investment in quality, and at the same time to decrease the overall cost of the product or service. Because of such dynamic changes of the business environment, you must make sure that your tech organization frequently reviews and potentially updates its quality strategy, to reflect any changes in the business environment. As a first step you must make sure to ensure strong link between your quality strategy and the business and product strategies of your company.

{a3}
Some of the primary inputs which you should start making sure to guide your quality strategy are the business and product strategies. For example, some companies emphasize a lot on quality and reliability in their product or service offerings. It is important the tech organizations of such companies to reflect that in the quality strategy, by planning the necessary quality activities and processes.
For other companies, extensive quality is not part of the pillars of their business strategy canvas. Tech organizations in such companies should not plan extensive quality activities, as this will deteriorate the business performance of these companies.
One very important thing to note is that usually the business realities in the companies are very dynamic, and things might change overnight. For example, a new startup might come with innovative idea, for which the willingness to pay of the customers to be very high. As a result, they might be willing to accept some shortcomings in the quality of the product or service. In the near future though, many other companies might come up with similar products or services, and when that happens, usually clients become much more demanding in terms of quality. Not to mention that such increase in the demanded quality usually is combined with increased price sensitivity, as the increased competition often leads to lower prices. So, the tech organizations have the conflicting demands to increase the investment in quality, and at the same time to decrease the overall cost of the product or service. Because of such dynamic changes of the business environment, you must make sure that your tech organization frequently reviews and potentially updates its quality strategy, to reflect any changes in the business environment. As a first step you must make sure to ensure strong link between your quality strategy and the business and product strategies of your company.

{a5}
It is good that some of the primary inputs which guide your quality strategy are the business and product strategies. This is important, because for example some companies emphasize a lot on quality and reliability in their product or service offerings. As a result, the tech organizations of such companies must reflect that in the quality strategy, by planning the necessary quality activities and processes.
For other companies, extensive quality is not part of the pillars of their business strategy canvas. Tech organizations in such companies should not plan extensive quality activities, as this will deteriorate the business performance of these companies.
One very important thing to note is that usually the business realities in the companies are very dynamic, and things might change overnight. For example, a new startup might come with innovative idea, for which the willingness to pay of the customers to be very high. As a result, they might be willing to accept some shortcomings in the quality of the product or service. In the near future though, many other companies might come up with similar products or services, and when that happens, usually clients become much more demanding in terms of quality. Not to mention that such increase in the demanded quality usually is combined with increased price sensitivity, as the increased competition often leads to lower prices. So, the tech organizations have the conflicting demands to increase the investment in quality, and at the same time to decrease the overall cost of the product or service. Because of such dynamic changes of the business environment, you must make sure that your tech organization frequently reviews and potentially updates its quality strategy, to reflect any changes in the business environment. Also, you must continue with your effort to ensure strong link between your quality strategy and the business and product strategies of your company.

{a6}
It is great that some of the primary inputs which guide your quality strategy are the business and product strategies. This is important, because for example some companies emphasize a lot on quality and reliability in their product or service offerings. As a result, the tech organizations of such companies must reflect that in the quality strategy, by planning the necessary quality activities and processes.
For other companies, extensive quality is not part of the pillars of their business strategy canvas. Tech organizations in such companies should not plan extensive quality activities, as this will deteriorate the business performance of these companies.
One very important thing to note is that usually the business realities in the companies are very dynamic, and things might change overnight. For example, a new startup might come with innovative idea, for which the willingness to pay of the customers to be very high. As a result, they might be willing to accept some shortcomings in the quality of the product or service. In the near future though, many other companies might come up with similar products or services, and when that happens, usually clients become much more demanding in terms of quality. Not to mention that such increase in the demanded quality usually is combined with increased price sensitivity, as the increased competition often leads to lower prices. So, the tech organizations have the conflicting demands to increase the investment in quality, and at the same time to decrease the overall cost of the product or service. Because of such dynamic changes of the business environment, you must make sure that your tech organization frequently reviews and potentially updates its quality strategy, to reflect any changes in the business environment. Also, you must continue with your effort to maintain the strong link between your quality strategy and the business and product strategies of your company.

{q7003} In your functional testing, in addition to the positive testing, you have also negative tests.

{r190} Quality assurance maturity
{w2}

{a1}
Adding negative tests is a very easy and quick approach to strengthen the quality of your product or service. Very often quality activities cover primarily positive scenarios, which leaves significant risk for defects. Adding negative tests, in addition to your positive tests, will significantly mitigate that risk. You’re strongly encouraged to consider that option.

{a3}
Adding negative tests is a very easy and quick approach to strengthen the quality of your product or service. Very often quality activities cover primarily positive scenarios, which leaves significant risk for defects. Adding negative tests, in addition to your positive tests, will significantly mitigate that risk. You’re strongly encouraged to further strengthen that area.

{a5}
It is good that you have negative tests, as it is a very easy and quick approach to strengthen the quality of your product or service. Very often quality activities cover primarily positive scenarios, which leaves significant risk for defects. Having negative tests, in addition to your positive tests, significantly mitigates that risk for your product or service. Continue with your effort to further strengthen that area.

{a6}
It is great that you have negative tests, as it is a very easy and quick approach to strengthen the quality of your product or service. Very often quality activities cover primarily positive scenarios, which leaves significant risk for defects. Having negative tests, in addition to your positive tests, significantly mitigates that risk for your product or service. Continue with your effort to maintain that area.

{q7004} You have boundary testing.

{r190} Quality assurance maturity
{w1}

{a1}
Same goes for boundary testing, which is an easy and quick way to improve your quality. Also, boundary testing usually requires from your teams to rethink the feature requirements from new perspective, which is very useful for their deep understanding. Think about planning such tests as part of your quality activities.

{a3}
Same goes for boundary testing, which is an easy and quick way to improve your quality. Also, boundary testing usually requires from your teams to rethink the feature requirements from new perspective, which is very useful for their deep understanding. Think about planning such tests as part of your quality activities.

{a5}
Good that you are using boundary testing, which is another easy and quick way to improve your quality. Also, boundary testing usually requires from your teams to rethink the feature requirements from new perspective, which is very useful for their deep understanding.

{a6}
Great that you are extensively using boundary testing, which is another easy and quick way to improve your quality. Also, boundary testing usually requires from your teams to rethink the feature requirements from new perspective, which is very useful for their deep understanding.

{q7005} You are measuring the code coverage from the different types of automation tests that you have.

{r190} Quality assurance maturity
{w2}

{a1}
You are strongly encouraged to start measuring the code coverage of the automation tests that you have. This can give you a strong indicator how many of your functional flows are covered and which one, for every type of automation test that you have.

{a3}
You are encouraged to further adopt measuring the code coverage of the automation tests that you have. This can give you a strong indicator how many of your functional flows are covered and which one, for every type of automation test that you have.

{a5}
It is good that you’ve adopted measuring the code coverage of the automation tests that you have. This gives you a strong indicator how many of your functional flows are covered and which one, for every type of automation test that you have. Continue with your effort to fully adopt such measuring for all types of automation tests that you have.

{a6}
It is great that you’ve largely adopted measuring the code coverage of the automation tests that you have. This gives you a strong indicator how many of your functional flows are covered and which one, for every type of automation test that you have. Continue with your effort to maintain the measuring for all types of automation that you have.

{q7006} You do performance testing for every release or more frequently.

{r190} Quality assurance maturity
{w4}

{a1}
It is very desirable that you start doing performance testing of your product or service. Performance is one of the non-functional areas that frequently has very strong correlation with the business performance. If you have a web portal or mobile application that loads slowly, or that are slow to navigate through, this will impact significantly the business metrics of your company, even if you have a very good functional product.
Depending on your business strategy, you can implement a minimum solution, quick automatic performance testing and reporting for every release, or extensive performance testing suite and process. The performance testing itself can be relatively simple, for small applications, and quite complex for big B2B products for example. Make sure you align the investment in that area with your overall business and product strategy, but in all cases a quick automatic performance testing and reporting can have a significant positive impact on the business.

{a3}
You can further explore enhancing the performance testing of your product or service. Performance is one of the non-functional areas that frequently has very strong correlation with the business performance. If you have a web portal or mobile application that loads slowly, or that are slow to navigate through, this will impact significantly the business metrics of your company, even if you have a very good functional product.
Depending on your business strategy, you can implement a minimum solution, quick automatic performance testing and reporting for every release, or extensive performance testing suite and process. The performance testing itself can be relatively simple, for small applications, and quite complex for big B2B products for example. Make sure you align the investment in that area with your overall business and product strategy, but in all cases a quick automatic performance testing and reporting can have a significant positive impact on the business.

{a5}
It is good that you are investing proactively in performance testing of your product or service. You can further explore enhancing it, as performance is one of the non-functional areas that frequently has very strong correlation with the business performance. If you have a web portal or mobile application that loads slowly, or that are slow to navigate through, this will impact significantly the business metrics of your company, even if you have a very good functional product.
The performance testing itself can be relatively simple, for small applications, and quite complex for big B2B products for example. Make sure you align the investment in that area with your overall business and product strategy.

{a6}
It is good that you are investing proactively in performance testing of your product or service. Performance is one of the non-functional areas that frequently has very strong correlation with the business performance. If you have a web portal or mobile application that loads slowly, or that are slow to navigate through, this will impact significantly the business metrics of your company, even if you have a very good functional product.
The performance testing itself can be relatively simple, for small applications, and quite complex for big B2B products for example. Make sure you align the investment in that area with your overall business and product strategy.

{q7007} You do stress testing for every release or more frequently.

{r190} Quality assurance maturity
{w1}

{a1}
It is highly recommended that you start doing stress testing at least once per every 4-5 minor releases and once every major release.
Stress on your system can come from many directions – market seasonality, marketing campaigns, CRM campaigns, etc.
Usually tech teams test systems against a set of defined functional requirements. Adding stress testing can reveal major flows in your software system, which might have a very negative effect on the company during peaks of business operations. For example, if your software system is composed by many software modules or microservices, usually if only one service goes unavailable due to overload, this often leads to chain effect for the downstream services that call the one that goes off. This can quickly make your whole software system unavailable to serve any business transactions. Stress testing can quickly reveal such flaws, and this can enable your tech teams to strengthen your software system.

{a3}
It is highly recommended that you start doing more extensive stress testing, at least once per every 4-5 minor releases and once every major release.
Stress on your system can come from many directions – market seasonality, marketing campaigns, CRM campaigns, etc.
Usually tech teams test systems against a set of defined functional requirements. Adding stress testing can reveal major flows in your software system, which might have a very negative effect on the company during peaks of business operations. For example, if your software system is composed by many software modules or microservices, usually if only one service goes unavailable due to overload, this often leads to chain effect for the downstream services that call the one that goes off. This can quickly make your whole software system unavailable to serve any business transactions. Stress testing can quickly reveal such flaws, and this can enable your tech teams to strengthen your software system.

{a5}
It is good that are doing stress testing. It is recommended to do this at least once per every 4-5 minor releases and once every major release.
Stress on your system can come from many directions – market seasonality, marketing campaigns, CRM campaigns, etc.
Usually tech teams test systems against a set of defined functional requirements. Adding stress testing can reveal major flows in your software system, which might have a very negative effect on the company during peaks of business operations. For example, if your software system is composed by many software modules or microservices, usually if only one service goes unavailable due to overload, this often leads to chain effect for the downstream services that call the one that goes off. This can quickly make your whole software system unavailable to serve any business transactions. Stress testing can quickly reveal such flaws, and this can enable your tech teams to strengthen your software system. Continue with your effort to further enhance and adopt that practice.

{a6}
It is great that are doing stress testing. It is recommended to do this at least once per every 4-5 minor releases and once every major release.
Stress on your system can come from many directions – market seasonality, marketing campaigns, CRM campaigns, etc.
Usually tech teams test systems against a set of defined functional requirements. Adding stress testing can reveal major flows in your software system, which might have a very negative effect on the company during peaks of business operations. For example, if your software system is composed by many software modules or microservices, usually if only one service goes unavailable due to overload, this often leads to chain effect for the downstream services that call the one that goes off. This can quickly make your whole software system unavailable to serve any business transactions. Stress testing can quickly reveal such flaws, and this can enable your tech teams to strengthen your software system. Continue with your effort to further enhance that practice.

{q7008} You do security testing every quarter or more frequently.

{r190} Quality assurance maturity
{w2}

{a1}
It is strongly recommended that you enhance your security testing procedures. Security breaches are one of the problems that can cause the most damage on the company and can jeopardize the whole business.
It is not necessary to make extensive security testing – this might be very costly and in many cases is not even needed, because it might not add significant additional value. You can start with easy and quick security testing procedures and even simple security reviews, which will add significant value. But make sure that you periodically review and enhance your security testing procedures, where that is needed. Also, you can plan some quick and less costly security testing procedures to be executed more frequently, while others which are more expensive and lengthier, less frequently. For example, it is probably not needed to do penetration testing every release, so you can plan to do it once per year.
Make sure that you also analyze what part of the security testing should be done in-house, and for what part you’ll hire external help. In most of the cases it makes sense to execute the simple and quick security tests in-house. The more complex and lengthy security tests require deep expertise, and at the same time you don’t perform them so frequently. So, it might make sense to hire external companies for them, instead of building deep expertise in-house, which will be rarely used.

{a3}
It is recommended that you enhance your security testing procedures. Security breaches are one of the problems that can cause the most damage on the company and can jeopardize the whole business.
It is not necessary to make extensive security testing – this might be very costly and in many cases is not even needed, because it might not add significant additional value. You can start with easy and quick security testing procedures and even simple security reviews, which will add significant value. But make sure that you periodically review and enhance your security testing procedures, where that is needed. Also, you can plan some quick and less costly security testing procedures to be executed more frequently, while others which are more expensive and lengthier, less frequently. For example, it is probably not needed to do penetration testing every release, so you can plan to do it once per year.
Make sure that you also analyze what part of the security testing should be done in-house, and for what part you’ll hire external help. In most of the cases it makes sense to execute the simple and quick security tests in-house. The more complex and lengthy security tests require deep expertise, and at the same time you don’t perform them so frequently. So, it might make sense to hire external companies for them, instead of building deep expertise in-house, which will be rarely used.

{a5}
It is good that you are performing security testing, because security breaches are one of the problems that can cause the most damage on the company and can jeopardize the whole business.
Be careful that in many cases it is not necessary to make extensive security testing – this might be very costly and in many cases is not even needed, because it might not add significant additional value. Make sure that you periodically review and enhance your security testing procedures, where that is needed. You can plan some quick and less costly security testing procedures to be executed more frequently, while others which are more expensive and lengthier, less frequently. For example, it is probably not needed to do penetration testing every release, so you can plan to do it once per year.
Make sure that you also analyze what part of the security testing should be done in-house, and for what part you’ll hire external help. In most of the cases it makes sense to execute the simple and quick security tests in-house. The more complex and lengthy security tests require deep expertise, and at the same time you don’t perform them so frequently. So, it might make sense to hire external companies for them, instead of building deep expertise in-house, which will be rarely used.

{a6}
It is great that you are performing security testing, because security breaches are one of the problems that can cause the most damage on the company and can jeopardize the whole business.
Be careful that in many cases it is not necessary to make extensive security testing – this might be very costly and in many cases is not even needed, because it might not add significant additional value. Make sure that you periodically review and enhance your security testing procedures, where that is needed. You can plan some quick and less costly security testing procedures to be executed more frequently, while others which are more expensive and lengthier, less frequently. For example, it is probably not needed to do penetration testing every release, so you can plan to do it once per year.
Make sure that you also analyze what part of the security testing should be done in-house, and for what part you’ll hire external help. In most of the cases it makes sense to execute the simple and quick security tests in-house. The more complex and lengthy security tests require deep expertise, and at the same time you don’t perform them so frequently. So, it might make sense to hire external companies for them, instead of building deep expertise in-house, which will be rarely used.

{q7009} The business availability of your product or service is 99.99%

{r190} Quality assurance maturity
{w5}

{a4}
The availability of your product or service has a significant impact on the overall business. Downtimes, especially in peak times, might cause significant financial losses, both direct due to the downtime, and indirect, due to the lost trust of the customers.
Also, in many cases the availability of your product or service is a primary indicator how effective are your quality strategy, processes and activities. It is the ultimate result of your quality activities. If they are thorough and efficient, you’ll enjoy availability of 99.99% or better.
In all other cases of availability less than that, you must continue to invest in improving and enhancing your quality activities and processes. If it is significantly less than 99.99%, you must re-analyze your whole quality strategy. Probably you are missing some significant quality aspects, which need to be implemented in your tech organization.
You have to know that availability of less than 99.99% usually puts a lot of pressure on the tech organization from the business. If you don’t show significant improvement fast, the image of the tech organization will be of an ineffective one, an organization that cannot deliver the expected results to support the business of the company. This can result in lost trust, and big reorganizations of the tech team and particularly its leadership.
Also keep in mind that in fast growing businesses, you must invest in improving the availability continuously – it’s not a one-off effort. The reason is that the continuous growth of the business requires the software system to be also continuously enhanced and even re-architectured.

{a6}
The availability of your product or service has a significant impact on the overall business. Downtimes, especially in peak times, might cause significant financial losses, both direct due to the downtime, and indirect, due to the lost trust of the customers.
Also, in many cases the availability of your product or service is a primary indicator how effective are your quality strategy, processes and activities. It is the ultimate result of your quality activities. If they are thorough and efficient, you’ll enjoy availability of 99.99% or better.
In all other cases of availability less than that, you must continue to invest in improving and enhancing your quality activities and processes.
Also keep in mind that in fast growing businesses, you must invest in improving the availability continuously – it’s not a one-off effort. The reason is that the continuous growth of the business requires the software system to be also continuously enhanced and even re-architectured.

{q7010} What percentage is your regression testing before release, out of the total release time? For example, if you have a 3 weeks releases and your regression testing takes 1 week, indicate 33%

{r190} Quality assurance maturity
{w4}

{a10}
Your regression testing is less than 10% of the time of your release. This is good, as it increases the time in which you can implement new features during the release, and as a result increases the overall ability of your tech organization to deliver new features. If in future you detect that your release testing starts taking more time, for example as a result of adding more test cases or test activities, you must re-think your release testing approach and set as a priority to decrease that time. You can consider adding automation and decreasing the manual testing, as well as enhancing your regression testing approach. You can employ different techniques for that, for example, you might run lower priority test cases more rarely, or implement intelligent testing in which you test thoroughly only those parts of the application which are changed or impacted by the new release and do a more high-level quick testing of the rest of the application.
Make sure you implement the appropriate monitoring of that metric and keep your regression testing effort less than 10% of your overall release time.

{a29}
Your regression testing takes a significant time of your release. This decreases the time in which you can implement new features during the release, and as a result decreases the overall ability of your tech organization to deliver new features. You must re-think your release testing approach and set as a priority to decrease that time. You can consider adding automation and decreasing the manual testing, as well as enhancing your regression testing approach. You can employ different techniques for that, for example, you might run lower priority test cases more rarely, or implement intelligent testing in which you test thoroughly only those parts of the application which are changed or impacted by the new release and do a more high-level quick testing of the rest of the application.

{a30}
Your regression testing takes a significant time of your release. This decreases the time in which you can implement new features during the release, and as a result decreases the overall ability of your tech organization to deliver new features. You must re-think your release testing approach and set as a priority to decrease that time. You can consider adding automation and decreasing the manual testing, as well as enhancing your regression testing approach. You can employ different techniques for that, for example, you might run lower priority test cases more rarely, or implement intelligent testing in which you test thoroughly only those parts of the application which are changed or impacted by the new release and do a more high-level quick testing of the rest of the application.

{c8} Performance management and HR

{q8001} You have clearly defined and unified titles and/or grades in your tech organization.

{r120} Organizational maturity
{w5}

{a3}
You don’t have clearly defined and unified titles and/or grades in your tech organization. Having such is a foundational requirement for having meaningful career conversations with your employees. Without them it’s harder to ensure fairness during the performance management process and the promotion cycles. It also might confuse your employees regarding where they stand at the technical ladder as well as how their responsibilities differ from their colleagues which have a slightly different title. Unified grades clearly defines the opportunities for growth inside the organization thus lowering the risk of your employees to look for external opportunities. If your organization is above the 50+ people mark consider introducing a career path framework. If your organization is above the 100+ people mark consider it with urgency.

{a6}
You have clearly defined and unified titles and/or grades in your tech organization. This is a foundational requirement for having meaningful career conversations with your employees. Having clearly defined titles and grades is a major prerequisite in order to ensure fairness during the performance management process and the promotion cycles. This also gives a clear understanding for every employee regarding where they stand at the technical ladder, as well as how their responsibilities differ from their colleagues which have a different title. Unified grades clearly define the opportunities for growth inside the organization, thus lowering the risk of your employees to look for external opportunities.

{q8002} You have clearly defined competences for each of the titles and grades in your tech organization.

{r130} People process maturity
{w3}

{a1}
You have introduced titles and grades in your organization but there is no competencies defined per title or grade. It might even be the case that you still don’t have the titles and grades defined. While this is ok for very small organizations (less than 50 people) it’s a must have for every other organization. Not having a comprehensive competencies model could make the performance evaluation cycles and the promotion process long and tedious due to the need for many calibration sessions both horizontally and vertically organization wise. This problem becomes particularly visible in larger organizations. You might also see different outcomes from the different cycles e.g. an engineer was promoted in cycle 1 because of a particular achievement, while another engineer was not promoted in cycle 2 having the same achievement, because the promotion criteria was set differently due to increased volume of achievers in your organization. Such discrepancies might be perceived as an organizational unfairness by your engineers and could have negative consequences on your organization’s morale, motivation and attrition rate.

{a3}
You have introduced titles and grades in your organization but you have only very basic competencies defined per title or grade. Although better than none defined, there might be still room for interpretation regarding what’s needed for a promotion or how the performance is evaluated. It could potentially make the performance evaluation cycles long and tedious due to the need for many calibration sessions both horizontally and vertically organization wise. This problem becomes particularly visible in larger organizations. You might also see different outcomes from the different cycles e.g. an engineer was promoted in cycle 1 because of a particular achievement, while another engineer was not promoted in cycle 2 having the same achievement, because the promotion criteria was set differently due to increased volume of achievers in your organization for example. Such discrepancies might be perceived as an organizational unfairness by your engineers and could have negative consequences on your organization’s morale, motivation and attrition rate.

{a4}
You have introduced titles and grades in your organization, but you still don’t have very clearly defined competencies per title or grade. Although better than none defined, there might be still room for interpretation regarding what’s needed for a promotion or how the performance is evaluated. It could potentially make the performance evaluation cycles long and tedious due to the need for many calibration sessions both horizontally and vertically organization wise. This problem becomes particularly visible in larger organizations. You might also see different outcomes from the different cycles e.g. an engineer was promoted in cycle 1 because of a particular achievement, while another engineer was not promoted in cycle 2 having the same achievement, because the promotion criteria was set differently due to increased volume of achievers in your organization for example. Such discrepancies might be perceived as an organizational unfairness by your engineers and could have negative consequences on your organization’s morale, motivation and attrition rate.

{a6}
You have introduced titles and grades in your organization and you have a clear definition of competencies per title or grade. Everyone in your organization understands where they currently stands and what’s needed in order to progress to the next level. Great job! Your performance evaluation cycles and the promotion process quick and you need only vertical calibration sessions i.e. with your manager.

{q8003} You have a clearly defined and applied performance management framework.

{r130} People process maturity
{w4}

{a1}
There is no performance management framework defined yet and if you’re making performance assessment or promotions it’s on an ad-hoc basis. This is not sustainable and your employees might feel stagnation in their professional growth ultimately looking for opportunity outside of your company. While it works for young and small startups if your organization passed the 50+ employee mark it’s highly recommended to make the first steps in defining an official performance management framework. It will help you to consistently and predictably evaluate the growth of your employees, give them official recognition for their achievements and instill the feeling that they’re growing with the organization.

{a4}
There is a defined and applied performance management framework. You might even already had a few performance management cycles completed, continuously improving the process on the way. This is great and it’s a sign for a mature organization. Although there might be still challenges with not finishing on time, communication to the organization, setting the right expectations for everyone participating in the process, formulating the guidelines for the different activities during this complex exercise, not including the work on the performance management in the business and product plans for this time of the year, at the end of the day you’re making steady progress with each cycle and your employees are mostly happy with the results. A recommendation at this stage is over communicate, set the right expectations for the process and try as much as possible to ensure a fair outcome.

{a6}
There is a clearly defined and applied performance management framework. This is great, because it’s a fundamental prerequisite for rewarding high performance and instilling strong feeling of organizational fairness.

{q8004} Each employee in your tech organization has a professional development plan, which is supported by her manager.

{r130} People process maturity
{w2}

{a1}
No or very small percentage of the employees in the organization have a professional development plan supported by their manager. Employee growth or the perception of advancing in one’s career is directly correlated to the attrition rate and to the employee satisfaction and motivation. You have a higher risk of losing high performing employees shortly after they reach a year or two of tenure. In today’s highly competitive tech market and industry employees expect to see signs of professional growth at least once per year. In many cases that period is even shorter e.g. 6 months, especially for smaller organizations.

{a4}
Many managers in your organization are working on professional development plans with their team members. This usually results in motivated employees, especially your high achievers. Consider making a push and enforce this best practice throughout your entire organization. Not having professional development plan increases the risk of losing high performing employees shortly after they reach a year or two of tenure. In today’s highly competitive market and tech industry employees expect to see signs of professional growth at least once per year. In many cases that period is even shorter e.g. 6 months, especially for smaller organizations.

{a6}
Every employee in your organization has a professional development plan supported by their manager. This is great! It usually results in highly motivated and engaged employees, which want to stay in your organization because they like what the future holds for their careers. In today’s highly competitive market and tech industry employees expect to see signs of professional growth at least once per year. In many cases that period is even shorter e.g. 6 months, especially for smaller organizations. organization wise you also understand well which open positions needs to be filled with external talent and which positions could be filled with internal talent willing to grow.

{q8005} Each employee in your tech organization has regular 1:1 meetings.

{r130} People process maturity
{w5}

{a1}
No or very small percentage of the employees in the organization have regular 1:1 meetings. These meetings are very fundamental and give your employees personal and professional support, professional development plan, mentoring and coaching etc. They also provide benefits to your managers e.g. to get a deeper understanding of the team dynamics, understand and properly interpret various reasons for fluctuations in employee’s productivity, mentor and guide their teammates and so much more. There might be many reasons why there are no 1:1 meetings in your organization from not enough managers to not understanding the benefits of holding such meetings. In any case consider introducing them as a regular practice, it will certainly increase the maturity of your organization.

{a4}
Many employees in the organization have regular 1:1 meetings. This is great, keep pushing until everyone in the organization has them. These meetings are giving your employees a chance to have personal and professional support, professional development plan, mentoring and coaching etc. and at the same time your managers have a chance to get a deeper understanding of the team dynamics, understand and properly interpret various reasons for fluctuations in employee’s productivity, mentor and guide teammates and so much more. Take a deeper look at why there are still places missing them, maybe your people managers are overloaded and need additional support?

{a6}
Every or almost every employee in the organization have regular 1:1 meetings with their manager. This is great! These meetings are giving your employees a chance to have personal and professional support, professional development plan, mentoring and coaching etc. and at the same time your managers have a chance to get a deeper understanding of team dynamics, understand and properly interpret various reasons for fluctuations in employee’s productivity, mentor and guide their teammates and so much more. That is a sign for a mature organization and your employees certainly appreciate the personal attention they get from their managers.

{q8006} At least 30% of the time of the 1:1 meetings in your tech organization is spent on professional development and other non-operational topics.

{r130} People process maturity
{w2}

{a4}
1:1 meetings should not be purely operational meetings. The manager should be able to get all operational information from daily stand-ups, demos, occasional design discussion, general team communication in the room. 1:1 are great opportunity to learn more about the current level of motivation for your employees, team dynamics, understanding and properly interpreting various reasons for fluctuations in the employee’s productivity. At the same time the employee should have a chance to receive personal and professional support, professional development plan, mentoring and coaching and so much more. It’s recommended to keep healthy part of the meeting for non-operational topics.

{a6}
At least 30% of the time of the 1:1 meetings in your tech organization is spent on professional development and other non-operational topics. Keep it up. 1:1 meetings should not be purely operational meetings. They are also a great opportunity to learn more about the current level of motivation for your employees, team dynamics, understanding and properly interpreting various reasons for fluctuations in the employee’s productivity. At the same time the employee have a chance to receive personal and professional support, professional development plan, mentoring and coaching and so much more.

{q8007} When employees receive their performance evaluations, by far and large, they are not surprised by them.

{r130} People process maturity
{w3}

{a1}
When employees receive their performance evaluations, the results are by far and large unexpected. A possible reason for that might be if there are no clear guidelines on how the performance is measured or the guidelines are not clearly communicated to everyone involved in the process. It might also be the case that some employees are not self aware about their own performance which might be improved by more frequent feedback during 1:1s with the manager. Consider root causing the problem and take steps for improving it otherwise the risk of employee dissatisfaction and stress for both the employee and the manager is significantly increased.

{a4}
When employees receive their performance evaluations, sometimes the results are unexpected. A possible reason for that might be if there are no clear guidelines on how the performance is measured or the guidelines are not clearly communicated to everyone involved in the process. It might also be the case that some employees are not self aware about their own performance which might be improved by more frequent feedback during 1:1s with the manager. At this point the major problem for employees receiving unexpected results should be already identified and steps should be taken for improving it. Keep pushing in that direction, otherwise the risk of employee dissatisfaction and stress for both the employee and the manager for your organization is increased.

{a6}
When employees receive their performance evaluations, by far and large, they are not surprised by them. This means that there are clear guidelines for the performance management on an organizational level, which are properly propagated to everyone in the organization. Your managers are well trained in setting expectations which results in high employee satisfaction and a smooth and easy communication for both the employee and their manager.

{q8008} You are regularly tracking the NPS of your tech organization.

{r110} Organizational health
{w2}

{a1}
You are not regularly tracking the NPS of your tech organization. You might be missing on a valuable insight about your workforce health. Consider start tracking such data as it will provide your management team with early signs if the team morale is going down which might result in an increased attrition rate or a decreased performance output. Another benefit is that the data collection for such metrics is usually anonymously gathered thus allowing people to state an opinion they wouldn’t do otherwise.

{a3}
You are rarely tracking the NPS of your tech organization. Measuring your workforce health is an invaluable tool at your disposal. It helps your management team and especially top level management to keep track of what is the team morale on every level of the organization and take preventive actions if there is a need. Keep in mind that the more data points you have the better you will understand your organization and the faster you can react to a change. If the measurement period is that long your results might be affected by recency bias. Could you measure more often?

{a5}
You are tracking the NPS of your tech organization relatively regularly. Measuring your workforce health is an invaluable tool at your disposal. It helps your management team and especially top level management to keep track of what is the team morale on every level of the organization and take preventive actions if there is a need. Keep in mind that the more data points you have the better you will understand your organization and the faster you can react to a change. Could you measure more often?

{a6}
You are tracking the NPS of your tech organization regularly. Measuring your workforce health is an invaluable tool at your disposal. It helps your management team and especially top level management to keep track of what is the team morale on every level of the organization and take preventive actions if there is a need. Keep it up.

{q8009} You are regularly surveying your tech organization for potential problems and improvements.

{r110} Organizational health
{w4}

{a1}
You are not regularly surveying your tech organization for potential problems and improvements. It might prevent you from getting to know about potential problems and improvements in your tech organization. Such surveys are also providing valuable insights about your workforce health and at the same time a great source of new ideas and improvements for your product and business. If you give your team the option to anonymously provide input, it might actually help people to open up and share problems that they wouldn’t share otherwise. It’s just too good tool to miss also.

{a3}
You are rarely surveying your tech organization for potential problems and improvements. These surveys gives you the advantage of a deeper understanding of your tech organization and having an early signs for potential problems and improvements. Your management team must be aware of many of the toughest issues that your employees are currently facing and also have a good idea what the employees would like to see implemented in future. Hopefully you regularly follow up on both the potential problems and opportunities for improvements. Keep in mind that the more data points you have, the better you will understand your organization and the faster you can react to a change. If the measurement period is that long your result might be affected by a recency bias. Could you survey more often?

{a5}
You are regularly surveying your tech organization for potential problems and improvements. This gives you the advantage of a deeper understanding of your tech organization and having an early signs for potential problems and improvements. Your management team must be well aware of many of the toughest issues that your employees are currently facing and also have a good idea what the employees would like to see implemented in future. Hopefully you regularly follow up on both the potential problems and opportunities for improvements. Keep in mind that the more data points you have, the better you will understand your organization and the faster you can react to a change. Could you survey more often?

{a6}
Keep regularly surveying your tech organization for potential problems and improvements. This gives you the advantage of a deeper understanding of your tech organization and having an early signs for potential problems and improvements. Your management team must be pretty well aware of many of the toughest issues that your employees are currently facing and also have a good idea what the employees would like to see implemented in future.

{q8010} You always follow up based on the findings from the surveys.

{r110} Organizational health
{w5}

{a1}
You don’t follow up based on the findings from the surveys or you’re having no surveys at all. Having a regular and official follow up based on the findings from the surveys is important in building trust with your organization. Not following up exposes you at the risk of people stop providing feedback at all and this in turn will prevent you from having a valuable and diverse insights. In some organizations, it also might be the case that there are too many surveys going out at the same time, leaving your management with no time to react to every single one of them.

{a4}
You follow up based on the findings from the surveys more often than not and this is a serious step towards maturity in the organizational health area. Having a regular and official follow up based on the findings from the surveys is very important. Chances are high that to a significant extent your employees find the organization trustworthy and in most of the cases are happy to provide you with valuable and diverse insights. Keep in mind though that not following up exposes you at the risk of people stop providing feedback at all. If you have such cases, maybe you could survey a bit less, but always follow up?

{a6}
You always follow up based on the findings from the surveys and this is great as it shows organizational maturity. Having a regular and official follow up based on the findings from the surveys is very important. Your employees finds the organization trustworthy and are always happy to provide you with valuable and diverse insights. Keep it up! On a side note that even if you always follow up if there are too many surveys going out at the same time this might lead to a “survey fatigue” i.e. even if you always follow up people might not always respond. If you find yourself in such situation reduce the amount of the surveys to the most important ones.

{q8011} There is an anonymous communication channel created by HR where people can escalate and raise HR related problems, also anonymously.

{r120} Organizational maturity
{w2}

{a1}
There is no anonymous communication channel created by HR where people can escalate and raise HR related problems. Sometimes there are problems that are ignored or can’t be solved by the manager or their superior. Even worse there are problems that are too sensitive to share or sharing them might even provoke retaliation. Examples of such are fraud, sexual harassment, discrimination, workplace bullying and many others. Employees with such problems might feel trapped by the inability to share them and eventually leave your company. Having a system where employees can anonymously communicate directly with HR or top level management could potentially prevent you from losing loyal employees and even avoid lawsuits. It also provides another way of HR and top level management to have a reliable insights of the workforce health. Consider creating such anonymous channel that goes directly to HR. This will reduce your risk regarding the proper handling of all of the examples listed above.

{a3}
There is an anonymous communication channel created by HR where people can escalate and raise HR related problems, but it’s not regularly used. Having a system where employees can anonymously communicate directly with HR or top level management is great! There might be multiple reasons why people don’t use it, for example they’re not convinced in their anonymity, previous experience didn’t led to follow up and results, there is insufficient communication in the organization about the existence of this channel and many more. Investigate why this is the case and fix it. It will help you detecting and dealing with a large set of issues examples of such are fraud, sexual harassment, discrimination, workplace bullying and many others. Employees with such problems might feel trapped by the inability to share them and eventually leave your company. Your system is a good way of HR and top level management to have a reliable insights of the workforce health. Of course if your NPS score is very high there is always the possibility that everything in the company is perfect, managers are good in resolving everyone’s problems and people just don’t need the channel. It’s advisable to keep it up though, just in case.

{a6}
Having a system where employees can anonymously communicate directly with HR or top level management is great! It helps you detecting and dealing with a large set of issues. Examples of such are fraud, sexual harassment, discrimination, workplace bullying and many others. It’s also a good way of HR and top level management to have a reliable insights of the workforce health. Moreover if it’s regularly used, this means that the employees trust it and you’re following up on every reported problem. You’ve done a great job, keep it up!

{q8012} An HR strategy for inclusion and diversity exists and is applied across the tech organization.

{r120} Organizational maturity
{w3}

{a1}
An HR strategy for inclusion and diversity doesn’t exist or is not applied across the tech organization.While strategy document per se might not be required for small startups, equality and diversity is relevant for all workplaces regardless of their size. It is important to ensure that everyone has access to the same opportunities and experiences the same, fair treatment. Consider to take a stand, develop a strategy and communicate it with everyone in an effort to uncover unconscious biases and set the standards for expected behavior.

{a4}
An HR strategy for inclusion and diversity exists, but is not widely applied across the tech organization.There might be areas which are too unbalanced from diversity perspective. If that is the case, the fact that your organization explicitly took a stand, developed a strategy and communicated it with everyone in an effort to uncover unconscious biases and set the standards for expected behavior, speaks good for its maturity and the general direction it’s heading to.

{a6}
An HR strategy for inclusion and diversity exists and is applied across the tech organization.The organization is by far and large balanced from diversity perspective. The prevalent culture in your organization is a culture of inclusion where everyone has access to the same opportunities and the same, fair treatment. The fact that your organization explicitly took a stand, developed a strategy and communicated it with everyone in an effort to uncover unconscious biases and set the standards for expected behavior, speaks good for its maturity and the general direction it’s heading to.

{c9} Innovation

{q9001} In your tech organization, you have a defined and applied process for innovation.

{r70} Innovation strategy
{w3}

{a1}
You don’t have a well defined and applied process for innovation. Innovation might still happen in the company, but as you lack a well defined process, engineers and managers might find it harder to justify the time spent exploring new ideas, especially if they turn out not to be successful. It’s time to decide what is your policy regarding innovation. There are multiple different options regarding how to nurture innovation in your tech organization, how people contribute to it, how to measure success, how to productise good ideas, how to carry out communication on this particular topic etc. In any case a defined and applied process, even if it just states that at this stage of your journey you focus on execution instead of innovation, will make the decision easier next time when someone in your organization would like to pursue an innovative idea.

{a4}
You have established rules around innovation and you can see innovative ideas explored in your organization. However something is still missing, it might be not enough ideas coming from the engineers, not enough time per engineer to validate the idea, no organised way to track and follow up innovative ideas, no clear path from verified idea to productization or other reasons. Consider strengthening the process and/or communicating it better to your organization. Maybe you didn’t dedicate enough workforce orchestrating the process? You’ve already made the choice to invest in innovation, it’s a matter of time and a bit of organizational effort to see the fruits of it.

{a6}
You have a defined and applied process for innovation that is working for your organization. Everyone in the organization clearly understand how innovation functions in your organization and there is no confusion in engineers and managers how to approach new ideas. Great achievement! Both your tech organization and your business are in a better place today because the results of it.

{q9002} Every employee in your tech organization knows how they can contribute to the innovation effort.

{r60} Innovation process
{w3}

{a0}
You don’t have an innovation process in place or it is not a priority for you at this stage. Innovation might still happen in the company, but due to the no defined official rules engineers and managers might find it harder to justify the time spent exploring new ideas especially if they turn out unsuccessful.

{a4}
Not every employee in your tech organization knows how they can contribute to the innovation effort. This might be due to many different reasons, for example, the strategy is not well defined, communication is not clear, the process is still maturing, not every employee is allowed to contribute to the innovation effort and many more. It’s very positive however that there is some innovation process in place, it’s working and probably you’re already seeing the results of it. Keep pushing the communication and keep refining your process.

{a6}
Every employee in your tech organization knows how they can contribute to the innovation effort. Your communication strategy is working well and your process is mature enough and easy to follow. Giving everyone a chance to contribute to the innovation in the company has the additional added benefit of diversification of the new ideas that are flowing in.

{q9003} In your tech organization, every employee can contribute to the innovation effort.

{r60} Innovation process
{w5}

{a0}
You don’t have official innovation process in place or it is not a priority for you at this stage. Innovation might still happen in the company, but due to the no defined official rules engineers and managers might find it harder to justify the time spent exploring new ideas especially if they turn unsuccessful.

{a4}
Not every employee in your tech organization can contribute to innovation effort. Keep in mind that innovation might come from unexpected sources. Limiting it to only a predefined group of people will hinder the diversity of ideas and might lead to missed opportunities. If you don’t give a chance for everyone to participate in the process there is a risk that your innovation department might be considered highly desirable and fun to work in thus making your other departments less attractive to engineering.

{a6}
Every employee in your tech organization can contribute to innovation effort. This is great. Innovation might come from unexpected sources and letting everyone to contribute also diversifies the new ideas. It is also a way of thinking, so keeping everyone engaged or at least giving everyone a chance to be engaged might potentially lead to more innovative ideas for exploration and verification in the long run.

{q9004} List the percentage of the total capacity, that is spent on average by the members of the tech organization on innovation.

{r70} Innovation strategy
{w5}

{a0}
You don’t have official innovation process in place or it is not a priority for you at this stage. Innovation might still happen in the company, but due to the no defined official rules engineers and managers might find it harder to justify the time spent exploring new ideas especially if they turn unsuccessful.

{aN/M????}
You have innovation process in place that is working and probably feeding your engineering, product and business with fresh new ideas. Measuring always helps making better decision e.g. how do you know if your tech organization is investing enough time in innovation? Without this knowledge it’s hard to decide where to focus your effort – encouraging your team to innovate more, improving the validation of the new ideas, improving the productization process etc.

{a1}
You have innovation process in place that is working and feeding your engineering, product and business with fresh new ideas. You are also measuring the total capacity of your engineering spend on average on innovation.You are in a great spot to make informed decisions on your innovation investments.

{c10} Data

{q10001} The product managers in your tech organization are actively using input from Data Analyst when defining the product features.

{r30} Data driven organization
{w4}

{a1}
The Product Managers in your tech organization are not actively using input from Data Analyst when defining the product features. This might be due to lack of resources, lack of data driven culture, lack of the required tooling around data, lack of data professionals, or your company might be still small and this role is performed by other employees, for example the Product Managers themselves. Important questions are:
● how you product team prioritises one feature over another? Is there an objective way of justifying a decision or it’s mostly subjective?
● How objectively you evaluate the results of product experiments, testing market hypothesis?

{a4}
Many of the product managers in your tech organization are actively using input from Data Analyst when defining the product features. What is the reason the rest of your product team is not using such input? Is it due to a lack of data professionals, you’re still beginning your data journey, not everyone believes in data, tooling is hard to use or other reasons? Keep pushing for a more data driven culture. Keep showcasing and promoting results based on data driven decisions. Your business, product and engineering will thank you one day.

{a6}
Product managers in your tech organization are actively using input from Data Analyst when defining the product features. This is great. Your product decisions are data driven, justifiable and by a big extend more accurate than those taken using subjective measures. You’ve completed at least your initial data infrastructure. Keep pushing in that direction and if you’re still not, consider opening data and the related tooling to every member of your organization.

{q10002} List how many unique product experiments are you running per month per team.

{r30} Data driven organization
{w5}

{a0}
You are not running experiments as part of your production deployment process or you are not pushing product changes to production every month. In the later case you are probably delaying customer feedback regarding how your new ideas are accepted and used. There are a couple of risks involved if you are not running experiments in production, but just enabling to all your clients. From quality perspective if the new functionality has issues all customers will be affected. From product perspective you might be limiting your understanding of the customer impact your new feature has made, because the impact might be hidden behind other releases which happened at the same time or because of pure external factor/market conditions.

{a2}
You are releasing new content at least once per month and you are measuring the impact it makes to your customers. This lets you both control better your product quality and have a rapid feedback on how your clients accepts and interacts with the new functionality. It also helps you iterate faster and make quicker and better decisions for your product. Consider increasing the number of unique product experiments in production. If possible, it will let you react quicker to the dynamic market conditions.

{a3}
You are frequently releasing new content and you are measuring the impact it makes to your customers. This lets you both control better your product quality and have a rapid feedback on how your clients accept and interact with the new functionality. It also helps you iterate faster and make quicker and better decisions for your product.

{q10003} Every employee in your tech organization can design and run an experiment.

{r30} Data driven organization
{w6}

{a1}
Almost no one in your tech organization can design and run experiments. Enabling your employees to design and run experiments can significantly shorten the product cycle, from ideation to market release. Some companies are concerned that such democratization might lead to chaos and product conflicts, and these are absolutely valid concerns. To avoid such problems, your experimentation process should be automated, with the corresponding rules and policies integrated within the automation.
Restricting the experimentation only to limited people has a lot of drawbacks:
● Limited number of experiments that these people can run, in comparison with the number of experiments that the broader tech team can run.
● Designing and running and experiment, evaluating the results and improving the product, is an activity which strongly boosts a behaviour of ownership and deep understanding of the customer needs. You definitely want to see your tech organization having these.
● Every domain team has the best knowledge of its customers and is in the best position to come up with hypotheses that need to be tested. A central team can hardly have such deep insights for every domain, especially as your company is growing.
● If your team members cannot design and run experiments, most probably many great ideas, born within the teams, are dying, because the team members don’t have quick way to validate them, and they might be reluctant to engage with external teams, as this will require more effort and communication overhead.

{a4}
Many employees in your tech organization can design and run experiments, but data and tooling is still not available for everyone. This is a great step forward for becoming a truly data driven organization. Don’t stop making your data more accessible and your tooling more widely applicable. At the same time make sure that everyone that can already use the data and tooling is actively doing it. Your business decisions, product experience and code releases will become even better.

{a6}
Every employee in your tech organization can design and run experiment. This is a great step forward for becoming a truly data driven organization. Your next step should be making sure that everyone is using this capabilities. Your business decisions, product experience and code releases will become even better.

{q10004} Employees in different functions (QA, dev, product, etc.) actively design and run experiments.

{r30} Data driven organization
{w3}

{a1}
None or only single function in your tech organization actively designs and run experiments. This might be due to many different reasons, for example not everyone is trained to work with data, relevant data is confidential or not otherwise accessible to every function, tooling is not sufficiently covering all use cases or others. Designing a running experiments is an important prerequisite for a data driven organization. If you prefer to make your choices in every function based on data instead of using more subjective measures, consider applying what you already have in terms of data strategy broadly in your tech organization. One option is making data and experiments entirely a self service capability. If you don’t have a data strategy yet, consider investing into it sooner than later.

{a4}
Many functions in your tech organization actively design and run experiments, but still there are some that use more subjective measures to take decisions. This might be due to many different reasons, for example not everyone is trained to work with data, relevant data is confidential or not otherwise accessible to every function, tooling is not sufficiently covering all use cases or others. It’s great that you’re already on your way to being a fully data driven organization. Consider applying what you already have in terms of data strategy broadly in your tech organization.

{a6}
Every function in your tech organization actively design and run experiments. This is great, you are steadily on your way or even already a fully data driven organization. Making objective decisions based on data has many long term benefits compared to taking decisions based on more subjective criteria.

{q10005} Any member of the tech organization can design and run an experiment in less than 1 day.

{r30} Data driven organization
{w2}

{a1}
People who design and run experiments cannot do it easily. This might be due to many different reasons e.g. no data tooling, data tooling not tightly integrated with the development and release process, business data is not accessible to everyone in the organization or others. In any case this might hinder your ability to run experiments in production – the longer it takes to design and run them, the less enthusiastic will be people to do it. Consider analysing the workflow of introducing a new experiment and finding the bottle necks.

{a4}
Members of the tech organization easily do design and run experiments. However in many cases it takes longer than one day to execute the process. This might be due to many different reasons e.g. data tooling not tightly integrated with the development and release process, business data is not accessible to everyone in the organization or others. It is great that you have the tooling and flexibility in place to design and run experiments. Keep in mind that sometimes the slowness or limitation of the process might make people less enthusiastic about using it which might lead to skipping an important step in your release process or introducing cross cutting release delays which is expensive. Consider analysing the workflow of introducing a new experiment and finding the bottle necks.

{a6}
Every member of the tech organization can design and run experiments in less than a day and most probably it is becoming or has already become a regular part of your release process. This is great! It allows you to control better the quality of your product, receive quick and valuable feedback from your customers and to be data driven in every decision you take regarding your product and software architecture.

{c11} IT Infrastructure and DevOps

{q11001} You have a defined strategy for monitoring and alerting of your IT infrastructure.

{r90} Operational maturity
{w6}

{a1}
There is no strategy in place for monitoring and alerting of your IT infrastructure. Downtime or critical disruptions of your services are usually reported to you by your customers. This is a reactive mode of operation and might be attributed to a bad user experience. Consider investing in monitoring and alerting solution that will allow you to proactively react to system disruptions thus minimizing the exposure of your users to such events.

{a4}
There is a strategy in place for monitoring and alerting of your IT infrastructure, but there are still many places in your organization where the rules are not followed yet. Having the strategy in place is a great step forward to a more proactive identification of a system downtime and faster incident management. However still, due to not enough monitoring and alerting coverage sometimes downtime or critical disruptions of your services might be reported to you directly by your customers. Set as a priority to further strengthen your strategy for monitoring and alerting of your IT infrastructure, and communicating it often within your engineering departments.

{a6}
There is a strategy in place for monitoring and alerting of your IT infrastructure and most of your infrastructure is already covered. This is a great step forward towards a proactive system downtime identification and better and faster incident management. At this stage there should be rarely cases where customers report problems that you were not aware of. This will improve your customer experience as you can be proactive in your communication and set expectations, always being one step ahead.

{q11002} You have a defined infrastructure architecture, e.g. network topology, storage, etc.

{r80} IT Architecture
{w3}

{a1}
You don’t have a defined infrastructure architecture, e.g. network topology, storage, etc. It currently either all in the heads of your devops and infra engineers or even some knowledge might be already. There is certainly little or no documentation in place. This is leaving you with a system that people are afraid to modify. Consider acquiring and structuring that documentation. It’s a very important input for every major technological decision or assessment that you will be making in the future.

{a4}
A defined infrastructure architecture exists, e.g. network topology, storage, etc. but there are still some missing sections or it’s not detailed enough. This is a great step forward to fully understanding your system, as well as being able to quickly onboard engineers onto it. Consider defining how much documentation is enough and at which abstraction layer. This will allow you to make better architectural decisions or infra assessments going forward. Creating a routine for regular updating of the existing documentation will keep it fresh and accurate.

{a6}
A defined infrastructure architecture exists, e.g. network topology, storage, etc. and there are no major missing sections. The level of detail is sufficient to allow non system engineers or new hires to quickly understand the infrastructure landscape. This is a great step forward to fully understanding your system as well as being able to quickly onboard engineers onto it. It also allows you to make well informed architectural decisions or infra assessments going forward. Creating a routine for regular updating the documentation will keep it fresh and accurate.

{q11003} Your production environment are created automatically (that includes: service deployments; resource provisioning e.g. databases, message queues, caches etc.; networking, vpn provisioning, DNS configurations, certificate management; initialisations and configurations of the environment, secret management etc.).

{r90} Operational maturity
{w5}

{a1}
Large portions of your production environment are created manually. This might work well for a very small startups, but once you grow past a single service and a single engineering team, it will become harder and harder to keep track of all the changes that are happening in your production environments. One major risk here is that you might be unable to recreate your production environment in case of urgency, which in turn could affect your business negatively. Keep your eye on and try to prevent cases were key infrastructural knowledge is held by a single person or a small team. This doesn’t scale well and will introduce bottlenecks in your processes. Focus your attention on automating your deployments and standardising your infrastructure management.

{a3}
Part of your production environment is automatically created, but there are still many portions where people do manual deployments or configurations. There is still a high risk that you might be unable to recreate your production environment in case of urgency, which in turn could affect your business negatively. Keep pushing for the automation and standardization of your infrastructure management. Make sure that your team is trained how to use the available tooling to automate their deployments and that knowledge is not siloed in a single person or a team.

{a4}
Majority of your production environment is automatically created, but there are still portions where people do manual deployments or configurations. There is still a high risk that you might be unable to recreate your production environment in case of urgency, which in turn could affect your business negatively. Keep pushing for the automation and standardization of your infrastructure management. Make sure that your team is trained how to use the available tooling to automate their deployments and that knowledge is not siloed in a single person or a team.

{a6}
Your production environment is fully automatically created. You should be able to recreate your production environment in a reliable and repeatable manner which will be very helpful if you have to do it in a case of urgency and high need. Make sure that your team is trained how to use the available tooling to automate their new deployments and avoid focusing that knowledge in a single person or a team.

{q11004} Your teams can create and use test environments which are an exact copy of your production environments.

{r90} Operational maturity
{w4}

{a1}
Your teams can’t create and use test environments, which are an exact copy of your production environment. While this could be ok for some businesses, having the capability to replicate your production systems and data in many cases proves to be immensely helpful for ensuring the quality of your product. It unlocks many different types of testing like system, load, performance, fault injection etc. which are very hard or impossible to achieve otherwise. If your business will benefit from these types of testing, identify the reason that is preventing you from being able to replicate your production systems (e.g. lack of automation) and work towards fixing it.

{a4}
Your teams can create and use test environments, which are similar to your production environment, but not a full replica. This is a good start and depending on the business it might be all you need in that area. You should be able to execute testing like system, load, performance, fault injection etc. on environments very similar to your production one. Make sure that your teams use this capability in its full potential.

{a6}
Your teams can create and use test environments which are an exact copy of your production environment. This is great! It unlocks many different types of testing like system, load, performance, fault injection etc. which are very hard or impossible to achieve otherwise. Make sure that your teams use this hard to achieve capability to the best possible extent.

{q11005} You have a strategy in place for monitoring and optimising your IT costs.

{r90} Operational maturity
{w2}

{a1}
You’re not actively monitoring your IT costs. This might be ok for small businesses, but as you grow bigger it could become a problem. It’s important to understand where the costs are coming from and how to optimise them in the long run. The more the strategy around monitoring and cost optimisation is delayed the harder it gets to define one and put it into action. Cost optimisation should be part of the organization culture and the smaller the organization, the easier it is to ingrain it. Don’t wait until you have to deal with cost cuts.

{a4}
You’re actively monitoring your IT costs and can differentiate between essential and not essential costs. There might be however no holistic strategy how to optimise costs in the long run.
This is a good first step, however the more the strategy around monitoring and cost optimisation is delayed, the harder it gets to define one and put it into action, especially in scaling tech organizations.
Cost optimisation should be part of the organization culture and the smaller the organization, the easier it is to ingrain it. Keep educating your team how to differentiate important from unimportant costs, and the importance of being mindful with the company resources.

{a6}
You’re actively monitoring your IT costs and can differentiate between essential and not essential costs. There is strategy in place how to optimise costs in the long run and everyone in the organization understands it and follows it. Being mindful about the company resources and not using more than needed is part of the culture and is a sign of a mature organization.

{q11006} You know well the scalability limits of your IT infrastructure.

{r80} IT Architecture
{w3}

{a1}
You don’t know the scalability limits of your infrastructure. This is ok for small businesses with low to medium growth, but the faster your business grows, the more aware you should be of these limits. This is essential strategic knowledge, as usually scalability is a product of the architecture and architectural changes are slow to implement. If there are foreseeable scalability problems, it’s good to know them well in advance. If you are a fast growing business, it’s highly advisable to invest some effort into figuring out how long your current architecture will hold until you hit scalability problems.

{a4}
You know the scalability limits of parts of your infrastructure, but there are still unknown areas. This is great if you’ve found out the less scalable parts of your systems as these often needs the attention first. Knowing your scalability limits is essential strategic knowledge as usually scalability is a product of the architecture and architectural changes are slow to implement. If however you’re unsure and there might be unknown areas with less capabilities to scale it’s worth the effort to find them out. The chain is as strong as its weakest link. In any case if you still don’t have a plan in place how to deal with these limits it’s highly advisable to iron it out especially if you’re a fast growing business.

{a6}
You know very well the scalability limits of your infrastructure and might even already have a plan how to address those needs in a timely manner. This is great! Knowing your scalability limits is essential strategic knowledge as usually scalability is a product of the architecture and architectural changes are slow to implement. If you still don’t have the plan in place how to deal with these limits it’s highly advisable to iron it out especially if you’re a fast growing business. The risk of not addressing those issues on time is that your developers might keep piling on top of the not scalable components and make their refactoring later on a harder process.

{q11007} You monitor and track the reliability of your IT infrastructure.

{r90} Operational maturity
{w5}

{a1}
You don’t actively monitor or track the reliability of your IT infrastructure. In today’s world all customers expect the service to be up and running 24/7 and anything less than that puts your business at a high risk of customer churn. Production issues and downtime are part of the game and part of being agile, but the speed of detection and recovery is essential in these cases. Setting up a reliable IT infrastructure monitoring is not a simple process, especially when your business is rapidly growing, so starting early is a good option.

{a4}
You actively monitor and track the reliability of parts of your IT infrastructure. This is a great start especially if you’re already monitoring your most business critical services. In today’s world all customers expect the service to be up and running 24/7 and anything less than that puts your business at a high risk of customer churn. Production issues and downtime are part of the game and part of being agile, but the speed of detection and recovery is essential in these cases. Setting up a reliable IT infrastructure monitoring is not a simple process, especially when your business is rapidly growing, so starting early is a good choice. Keep pushing and measuring key KPIs like availability, reliability and uptime.

{a6}
You actively monitor and track the reliability of your entire IT infrastructure. This is a great! In today’s world all customers expect the service to be up and running 24/7 and anything less than that puts your business at a high risk of customer churn. Production issues and downtime are part of the game and part of being agile, but the speed of detection and recovery is essential in these cases. Setting up a reliable IT infrastructure monitoring is not a simple process, especially when your business is rapidly growing, so starting early is a good choice. Keep pushing and measuring key KPIs like availability, reliability and uptime.

{q11008} You have fully automated bullet proof process to automatically deploy new code in production. It takes a few minutes for a newcomer to successfully deploy to production.

{r90} Operational maturity
{w5}

{a1}
Your production deployment process is relatively complex and not that bullet proof. You might not even have a unified process and there are certainly ways in which a newcomer might get it wrong. Speed and easiness of production deployments is essential for most of the software companies. The harder or complex the process from developer’s perspective is, the higher the chance to make a mistake and break your production systems. This multiplied by the number of developers in your organization shows that the bigger the organization the more important it is to simplify the developer’s production deployment experience. It’s never too early to start working on that processes, because as the organization grows, the complexity of introducing new processes grows as well.

{a4}
Your production deployment process is relatively complex and not that bullet proof, but you’ve made steps to simplify and unify it. There are still ways in which a newcomer might get it wrong, but in most of the cases the onboarding goes well. Speed and easiness of production deployments is essential for most of the software companies. The harder or complex the process from developer’s perspective is, the higher the chance to make a mistake and break your production systems. This multiplied by the number of developers in your organization, shows that the bigger the organization, the more important it is to simplify the developer’s production deployment experience. It’s great that you’re already working on that processes, because as the organization grows, the complexity of introducing new processes grows as well. Keep pushing for making deployments easier and unified experience.

{a6}
Your production deployment process is simple and bullet proof. A newcomer usually successfully deploys code to production in their very first day of work. Speed and easiness of production deployments is essential for most of the software companies. The harder or complex is the process from developer’s perspective, the higher the chance to make a mistake and break your production systems. This multiplied by the number of developers in your organization shows that the bigger the organization the more important it is to simplify the developer’s production deployment experience. It’s great that you’ve accomplished simple and unified deployment experience already, because as the organization grows the complexity of introducing new processes grows with it as well.

{q11009} You have a common company wide adopted maturity assessment model per service or tech component used by your teams.

{r90} Operational maturity
{w2}

{a1}
There is no common company wide adopted maturity assessment model for your services or components. Such models allows you to define what good service or component looks like e.g. in the areas of continuous integration and deployment, various types of testing applied, monitoring, MTTD and MTTR SLAs, security, operability etc. They’re generally best applicable for mid sized and big companies as they have more services and components and benefits more from the standardisation process. However even with small companies it’s advisable to start laying out the foundations of those maturity models, because it will make it easier in the long run. If you’re a mid or large size company with tens or even hundreds of services and still don’t have maturity assessment model it’s highly recommended to start defining those as it will allow you to quantify the maturity of your tech.

{a4}
To some extent there is a common company wide adopted maturity assessment model for your services or components, however maybe your maturity models still don’t cover important areas such as monitoring, reliability, CICD etc. or they’re not uniformly applied throughout your organization. This is a good first step forward and at this point you should already be able to see quantitative measurement of the maturity of your tech organization. Keep defining assessment models for the areas that you’re missing (e.g. continuous integration and deployment, various types of testing applied, monitoring, MTTD and MTTR SLAs, security, operability etc.) and following up on the already discovered shortcomings in your organization. You can use the assessment and the aggregated data to communicate the health of the tech organization to non-tech stakeholders and use that for justifying investments in areas, where the business doesn’t see immediate benefits.

{a6}
There is a common company wide adopted maturity assessment model for your services or components which cover all important areas such as continuous integration and deployment, various types of testing applied, monitoring, MTTD and MTTR SLAs, security, operability etc. and they’re uniformly applied throughout your organization. This is a great accomplishment and at this point you should already be able to see quantitative measurement of the maturity of your tech organization. You can use the assessment and the aggregated data to communicate the health of the tech organization to non tech stakeholders and use that for justifying investments in areas where the business doesn’t see immediate benefits.

{c12} Productivity and Efficiency

{q12001} The teams in your tech organization have a definition of productivity.

{r150} Productivity and efficiency
{w2}

{a1}
The teams in your tech organization doesn’t have a definition of productivity. This is understandable. In fact there is no broadly accepted definition of software engineering productivity, mostly because it’s intellectual work that is very different in nature from the manual work, which can be defined with the simple equation Productivity = Output / Input. Nevertheless, it is strongly recommended to come up with a definition that works for your organization and start measuring. The more data you have, the better you know what to change in measurement or if there is room for improvement in your teams. KPIs that could be taken into account are for example production pushes per day, team velocity etc. Metrics as simple as amount of time spent on meetings versus the amount of time spent coding can also be a good start. This is a very good blog article about how to measure productivity in a tech organization, which you can use as a source of useful hints and inspiration : https://topstrengthener.com/2019/02/01/measuring-and-improving-the-productivity-of-your-tech-organization-in-its-transformation-journey/ .

{a4}
The teams in your tech organization have a definition of productivity however it might be only formally defined without officially tracking it or actually taking measures to improve it. The fact that you have a definition of productivity alone is a great start. So far there is no broadly accepted definition of software engineering productivity in the industry so you’re already ahead. It is recommended to start measuring and incrementally improve your own definition. The more data you have the better you know what to change in measurement or if there is a room for improvement in your teams. Additional factors that could be taken into account are for example quality, autonomy, project success, customer satisfaction, innovation. Metrics as simple as amount of time spent on meetings versus the amount of time spent coding or having clearly defined goals can also be included if you don’t measure them yet.

{a6}
The teams in your tech organization have a clear definition of productivity, it is officially tracked and often you are taking measures to improve it. The fact that you have a definition of productivity alone is a great start. So far there is no broadly accepted definition of software engineering productivity in the industry so you’re already ahead. It is even better that you’re incrementally improving your own definition. The more data you have, the better you know what to improve in your teams, in order to further boost their productivity.
Great job, keep measuring and improving. Additional factors that could be taken into account are for example quality, autonomy, project success, customer satisfaction, and innovation. Metrics as simple as amount of time spent on meetings versus the amount of time spent coding or having clearly defined goals can also be included if you don’t measure them yet.

{q12002} You have a definition of productivity of your overall tech organization.

{r150} Productivity and efficiency
{w2}

{a1}
There is no definition of productivity of your overall tech organization. A very simple approach would be to have this metric as an aggregate of the productivity metrics of your individual teams. If your teams still doesn’t have productivity metrics defined it might be a good idea to start there.

{a4}
You have a definition of productivity of your overall tech organization however it might be only formally defined without officially tracking it or actually taking measures to improve it. The fact that you have a definition of productivity alone is a great start. So far there is no broadly accepted definition of software engineering productivity in the industry so you’re already ahead. It is recommended to start measuring and incrementally improve your own definition. This way you can improve based on actual data. Additional factor you can add in the productivity equation might be the aggregate of the productivity metrics of your individual teams. If your teams still doesn’t have productivity metrics defined it might be a good idea to start there.

{a6}
You have a definition of productivity of your overall tech organization, it is officially tracked and often you are taking measures to improve it. The fact that you have a definition of productivity alone is a great start. So far there is no broadly accepted definition of software engineering productivity in the industry so you’re already ahead. It is even better that you’re incrementally improving your own definition. The more data you have the better you know what to change in measurement or if there is room for improvement in your organization. Great job, keep measuring and improving. Additional factor you can add in the productivity equation might be the aggregate of the productivity metrics of your individual teams.

{q12003} The efficiency of the teams, as well as the overall tech organization, is monitored, measured and continuously improved.

{r150} Productivity and efficiency
{w5}

{a1}
The efficiency of the teams, as well as the overall tech organization, is not monitored, measured and continuously improved. It is recommended to know how efficient are your teams and organization. While tech companies should be careful with over optimising for efficiency, as too rigid processes increases the risk of suppressing creativity, there should be a certain amount of attention to measuring, monitoring and improving efficiency. This will improve the overall output of the business and if done well, could improve the team motivation as well. Invest in training your staff, following the industry practices like architectural, design and code reviews in order to increase the quality of your organization’s output, and last but not least, introducing KPIs that will show if you’re improving or not.

{a4}
The efficiency of the teams, as well as the overall tech organization, is monitored, measured and continuously improved but the process is either in early stages or not thoroughly applied. Measuring the efficiency or even having a common understanding of it on a team and organizational level is a great first step. Keep improving your understanding of what is an ideal state and measuring your current situation. While tech companies should be careful with over optimising for efficiency as too rigid processes increases the risk of suppressing creativity there should be a certain amount of attention to measuring, monitoring and improving efficiency. This will improve the overall output of the business and if done in the right balance could improve the team motivation as well. A few ideas to incorporate into your processes, if you didn’t already, are to invest into trainings for your staff and following the industry practices like architectural, design and code reviews in order to increase the quality of your organization’s output.

{a6}
The efficiency of the teams, as well as the overall tech organization, is monitored, measured and continuously improved. This is great! A few ideas to incorporate into your processes, if you didn’t already, are to invest in trainings for your staff and following the industry practices like architectural, design and code reviews in order to increase the quality of your organization’s output.

{q12004} A process for continuous improvement is defined and applied, both for the individual teams, as well as for the overall tech organization.

{r150} Productivity and efficiency
{w5}

{a1}
A process for continuous improvement is not defined and applied, both for the individual teams, as well as for the overall tech organization. Adjusting and incrementally improving over time is expected from many organizations, in order to stay competitive both as a business and as an employer. It’s recommended to work on defining KPIs for measuring your productivity and efficiency, in the beginning to understand where your organization stands and draw a baseline. As a second step it’s recommended to decide what would be the ideal state for your organization, for example based on industry benchmarks. Then follows execution, continuous observation, adjustments and improvements.

{a4}
A process for continuous improvement is defined and applied, both for the individual teams, as well as for the overall tech organization, but you have identified inefficiencies in the process or missing areas. Having it defined is a great first steps and speaks good for your organizational maturity. Adjusting and incrementally improving over time is expected from many organizations, in order to stay competitive, both as a business and as an employer. Keep working on getting a better understanding of your organization and how you can improve. It might be defining additional KPIs and adding them to your baseline, deciding on additional industry benchmarks to follow, frequent work on improving the productivity and efficiency of your team and organization. At this stage you should be well aware of what would be the best next step.

{a6}
A process for continuous improvement is defined and applied, both for the individual teams, as well as for the overall tech organization and your team is happy about it. Having it defined and working speak good for your organizational maturity. Adjusting and incrementally improving over time is expected from many organizations in order to stay competitive both as a business and as an employer. At this point you should have a solid KPIs and baseline for your organization’s and individual teams’ productivity and efficiency. There should be also an ideal state defined as well as a solid path on how to get there. Great job!

{q12005} Lead and Cycle times of the whole system are measured and improved, e.g. how much time it takes from the customer request to actually delivering the requested feature back to the customer.

{r150} Productivity and efficiency
{w3}

{a1}
Lead and Cycle times of the whole system are not measured and improved. Measuring that allows you to be more predictable as an organization thus helping your business make more accurate commitments and predictions. It also might help you improve over time or at least understand where most of the time is spent during the process of producing value to the customers. This cross cutting and holistic metric, which is part of the broader performance and efficiency evaluation of your organization, could potentially uncover inefficiencies which would be hard to spot or comprehend otherwise. You can check this blog article as a source of valuable hints how this can be achieved: https://topstrengthener.com/2019/02/01/measuring-and-improving-the-productivity-of-your-tech-organization-in-its-transformation-journey/

{a4}
Lead and Cycle times of the whole system are measured and improved, however it’s not thoroughly adopted throughout the organization. This is a great first step. Measuring lead and cycle times allows you to be more predictable as an organization, thus helping your business make more accurate commitments and predictions. However, at this point you might not be yet fully transparent as an organization regarding the time needed to produce a feature or a product. Hopefully you should start getting a feeling about where most of the time is spent during the process of producing value to the customers. Keep pushing and standardizing this metric for your organization. It might potentially uncover inefficiencies which would be hard to spot or comprehend otherwise.
You can check this blog article as a source of valuable hints how this can be achieved: https://topstrengthener.com/2019/02/01/measuring-and-improving-the-productivity-of-your-tech-organization-in-its-transformation-journey/

{a6}
Lead and Cycle times of the whole system are measured and improved and you’re happy with the results. At this point the feedback from the business should be that you’re predictable and transparent as an organization at least regarding the time needed to implement a feature or a product. You should also know where most of the time is spent during the process of producing value to the customers and hopefully taking measures to bring that down. Good job!

{c13} Communication

{q13001} The members of the tech organization are well aware of the engineering roadmap.

{r260} Tech communication maturity
{w5}

{a1}
The members of the tech organization are not aware of the engineering roadmap. This might be due to different reasons e.g. the roadmap doesn’t exist at all or there is a roadmap, but it’s not communicated to the team. Making sure that everyone is aligned, especially on the high level guidelines and strategy, becomes more and more important as the organization grows. Failing to do so might result in different teams pulling in different directions. A possible consequence is to end up with a very fragmented architecture and architectural changes usually takes longer time for implementation. The recommendation is to start spending time defining and actively communicating your engineering roadmap in order to avoid the above mentioned risks.

{a4}
The members of the tech organization are to a large extent aware of the engineering roadmap. This is great because of multiple reasons – first you have engineering roadmap, which is a milestone by itself, and second you’re actively communicating it to the organization. Keep pushing that communication making sure that everyone is aligned, especially on the high level guidelines and strategy. This becomes more and more important as the organization grows. Failing to do so might result in different teams pulling in different directions. A possible consequence is to end up with fragmented architecture and architectural changes usually takes longer time for implementation.

{a6}
Everyone in the tech organization are aware of the engineering roadmap. This is great because of multiple reasons – first you have engineering roadmap which is a milestone by itself and second you’re actively communicating it to the organization. Keep pushing that communication making sure that everyone is aligned, especially on the high level guidelines and strategy. Think about extending the communication even further, outside of the tech organization, providing transparency and clear expectations to the rest of the business in that process. This becomes more and more important as the organization grows and in many cases the business complains about tech being a black box for them.

{q13002} The members of the tech organization are well aware of the product roadmap and the product strategy.

{r260} Tech communication maturity
{w5}

{a1}
The product roadmap and the product strategy are not clear for everyone. This might be due to different reasons e.g. the roadmap doesn’t exist at all or there is a roadmap, but it’s not communicated to the team. Making sure that everyone in tech is aligned, especially on the product roadmap and strategy, is crucial for every organization due to many different reasons. One of the most important is pure motivational, if there is no vision ahead how is the engineering team expected to follow. Another one is in the case of a roadmap that is not well communicated the product team is deprived of a very important source of feedback. In any case the recommendation is to start spending time defining and actively communicating your product roadmap in order to avoid the above mentioned risks plus many more.

{a4}
Everyone in the organization is more or less aware of the product roadmap and the product strategy. This is a sign of process maturity – first you have a product roadmap, which is a milestone by itself, and second you’re actively communicating it to the organization. Keep refining the roadmap and keep communication flowing. Making sure that everyone in tech is aligned, especially on the product roadmap and strategy, is crucial for every organization. Failing to do so might have motivational implications on your team. Besides that a well communicated roadmap will give the product team an important source of feedback.

{a6}
Everyone in the organization is very well aware of the product roadmap and the product strategy. This is a sign of process maturity – first you have a product roadmap, and second you’re actively communicating it to the organization. Keep refining the roadmap and keep communication flowing. You’ve most likely already heavily involved your business stakeholders to the product discussions, but as your company grows, there might still be business units which are not that well aware of the product vision. It’s highly recommended to extend your communication to everyone in the company, and maintain that as your tech organization and the company grow.

{q13003} The different non-engineering units in the company are well aware of the priorities and deliverables from the tech organization.

{r250} Tech-Business communication maturity
{w4}

{a1}
The different non-engineering units in the company are not aware of the priorities and deliverables from the tech organization. There are multiple risks involved here. As the communication is not flowing your tech organization might be considered a black box by the business. It might lead to the rest of the company underappreciating the deliveries from the tech (or not even knowing about them), thus hurting the motivation of your tech teams. Another risk if the priorities and the deliveries are not well communicated is that the tech organization will be deprived from a very important source of feedback – the business itself. In many cases the non-engineering units in a company are the ones that are interacting on a daily basis with your customers and it’s highly recommended to keep them in the loop on what tech is considering important, what has been already delivered and what is scheduled to be delivered soon.

{a4}
The different non-engineering units in the company are to a large extent aware of the priorities and deliverables from the tech organization. At least the major business stakeholders are. This is a great start as you’ll be avoiding running into several risks. For example your tech organization being considered a black box by the business or depriving the tech organization from a very important source of feedback – the business itself. Keep extending your communication to even more non-engineering units. In many cases it’s the non-engineering units in a company that are interacting on a daily basis with your customers and it’s highly recommended to keep them in the loop on what tech is considering important, what has been already delivered and what is planned to be delivered soon.

{a6}
The different non-engineering units in the company are well aware of the priorities and deliverables from the tech organization. This is a great! You’re avoiding a plethora of problems and risks involved if this communication channel is missing or not functioning well enough. Keep that communication flowing, it will prepare your business well for the uncertainties of the new releases and at the same time will give your tech organization a valuable business feedback.

{q13004} The different non-engineering units in the company are well aware of the features that are released in every next release of your product or service.

{r250} Tech-Business communication maturity
{w3}

{a1}
The business in general is not aware of the features that are released in every next release of your product or service. Usually the business units in a company are the ones that are on the front line interacting with the customers. If they’re not aware of the current state of the product, the risk of miscommunication increases, as well as the overall readiness of the company to react in case of product issues. Consider creating a communication channel which allows everyone in your company to be on the same page regarding what goes out with every next release of your product or service, how this should be communicated with customers as well as what to do in case of bugs.

{a2}
The different non-engineering units in the company are to a large extent aware of the features that are released in every next release of your product or service. At least your major stakeholders are. This is great, keep pushing that information out to as many non engineering units as possible. In many cases it’s the non-engineering units in a company that are interacting on a daily basis with your customers and if they’re not aware of the changes there is a higher chance that they won’t be able to react adequately when things go wrong. Even if they don’t go wrong the pure marketing opportunity lost because the lack of communication might impact negatively the adoption of the new features.

{a4}
The different non-engineering units in the company are to some extent aware of the features that are released in every next release of your product or service. At least your major stakeholders are. This is great, keep pushing that information out to as many non engineering units as possible. In many cases it’s the non-engineering units in a company that are interacting on a daily basis with your customers and if they’re not aware of the changes there is a higher chance that they won’t be able to react adequately when things go wrong. Even if they don’t go wrong the pure marketing opportunity lost because the lack of communication might impact negatively the adoption of the new features.

{a6}
The different non-engineering units in the company are well aware of the features that are released in every next release of your product or service. This is great, keep pushing that information out on a regular basis. In many cases it’s the non-engineering units in a company that are interacting on a daily basis with your customers and if they’re not aware of the changes there is a higher chance that they won’t be able to react adequately when things go wrong. Even if they don’t go wrong the pure marketing opportunity lost because the lack of communication might impact negatively the adoption of the new features.

{q13005} The different non-engineering units in the company have the opportunity to regularly provide feedback to the tech organization and its individual teams.

{r250} Tech-Business communication maturity
{w4}

{a3}
Your tech organization might be detached from the business as there is not enough opportunity for regularly providing feedback on organizational and team levels. This might result in wrong prioritisation and implementation of features which are not that critical for the current business needs. Consider opening regular two-way communication channels between the different structures of the company, so that the non-engineering units can provide valuable feedback to the tech teams.

{a6}
The different non-engineering units in the company have the opportunity to regularly provide feedback to the tech organization and its individual teams. That decreases the risk of detaching of your tech organization from the rest of the company and makes sure that your team is making the right prioritisation and implementation of features critical for the current business needs. Keep your communication channel open, the more transparent and accepting feedback is your tech team to the rest of the organization the better.

{q13006} The members of the tech organization are aware of the activities of the non-engineering teams which might impact the tech team, e.g. big marketing campaign which might cause peak load on the system.

{r250} Tech-Business communication maturity
{w2}

{a3}
The members of the tech organization are not well aware of the activities performed by the non-engineering teams, which might impact the tech team, e.g. big marketing campaign which might cause peak load on the system. The lack of communication might be dangerous, as it introduces a risk of the system behaving in an unexpected way without engineering having a prior knowledge of the reasons for that. A channel where major activities and events that might affect the system behaviour are planned and communicated in advance could be beneficial. A training for the business teams regarding what activities could impact the system in an unexpected way e.g. it’s limits, could be done as well.

{a6}
The members of the tech organization are to a large extent aware of the activities of the non-engineering teams which might impact the tech team, e.g. big marketing campaign which might cause peak load on the system. This is great and shows maturity in your communication strategy. You’re avoiding many possible risks of the system behaving in an unexpected way, due to engineers not being aware of certain activities performed by the business units, which might impact the system. This results in a more reliable and predictable system.

{q13007} The members of the tech organization are well aware of the business strategy of the company.

{r250} Tech-Business communication maturity
{w2}

{a3}
Your tech teams are not well aware of the business strategy of the company. This imposes a significant risk of prioritising features and general tech improvements, not aligned with the current needs of the company. It also could affect the motivation and morale of your teams, as they can’t easily correlate the results of the company with their own contributions. Even a quarterly all-hands reminding everyone what is currently important for the business, which is translated afterwards at a team level, will go a long way.

{a6}
The members of the tech organization are well aware of the business strategy of the company. This decreases the risk of wrong priotization, as well as the risk of general tech improvements not aligned with the current needs of the company. Keep this channel open and communication regularly flowing in both directions. This should improve even further the focus of the company as a whole as well as its agility.

{q13008} The members of the tech organization are well aware of the company vision and mission.

{r250} Tech-Business communication maturity
{w3}

{a3}
The members of the tech organization are not well aware of the company vision and mission. While the business strategy is important the vision and mission of the company is even more. This is because the horizon in this case is well further ahead in time and unawareness in this area could result in errors that are very hard to correct. Consistently repeat your vision and mission statement to the rest of the company whenever there is a good opportunity to do so. Make sure that both of them are clear enough and easily digested by every employee in your company.

{a6}
Most of the members of your tech organization are well aware of the company vision and mission. While the business strategy is important, the vision and mission are even more important. This is because their horizon of effect is further ahead in time and unawareness in this area could result in missteps that are very hard to correct. It also creates a sense of belonging which could reduce attrition rate and increase the overall engagement levels of your teams. Keep repeating your vision and mission statement to the rest of the company, whenever there is a good opportunity to do so, and provide examples of how daily activities or decisions are connected with the mission and vision. Make sure that both of them are clear enough and easily digested by every employee in your company.

{q13009} The members of the tech organization are well aware of how their daily work contributes to the company vision.

{r250} Tech-Business communication maturity
{w3}

{a3}
The members of the tech organization are not well aware of how their daily work contributes to the company vision. The vision and mission of the company should drive the decisions that your team is taking every single day. Failing to do so increases the risk of making strategic missteps that are very hard to correct. Additionally if your team members can’t associate their work with the mission and vision statement of your company there is an increased risk of them losing motivation and drive. Consistently repeat your vision and mission statement to the rest of the company whenever there is a good opportunity to do so.

{a6}
The members of the tech organization are well aware of how their daily work contributes to the company vision. The vision and mission of the company are driving the decisions that your team is taking every single day. This significantly decreases the risk of making strategic missteps that are very hard to correct. Additionally your team members could associate their work with the mission and vision of your company, that could help keep their motivation and drive high.

{q13010} The members of your tech organization know in what communication channels and in what format to exchange the different types of information.

{r260} Tech communication maturity
{w5}

{a3}
It’s sometimes hard for your team to choose the right communication channels and the right format to exchange different types of information. Regardless of the reasons, there is an increased risk of miscommunication or failing to communicate important messages quickly and reliably. Consider either revising your communication strategy or communicating it more broadly and effectively i.e. consistently communicate regarding how to communicate. Especially if you’re in a fast growing stage, your ability to reliably exchange information is crucial for the success.

{a6}
The members of your tech organization know in what communication channels and in what format to exchange different types of information. This is a sign of maturity of your processes and significantly decreases the risk of miscommunication or failing to communicate important messages quickly and reliably. Keep consistently communicating regarding how to communicate. Pay special attention if you’re in a fast growing stage, as your ability to reliably exchange information might be lagging behind.

{q13011} Your tech organization have a formal communication strategy defined and applied, which among other things, allows important information concerning your tech organization to reach reliably everyone of its members.

{r260} Tech communication maturity
{w5}

{a3}
Your tech organization doesn’t have a formal communication strategy defined and applied, which among other things, allows important information concerning your tech organization to reach reliably everyone of its members or it’s not efficient enough. The capability to make sure everyone is on the same page in your tech organization is very important. As your organization grows changes related to architecture, technology selection, quality assurance strategies etc. becomes harder and harder to be reliably propagated. Yet it is more important than ever to communicate those. There are many possible ways of resolving this challenge. The recommendation is to either reconsider your current approach or keep insisting on it until there are visible results in your organization. This will prevent a lot of ambiguity and frustration among your team members.

{a6}
Your tech organization have a formal communication strategy defined and applied, which among other things, allows important information concerning your tech organization to reach reliably everyone of its members. It is efficient enough to make sure that your team members are aligned around core principles in the areas of architecture, technology selection, quality assurance strategies etc. and also provides the opportunity to reliably introduce changes in them. This is great, as it prevents a lot of ambiguity and frustration among your team members, especially when your organization grows in size and keeping up with everything becomes challenging.