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. 

SAFe Evolution

I have been involved with SAFe for about five years now. We first started by taking inspiration from Dean Leffingwell's Scaling Software Agility book. Then we bumped into the SAFe big picture. I think it was something like version 2.1 back then. There were still HIP-iterations in the end (H stood for hardening) and the model was talking about Potentially Shippable Increments and Releases.

SAFe 2.5, Leffingwell LLC

Originally I fell in love with the simplicity of having on one level sprints and on another über-sprints. We were building new releases of our product a few times a year and wanted to speed up. Also, we were having quality issues due to scope extensions and schedule slippage. Our story has been presented in this case study.

Version 3.0 made it more clear that we don't have a separate value stream for architecture and business. I guess it was also due to popular demand that the hardening was dropped from the end of the release period. I still think it was quite realistic and would be for an enterprise that is new to agile. Things don't become fully automated over night. I became certified SAFe Agilist during the 3.0 version.

SAFe 3.0, Scaled Agile Inc

I had mixed feelings about version 4.0. I was really happy to see the Customer in the big picture for the first time, but adding yet another layer (Value Stream level) seemed like too much. That was probably mainly due to the fact that I weren't involved in such activities where so many layers would have been needed. In a way, I think it would be possible to add even more of these levels. After all, we are talking about scaling.

SAFe 4.0 was very handy when you hid the Value Stream level. Of course you need to make decisions based on economics in all cases and you want to apply agile architecture, but you can do it even if you don't have it in the big picture. Communities of Practice were also a welcome addition. You probably want to have some support groups for people who serve in similar roles. That's how you can benefit more from organizational level learning. During the 4.0 era I got certified as SAFe Program Consultant (SPC4.0).

SAFe 4.0, Scaled Agile Inc.

As with previous changes and additions, the new version SAFe 4.5 brings both welcome additions and things that seem to be added mainly because they are current hype. The ability to customize your big picture: Essential, Portfolio, Large Solution or Full SAFe is really good thing. I bet many companies can do with Essential or Portfolio SAFe. But it's a good thing that the more complex versions are available too.

SAFe 4.5, Scaled Agile Inc.

Then what I don't really like (this is my personal opinion), is the fact that SAFe is getting more bloated. I think in the core things are about scaling, cadence and transparency. The power triangle that makes a distinction between content, process and technical quality authority (PO, SM & Team or PM RTE & Architect). I see no need to add DevOps practices, Lean UX nor Lean Startup practices here. They are fine practices that I appreciate and use. But for example in teaching Leading SAFe course, they make things more complicated. Also, due to the fact that the slides covering those aspects don't really include much of instructor notes, I kind of feel those topics are still in an early phase.

Special rant from many of my trainees: THERE ARE WAY TOO MANY ABBREVIATIONS! MMF, WSJF, CoP, FAB, RTE, STE, CoD, CALMR, MTTR, WIP, CI, CD, CE, BUFD, MBSE, KPI, ROI (...maybe you get the point). Some of these are industry standards, but if you bump into these for the first time during your Leading SAFe class, you have quite a mouthful.

As an end note, I feel SAFe 4.5 is great, but there should be a clear separation between the core practices (regardless of configuration) and such additional practices that simply underline that SAFe is a collection of different IT industry best practices. Which it clearly is.

Implementing Communities of Practice - In Practice

Lately I've been suffering from a writer's block, because I stumble to the fact that I've already written about the topic I have in mind. I've already written about Communities of Practice too, but now I have a different angle.

I'm currently working as a People Manager in a big finnish software & telco company. Title doesn't probably tell much, but in practice it means that I'm an administrative supervisor for ~30 persons. My closest colleague has a team of about same size, but we are strongly trying to operate as one big team with two supervisors. And to do it so that every person in our teams could discuss with either one of us and things would simply work.

At the same time I want to underline that we are serving the people, not the other way. In our field it's the experts who create all the customer value. They are the rockstars or boxing champs. We are the coaches and managers who make sure they can concentrate on where they excel.

But this is just the foundation. My duty is making sure we have the right staff and that there aren't any major impediments. I don't really manage the daily work, that guidance comes from the self-managing agile teams.

Our teams each serve a few customers. That enables us to get the benefit from working together for long enough to reach high performing state, and on the other hand, enough flexibility and variance so the work doesn't get boring. Teams are headed by a Technical Product Owner who handles the team's backlog.

With our team based organization structure alone we carry a big risk of slipping into silos. Self-managing and self-organizing teams are great, but really big benefits materialize when we can learn from each other. This is why we need the communities of practice (or in short CoP).

Before we reorganized ourselves into the current form, I headed the Technical Product Owner team. We had a community of practice. And I'm really proud to see they still have one even after I stopped facilitating the meetings. As a side note, it's a perfect way to acid test your coaching results. What happens when you're not around? If everything halts, you should maybe look into the mirror.

We have also other CoPs. One for designers, one for testers, one for architects and so on. Most of these communities are headed by a Technical Lead. These people are our most superb technical experts who are tasked with the goal of making our people competitive in the long run. They coach and mentor others in their technical field. It's actually a great opportunity for a younger professionals to grow.

