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

Developers - Cost or Asset?

When things get big enough there might be functional silos that concentrate on specific activity. These could classically be something like sales, development, support and marketing. Of course these functions should be made as efficient as possible taking into account the whole. Customer value is usually built in co-operation between all the functions, not by a single unit.

Metrics can be a double-edged sword, if they are applied to functions instead of taking into account the whole value chain. Sales funnel is quite easy to quantify. You have numerable amount of possible clients. You can count how many units you can sell to this market, thus getting the absolute limit value for your cash inflow. It's easy to measure how much a single sales person or sales unit can close deals and bring in money.

If you sell development hours, it's also quite easy to measure how much a developer generates turnover or how big the billing rate is.

In typical cases salaries are even easier. There's usually a fixed sum of money that is paid to the person monthly. This is the cost of a developer (plus hardware & licenses too).

But it’s much more difficult to quantify the financial benefit of an in-house developer who works in R & D. One could make a rough estimate about how much an equivalent consultant would cost. But this doesn’t take into account the subtle knowledge that is accumulated over time or the internal relations. Possibly this person is the glue that keeps the team together, the humorist that keeps people in high spirits or the oil that lubricates the internal cogs and makes things happen. Not impossible, but difficult to quantify.

Without visibility and understanding, one can draw wrong conclusions about the situation. Classic would be rewarding sales department for bringing in the money and cutting costs in operations by sacking people.

 

"What should I do then?"

To remedy the silo problem and optimizing parts in expense of the whole, you should concentrate on metrics that measure the whole value chain and are difficult to gamble. Some examples:

• NPS. How the customer experienced your service?
• Lead time. How long it took your organization to meet the customer’s need?
• Profitability. Do not concentrate on (just) how much sales you make. Pay attention to how much it costs for you to develop, deliver and market the product/service.  

 

 Photos by "My Life Through A Lens", Spenser H, Fabian Grohs and Mike Wilson on Unsplash.

Employee Turnover and How To Avoid It

In the current market situation, software development professionals are the ultimate scarse resource. I'm not exaggerating if I say that these people, for example talented architects or data scientist, don't need to look for positions. They are being actively approached by headhunters and hiring managers.

They are neither easily replaceable, like cogs in a machine. Usually they possess knowledge that has been accumulated over a long period of time. Into some extent this information is useful in other environments, but it's most valuable in the current setup. That is why the existing employee is most valuable to their current company.

The cost of employee turnover

Losing a member from a well welded team has a significant cost that can be divided into (at least) the following parts:

1. Team loses a member and thus his/her direct contribution.
2. Team needs to reorganize and learn to function without the lost member.
3. Recruitment takes time away from development.
4. When the new team member is found, he/she needs to be oriented and inducted.
5. Team needs to reorganize again to function with the new member.

Sadly, I feel that many times people only think about the first bullet. And maybe if there's been difficult recruitments, also the third one. But all of these have a cost.

For the above mentioned reasons companies should do all possible efforts to keep their employees happy. I understand this is not possible for all company roles and it might be viewed as unfair. But it's really as simple as the law of demand and supply. With the rise of banks and other companies digitizing their services the demand is bigger than ever. (Almost) all companies are becoming software companies. And there's rather limited supply of software engineers.

Few tips on how to keep your employees

Compensation is one parameter in the puzzle. It should be on a decent level, but it isn't everything. Benefits that either have monetary value or make the life easier also count. I think the latter ones are more effective in retaining employees. Generally people are lazy (at least I am). Autonomy in choosing your own tools and ways of working increases happiness. If your work has a higher purpose or meaning to the society, it's a plus. For people who work with their brains, right amount of challenge is expected. And finally, you should be able learn new things.

There's a cost for keeping your employees, but usually it's smaller than losing them.

Walking Through a Process

I've recently started working part-time as an internal tutor in my organization. I could best characterize the tutor pool as having internal (agile) coaches available for different continuous improvement activities. Main focus is on process improvement and facilitation.

I think the tools and techniques are quite sophisticated. If you are familiar with Lean, you probably know the fishbone and 5 times why. This time me and my colleague facilitated a process walkthrough using the OPERA technique. We scheduled a three hour time slot for the event.

Fishbone

As we are both really new tutors, we went through the exercise before with our mentors. The person responsible for the development of the particular process was also involved in the preparations. The ultimate goal was to update the whole process. But for our session at hand we set our goal on better understanding the current status.

My colleague had done a very good script for the session with timings. We started with a short introduction (15 minutes). The participants also listed their expectations for the meeting. All the expectations were surprisingly well aligned: more understanding about the current status.

In OPERA technique people first write down their own ideas (O) on post-its. Everyone was instructed to write 3-5 things that currently work and similarly topics that could be improved. For this we gave them 10 minutes.

Time-Timer

Next, the participants paired up (P) and discussed their ideas with their pair. For this we gave them 15 minutes. If you visualize the passage of time, people can self manage their timing and you don't need to hurry them. If you can get your hands to a Time-Timer, that's great, but if you don't have one available, you can use for example Online Stopwatch. The countdown works well and you have an alarm in the end.

After the pair work, we collected the ideas on the whiteboard and the pairs explained (E) their findings to the others. For this phase we had reserved 35 minutes. In addition to positive findings and improvement topics we also had a category for ideas.

After collecting the ideas on board we discussed possible themes that could be identified. In 'by the book' OPERA we would have had ranking (R) and arrangement and actions (A), but in our case we pretty much skipped those.

Opera, not OPERA

From the results we crafted a sort of hypothesis for what the current status was. To test this hypothesis, we needed to go check things in practice. In Lean, you would use the principle Genchi Genbutsu or do a Gemba walk. In our case we will examine the current status by interviewing the process actors.

We had done a lot of ground work with the interview questions, so this part didn't take long. But if you start from scratch, be prepared to spend considerable amount of time on this. With a predefined set of questions you get better data can identify patterns from the answers.

The interviews will take a lot of time, but during the meeting we decided who were going to be interviewed and the team split into pairs. Scheduling the interviews were left as an action point and we only agreed on the deadline date. We will have another workshop session when the interviews are done and we can look at the results together.

Photo by Artur Rutkowski on Unsplash

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.