Safe environment

The term “safe environment” got a lot of traction in recent years, whether it’s conferences, books, TED talks, or blog posts. The thing is, that it’s very hard to understand it correctly and bring it to life on a company or a team level. So the question is what do the words “safe environment” actually mean and why is it so important? How can leaders, managers, or coaches make sure that people have the feeling of a “safe environment” every single day they come to work? 

Let’s start at the theoretical level with a definition first, and then we’ll gradually move to examples and finish up with a couple of practical tools and ideas you can try out in your companies, teams, or departments.

What is a “safe environment”?

Having a safe environment in a company means that everyone in the company or a team can devote 100% attention to the work itself. Simply put everyone can be focused on doing something valuable, be creative and productive. The role of the leaders is to create an environment, where failure is acceptable and failing is taken as the best way to learn.

In this kind of environment, people feel supported and cared for in every aspect of their job. That means not having to worry about somebody punishing them for “bad KPIs”, or about their colleague(s) waiting for their position to become available. In other words, there are no hidden agendas or politics so you can just do what you love and what you were hired to do.

How can you recognize it?

The barometer is quite simple and can be summed up to a couple of key questions that you can ask yourself as a team member or a leader to see where your team currently stands.

1. How often do people in your team/company come up with new ideas or experiment with new tools/practices?

Is the number close to 0 or were there so many experiments it’s hard to keep track of them?

2. How often do people challenge the status quo? (e.g. say ”No”, “I don’t agree” or “I have a better idea.” on a meeting)

Are meetings more a passive information sharing where the leader/manager communicates towards others without any reaction/counter-proposals or is it a live discussion where every opinion counts?

3. How do people react if someone wants to measure/track trends and numbers?

Is it “Wait, what happens if I don’t meet the numbers? Am I going to get punished or even fired?” or “That’s great! More data that will help us improve and see things/patterns we weren’t able to see before”

4. What happens when a Sprint is not delivered or a project does not meet the deadline? 

Is it “Whose fault is this and how is it possible that it failed?” or ”What can we do to improve?”

5. What is the level of transparency within the company? 

Are numbers related to company management available only for the “chosen ones” or are they transparently shared with the whole company? 

These five key questions help you understand how well you’re doing as a team/company. If your answers were mostly similar to those second options mentioned above, then congratulations, please share what you do and what helped you get there with the rest of the world. If it’s the opposite, then it’s a signal that people don’t feel safe when they are at work and the next obvious question is…

What can you do about it?

As fuzzy as this topic sounds and as broad as it is, there are some activities that you should try that will lead you to a better & safer environment or at least to a better understanding of the underlying issue that you need to be focusing on is.

Change yourself

When you are a leader, starting with your own transformation would have the biggest impact on the company. Be more direct and try to provide more room for people’s ideas and experiments with unknown results. More tips in our previous article focused on Agile leadership.

Do a safe environment barometer/health-check

If you’ve heard about Spotify health check or Atlassian Health monitor, you can apply the same principles in this case as well. Just ask people how they feel. The focus of the survey should be similar to those questions mentioned above like for example:

  1. How comfortable are you with giving feedback to your team lead, manager, or anyone from company management? (Could be split to multiple questions to get better feedback)
  2. Do you feel there is mutual trust between our department and other parts of the company (e.g. Sales, Engineering, Product, etc.)? 
  3. Do you feel you take initiative and make decisions in your daily work without having to ask for approvals or worry about possible negative consequences?

You’ll surely find more questions relevant to your company and field you work in, these three just cover the basic principles of how to design it.

Every single one of these questions should have a section where anyone can write their comments as well so that you can get more context apart from the statistics. You’ll be surprised how much you’ll learn about the potential issues and challenges in these comments sections. 

Another great barometer is for example making the name field optional in these surveys. That alone will tell you a lot about the safe environment in your company because if people are not willing to put their name to the answers, that means there’s room for improvement in the company culture.

Try a company NPS survey

A very similar idea is trying an NPS (Net Promoter Score) survey within your company. Usually, this tool is used to understand how customers feel about a product or a service but why not use it internally as well, right? All it takes is just one simple but very powerful question

“On a scale of 1-10 how much would you recommend our company to a friend?”

Add a freeform text field as the numbers will tell only one part of the story and you need the details to improve as well. Plus as I’ve mentioned before, an optional field with name/e-mail can work as a good barometer here as well. Do it regularly (at least twice per year) and work with answers systematically. Always tell people what you are going to improve till the next survey (and transparently communicate of course!).

