Adequate Introspection as a Growth Enabler

After some recent conversations with my colleagues, I'm more and more convinced that identifying and accepting flaws in one's own behaviour and skills is a big requirement for self-improvement. During my life I've met multiple people who tend to find the reasons for failures always from circumstances, environment or from other people. This might be a good psychological coping mechanism for safeguarding one's self-image, but it's also pretty bad for self-improvement. People who do not find anything to improve in their own actions rarely do anything to do things differently. Because why would they? It's the other people who should change.

 

Life is hard if you cannot trust others. 

This might also be related to trust. Probably it's not a good strategy to admit and advertise your weaknesses to people that you do not know well. They may use that information against you. That's why building trust is also key for unlocking personal and shared learning possibilities. 

As an example of how things could optimally go, let's think about a well functioning team. When people trust each other and are ok with showing their own vulnerability, they can expose ideas or plans to others and get feedback.When everybody knows that the team is building something together, it's no longer about individuals and their ideas. Ideas are criticised, bent and stretched and built on top of each other. When the best possible solution is found as a result of combined effort, everybody benefits from understanding it. And everybody grows and learns. This is the one of the biggest benefits of well functioning team.

 In a well functioning team people collaborate.

But everything starts with trust and safety. People need to be able to be vulnerable and tell if they do not know something. If they need to wear a psychological armor all the time, (working) life is hard. As a leader you can enable trust by leading by example. Trust others. Tell if you don't know. Ask seemingly stupid questions (that often are not that stupid. No-one else just dares to ask them.) Before you can trust others, you need to be in peace with yourself. And admit that if things that you participated did not go perfectly, maybe you need to do something differently next time.

The Risk of Unconventional Career Journey

Unconventional career journeys are risky

Often recruitment is numbers game and very staged. Recruiters are scanning through hundreds or even thousands of profiles and they have a specific criteria they compare those profiles against. Does the applicant have more than 5 years of experience in the craft? Have they been in supervisory role before? Have they managed managers? If any of the box goes without tick, in most cases they take the next application. 

Of course market situation also affects this, but if the company has got traction and there are enough applicants, this is how it goes. So without proper experience you don't even make it to the interview stage.

Box without a tick -> next applicant. 

There are less opportunities for generalists 

Because companies (and especially software engineering organisations) are traditionally built as they are, they follow this pattern: engineers (individual contributors) report to a team lead or engineering manager. These teams are then gathered into engineering departments, groups or tribes that are led by a director. Group of groups is then possibly called a unit and led by a vice president. The title for the highest ranked person depends on the company size, but could be "Head of", "Senior/Executive Vice President" or "Chief Techonology Officer".

When recruiters are filling these higher ranked roles, they are checking how the candidates have succeeded in the roles on the previous ladder. How successfully have they managed other managers or other directors? How long they have done that and in how many companies?

In this case people who have spent time in other functions (like being Product/Project Managers) or horizontal roles (like Agile Coach) have disadvantage. Their experience isn't immediately recognisable as beneficial for the role at hand. It's nice to have, but not fulfilling the requirements.

Sometimes the risk pays off 

There are roles that combine requirements from multiple crafts. Two possible mentions could be Product Engineer and Chief Product and Technology Officer (CPTO). Product Engineers are often people who are the first employees or founders of a tech startup. When you need to have someone who is able to think what the users need and turn that into a working application. With the latest advancements in AI and assistive technology, this might become more easy. If you have proper customer understanding and can explain it in words, tools like Copilot and Cursor can help you do the rest.

AI might change the game. 

CPTO role is another where two crafts come together. One needs to be knowledgeable about product management and be able to transform customer requirements into a roadmap and drive the implementation. Probably this role is more common in smaller companies, but could be considered also in bigger companies when a strong execution focus is required. And when the leadership team needs to be able to trust one person with the ownership of results. These roles can be opportunities also for generalists.

My story

