Dec 14, 2025

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. 

Nov 8, 2025

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.