Resilience

I was recently in a one day refresher training about coaching leadership. About one and a half years ago the original training was longer, couple of months. It included lots of assignments and pair learning with my supervisor colleagues. The training was organized in house and participants came from different departments of my company. Actually, this was one the most powerful takeaways from the training: I got to meet and network with people who work in very different environments. But we all have something in common: leading people is our day job.

Our everyday realities differ. It's diffrerent being in sales or in the frontlines of customer service than in the R&D or doing software development project work. But in the end, for leader the goal is same: your job is to help your team members succeed.

Photo by jesse orrico on Unsplash

The training was implemented in such a way that there were numerous pair and group conversations. One topic was resilience, the ability to overcome a disruption (for example an organizational change). With a quick poll it seemed that almost all participants thought that they were very resilient. They were able to work under stressful conditions and stay sharp. Afterwards I began to think that

Is high resilience a precondition for a successful leader?

But which way does the causality work? Was it a precondition or had these people become more resilient after being in the management position? Maybe worth researching a bit more.

At least it would be a benefit. That in today's stormy waters (of corporate life) you can stay calm. But it's not only about you. Since even if you can get over things quickly, others might take longer. And if you forget this, you may move too fast.

• Give your people time to adapt. 
• Offer them opportunities to discuss and reflect. 
• And use your gift of keeping your head clear to help others.

Photo by Dane Deaner on Unsplash

Facing the Inevitable

Layoffs, bankruptcies and people losing their jobs seems to be almost like a trend nowadays. For the previous generations it was possible to graduate, get a job and finally retire with a gold watch after working in the same company for all of your career. If someone now has something similar in mind it almost feels naive.

Of course there are always exceptions. And probably there's big variation between different companies. But I think everyone needs to admit that things happen faster than before. Fortunes are made and lost in mere days, maybe even faster. Robots handle transactions at the stock market. One of the big dilemmas seems to be that there's a lot more data available than before, but it seems increasingly difficult to distill the important messages from the background noise. Do we have time and wisdom to understand what we measure?