Personally I feel like I stepped into the trap of being stuck on the generalist path for too long. I was once in a situation where I almost got to lead a department. I had carried out the organisational change, recruited the team leads and communicated what is going to happen. But then, when the new organisation was announced, I found myself somewhere else than in the head of this new department. Maybe the main learning was that one needs to be in really good terms with the decision makers in your 'homebase'. This is why I also see working abroad, far from the company headquarters, as a personal risk to anyone doing that. Out of sight, out of mind.

Don't forget to which organisation you report to. 

And I have had a bit too much agile coaching in my CV. People are offered positions that reflect what they have in their existing journey. Not what they are looking forward to doing next. That's why making a career shift is so difficult. If you want to do that, be prepared to take the long road. When you don't tick the previous boxes, (in most case) you won't stand a chance. 

Social Patterns: Sacrifice One Person

Sacrifice One Person 

Modern software development is mostly a team sport. Even with AI tools becoming more and more common, most companies organise their product development into teams that own specific parts of bigger software assets. And these teams can then have different ways of working and agreements. Social patterns (how to organise humans and handle communications) is not a new field of study.

I originally found these patterns from the book Organizational Patterns of Agile Software
Development by James O. Coplien and Neil Harrison. It was written in 1995, so exactly 30 years this year. 

Sacrifice One Person is a social pattern where one person from the team takes care of any small distractions that come to the team. This is something that probably many teams in different organisations have tried. I'll give a description of how that is done in the company I'm working in. 

Implementation 

The role is called Investigator and shifts are one week long. All team members are part of the rotation. The shifts affects only the working time, on call is handled by different people. Pagerduty application handles the rotation. It also alerts people if there's problem in their service.

One person answers, others continue work.

The Investigator shift is also visible in the calendar. Person who is one duty, has a full week calendar block that remind them and others that it is their turn. Every team also has a team Slack channel and if anyone needs help from the team, they can ping @Investigator. With this handle the person on duty will automatically be pinged and everyone else can continue their work.

Results 

When this social pattern is well adopted, it significantly decreases distractions and frees a lot of team resources to continue working on the normal backlog work. Without this pattern, probably the whole team would be pinged or the burden would concentrate on the few most senior individuals. By agreeing on the practices (for example that @Investigator pings need to be answered within agreed timeframe) it also improves the service level for internal customers. Because they have an agreed and supported way of getting reply to their questions and inquiries.

Depending on the amount of technical debt, wideness of team scope and size of the customer pool, Investigator shifts can also be stressful. Many teams have then agreed on supporting practices for their Investigators. There can be regular calls during the week or even two Investigators, if the expected weekly workload is very extensive.

With all the potential stress, many developers still seem to like the role. It is a chance for them to diversify their work and often learn something new.

This social pattern has been tried and proven to be useful. So I would highly recommend implementing something similar in your organisation. 

Migrating JIRA Cloud Project from one Site to Another

I have lately been trying and failing in trying to move (or copy) JIRA project from one site to another. One could think that this is so common use case that Atlassian would provide easy tooling for this. But based on quick Google search, this is not as straight forward as one would think. And hope.

The first instructions I found were based on making a backup of your site. Don't do that! If you try to import the backup, you will accidentally overwrite your whole JIRA instance. This only works if you want to bring the project(s) to an empty JIRA site.

But what does work, is the cloud-to-cloud migration that was still in beta when I tried it. With this approach I managed to bring individual cloud JIRA projects from other cloud instances to a common JIRA. In the following section I will tell how to do that and what potential pitfalls to expect.

Prerequisites

Cloud-to-cloud migration has some pretty heavy prerequisites, probably biggest of them being that you need to have Org Admin access rights for both the JIRA you are migrating from and for the receiving instance. I think this is pretty overkill. I hope in the future there would be some much lighter way of moving JIRA projects between sites. That would be possible with Trusted or Site Admin accesses.

Then you need to have the same Apps installed in both instances. This is good to keep in mind, especially if you have some costly ones in the original site. If you can, try to keep the set minimal. Keep it simple is a good rule.

