Leadership, Self-Improvement, Public Speaking, Craftsmanship
my job, my life, my passion…
Responsibility is about the details
Nov 8th
Recently I had a meeting with my team on which we discussed the areas that are painful for us. Let’s face it – things aren’t going quite well now: we know the we cannot meet the deadline, the project will end way over budget and in other systems we are mostly fighting fires instead of delivering actual value. This is the price for rebuilding the team and we are aware of it.
Preparing for the meeting, I was planning a revolution – I wanted to turn the whole work culture upside down, to change something. I didn’t know how exactly I should do that but I felt an urge to do something to overcome the stagnation and chaos that infected the team. Fortunately I had a long time to think it over.
So the meeting started and we discussed many things and ideas: how to improve our Kanban board, how we should share the problems and the knowledge, how we should work on improving our craft skills and so on, but the whole discussion started with one topic – responsibility. I need to trust my team and I need my team to trust me. And the factor that has a huge impact on trusting each other is taking responsibility for yours and your teammates’ work. We won’t deliver the value for the client unless we feel responsible for every single task we have to accomplish.
And by being responsible for your part of the job I mean the small things that matter. Things that often show that Kate is taking the responsibility and John is not. Responsibility is about how you care for the details, like changing the status in our bug-tracker, linking the changeset with a proper task, moving a sticky on the board, leaving the codebase stable while leaving for home, finishing a task according to deadline we have agreed on and so on. If you are a part of the team and you want to be respected and trusted, you need to be responsible. Not in words but in acts, and not for me but for the team and for yourself.
We agreed that we will change many things in our team, but we will start with responsibility.
Another day in KanbanLand – How it all started
Oct 1st
Yes we Kanban. We started about 1,5 year ago and I think that right now I have enough food for thoughts to share with you, so be prepared for the whole series.
The background
My team was struggling with a lot of maintenance work in big, legacy systems. We didn’t really complain. We all understood that we have to support these systems and that we will try to make them better than they are right now. We had different problems and we were seeking solution. I’m a regular reader of Pawel’s Blog and I read his Kanban Story so giving Kanban a try was sort of a natural choice for us. We had some experience with Scrum so we needed to change our thinking about the board, rules and other stuff connected with Kanban. We didn’t really know whether Kanban would help us overcome those problems but we had nothing to lose. Scrum wasn’t taken under consideration because a lot of maintenance work resulted in delivering change on demand, with no iterations.
The problems
We were having difficulties in many areas:
- Too much work started, and left uncompleted – often we had to abandon task that was already in progress and focus on another, more important one. This issue is also directly connected with another,
- Changing priorities,
- Deployment hell – we didn’t know which feature we should deliver to which environment on the client side,
- and more, and more, and more…
AND THE TIME PASSED
After 1,5 year of experimenting with Kanban we still have a lot to learn. One of our Task Boards (yes – we use more than one) looks like this:
What you can basically see here is that we still have a problem with a lot of Work In Progress and we are aware of that. You can also possibly see that our columns are split not only vertically but horizontally as well. A vigilant reader will also notice different card colours. And that’s all true but that’s another story…
And do You Kanban? How?
Feel useless? Don’t code. Be with your team!
Sep 25th
One of the projects my team is currently working on is in very critical stage. We have big problems with delivering on time, the requirements are permanently evolving, we are fighting with an internal tool we are using to build this project, and finally we are fighting with some deficiencies in our skills. We came to the stage when there is really only one functionality that has to be delivered before the deadline and we are struggling to meet this deadline.
I used to be a programmer, a good one I’d say. I know that time is really valuable right now and to help the team I could just leave my manager’s hat on the desk, wear the programmer’s hat and start coding with other members to meet the deadline. Although it may sound reasonable I’ve already done such a thing twice and it was never a good decision. Every time you switch to coding, your team suffers from not having a leader.
Having really tough moments in the team, lacking time, people, tech skills is one of the moments when I wish I’ve never known how to write code, so I wouldn’t be tempted to do it. I decided to be assertive this time. No coding anymore. So I made the decision, but it doesn’t mean I won’t try to help my team to achieve this goal. When struggling with such a problem do your best to increase your team’s chances for success but do it using your managerial skills.
What should you do when your team is chasing with time and you cannot help them directly solve the problems they are facing?
Be with your team. I’m currently writing this blog post while sitting in the room full of developers and from the perspective of writing code I’m useless to them. But that’s not the point. The point is to show your support, your respect to their work. Show that you care.
Remove obstacles. The build server is not working? Find someone to fix it. Coffee machine is broken? Go, buy some instant one. The requirements need to be explained? Contact the client do it right now.
Don’t interrupt. It’s not the right moment to do a Gemba walk. Let them focus. Stop asking “how are we doing?”. Shut up and just wait for the moment you will be helpful.
Care. Force to take a break. Bring coffee. Order pizza.
If you ask your team to stay afterhours or to work on weekend and you are not with them you are everything but the manager.
And when the busy season ends never forget to thank them.
It is your attitude – how do I suck with positive feedback…
Nov 17th
Just today I was evaluating a speech during Toastmasters meeting. I was also evaluated as the evaluator. And I was told (again) that I cited really good examples, my advices were really helpful, I pointed out why some behavior is bad, I even pointed out why some other behavior is good, but I didn’t show the positive emotions when talking about the things I liked, and I didn’t give power to the speaker to deliver the next speech.
You know the feeling when there is a guy who is talking about love, but you feel that if he could he would kill you? When there is somebody laughing during a really sad moment? When you are praising somebody, but you are not smiling? Something is wrong there. The guy is unnatural. One of my main problems is praising people, or to clarify – doing it in a wrong way or not praising them at all. And it’s not something I was born with. I learned it. I was doing it for years, because I thought that if I praise them too much they will stop growing. And it doesn’t really work this way, does it?
So now let’s listen to some thoughts on giving positive feedback:
+ John – my evaluation sucked.. What was wrong? You heard it. It was specific, I was speaking only for myself, I gave examples and advices and it still sucked.
- You have to be honest – if you didn’t like something don’t try saying you did. And remember – there is always something good. Maybe you need more time to find it, but for sure there is something that you liked.
+ Oh come on. I’m honest all the time. And I always try to find something good in what somebody said. That’s not that.
- So maybe the problem is that you point out too many negative things and general impression is that you didn’t like the speech.
+ But isn’t it the point of evaluation – to point out the downsides? We are giving feedback to someone, so he can learn something and improve it next time.
- Indeed it is. However, if you focus mainly on the things to change, your evaluation will be discouraging. And what is the point in giving the speaker great advice, but on the other hand making him feel depressed so he probably won’t like to speak again? The goal of the evaluation is to show someone areas for improvement and to give this person power to try again and correct the mistakes he had made.
+ Ok, I start getting your point. But how?
- Start with smiling – if you don’t smile, no matter what you say, it won’t help. Smile shows your positive attitude. It also creates a bond between you and the person being evaluated.
+ Will smiling be enough? That’s quite easy.
- It is not. And keep in mind all the things I already told you. And that’s not all. You can do one more thing that will help you – practice:
- Listen to other evaluators – as you already now learning by example is the best way to learn. So find those people whose evaluation you like and try to follow them. Ask them how they do it, why they did focus on that thing and on the other.
- Praise people in your everyday life. If you see that somebody did something nice – tell him about it.
- Stand in front of the mirror and say praises and positive feedback and see if you are convincing. Ask somebody from your family to watch you while you do it and ask him what does he think about it.
So it seems to go totally different than I thought for years. Praise people and see how they grow. And smile.
And what is YOUR experience with giving positive feedback?
Talk to me
Nov 2nd
There are many skills that you can and should learn when you are managing people. One of them is listening. There isn’t any easier way to became aware of what members of your team want. You should listen to the team as a whole and to every person individually. During my everyday life I’ve learned a few things associated with listening:
- You can learn it. Anyone can. It requires a lot of work, and a lot of observation, but it is undoubtedly doable.
- Be honest. People will start talking when they have confidence that you eager to hear what they want to share with you.
- Be patient. It won’t happen in the twinkling of an eye. It may be long way for both of you. Remember the story about the Little Prince and the fox? Every day you will come and sit down a little closer.
- Be flexible. You have to be ready to listen to people all the time. They choose the moment, not you. It may be the only opportunity you are going to have. So when it happens be ready to abandon what you are doing at the moment and listen. If you miss it you may be waiting for a long time to get another chance.
But listening is one thing. The other one is letting people know that you are willing to listen. Does your team know that you want to listen? That you want to know? If they don’t what are you waiting for? Make them aware that you are there for them. That you want to know. That if something bad happens, or something annoys them, or whatever comes to their minds – you are interested. And you better be so. Explain that in case of any trouble you will be able to help only if you know what’s going on.
Remember – the best way to learn listening to people is listening to people.
And what do you do to listen to your people better?
It is always about people…
Oct 26th
There are meetings in my company that are about forcing people to do something. For example how to force them to write unit tests. Or how to make them write secure code. Or how to force them to be happy. Well the last one maybe not. And these are processes. But whenever I’m attending such a meeting I get the feeling, that it is not about processes – it is about people. People are responsible for quality – not processes.
Many times when I hear about delivering software faster, and less error prone, and I hear about tools and practices, that will help us achieve this goal I ask myself if we are focusing on the right thing . And the conclusion is simple – it is about people. People bring value to the project – not tools or practices.
If I hear about manager talking about his project and talking about resources: Paul, Jane, Matt and asking his boss for more resources needed to accomplish his project I think there is a place for improvement in his thinking. It is people who are programming. It is people who are testing applications and writing documentation. People are doing the job – not resources. And those people have hobbies, families, duties. They have problems in their every day life.
And another important thing about people is that they create interactions, they talk with each other, they share their knowledge, they exchange experiences, they create atmosphere in your team.
I know we all know that and I also know, that we all tend to forget about it. We still value tools and processes more than people. And we talk about resources and resources’ availability not about people and their holidays. But it is always about people.
So remember
- if you want to increase quality of your products – focus on people
- if you search for a place for improvement – focus on people
- if some problem occurs – focus on people
- if you want to deliver better problem – focus on people
Just focus on people!
And how do you focus on people?