BASE 1.0 | TOPStrengthener®

{q1001}

Question 1 Your teams have all the necessary skills to implement end-to-end customer facing features
Area: Organizational design
Weight: 5
Inversed: no

{a1}

You have teams which are not enabled to deliver end-to-end customer features, which is a critical problem for your tech organisation 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 organisation that you should tackle with high priority. This prevents it from being efficient and deliver customer value effectively.

{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 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. 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}

Questions 2 In your organisation, you have people who need to do tasks very different from their core expertise on their own initiative.
Area: Organizational maturity
Weight: 3
Inversed: yes

{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}

{q1003}

Question 3 In your teams, you have people who need to do tasks very different from their core expertise, because they are asked to do so.
Area: Organizational maturity
Weight: 5
Inversed: yes
Note: 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}

{a6}

{q1004}

Questions 4 The ratio of Engineering Manager to engineers in your organisation is between 1:5 and 1:8
Area: Organizational design
Weight: 5
Inversed: no

{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 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.

{q1006}

Question 6 In your organisation, 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.
Area: Organizational design
Weight: 2
Inversed: no

{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}

{a5}

To a large extent your teams are working with one Product Manager.

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.

Having one Product Manager per team is an important prerequisite, in order to make your tech organization efficient.

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.

{q1007}

Question 7 – What is the average age of defect in your tech organization? Answer N/A if you don’t measure it.
Area: Organizational maturity
Weight: 2
Inversed: no

{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 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. 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. 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. 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.

{q1008}

Question 8 – 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.
Area: Organizational maturity
Weight: 2
Inversed: no

{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 organisation. 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 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 organiztion, 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.

{q1009}

Question 9 – What is the average throughput of the teams in your tech organization? Answer N/A if you don’t measure it.
Area: Organizational maturity
Weight: 1
Inversed: no

{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.

{q1010}

Question 10 – How much you’ve improved the average throughput of your teams for the past 1 year? Answer N/A if you don’t measure it.
Same content as question 9.

{a0}

{a1}

{q1011}

Question 11 – Responsibilities for every person, team or structure in general in the organisation is clearly defined. There is no case where a responsibility is split or unknown.
Area: Organizational design
Weight: 5
Inversed: no

{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.

{a3}

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.

{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.

{q1012}

Question 12 – You have complaints from teams in your organization that they’re blocked on the delivery of their features.
Area: Organizational design
Weight: 4
Inversed: yes

{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}

{q11001}

Question 1: You have a defined strategy for monitoring and alerting of your IT infrastructure.
Area: Operational maturity
Weight: 6
Inversed: no

{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 organisation 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.

{a5}

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 no 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}

Question 2: You have a defined infrastructure architecture, e.g. network topology, storage, etc.
Area: IT Architecture
Weight: 3
Inversed: no

{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.

{a5}

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}

Question 3: 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.).
Area: Operational maturity
Weight: 5
Inversed: no

{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.

{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.

{a5}

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}

Question 4: Your teams can create and use test environments which are an exact copy of your production environments.
Area: Operational maturity
Weight: 4
Inversed: no

{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}

Question 5: You have a strategy in place for monitoring and optimising your IT costs.
Area: Operational maturity
Weight: 2
Inversed: no

{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 organisation culture and the smaller the organisation, 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 organisation culture and the smaller the organisation, 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 organisation 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 organisation.

{q11006}

Question 6: You know well the scalability limits of your IT infrastructure.
Area: IT Architecture
Weight: 3
Inversed: no

{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}

Question 7: You monitor and track the reliability of your IT infrastructure.
Area: Operational maturity
Weight: 5
Inversed: no

{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.

{q11009}

Question 9: 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.
Area: Operational maturity
Weight: 5
Inversed: no

{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 organisation shows that the bigger the organisation 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 organisation 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 organisation, shows that the bigger the organisation, 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 organisation 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 organisation shows that the bigger the organisation 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 organisation grows the complexity of introducing new processes grows with it as well.

{q11010}

Question 10: You have a common company wide adopted maturity assessment model per service or tech component used by your teams.
Area: Operational maturity
Weight: 2
Inversed: no

{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 organisation. 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 organisation. 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 organisation. You can use the assessment and the aggregated data to communicate the health of the tech organisation 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 organisation. This is a great accomplishment and at this point you should already be able to see quantitative measurement of the maturity of your tech organisation. You can use the assessment and the aggregated data to communicate the health of the tech organisation to non tech stakeholders and use that for justifying investments in areas where the business doesn’t see immediate benefits.