Next, make sure you have same or similar enough custom fields in both instances. I failed my migration a couple of times because I had a validator in the original workflow that I didn't spot first that was relying on a custom field information. I had even trashed the custom field, but the reference was still left in the workflow. I would recommend simplifying your workflows before migrating.

 

Or putting the previous prerequisites into a simple list:

• You need Organisational Admin access for both JIRA instances
• You need same Apps installed in the receiving JIRA as in the original
• Same Custom fields are needed in receiving JIRA
• Check the workflows for validators. Keep it simple.
  

 

The Migration

Once you have done all the preparations, the actual migration should be smooth. For detailed instructions, check this link. In the original JIRA site, go to Settings > System > Import and Export > Migrate cloud site. Choose the receiving site (you will only see a list of sites you have Org Admin rights). Choose the projects you want to migrate. The conflict checker is very user friendly and helps you spot and clear conflicts before you try. If there's no conflicts, review and start the migration. Time it takes depends on the size of the project(s).

 

After the Migration

One thing that we noticed after the migration was that all users who were in the original project got site access to the receiving JIRA. They appeared as having site access, but no product access. In the user administration listing it also seems that these users would have received email invites, but according to Atlassian this is not the case. Never the less, I recommend removing their site accesses unless you intentionally want to give them access.

I hope in the future Atlassian provides a simpler tool for migrating individual projects between cloud instances. And with lighter access rights requirements. I think this must be quite common use case when companies evolve and merge.

Chasing Zero Bug Policy with a Three Strike Rule

Deal with Bugs Early

I claim that the best way to treat bugs is to deal with them fast. I call this the Zero Bug Policy. It means that anytime there's a new bug, development team fixes it as soon as they can. This minimizes the need of categorising bugs or spending time with bug backlog.

Unfortunately teams are often not in such a position that the amount of bugs is zero. Many would probably say that there is no such thing as a bug free software. At least software that has been developed for several years by multiple people and solves a complex real-world problem. Technical capability of the development team, culture, ways of working, staff turnover and many other factors contribute to the amount of bugs. Usually the more moving parts your solution and organisation has, the greater the chance that you will have existing bugs.

Then, assuming you are in a state where bugs have been and are piling up: how do you dig your way out of the situation? One way is to simply increase awareness. If having bugs has been the normal, you need to spend some energy to change the status quo.

Automate Your Way Out

I created a JIRA automation that implements so called Three Strike Rule. It runs periodically and has the following rules:

• All bugs that are found that have not changed status in 30 days, are labeled with Strike1. 
• All bugs that have Strike1 label and have not changed status in 30 days since, are labeled with Strike2
• All bugs that have Strike2 label and have not changed status in 30 days since, are closed/some other action taken.

I have also used JIRA project components and the ability to assign bugs to specific component owners, in most cases team leads. This makes the issues more personal and encourages action. Unassigned issues can be more easily ignored.

Automatic closing of bugs should be seen as something that should be avoided as much as possible. If customer has reported a bug and you close it with some automated message, it most probably is not going to increase the customer satisfaction. But on the other hand, neither does leaving the bugs rotting in your backlog.

With this simple Three Strike action I've witnessed a big decreasing trend in the number of aging bugs. When the rule was first implemented, there were several aging issues, but since then the numbers have gotten lot closer to the Zero Bug Policy for almost all teams.

Kata as a method for Target-Oriented Continuous Improvement

Kata as a word probably first brings to mind the repetitious practice of moves in martial arts. And repetition is definitely the key in that learning process. First you learn the basics of how a punch or kick is delivered. Then, little by little, you get better. You can move faster, the moves follow each other more fluently, there's no need to think.

Kata can be applied also in many other things as a method of target-oriented continuous improvement. The form I will describe here was made popular by Mike Rother in his book Toyota Kata and further instructions to implement the method can be found in Toyota Kata Practice Guide.

First we want to understand where we want to go. What is our vision? This is needed as a north star. It can be something huge and far in the future, but it will help in directing our efforts to correct direction.

Then we definitely want to know that where are we now. What is the current condition? Most probably our current condition is far from our vision, but with the two points we can form a line.