And actually some of these communities extend beyond our unit boundaries. Our company has thousands of employees and our unit has sister units in other divisions. With similar organization structures we have been able to extend the sharing of knowledge. This work is largely unfinished, but already for example the designers have weekly meetings together and testing is coordinated across the whole company. Personally I'd like to grow our Agile Community, but without concrete shared projects it's difficult to find the common ground. But maybe we arrange some event together and see where it goes.

Values and Principles

Last week I participated in a SAFe SPC 4.0 training. I was already somewhat familiar with the framework after previously attending a Leading SAFe training. After that I have been acting as a Release Train Engineer and heading a System Team for the past couple of years. But never the less, there's always room for learning more and the training was really good. Jennifer Fawcett has an overwhelming amount of experience and she's also really inspiring teacher. Maarit Laanti also shared interesting experiences from her past. I think these 'war stories' are always the most exciting content in any training.

My interpretation of SAFe is a map or definition of a complex system. Or a collection of practices that can be utilized to bring structure to an organization. So I don't consider it as a silver bullet or a project model that should be fitted 100%. And then again, this is just one possible view out of many. Reader is welcome to use SAFe in any suitable way.

But please remember that SAFe and other scaling frameworks are just frameworks. What is really important is the people and interactions that take place within the framework. I find also values and principles to be more important than specific practices.

SAFe Core Values include

• Built-in Quality
• Alignment
• Transparency and
• Program Execution

If you find for example transparency to be sore topic in your organization, then SAFe won't help you out much. In the end you might come to a conclusion that 'SAFe is broken', although the organizational dysfunction has just been uncovered by the transparency. I think the same has been pointed out about Scrum.

Then the SAFe House of Lean contains the following pillars:

• Respect for People and Culture
• Flow
• Innovation
• Relentless Improvement

As we are all unique, we have different biases. I for one emphasise the first and last pillar most. For me one of the most important things is that people respect each other. This regardless of gender, race or title. Constructive disagreement is ok. It even drives innovation. But respect and trust should be in place. Then you can take a humble look in the mirror and start the relentless improvement.

I'm not going to repeat points of Agile Manifesto here, but I'd like to point out a bit less known framework. Trust, inspirational motivation, intellectual stimulation and individual consideration are the corner stones of deep leadership. It was taught in Finnish army's leadership training and it made a lasting mark on me.

Sometimes we get lost in silos. It is easy to mentally divide people to 'us' and 'them'. Seeing the other person as a human being with hopes and dreams may help to respect the other person. And remember, even though you think something someone else is doing makes no sense, it probably makes perfect sense to him or her. Our past environments and experiences have molded us and we all see world a bit differently.

My own management/leadership methodology is based on making things easier for others. Instead of sub-optimizing things for yourself, try to make things better for others. Do not make others wait. And increase transparency as much as you can. When everyone works according to this very simple rule, the combined results can be huge.

Jogging Meeting

I have an impression that walking meetings are currently all the hype. Because everything should be always tested before judging, I decided to give it a spin. But why settle for a walk if you generally move faster?

So we decided to go for a jogging meeting with one of my team mates. I know he's an active runner and I too occasionally enjoy going for a run. And we have one-on-one meetings biweekly anyway.

When clock hit 2 PM we went to staff changing room and took the elevator down. Fortunately my team mate had been smarter than me and thought of a good route before hand. I had just thought about it, but didn't ever have time to do that. As one can guess, route length is an essential factor for keeping the meeting in schedule.

Weather was cold but sunny, practically no wind. A really nice running weather. Close to the office there was still some traffic, so it was not so easy to have a conversation. But after the first couple hundred meters we reached a calmer grounds and the conversation was easy.

Another factor to keep in mind is pace. Don't go too fast or you will be just huffing and puffing. With a decent pace you can talk, but still get some exercise.

During the jogging we discussed some memorable events from the past couple of weeks and how's the cooperation with other team members and rest of the organization. But since these one-one-one's are my substitute for development discussion, I wanted to also discuss future. For most this is a difficult topic (it is the same for me too), but I think it's also really important. I demand Product Managers to share their Roadmaps, because it means that we have some plans for the future and we won't be just hitting a wall after the current Release is finished. That's why I'd like people to also have plans for their future. Many times these plans can be beneficial from company's point of view also.

Skipping to the end: we reached the office safely, went to shower and got back to our computers. As an experience I think jogging meeting is definitely worth trying. Of course there are certain prerequisites, but if everything is matches and you feel like it, go for it! I'm pretty sure we'll try this again.

Personal Change Management

Despite the risk of sounding like an arrogant spoiled brat, I'll write this anyway. I have realized that moving from a developer role into management isn't just dancing on rose petals. And if you still try to participate in the development work, you experience brand new problems.

On one hand you feel like a member of the team. You participate in the work and you might even be good at it. And you know that it's value adding work. But due to your other duties you constantly feel that you are not doing enough. And you can't pair work as much you would like to, because it's rather time consuming. (Although I think the results are usually better than when working alone.)