What are the next steps?

Regardless of which option you choose, that is just one of many steps to take to build a better culture and a safer environment. What happens after is the key. Ideally, all the people in leadership positions should take a look at the results and see what they should focus on in the near future. 

1. Admit that your company culture has a long way to go

The first step might be the hardest one here. It’s so easy to just discard the feedback you were given and find an excuse for every single one of the responses. The fact is people were given a voice and leaders in the company should listen. Sometimes it means admitting that our company culture is not on a level we thought it was is the first step.

2. Follow-up with teams or on 1on1 meetings

There might be, for example, things that were not communicated well, and people are frustrated because of it so just take the time to talk to them individually or as a team. Show people that you care enough to take some time away from your busy schedule to discuss these issues and learn from them.

3. Look at the trends

Whichever option you choose, after a couple of iterations focus on the trend as well. Did more people respond? Or did more of them include their name because they now feel their opinion matters and feel safe to say it without anonymity? Or is it the other way around? The trend in these cases will always tell you if you’re going the right way in terms of company culture. The key is to understand that it’s not about where you start, it’s about where you want to go and what you’re learning in the process. The initial results might not be that great but the goal is to improve gradually, even if it’s just small steps. 

Conclusion

Having or creating a safe environment in a company is a hard thing to achieve. But in the end, it’s all about having the courage to ask the difficult questions, admitting there is room for improvement, and understanding that it’s up to the leaders in the company to improve and move the company culture to the next level.

Agile engineering

Agility has become popular across many industries. In IT where it has originated it is de facto standard. However, we also experience many Banks claiming they run more or less successfully an Agile transformation. Let’s hear a story from the Engineering – REHAU.

Briefly about REHAU

Rehau was founded in Germany and has been active in furniture, industry, construction and automotive since 1948. Now it is a global company with more than 20.000 employees. Our first cooperation in the automotive field was VW Beetle. VW group is still our big customer, next to it we supply main premium brands like Porsche, Audi, BMW or Daimler where we deliver mainly painted exterior parts on a polymer basis. We deliver bumpers and other exterior parts just in time and just in sequence in 16 different factories from the Republic of South Africa (RSA) across the whole Europe to the USA. In the Czech Republic, REHAU has an automotive development centre in Cestlice and three production plants in Moravska Trebova, Jevicko and Mlada Boleslav.

In the beginning

REHAU group started its Agile transformation in 2018 to become more flexible, faster with less friction between customers and REHAU teams. Lukas Kalal (Head of Engineering Design & Services CZ/IN, Praha – Ceslice) participated in excellent Agile training in the US which awakened in him a desire to incorporate some Agile principles into our daily work in our factory.

After this inspirational training, we were looking for a partner who would guide us through the topic of agility. We got a clear recommendation that RainFellows should be our first choice.

First step 

Any organizational change requires people to change their habits – they make up the real processes of a company. It sounds simple but in reality, you face all possible layers of resistance. Although we are well aware of the problems, we invent thousands of good reasons why we must stick to “old good ways” and everything else is extremely dangerous. It is our core beliefs that create a very powerful fear to change that creates such a strong resistance attitude like:

  • “New things always break and are dangerous!”
  • “This will never work for us because we are special! (We are not IT, we are a big company, we have rigid customers, we have distributed teams, etc.)” 
  • “We tried this already in the past and it didn’t work… Name one company where Agile works!”

We often hear reactions like this.

To change something costs energy and brings less stability. People have fear of the unknown – new things. We often forget that our success is based on our ability to adapt.

To change any habit (a.k.a. processes) requires making it conscious first including their negative impact and safely letting people change their core beliefs. That minimizes the level of fear and the layers of resistance as a consequence.

In order to create a safe environment for such reflection and gaining first-hand experience with Agile, we organised a full day Agile workshop. It included a half-day (!) simulation of a traditional project and an invention of Agile. Since it was just “a simulation” and participants even to some extent invented the Agile way of working themselves as a part of it (from that moment on they owned it!), everybody felt more relaxed and open to change in the end. The workshop allowed participants to realise current habits (a.k.a. processes), their negative impact, need for change and let their core beliefs safely change. Once we changed the core belief (e.g. “It’s a new thing and it’s dangerous”), the real change in our organization could happen.

Benefits of initial (“initiation”) workshop:

  • People got hands-on Agile experience in a safe environment that allowed them to learn from their mistakes
  • Answers to important questions from trustful experts and learning how other companies implemented Agile
  • Resistance attitude changed from “it will not work” to “let’s give it a try”
  • Ownership of the change moved to people
  • Energy and excitement for change

