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.

Leadership

A person starts to lead when she takes responsibility of something greater than just herself. Before this, she needs to learn to lead herself. This means she needs to take responsibility and make a decision to sit on the drivers seat. It is quite easy to blame someone else when something goes wrong. It takes courage to admit that I had the choice, I made the decision and it turned out to be wrong. But it's a necessary step towards leadership.

Leader should be vulnerable. Admit your mistakes. Say you are sorry. Ask other professionals for guidance and be willing to change your opinion when you see better facts and hear better arguments.

Don't try to be something you are not. Even if you have a few rough edges it might be better to show them than act. People can see through facades. But if you are rude, it still might be wise to polish your manners.

Empathy is a core leadership skill. But even empathy can be learned. Think about how your actions affect others. Or, better yet, ask them! And listen to the answers.

One dilemma in leadership is that many believe in leading by example. I do so too. But in expert organization that isn't usually a choice. The people in your team are better in their craft than you. So another leadership style kicks in: stay back and let other people shine. Support them. Clear obstacles from their path. And boost their confidence by telling them how much you respect them.

Inhale blame, exhale credit to others.

I'll open this up. You are the leader. You take the blame. Period. It doesn't really matter what happened, it can be discussed later (and should be analyzed with maybe 5xWhy?), but right there in the moment when shit hits the fan you take the blame. No excuses. Then, when the dust settles, you stop for a while with your team and have a retrospective. You learn and you try to make sure the same doesn't happen again.

And the credit part. When something great is achieved it is usually a group effort. Leaders many times get to represent others in events, but when positive feedback is given, make sure you remember that it is for the team. Thank them. Thank them in public. And celebrate the successes in private too. Raise toasts or have a bun together. (bun intended)

All pictures from Gratisography.

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

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.

Team Agility

I'm not really much of a manager. Probably a slightly better coach, but mostly I'm a leader. I can give people direction and help them find the path. I don't like to tell them exactly what steps to take, just where I want them to end up. And when possible, I can walk in front of them or with them depending on the situation.

But I have a problem when I don't know where we should be going. Usually the company Vision and Strategy give guidance. But when the strategy work is still ongoing, one needs to make do without one.

In uncertain conditions it might be good to go to basics, identify the 'axioms'. When there are many unknowns, what can you rely on?

What can you rely on?

What me and my team decided to do was to improve our own group work. We are a loose group of people who work in the customer front in different roles. We are also guiding the work of others as project managers and team leaders. If we can work together seamlessly, it benefits the whole unit.

We decided to work more in pairs and coach each other. Some wanted to expand their profiles, some wanted to still concentrate more on their current role. We also decided to invite each other to our retrospectives and to arrange sessions specifically for sharing knowledge. Then we decided to change our work planning meetings (that had previously concentrated on resourcing) to sessions that combine resourcing, ongoing projects and new sales cases to get a better visibility to where we are and where we are going.

Add visibility. Prepare for changes.

These changes will increase staff liquidity, our visibility and our ability to respond to changes (which I call agility). Regardless of what the new strategy will be, these changes will help to implement it.

This post originally appeared in my LinkedIn profile. Feel free to check it out too.

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.

Behind Enemy Lines - Project Days 2014

Sometimes I notice I can be awfully prejudiced. I can't help but think about projects being all about waterfall. Hehe, I actually blame partially Lyssa Adkins about this (although in my things I admire her). Her excellent book Coaching Agile Teams talks about recovering Project Managers in a sense that they are far from being Agile

Based on this the reader may understand why I had my doubts when I was asked to give a presentation at the Finnish Project Managers' gathering called Projektipäivät. The event consisted of 20 different seminars in both Finnish and English. The one that I participated could be translated as 'Taking the Benefits of Agility into Use'. So even though the whole event was about a substance that I don't know much about, the seminar I participated felt like a safe haven.