On the other hand, you have your new management duties. In my case it means both being a supervisor and a Product Owner. A lot of coordination and simply communicating with other people are needed. I need to maintain the Product Backlog and sometimes even have unpleasant conversations.

I feel that upper management and the rest of the organization (and probably in the end even my team) would like me to concentrate on my managerial work. From systems point of view I understand it. The body benefits more if the lungs don't try to act like blood cells or brains as fingers. And I consciously try to do that. But it's a bit unnatural and I still feel like I'm pulled in two directions.

I'm not sure how common or rare this is, but I've perceived that I'm not the only one suffering from this problem. As a conclusion, I think the problem is mostly just between ears. When a person changes his/her role, it is more often that (s)he isn't able and/or willing to let go of the old duties. Unlearning is hard. But if you want to initiate change, you have to start from yourself.

Bullying

This post was inspired by a situation I witnessed at the local lakeside (I'm on vacation). Two boys of about the age of ten were playing by the lake. Another pair of about the same age girls were swimming in the lake. Suddenly one of the boys threw the other one's shoes into the water. Then he kept saying that "go and fetch them before they drift too far." Well, they drifted too far. Both of the boys had their clothes on and weren't very keen to get into the water. Then they tried to get the girls, who were swimming, to fetch the shoes. There was plenty of bargaining, but in the end I asked my four-year-old to fetch the shoes with her float.

Later we witnessed the bully trying to push the other one to the lake and in addition throw his shirt and pushing his bicycle there also. He also managed to somehow make a small wound into the other one's hand. When they were about to leave they had a conversation about what the bullied one would tell home about the wound. I didn't hear the conversation well, but this was the only time the bully was feeling a bit uneasy. When they left, he made the final favor of kicking the other one's bicycle helmet around.

I feel ashamed because I didn't stop this. We merely said to them that that doesn't seem like a nice way to treat people nor equipment. But for the most part we just watched silently how this cruel play happened. Inside I felt like I would like to throw the bully into the lake and ask the other one why he thinks this guy is his friend anyway. But I didn't.

The scene reminded me of this video I had seen earlier:

Fortunately this isn't everyday life at workplaces (hopefully). Management is responsible for the well being of employees. This also means that management must stop this kind of abusive behavior right away. Doing this isn't easy or comfortable and most people will evade intervening like I did in this case. But it is the role of the management to do it.

When I was thinking about possible remedies for this I first came up with transparency. Usually the bullies try to work in secrecy. Out in the open the bullying is a lot harder. But in the particular case of these two boys I would just recommend ditching that other guy. No-one deserves to be treated that way. And most certainly not by a "friend". If the same happened in a (work) relationship, I would recommend doing the same.

For me personally the scene served as a chance to educate my own children about the real world. Everyone doesn't always play nice. But it's good to identify the persons and situations and hopefully be able to handle those if the time comes. Unfortunately I also demonstrated that grown-ups aren't always much of a help either. I need to shape up on this when my kids go to school..

Changing is Hard

I have come to the conclusion that resistance to change must be somehow built into us. Or at least it seems to be very natural. That's probably why there are countless of good and bad management books written about the topic. One of the best I know is Who Moved My Cheese? by Spencer Johnson. The plot in short is rather simple: there are two mice and two little people in a maze. Every day they go to a specific place in the maze to eat cheese. Until one day the cheese runs out and they need to adapt to the changed circumstances. Now I found out that there are even multiple videos made of the book. Here's one that I found:

Another short book about change management is John Kotter's Our Iceberg is Melting. This book is a fable telling about a penguin society. The penguins encounter a crisis when one of them notices that their iceberg is probably soon going to shatter. The book describes the steps for one possible way to carry out a change initiative. Amusingly, the reader may be able to recognize certain stereotypical (penguin) characters also in his/her own work environment.

Of course here I could pull Systems Thinking from my sleeve and simply say that it's the system that resists the change. The organizational culture developed during the years and the practices that people have gotten used to. Yes, true. It is the system that resists the change. And just like entropy, getting order to the chaos takes a lot of energy. The opposite happens without any extra effort.

In Systems Thinking management is responsible for the system, since they are the only ones who can modify it and change the rules. But sometimes it is hard to change the system even from the management direction. People are very reluctant to adopt to new ways and need constant reminding, gentle pushing and coaching. Repetition of the message seems to be really important. Otherwise people inevitably will revert to the old habits.

Books aside how do you carry out this in practice? I don't know. What I do is simply experimenting. Trying new ways of doing things and seeing how people react. Feedback is the key and sometimes a little provocation is required to wake people up a bit. And it is good to have a pragmatic colleague who pulls you out of your daily routines and reminds you to think about things that really matter: the big picture. (But it's so soothing to be busy and work on all those tiny details...)

Finally I'd like to share a video that tells about an interesting Agile organization. For me it could serve as a vision of where I'd like to steer my own organization. I think we are going to right direction, but Spotify has just taken a couple of more steps. Thank you Henrik Kniberg, you are an amazing fellow! (Also, just earlier today bought his latest book: Lean from the Trenches.)