Kaizen workshop 

After we let the team process experiences from the first workshop, there was time for the next one. The objectives of the workshop were: 

  1. Map existing processes
  2. Identify major issues and bottlenecks
  3. Co-create new ways of working
  4. Compile an implementation road-map

The whole team participated. Everybody could have their say which created a sense of ownership of the new way of working. It was really great to see everybody’s energy and excitement to contribute. As a result of full-day teamwork we came up with a proposal of Kanban Board, a scheme for items, and a new process around it.

Due to the nature of our work (Engineering), we decided to use the Kanban technique instead of the popular Scrum framework.

Why Kanban:

  • Exact specifications from our clients
  • Two weeks Sprints would mean an artificial milestone without building an incremental value
  • Need for whole process visualization
  • Incremental step from the current way
  • Kanban suits us better

As a final step we agreed following implementation road-map:

  • Ready physical board and presentation to the team (two weeks after the workshop) – collecting feedback, final changes
  • First pilot use (after one week)
  • Retrospective and improvements (after one month of use)
  • Retrospective and improvements with RainFellows (after 6 months)

Implementation of Kanban, Daily stand-ups and Retrospectives 

First, we created an environment that wouldn’t stop people’s enthusiasm by not working or missing equipment. We quickly bought magnetic whiteboards and used tape to define the agreed process layout – swimlanes. The whiteboard was equipped by post-its with different colours and magnets. The most important thing was to get started as quickly after the workshop as possible. We knew that the first board wasn’t optimal but everyone was aware that it would evolve and we would optimise it on the go.

We were happy that we made a change pilot team. The pilot team showed the way to the other teams and they were following. Some didn’t accept it at the beginning and considered it a waste of time. But the active ones pulled the rest.

Now everyone shares the same level of information and gets a complete overview of all projects. The speed of decision making has convinced even the sceptical ones. And now we are even helping other departments to start their Kanban Board.

Benefits we observe:

  • After few months, we had made a survey. The result surprised us all – it was very positive! 
  • “An overview” was named by everyone as the top benefit. The same level of information, even workload shared by everyone in the team. 
  • Easier cooperation and freedom to choose a task were other common answers from the team. 
  • From an outside perspective having a team spirit definitely increases transparency and the level of shared information across people. 
  • On top of all of that, the team naturally moved in a self-organising mode without any special steps.

Implementation of Jira 

We had a good reason for moving from physical boards to Jira. We had to improve our cooperation with our office in Detroit and our new office in India. Coordinating capacity in far locations without a shared capacity platform costs a lot of communication.

So like with a physical board, we created an environment that was working without any interruption from the start. We studied Jira and tested basic functionality like filters and different card layouts for better work organisation.

We found the Indian team as an optimal pilot for Jira. The brand new small team needed to get onboarded anyway. Why not to show them the new process right away. They accepted it as a part of onboarding, not as a change. We provided one week of personal support in India and let the team test Jira. After this successful test, we did a kick-off meeting in Prague. To keep the possibility of personal meetings we decided to use a projector next to the physical board and we did parallel visual support of our daily meetings. In the second meeting we revealed that everyone was looking at the projector instead of a physical kanban board so we have been using Jira only since then.

Home office 

Fortunately, we started with Jira before the forced home office era. In fact, it was just two weeks prior to the pandemic. So it was more an adaptation to the situation. Our meetings are now longer, instead of 5 minutes it takes 30 minutes. Mainly because we need to compensate for isolation and people like to talk about other stuff then issues or capacity.

Benefits of Jira:

  • The possibility to add information directly to the card. Having everything in one place and reachable for all team members
  • We cannot imagine handling the current situation with anything else than this platform with shared information
  • Digital Kanban Board opens the possibility for statistics and show areas where we can improve

Plans for future

We are still in the development phase and there is still a lot to do. We need to study Jira even deeper and also ask more feedback from the team.

On top of that we would like to start cooperation using Jira with our headquarters in Germany and help other departments across the company with this way of cooperation. Later it would be great if we used Jira for all project information without e-mails so the complete information was closely connected to the tasks. Looking more ahead, we would like to e.g. track hours and control the budget according to the Jira report or run projects with our customers in Jira.

Wrap up