The venue of the event was Dipoli, a building in Otaniemi, the cradle of technology in Finland. (I've also studied in Otaniemi, so it felt like a homecoming. :) ) All the presenters received a small bottle of Jaume Serra cava which I later learned was an excellent bubbling wine.

The first keynote was given by Ludovic Hauduc from Microsoft. He talked about the Future of Business Productivity and Project Management. Actually this was the first moment I gradually started lowering my defenses. He talked mostly about how the main characteristic of a successful project it that PEOPLE are involved. So it was not about the superior knowledge of the Project Manager. After the presentation I exchanged a few words with him and he said that MS Office unit is maybe not that agile yet due to the history, but they are on their path to change. Also I was curious about if they used SAFe model. But he told me they have their own way which is more of combination of different methodologies and once more emphasized the people aspect. I was very pleased about this message.

After the keynote I went to listen a seminar about Creative Utilization of Different Methodologies in a Project. Tero Huttunen from Tieto told about how the Project Managers face a big challenge with methodology knowledge. In the busy working life of today the PMs are under big time pressure all the time. And there are quite a few different methodologies out there: Agile, Scrum, XP, TDD, PRINCE, ABC, SAFe just to name a few. How could they find time to learn about all these and still have the project on tracks? (Personally I think it's about changing mindset. Giving more freedom and responsibility to the teams will make everyone's life easier. Of course given that the environment is accepting for such thing.)

Next Juhani Snellman and Elina Koskela from Reaktor talked about using Kanban in IT-projects. They also started their presentation by saying that they don't really have Project Managers and that they do everything in an Agile way. But the presentation was interesting. Kanban isn't totally new thing to me, but I haven't ever used it 'in production'. I merely know about the theory so it was nice to listen people who are actually using it (and even teaching how to use it.) My question to them was about statistics. They showed a nice cumulative flow diagram where they could show lead time and WIP. But when using physical boards someone needs to collect these statistics. From JIRA you can get that automatically, but yeah, using the real post-its has a nice wipe. (If you have distributed teams, working barely with physical boards is rather challenging.)

Then Mika Heikkinen from OP-Pohjola talked about how to use different methodologies in the big picture. Actually this was a bit misleading, because he was actually only talking about how they use SAFe. It was anyway really interesting. They have now used SAFe for over one year and have multiple Release Trains. Can't actually remember what was the percentage, but if I remember correctly they SAFe for about 40% of their projects. Could be less, could be more. But I claim that currently they might be one the biggest players in the SAFe field in Finland with their nearly 12k employees.

After the lunch break I joined the Leadership seminar. It might have been the most popular in the whole Projektipäivät event. The room wasn't the biggest, but it was really full. The facilitator, Mikko Babitzin from Tieto, had set up a second screen which was displaying the tweets with hashtags #projektipäivät and #onnistu2014. (Onnistu, which means succeed in Finnish, was the topic of this years event. Next year it will be growth which could be even more interesting.)

Vesa Rantala from Tieto shared his vast experience about working in foreign cultures and as a Project Owner. Main emphasis was once again in people and more on having personal relationship and interaction with them. Lack of asking question can also be interpreted in some cultures as not being interested in how things are proceeding. So by asking questions you signal your interest. Not really rocket science, but good to keep in mind.

Matti Vesala from Adare talked about social media and how to utilize and manage it. You don't need to be in social media, but if you accept the challenge you can get some interesting benefits. You can have your own prime time show. Not possible in television. :)

Hannu Salonen had selected 'Feedback is a Gift' as the headline for his presentation. It was both about positive and constructive feedback and about the challenge of giving and receiving it well. Really great thoughts and tips. Not really specifically for Project Managers but for anyone in a supervisor role. Or even for a leader who leads without any power over his/her followers (like a Scrum Master.) Actually I like this form of leadership the most and in the end it's the only thing that could work in today's working life. People are free to choose where they work and if you don't treat them well they can vote with their feet.

The final presentation in this seminar was given by Virpi Pikkarainen and Tiina Miettinen, two mothers and wives. (This was their own introduction.) Maybe the most important take-home I spotted was the fact that you cannot lead if you are neck deep in the details. You need to ascend a bit and take a helicopter view. Then you can see more clearly where you and the whole group should be heading.

The second keynote was given by Taneli Tikka, a serial entrepreneur who currently works in an internal start-up in Tieto corporation. They are developing the internet of things. Taneli's presentation was about transformational leadership. Good things start with Appreciation (of other people.) After that you can have Trust. Then if you throw in a bit of Enthusiasm and top it all with Learning you can be up to something really good. But remember to keep clear of being Passive or Controlling. Taneli was also referring to Deep Leadership, a methodology originally developed by Vesa Nissinen for Finnish Defense Forces. I wrote about it last summer. But anyway, I think Taneli's presentation was the most inspiring I have seen in a while or maybe even the best I've ever seen live. Charismatic person, still young and yet already long experience in start-ups and business in general.

The first day's program ended in a set of awards ceremonies. Awards were given for the best Project, best young Project Manager and for winners of Project Management Championship for students.

The second day started with the third and final keynote from Yrsa Sigurðardóttir. Her presentation was boldly named 'Project Management and Sex'. Well, it was really about genders, but this way she was able to draw more attention. ;) Currently there are no countries where it would really be beneficial to be born as a female. In Iceland the genders are closest but even there it's better to be born as male. But maybe things will change in the future. In her presentation she told about how they were able attract more women and young people into a project that was in really harsh conditions in the middle of nowhere. They made the camp really family friendly. The decrease in staff turnover was dramatic and results extremely good. Something to think about.