I have adopted some rules of thumb from what I've read. I don't anymore think that people will spend all their lives in the same company. For my own company and team I try to create best possible circumstances for them to work. Create a system that they can feel connected with and achieve something. Exchange their free time to a hopefully competitive salary (I don't have much power over this) and to tasks that are intellectually challenging, foster their creativity and when ever possible, can be identified as things that move the company towards some greater goal.

Another thing to consider is situation when company needs to let some people go. It always feels bad. But sometimes it is inevitable. I think about Nokia as an example. If you manufacture normal, non-smart phones and people don't buy them anymore, the situation is tough. There's no easy way to increase the sales. Maybe you can find a new market where people still would prefer these 'old school' phones, but that doesn't change the fact that globally the demand for them has gone down. And will not go up anymore in the foreseeable future. And if your organization consist mainly of experts in this field, management doesn't have a multitude of options. You can wait until your bank account is empty, but in the end the result will by inevitable and ugly.

In the end the choices are to go out of business or face the facts and adapt. Things that worked in the past do not work anymore and you need to come up with something new. You will need to develop new competencies and be bold enough to let go of the past.

For some this is a cruel message. For some it can be a wake up call. My best advice for everyone could be to keep challenging yourself and to learn new things. If you learned to do something 10 years ago and continue to do the same year after year... one day your services may not be needed anymore.

Stay curious and find out new things. Experiment. Stay agile and adapt to the changing environment. Learn everyday!

Answers to Open Questions

This time I'm writing a little differently structured blog post. Pierre Godts asked me the following questions at the Scaled Agile Framework group at LinkedIn. The question is related to the SAFe Case Study I wrote some time ago. So let's dive a bit deeper into some topics that were left our of the study.

Can you tell us more about the change at employee level? 

The change touched mostly people in the development. Previously all developers (coders and testers) had been in one big group and everyone shared the same supervisor. Work was organized around projects that were resourced from this pool of developers on a monthly basis. Projects were steered by people working in the business units.

After the change people were assigned to (Scrum) teams. Each team was appointed a Product Owner who was a member of a business unit. POs reported to the heads of business units (Chief Product Owners or Business Owners). Teams started to follow scrum way of working. During the same time our internal processes were also identified and written down. Release cycle was set to three months although we knew that we would probably face problems in the beginning.

Each team elected their own Scrum Master who then started to facilitate the events and see that we followed the scrum ceremonies. They were all certified (as were the POs). Scrum Master Community of Practice was also established and Chief Scrum Master started to facilitate it.

At the beginning Scrum Masters participated in a weekly Scrum of Scrums meeting. This was later replaced by a meeting that was between any member of each team. Scrum Masters started to have regular get-togethers where they discussed process related affairs and possible impediments that needed to be raised to company level.

What was their commitment to change? Were employees skeptical or not willing to change? 

People are all different. Some were more skeptical and some were more like early adopters. I belong to these guys who usually get excited about new things easily. But generally I'd say people were rather committed to the change. The previous state of the company was not really optimal either so I think there was a really fertile ground for some change.

And as depicted in many change management related books the early and late majority just needed a bit more time and discussion. Maybe with some more coaching the change could have been faster. In our case teams were more or less left to figure out the steps themselves. But maybe we just did it with some luck.

Did some employees got fired? 

No. No employees got fired during the reorganization. But some didn't like the new way of working and decided to seek their destiny somewhere else. Some started their own company, some simply changed employer. I claim that quite many of these people had been thinking about the change already for a bit longer while. The reorganization was just the final nail into the coffin.

But one really positive thing is that some people have returned. They have seen the greener grass but understood that maybe it's due to more fertilization...

Were new employees hired? 

Yes. The company has been growing and new teams have been established during the past years.

Was there an increase in number of employees? 

Yes. Same as previous question.

What about stress level, increased or decreased? 

This is tough one. Depends. No-one probably misses the long death marches when we tried to get the release together after a year of development. Or the feeling that if I don't get this feature into the product the customers will need to wait for it for another year. (This would inevitably increase the scope creep and result in not so well tested additions at the really late part of the release cycle.)

But then the other side of the coin is that previously some developers had a really big areas of responsibility. This would mean that you could potentially save the whole company by fixing some issues and get credit from everyone. When you are working in a team, it's usually the team that gets the credit. But I see this again as one inevitable thing that happens when a company grows over certain limit.

What about the budgets/costs, controlled? 

Honestly I don't know the answer to this one. Probably the budget was controlled, but it was done in so smooth way that it was never evident. More I would say people didn't take the full benefit of their empowerment. When you have been just a resource and someone else has been managing you or your project for long enough, you don't really understand what it means when your boundaries are removed. It's a slow process to get people to see that "Hey, can I do this? Ok, wow, I can!" And it feels great. As an employee it's a bit scary. But as a supervisor I think it's great to empower others!


Did the use of Jira cause problems/difficulties?

Not really. With our distributed setup JIRA was really an essential tool. I like physical boards and post-its but with multiple sites it's a luxury you can't really afford. And when you accompany JIRA with other Atlassian tools you can get real transparency to the development. You can see whole chain from idea to source code to testing and finally to the product. And with documentation included.

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.

My Bookshelf

Since I stopped doing value adding work (writing code) and started being an administrative expense (management & process stuff), I have read many work related books. I try to balance between reading fiction and other lighter material and then management books. Originally I was rather strict that reading books that benefit the company should happen during the company time, but I've a bit softened my view on this. It sounds like a cliché, but reading and learning new things is really an investment. So, since I also like reading that stuff, I've given myself permission to read interesting books also during my leisure time. :)