Agile was originally invented in IT to successfully manage projects in highly turbulent environments. However, many ideas originated in Toyota’s product development, in the work of the famous Czech entrepreneur Tomas Bata, and many others. Currently our global economy enters an unprecedented situation. We can expect unexpectable events and changes to happen as a consequence. Agility is therefore a logical instrument to successfully drift through high waves of the unknown.

What we have experienced in REHAU is that teams have changed during the transformation: they are more “fresh”, active, self-managed and respond faster.

Co-authors

Lukáš Kálal, Head of Engineering Design & Services CZ/IN, REHAU

Jakub Gurecký, Internal Agile Coach, REHAU

Key moments technique to build the culture of WE

Previous article defined Agile leadership. Now we ask the following questions: how to naturally and unobtrusively integrate everything described earlier into the  real life of the team and eventually build the culture level 4?

For this, we use alternate kind of Agile retrospective – we call it Key moments (alias, according to Logan, the Mountains&Valleys technique). How it works in practice:

Instead of the classic Agile retrospective where we ask endlessly 1) What went well and 2) What bothers us, the Key moments technique focuses on specific situations – key moments we have experienced and what the impact it had on us. Specifically: did the situation energize us or did it bother us and suck all the energy and excitement out of us? The team therefore learns to put a name on functional and dysfunctional stuff without asserting subjective judgement (e.g. “You never deliver anything on time!”), focusing on the actual impact (e.g. “I had to sit here all night and I disappointed my kids since I promised them we would play. If I knew you couldn’t make it, I would’ve helped you or at least planned it for later.”)

This technique is also called Situation – Behavior – Impact. As the leader, I stay in the position of coach (not judge or preacher), who only observes emotions and impact and helps the team constructively go over all the essentials. That’s how level 4 is about to be built.

These moments are plotted on a graph (on the wall, table,…), where the x-axis represents the time in which it happened and the y-axis represents the range of emotions, from frustrating lows to energizing highs. In the second step, this technique can be used to define the values and beliefs collectively adopted by the team. The moments where members of the team find themselves at the bottom (i.e. experiencing negative emotions) reflect the values and beliefs that are undermined at that specific moment, whereas positive moments are consistent with the established values. In this way, the leader can harmonize members around a common foundation of values and so build a stable level 4.

The level 4 is about relationship among all the members. This technique provides regular hygiene of the relationship between all team members. We typically run it on a quarter or an annual period.

Conclusion 

Successful Agile transformation is about new culture (not only a structure) that allows new mindset and new type of relationship to form. It is more about psychology than we may initially realize. No matter how complex structures we created around us, sooner or later we will face inevitable reality – we face our inner self.

Agile Leadership

We defined different culture levels and link to our inner beliefs we all carry with us in the previous article. Now we deal with a question: what is the role of the leader in the Agile organization? Who is actually the leader? Agile Coach? Product Owner? Tribe Leader? 

Logan defines Tribe Leaders as people who focus their efforts on upgrading the tribal culture. S/he speaks the language of each level in order to motivate them and look for ways to progress to another level until they reach stable level 4.

According to Logan’s definition, Agile leadership aims to upgrade the organisational culture to the stable level 4, Agile values ​​and principles. The rituals, ceremonies, techniques, meetings are here to support the transformation. If, for example, the team level 2 (I can’t do anything, I’m a victim) is afraid of Agile (see the example about self-management), the task of the leader is to gradually bring the team and its members to level 3 (self-confidence) and 4 (partnership). How?

The Product Owner (PO) expresses their attitude towards clients and open communication towards the team. By creating a partner relationship (rather than hierarchical) between themselves and the team and between the team and clients.

For example, the PO should not criticize the team in retrospect for doing something stupid or for not doing it differently. I once heard a PO say retrospectively, “You should be more Agile” — ha!

The PO should instead clearly articulate what they need and why. What impact does it have on the product, clients, the company. Transfer the experience of meeting with clients to the entire team. Draw the team into experiments by introducing Dual track (providing innovation and verification to deliver a stable product), furthermore explaining, not lecturing, why MVP (Minimum Valuable Product) is acceptable or not.

Acceptance and feedback during the review is not a demonstration of the Ego of level 3, alias “I” – I’m the master here and will decide what’s good and what’s not. Getting to level 4 is about moving away from assessing and expressing your own opinion towards transpersonal identification, what has what impact on clients, product, our mutual business. The PO is the “channel” for conveying the experience of clients. The PO and team are in the same “partner” boat.