Later during the second day I actually got rather nervous about my own presentation. I made some final modifications and practiced some more. In the end I was rather happy with the content. Although my seminar had headers in Finnish, I wanted to present in English. Mainly because I thought it would have been recorded and I could have utilized that also in our internal communication (and for myself to take a look at how I present myself in public and how I could learn to do it better.) Unfortunately it wasn't recorded. But I kept the schedule, there was some time for questions in the end and feedback was positive. And I sincerely enjoyed. I knew my subject and I was happy about seeing people's eye contact. I think I was able to give them something.

The Roles and Responsibilities in an Agile Project and Organization from Toivo Vaje

But the final conclusion from the whole event was that projects don't necessarily mean waterfall. I think based on this event the scene has changed into something a lot more Agile. I think the two could live happily hand in hand. But I would have never found this out if I had not participated. Learning is everything. 

Deep Thoughts

Some of the mnemonics from code writing work in coaching also. For example KIS = Keep it simple. Extremely good thing to always keep in mind. On the other hand, I think DRY = Don't repeat yourself doesn't work that well. Many times (well, always) repetition is the key to learning.

That's why I sometimes find it odd that there are so many different frameworks that basically teach you the same things you usually learn at the playground. Be polite. Say you are sorry. Play nice with others. Everything starts with the way of being with others.

Since we usually forget many of these important lessons, I'm going to mention here one framework that I've been especially happy with. It's called Deep Leadership and at least a couple of years ago Finnish army was using it in the military leadership training.

It's based on four cornerstones:

• Building trust
• Inspirational way of motivating
• Intellectual stimulation
• Meeting people 1 on 1

(I remember these only in Finnish so they could probably be translated in a better way.)

And although people generally seem to think that leadership skills taught in the army cannot be applied directly in working life, I'm a strong believer in this framework. And I think it's well in line with agile values and how I personally see that expert organizations should be lead.

The framework also includes extensive feedback from three directions: superiors, peers and subordinates. And you can never have too much feedback, right?

Building Trust

One thing that I find very interesting in Scrum is the fact that the Scrum Master doesn't have any power over the team. So there's genuine need to persuade the people. Motivate them and get them to do things through leadership. And I think this lack of power is the key in expert organizations.

In case you are dealing with complex products, you probably have very intelligent people working with you. And usually those people know their value. If you boss them around and manage them too tightly, they will just pack their things and move to another company. So you need to have a light touch. Leadership is required.

And I think one key thing in leadership is building trust. Let's say there's a building on fire. Everyone is exiting the building in a rapid fashion. Who knows, the building might even be collapsing soon. But there might still be people trapped inside and they might need help.

a) You are always telling people what they need to do. They don't usually like it and people talk behind your back. You don't care since you get the job done. Who cares if you have to cut a few corners or lie in a couple of places? And if you hear something useful, you usually take advantage of it without thinking about others too much.

b) You always treat people with respect. You see others as persons who have their own hopes and dreams. And you realize you spend a lot of time with these other people, so you like to make sure you all enjoy your time together. If someone needs help, you offer assistance. When someone tells you something private, you don't spread that around. And every time you are true. Whatever happens, people know that you are telling the truth.

Okay, there are now these two persons: a) and b). Which one would you follow into a burning building?