Next we can try to define a meaningful target condition that would be in the direction of our vision. This one should be a bit more realistic to reach within a time horizon of at least couple of months. In enterprise setup the target condition could be at the end of a quarter or year half.

Once we know where we stand currently and have defined our target condition, we probably realise that there is something blocking us from advancing directly to the target. There are things that we don't know and uncertainties. We lack information. This boundary of information is called knowledge threshold. To widen the area of our knowledge and understanding, we can make experiments. Actually a lot of the process is about conducting these experiments. The next part is iterative.

1. We formulate an experiment. Something that will help us increase our knowledge threshold.
2. We list down our assumptions. What do we expect to happen.
3. We conduct the experiment.
4. We list down the results. What actually happened and how did the things go?
5. We analyse the results, reflect and learn from the experience.

Actually those 5 steps are then repeated time after time. As a companion for our experiments we will greatly benefit if we can come up with good metrics to assess our progress. Otherwise it will be difficult to measure if we are actually getting closer to the target or further away from it.

Horizon 3 Development

The following post is not that directly concentrating on software development, but more in the early stage business development in B2B field. The learnings here seem to apply to domains that are a bit slow moving, like maritime and telecommunication. Maybe they can be applied more widely, but I have no first hand experience from others. Would be interesting to hear your thoughts if you have similar experiences from other business fields.

 McKinsey's three horizons is a framework for categorising businesses that are in different stages. 

Three Horizons

Horizon 1 (later H1) is a steady running mature business. One that is no longer growing much, but generates revenue steadily. Aim in this business is to maximize profitability. 

Horizon 2 (later H2) is growth business. It is not yet necessarily profitable, but the engine of growth has been found and there's a good product-market fit. Aim is to maximize the growth while there's still market left. At the later stage the goal is to make the business profitable a.k.a become H1 business.

Horizon 3 (later H3) is new business. Usually far from profitable, maybe even no customers at all. In this category useful metrics can be found from Lean Startup. In theory companies would like to minimize the time spent in H3 and skip this part with as little effort as possible and become an H2 business.

One can see similarities in the three horizons model and Technology adoption lifecycle model. The early adopters are willing to try new things and are willing to accept some 'children's deceases' in the products partially for the possible edge they can gain from the new innovation, partially for the sheer value of being seen as pioneers or forerunners.

The Problem in H3

The problem is that one cannot advance from H3 to H2 without really having a solid, scalable solution. H3 customers might be willing to have a proof of concepts, co-develop or co-create a solution together with the solution provider, but usually customers at later stages are expecting more maturity. And there are two options: you build the basis for scalability while you are still seeking the product market fit with your H3 business or you are late and will have huge delivery pains at the beginning of your H2 journey.

Needless to say, the problem is not that trivial to solve. H3 businesses are usually startups or internal startups with limited resources and budgets. Time is their biggest enemy, because time equals salaries and other operational expences and with a long time to market you probably lose the opportunity window and some competitor gets the customers. The time constraint is the reason companies do sub-optimal design choices that result in non-scalable architectures. Instead of taking the extra time to do things properly, companies take technical debt. And when you reach the growth phase it might be really difficult to find the time to pay the debt back.

What to Measure

In my experience (B2B software development in telecommunication field), the biggest bottleneck is not software, it's customer access. The metric I propose to follow in H3 phase is how deep customer relationship you have been able to develop.

• How many meetings you have had with different people in the customer organisation?
• What are the roles and ranks of persons you have been interacting with?
• How precise questions they have asked?
• How well have you been able to understand the customer's business and identify the customer's painpoints and problems?
• Are you able to provide them with something that helps them
  a) save money
  b) get more money
  c) help them do something they couldn't before

Deepening the customer relationship takes a lot of time. So does finding new customers. That's why testing your ideas might be really slow compared to working in B2C where you can more easily reach many customers (although I'm aware that it is nowadays really difficult to get consumers attention). Keep track of your progress and you are able to make decisions based on data!