The Tribe Leader (or B-1) leads the entire tribe towards these values. They reflect the opinion of all members, connect everyone in the tribe by, e.g. creating space for sharing via tribal-wide retrospectives or regular Show&Tells. The door of the tribe leader is always physically and mentally open to anyone from the tribe and outside it. They build partner relationships with other Tribe Leaders. They have themes common to all the tribes on the cross-tribe kanban board. As the head of the entire system/tribe, the Tribe Leader plays the key role of the person whose behavior and unwitting intentions set the standard for the entire tribe. What they say to the members of the tribe is not important; important is the truthfulness of the intention, attitude and core beliefs that lie in the background of what they say. “Am I doing this for the good of the whole tribe or for my own benefit?”

And how about the Agile Coaches? They name the current values and beliefs during retrospectives and the gap between them and level 4, e.g. by using coaching tools or techniques such as Mountains&Valleys. They create a safe environment for moving to higher cultural levels. They provide adjusting mirror whenever team demonstrates behavior against the values. They use e.g. Situation-Behavior-Impact way of providing feedback — “Don’t criticize the PO, don’t tell them what they should or should not do when it bothers you that they do the same thing. Say what impact it has on you and what you need from them.” It is partner level communication of the level 4.

To achieve stabilization at level 3 i.e. the self-confidence of individual members and so avoid the fears of being excluded from the whole (see the story of the hockey player), they explicitly point out the contribution of individual members even in the case of fuckups: “We all learn our form of Agile on the go. Problems exist and always will. Making a mistake is OK. We’re in this thing together. It helps the team next time when you ask for help. It’s OK. We all need it. You’re a valuable member, look at this feedback here. Thank God you’re on the team!” This encourages others to learn to express their own support in addition to constant criticism.

The key moments technique

The next article will describe one of the techniques to upgrade team culture to level 4. The technique assists the team to consciously deal with various situations that might be source of hidden friction inside the team; eventually to name current values and potential gaps between them and level 4. The article will go live on Thursday, May 16th.   

 

Open DevOps Italy

What is DevOps? How to explain benefits to the entire organization? How to deal with company culture?

It’s Friday, May 19th. We are sitting at the Rome – Ciampino airport with Jan waiting for our flight back home. It was pretty intense week of our presence at two Open DevOps conferences in Milan and Rome, the week full of travelling, meeting lot of people interested in DevOps and of course, great Italian food and coffee! The conferences were organized by our friends at Emerasoft and their partners. Big applause to them for excellent events!

Our job was to run game based workshops that would simply explain and educate what DevOps is, why we need it and what are the basic principles behind it. For that purpose we have designed brand new DevOps game. How did it go? What were our main observations?

One of the main topics out of the conferences relates to the company culture. In Rome we got stuck on the subject already in the morning when we had a table discussion. As you can see, all the speakers were pretty concentrated:

When you are an evangelist of e.g. Agile and DevOps, you get pretty frustrated when your organization resists to adopt it or resists to adopt it right now. There are people afraid to change (why to change it since it has been working this way for 10-20 years) or people too busy (we have other problems to fix) or your management is not in. That all together pretty much creates status quo of your company culture – set of values and beliefs that cause a stereotypical behavior in the company. And then came a question from the audience: “how do you deal with it?”

This is one of the subjects of my interest for more than two decades. And still I think this is not easy to solve. What we observed in practice and also at the conferences, the game based trainings brought people together – finally. We usually hear feedback like: “It felt like after intense team building except we were also able to solve our major problems that we couldn’t solve for many years.” Another feedback the people told us: “It was after long time we felt excitement at work!”

We have got fantastic feedback in Milan as well as Rome. How come? What was the magic? The workshops were based on specifically designed aha-moments, well executed coaching, and team self-experience.

Well, the events are now part of history. But we decide about the future. Now sitting at the airport I take lot of good feelings with me home. Now I’m looking forward to see my family and Czech beer. And another DevOps game session, of course 😉

Arrivederci amici!

PS / You can check out our trip in pictures: https://goo.gl/photos/AJZVrgwVoTm8kNR47

Show and tell: way to share info across borders

Have you ever noticed that we seek for complex solutions and yet simple things work incredible well? This short article describes one such a practice we call Show & Tell.

I guess you heard of Show and tell at school. Kids bring an item from their home and they present it to their classmates. They share what they learnt about and they share feelings and passion. They share something about themselves.

In complex projects we typically struggle to efficiently share knowledge and passion between us. Everybody is pretty focused on their area, team, tasks. Or the other extreme: everybody communicates with everyone and there are long, exhaustive meetings and you value 1 minute out of 1 hour meeting.

