The Assessment aims to attain alignment about the current state, the target and the roadmap for moving from the current state to the target state. Simultaneously, the Assessment is also an opportunity to assess the level of business that would be attained by achieving the target state.
Our Mutual Compatibility test involves the following:
Value & Priority
Management & Team Motivation
Transformation Execution Feasibility
Is the company a product company (not a service company)? (see Note 1)
Is the company technologically driven at its core (not just support)? (see Note 2)
Is the company operating in an industry that requires high-quality standards (huge financial/reputation/legal loss due to software bugs)? (see Note 3)
Notes:
Note 1: We work with product companies because the economic value of our Technical Coaching is helping increase quality and reduce the total maintenance cost of the product across the lifecycle. This is a major economic incentive for product companies because maintenance cost is their biggest overall cost and furthermore, maintenance cost directly affects their ability to deliver at a sustainable page. This is contrasted to service companies, where the economic model is billing by the hour.
Note 2: We work with companies that are technologically driven - either it's a purely technological company, or a company in another industry where the software plays a core role, rather than a supporting role.
Note 3: The highest value we offer to companies operating in industries that require high-quality standards (e.g. finance, insurance, automotive, manufacturing, logistics), and companies who have B2B clients. The reason is that in these contexts, quality is a must-have, esp. when working in highly-regulated industries where the loss of quality could lead to severe financial loss, reputation loss, and even legal problems.
Does the company already have stable revenue streams? (mid-large company, or minimum a scale-up)? (see Note 1)
Is there stability/certainty with respect to development teams? (see Note 2)
Notes:
Note 1: During the early phases of a company, the startup phase, the most important work is the Product-Market Fit (PMF) validation. The key investment at this phase is in sales and marketing, and producing an MVP. Often the quality is not a priority (except if the company is operating in the finance industry and thus would suffer reputation loss if MVP does not work well). Furthermore, standardization and processes are not a priority. However, after there is a "paying customer" (or investments have been secured), and as the company wants to add more features or reach more customers, that's when the pain of maintenance cost kicks in - when there are more bugs (quality problems), when change is expensive (high maintenance cost), when the team can't be scaled (diseconomies of scale). That's the point from which our services start having value - the biggest the problem, the higher the value we can provide.
Note 2: High stability means that if we agree upon certain schedule that there will be high probability that the team will be able to keep to that schedule, and minimal rescheduling. Low stability means things are changing all the time, there is no possibility to plan anything a few months ahead, and that if any meetings are agreed upon that most likely they will change. Our Technical Coaching programme (and others) only make sense if we see high stability in the company; otherwise if there is a lot of instability it would cause session losses for the team.
Is there a very high financial benefit for the Company arising from the reduction of maintenance costs and delivery acceleration?
Is there a very high financial benefit for the Company in terms of scaling its product and teams; so it can achieve economies of scale?
Is there a strong reputation benefit for the Company, whereby their users will have greater trustworthiness in their product, and prevent reputation loss?
How important is it to solve the challenges very soon? Can we afford to wait? What are the losses or the risks to the company if we decide to delay the transformation?
What's the relative importance of building a culture of technical excellence - is it high on the priority list, or is it a nice-to-have initiative for some undefined future?
Are there any plans to expand the product or to expand the team? What will be the cost to the company of such an expansion if the team quality foundation isn't yet set?
Do the Engineering Leaders have strong intrinsic motivation for high quality?
Do the Engineering Leaders want to build a culture of technical excellence and continuous delivery?
Do the Engineering Leaders have a strong motivation for both cost reduction and delivery acceleration due to higher quality?
Is the team aligned regarding the current challenges we presented? Does the team see those challenges as pain points affecting their daily work?
Does the team feel strong motivation and commitment to solve current challenges and improve their technical practices?
Does the team enjoy learning new things, receiving and providing feedback, and continuously improving themselves?
Is there a strong stress reduction benefit for the team, to have reduced stress and pressure due to the higher quality?
The primary focus of our coaching is backend software development (e.g. Java, .NET, NodeJS, Python, C/C++). The reason is that techniques Hexagonal Architecture, Clean Architecture, Clean Code, Test Automation, TDD all arose from Enterprise Software Development world - backend development - where the biggest challenge to be solved was software maintenance costs. A secondary focus of our coaching is embedded software development (e.g. C/C++, Python, Java). Currently, frontend development is generally outside of our coaching focus.
Is there high complexity in the business logic, architecture, and codebase (and not just a simple CRUD app)?
Does a high percentage of the system involve backend development (and/or embedded development)?
We require that a Transformation Tech Lead (TTLD) is selected on behalf of the team.
Who will be selected as the Transformation Tech Lead (TTL)?
The existing Team Lead / Tech Lead may be selected for this role, assuming they satisfy the conditions (see below)
Otherwise, another Senior Developer, or an Engineering Leader or another member in the organization may be selected for this role, assuming they satisfy the conditions (see below) - for us, the current organizational title of that person is not important, what really matters is that the conditions are satisfied
The role of the Transformation Tech Lead (TTL) will include the following:
TTL will be the primary single point-of-contact for Optivem; representing the team
TTL will be the primary technical decision-maker as we move through the Coaching program
TTL will generally need to be present in all or majority of our Coaching sessions
TTL will also generally be the Session Organizer
The conditions that need to be satisfied by the Transformation Tech Lead are based on our previous experience for success factors:
TTL's primary expertise and motivation for Backend Development (and/or Embedded Development) (see Note 1)
TTL has strong intrinsic motivation for Clean Code, and a strong motivation for Test Automation (see Note 2)
TTL already has strong experience in software development in general (see Note 3)
TTL will allocate additional time beyond our sessions for the Reference Implementation (see Note 4)
TTL will be an Internal Champion to the whole team for best practices and will be mentoring the team (see Note 5)
Notes regarding the conditions are as follows:
Note 1: The reason why we require TTL to have expertise and motivation in Backend and/or Embedded Development is because those are the areas that we focus on as part of our Technical Coaching. In particular, most of our experience up to now has been in the successful implementation of best practices for Backend Development, and many of those practices are also equally applicable to Embedded Development - the reason is because those are the developments which have significant business logic, hence Clean Architecture and Unit Testing have high value there. Currently, we do not cover Frontend Development, or Machine Learning, or UI Test Automation, but the team is free to extend knowledge gained throughout coaching and apply best practices to those segments too.
Note 2: "Instrinsic motivation" for software quality is crucial, esp. emphasis on Clean Code and Test Automation. Not everyone has such a motivation - indeed, many developers are motivated by just delivering functionality, but not necessarily by how it's developed or the quality level; only a minority of developers actually satisfy this criteria. TTL has already demonstrated this motivation not just through words, but in actions - for example, they had already shown initiative within the company to clean up code, etc. Last, but not least, this person has seen the problems of Manual Regression Testing and really wants to adopt Test Automation.
Note 3: For us, it is fine for the team to consist of junior developers (we've coached multiple junior teams), but we do require the TTL to be "senior". Please note, for us "senior" doesn't necessarily mean the years of experience, but rather the extent of experience. For example, someone might have just 3 years of experience but they can work independently and they mentor others; they have already have interest in quality and have invested time in best practices, they have experienced the stress and pressure which came due to problems in code quality and test automation. The reason why we require a level of "senirity" in the TTL is because we (Technical Coach) cannot replace the TTL in an operational sense. Thus, we do require that they are already skilled enough to complete their ongoing work, they already mentor others and they are motivated to go deeper into best practices.
Note 4: We do require that the Transformation Tech Lead allocate additional time beyond the session for implementation based on knowledge gained through our sessions. Through our coaching, we're building the Reference Implementation. If the Transformation Tech Lead is spending all their days fire-fighting and solving production issues, and has no additional time, then we cannot move forward. Thus the Transformation Tech Lead will indeed do some heavy lifting to make the change happen.
Note 5: The Transformation Tech Lead, as someone who is already experienced and has authority, as someone who plays a key role in the Reference Implementation and mentoring the rest of the team, is taking on the role of an Internal Champion. The role of Internal Champions means that the Transformation Tech Lead is the primary driver of the change in the team (as opposed to the change being forced upon by the Engineering Manager or the Technical Coach).
Are there any blockers that would pose a significant risk to the execution of the transformation?
Do any dependencies on other people, departments, or third parties which affect execution feasibility, alignment, or approval?
Does the company have the resources to allocate up to 10% of the employee weekly for incrementally executing the transformation?
To move forward with Technical Coaching or Technical Consulting:
We need a strong YES from the Client for ALL of the above
We need a strong YES from Optivem for ALL of the above
Only if there is a strong YES from both sides, we both see a high value, a strong fit, and a mutual win-win; then we may proceed towards reservation of the 3-month coaching program.
All the conditions written above are because any Change Management initiatives are hard (indeed, many Transformations fail), so, for that reason we are setting a high bar of standards that are needed to be met to have a high chance of a successful Transformation, and to ensure that whatever we do is setup for a win-win.
This is important because the success of our transformation is based on mutual value, competence, commitment and motivation.
If there is a NO or MAYBE, then it would not be in anyone's interest to proceed forward. Of course, NO doesn't mean "never", but rather "not now", as we realize that circumstances may change in the future. If circumstances do change, then we may re-evaluate our compatibility.