Now I'm dropping the bomb: every management or process book ever written isn't a pearl! That's right. Actually, many really, really aren't worth a read. That's why I'd like to save everyone's time and just list the ones that have somehow made an impression on me.

I start from the one that has maybe made the biggest impact on my thinking: Coaching Agile Teams by Lyssa Adkins. I read this when I had just started as the Chief Scrum Master. I'm still on the voyage, but this book actually started the journey. Well written and worth reading if you want to help teams as an Agile coach.

The second one in the series of really good books that offer something new and neat is Lean Startup by Eric Ries. It doesn't go into the category of coaching, but has given me a lot of nice ideas regarding product development. I think it should be a must read for any Product Owner and could be really thought provoking for any Agile Developer. Some great catches from the book: Minimum Viable Product, experimenting, pivoting and actionable metrics. Just read it! <3

Third one in the series I actually read when again starting in a new role. This one is for Agile managers and is called Management 3.0. It's written by Jurgen Appelo and belongs to the same Mike Cohn signature series as Coaching Agile Teams. (This is not a paid commercial, but I just say that that series has a lot of good books.)

I'm not sure if the ideas are really original, one might even say that they are copied and just put under one cover, but it doesn't matter. Like Scrum combines many useful practices under one easy name and is easy to get a buy-in for, Management 3.0 groups a set of management practices. It's easy and fun to read and I think quite many managers (people who are responsible for the well being of others) should read this book. In most cases people are working in a company voluntarily. They are free to vote with their feet. Especially skillful, talented people. As a manager you should realize this and create an environment where these people enjoy working.

For the rest of the books I won't give such a lengthy description. These are a couple of easy to read books about change management:

• Who Moved My Cheese?
• Our Iceberg is Melting

Then these didn't make it into the top three, but I'm still a big fan of Henrik Kniberg's work:

• Lean from the Trenches: Managing Large-Scale Projects with Kanban
  
• Kanban and Scrum - making the most of both
  
• Scrum and XP from the Trenches
• Lean Mindset: Ask the Right Questions (co-authoring with the Poppendiecks)

This book by Daniel Pink is an excellent introduction to intrinsic motivation:

• Drive

All of the above a books that I could recommend people to read. Of course you should consider what fits your personal needs. 

Finally, a couple of books that I've read, but maybe wouldn't promote that much. If you are the author of these books, I'm sorry. But maybe you can take this as an improvement opportunity. ;)

• Lessons in IT Transformation
• Virtual Team Success: A Practical Guide for Working and Leading from a Distance
• Agile Software Development with Scrum (sorry Ken..)
• Agile Project Management with Scrum (..and once more)

And truthfully, many of these books aren't really in my personal library. But we have them at work and some I've borrowed from the local library. In addition to books you can find plenty of interesting (and free) material online. Blogs and videos are also good ways to stay up to date.

Edit (12/2015): Since the original time I wrote this post I've read a couple of really interesting books. Thinking Fast and Slow by Daniel Kahneman and Rocket Surgery Made Easy by Steven Krug. Both are excellent if you want to understand human behavior better.

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

Understanding the Whole

When a company is in the middle of an organizational change, it is sometimes difficult to understand your/others roles and the expectations. It's easy to stay with the comfortable old routines and do what you have always done. After all, you know what to do, you have done the same thing plenty of times before.

But here's the catch: what if things around you have changed? Things you know how to do might not deliver the value anymore the same way they used to. Or it can even be that the activity you keep on doing is creating a major pain for someone else in the organization.

Unfortunately I can't think of a good example where organs of living organisms were scrambled, but with organizations this can happen. And then it doesn't really work out well if the lungs still think they are fingers and forget to breath. It might have severe consequences even though they are still able to type like they used to. Like in the good old times.

Break the old habits! If you have been assigned to a new role, check what's really expected from you. Are you a muscle cell doing some heavy lifting or should you be concentrated on thinking about the future like the rest of the brain cells? How does your work affect the whole?