I saw the concept of Show and tell in Norway early this year. It was very similar to a pitch presentation that I saw normally at Start-up conferences and today, after many session we have conducted, I’m still impressed about its power and simplicity. Here is how it looks.

What is Show and tell in Business?

All people gathered at one place (an open space, kitchen) and a team representative presents 3-5min pitch + 2 min Q&A. The point is to rotate quickly between teams, ideally 3 persons within 30min time frame.

Typical process looks like:

  • Couple days before the meeting: people vote about topics, presenters are selected (e.g. via Slack dedicated channel)
  • One day before presentation: check of presenters, a pitch rehearsal
  • S&T day:
    • 10 min before: setup, pre-check
    • Start: an introduction (1-2min)
    • First presentation 3-5min
    • 1-2min Q&A – and the second presenter gets prepared
    • Second presentation 3-5min
    • 1-2min Q&A – and the third presenter gets prepared
    • Third presentation 3-5min
    • 1-2min Q&A
    • Wrap up, feedback, agree follow-up – who wants to continue in discussion

The pitch should present (ideally a real demo) about their current status or something they learnt and would like to share with others. The important question is: What is worth sharing?

Lessons learnt

I would like to share few important lessons we have learnt so far:

  1. The limited time is absolutely crucial; thanks to short time people put only relevant info into the presentation; the best time frame that works for us: 30min / 3 presentations. Who needs more info can agree follow-up meeting with a speaker afterwards.
  2. The preparation makes big difference – it’s totally different level of quality if people come prepared for presentation.
  3. Demo is worth of thousand words and if you see something, you believe it (skip boring slides). Focus on key scenario.
  4. Make it easy and comfortable to join the session – we prepare it at Open space where the whole team is located, or Canteen after rush hour (but people can still enjoy food), or an area where people flow from a lunch and can have a coffee.
  5. During / after lunch time makes it OK even when people are busy because they combine lunch / after lunch coffee with something useful.
  6. The flow – make it quick, seamless (presenters get prepared during Q&A), avoid any disruption – check out laptops upfront or avoid laptops. People must feel it is very efficient.

Next level – a communication with Business (Client)

Later we took the same concept and organized such a session with our Client to present innovations. Usually, IT gets pretty much isolated from market, customers, business.

We used the concept to present 4 selected innovations. It went perfect. The customer was really impressed (it was very efficient, well prepared) and crucial finding regarding one innovation happened:

  • Customer: “This is really great! We have been asking for it for last 3 years. How long will it take you?”
  • Developer: “One day. The platform already supports it.”
  • Customer: “What??? We have been planning ½ year project for it and this year we finally found a budget and you say it is already done and we could have it long time ago? I have really mixed feelings. Great that we had this meeting.”

It took ½ year to get a customer to this meeting. They didn’t see need for it before. Now we agreed regular S&T meetings with the business people.

It is all about communication

In our personal lives as well as business. But it is about efficient communication. We have been seeking for efficient ways of communication between people for 15 years – inside a company (across silos) as well as outside (with a customer / market, partner network, etc.)

If you need to know more, just leave us message and we can go deeper: contact.us@rainfellows.com

How consultants became owners

We at RainFellows have strong IT background. We started as excited Java Developers, later became Software Architects, Scrum Masters, Project Managers. We applied Agile and Lean thinking since our first days in IT. And the results showed immediately – our projects (that normally fail in IT) were considered successful by our colleagues, management, customers. And they started asking questions: “What did you do differently?”

Consultants don’t bleed

That was 2005 and that was the beginning of what we today call RainFellows. Back then, we provided trainings and mentoring. First, it was part time job, but within ½ year we transitioned into full time consultants. And we received mixed feedback – one type of feedback was typically from those we supported; the people really appreciated our knowledge and inspiration, support and leadership. The second one, typically from those who didn’t use our services, was criticism of consultants in general: “You consultants aren’t responsible for anything, you don’t guarantee anything except the invoice next month. But we inside the project bleed our own blood.”

Becoming co-owners

The first group (our customers) called us Bad Weather Friends (later transformed into the name RainFellows). They saw our unusually strong commitment as we would be members of customer company or project. But the other group still had troubles with consultants no matter what.

Today our clients are across many industries, not only IT. We have been using Success fee model for 2 years to emphasise our commitment and risk sharing with our clients. This year, we decided to go even further. We selected 5 companies where we have long and deep relationship with key people and we have and will become shareholders, co-owners of these companies. The step is taking us to the right level where our attitude has always been. Think and act as owner. Build something important and sustainable. Focus on value creation not hours charged.

New exciting project

These days we kick off another joint project. It is again in IT (which becomes an exception these days) so we get back to our roots. It is for Italian – Czech investors and the project will change the way companies build and transform their current IT systems. We build a team in Ostrava consisting of Java developers, JavaScript geeks, QA guards (you can read more info in letak_javascript_EN and letak_javaee_EN). You can greatly help us in this stage by recommending someone who needs to move to another level of competence and meaningful job. Together with us.

Stop boring and inefficient status report meetings!

You know how it goes. There is a group of coworkers round the table and they report one after another project status to their manager. Everyone should be interested in work of others but the truth is they just wait for their turn to say their part. The only person who is somehow satisfied in the end is the manager who just got information about project status. Everyone else hates this meeting or at least takes it as necessary evil. Is it possible to do it a better way?

Imagine people really looking forward to that meeting. Imagine people perceiving the meeting as a key part of their work; as a meeting that helps them very quickly, efficiently and collaboratively solve their operational issues. And imagine a meeting that convinces everyone the project continues as fast and right as possible.

How? Instead of reporting status let’s share what we do and miss and then solve issues in pairs based on actual needs – the same way businessmen do their business in 21st century.

How does it work?

First, the focus is moved from “where we were last week/month” to “what we need to move forward as quickly as possible”. Second, the project team works autonomously and the manager, instead of being a micro-controller, becomes a guardian of team values and boundaries of team autonomy, and an active supporter of project activities.

Meeting agenda

  1. meeting procedureEach and every participant gives 1-2 minute elevator speech:
    1. Who I am and what I do (can be reduced or skipped if people know each other well already)
    2. What we succeeded in since the last meeting and what I can help others with.
    3. What I struggle and need help with
  2. Other participants listen to the speech and do their best to help the speaker. They typically offer either their help or contacts in their network who can help. In both cases they do not say anything aloud, they just fill in a referral sheet immediately at the moment they see the opportunity to help. They do it immediately because we usually do not remember much after all the participants give their speech 🙂 The participants fill in a referral sheet also at the moment they want to accept offered help or they just simply want to know more about the shared topic.
  3. After the round ends, the participants pass their referral sheets to each other. This exchange visualizes all the connections and makes them conscious. There is also kind of psychological effect of accepting offered referral sheet as a gift, as a certain form of commitment. This increases likeliness of subsequent meeting and cooperation.
  4. After the referral sheets are exchanged the participants open their calendars and immediately plan meetings to share or help each other. A planned meeting in a calendar once again raises the chance the follow-up really happens afterwards.
  5. The leader of the meeting encourages the participants to connect and pair during the meeting. And s/he actively offers his/her help and network.

The leader and all the participants get synchronized about what is going on in the project and what are the current obstacles. Moreover they actively help each other to go further with the project.

What do we need?

1, Focus on future
Project has to have clearly defined goal (overall goal and the closest milestone) including acceptance criteria. Each and every project member knows answer to questions “What is a good result of the project?” (goals) and “How do we know we are there already?” (acceptance criteria, KPIs). Just go and ask randomly selected team member whether s/he can instantly answer these questions. If not – you know what to do 🙂

2, Autonomous team
Team members (or a team of teams) usually work independently. But hidden potential lays between the units, in collaboration: 1+1=11. When everyone understands the goals and the definition of done then the best way to create really collaborating team is to pair individual members to solve (non-trivial) problems in order to reach the goals. This way we build so called Triades (see Tribal leadership). By working in pairs they shorten work lead time, less likely introduce an error, learn from each other and become substitutable and they also build and strengthen their relations. Eventually, in the course of time we transform individualities to a collaborating autonomous team. You might then see teams, which did not talk to each other earlier, discussing and proactively solving project issues by a coffee machine.

3, Manager = Leader
The leader is the key part of the system. From the original control element s/he becomes a connector and supporting element. His/her most important role is to support team members pairing and to make sure everyone knows answers to the questions above. The leader then proactively removes obstacles that team cannot remove by itself and regularly “changes oil” by organizing regular team retrospectives – meetings where team members discuss what works well and should become a standard way of working and also what to improve. One and only one improvement is then taken into action and implemented as quickly as possible. We take just one and only improvement because we know from experience the more parallel work we start the less chance is to finish anything at all.

network meeting

Positive side effects

Established relationships and the habit of working in pairs pays off heavily later on when something unexpected happens (which actually happens every day 🙂 When people are used to work together and they know and trust each other they would most likely proactively solve issues together rather than set borders and blame each other.

We know each project is unique, would you share your story with us? – contact.us@rainfellows.com.

3 good reasons to get a Mentor for your team

For every team, in order to fulfill their mission – to satisfy their customers and stakeholders – it is important to stay focused on the value and continually improve the way of working. Having a Mentor can help in both and what’s more, it significantly boosts team’s productivity and efficiency. Let us have a look at three ways how the Mentor can help.

Mentor gives you external perspective so you don’t get stuck in a rut

Things look different when you are inside or outside. When you do a job it is difficult to stop, step back, forget everything you have learnt and take a fresh new look at what you do. A mentor gives you another perspective – especially by asking questions you wouldn’t ask yourself otherwise. Answering them honestly helps you to not get stuck in a rut and move forward.

Mentor brings experience and helps you apply it in your specific environment

Why to reinvent the wheel when you can accommodate someone else’s experience? The mentor shares stories about how other teams did your job, what problems they encountered and how they coped with them. He helps you to apply this experience in your job via training and hands-on coaching – all in specific context of your team.

One good example is daily Scrum meetings. Every team needs to be synchronized and identify and resolve problems as soon as they appear – no doubts about that. But implementing daily Scrum meetings by the book in a team of 15 people working on five different areas in a distributed environment might be a nightmare without previous experience. It can take a long time and can result in frustration of the team when they are forced to do something they don’t see value in.

An experienced mentor helps the team to understand the principle behind and take a shortcut when implementing it in their specific environment (e.g. how often should they meet, how to prepare, what questions to ask and what tools to use). This makes the implementation faster and smoother.

Mentor helps to align differing views of managers and workers to make them pull the same rope

Although both workers and managers are members of the same team and should have the same goal, their views often differ. Workers see the details of their job and concrete obstacles, while managers have more high level view – goals, strategy and dependences. Both perspectives are equally important and need to be merged. However, in practice they rarely meet. So despite both workers and managers are doing their best, they are not pulling the same rope.

Managers are often too busy or too far from the workers’ job

Managers often do not have enough time or comprehension of workers’ job to explain to every worker how does the chosen strategy affect her job and what exactly is expected from her. Or why her problem cannot be fixed now because we have more burning issues on the table. Or why a certain improvement idea cannot be implemented, although it would bring huge return on investment, because we are simply not making enough profit for such an investment right now.

Workers are often left with a simple “DO” or “NO” without “WHY”, which is very frustrating.

Workers are busy as well or think it is not their job to think

Workers, on the other hand, are often too busy with details or think it is beyond their responsibility to ask and try to understand the bigger picture. They prefer to “stay in their box.”

They often do not understand how they get affected by the strategy, what exactly is expected from them and how the whole chain they are part of works.

Therefore they cannot understand the impact of what they do and what they demand on the whole team and its customers. They do not see that by getting rid of “their pain” they can cause pain to someone else in the chain. For instance that demanding “doing things right” here and now (e.g. “the right testing”) could result in delivering everything so late, that customer will refuse to pay and there might be no business at all in future. Or that by not documenting their work they cause troubles to the future maintenance team.

Such a lack of context awareness makes it difficult for managers who need everyone to actively contribute and cooperate towards the common goal.

The Mentor helps both sides to better understand each other and work together

The mentor talks to both sides, thus understanding their perspectives – plus having an external one. Therefore he acts as a natural bridge between them.

He brings up-to-date information and “WHY” to the workers, helping them to better understand the big picture, their role in it and consequences of what they do.

He helps them to better formulate their ideas with respect to the needs and constraints of the managers (shifting their mindset from “my problem” to “our common goal”). The ideas are then more likely to get supported by managers and implemented.

By explaining the big picture again and again and focusing workers on the common goal, the Mentor helps managers to increase workers’ willingness to contribute to the effort necessary to implement the strategy and achieve the common goal.

Last but not least, the Mentor helps managers to understand what are the workers’ biggest concerns and pains, how they perceive the overall situation and how they feel about it, so the managers know how well their strategy is understood and followed and in which areas they need to communicate more.

All in all, the Mentor is your team’s best friend

The Mentor works as an information carrier, being the glue connecting the details and the big picture and making the whole team pull the same rope. He is your team’s thinking partner providing external perspective and experience. And he is always on duty to help you to not lose sight of your purpose and goal and to improve continually.

Do you have one? Would you like to? We are here to help.

Follow us on