First time here?
- Read why this site exists
- Read about the three team phases your team might be in.
- Read posts on the chaos phase, the learning phase, or the self-leading phase.
Stoos Gathering - Initial Thoughts
This past weekend I was honored to be part of what I hope will be the beginning of a transformation in management culture. The start of a tipping point. It was the Stoos Gathering. that site contains a statement that represents one of the things we all agreed on. and that was pretty difficult.
We were twenty one very different individuals, form four continents, many different countries, and sometimes very different cultures of communication and leadership.
In that single room, I believe we had no less than 15 different "ways" of doing things. The most powerful realization was that mostly people were not aware of each other's work. From Radical Management, Spiral Dynamics, Elastic Leadership, Beyond Budgeting, Management 3.0, Scrum, XP, And many other ways of work - we had to find a common ground.
We had to find something that we can all agree on. and stoos wa the first step to doing that. I think that's way there was so little that we can call "conclusions" as a result - we had discovered how big the problem really is.
To begin to change management culture (which has remained the same for decades) we need to find common ground, and the stoos network was a good start.
We also agreed to meet again , and to take other actions that will be detailed by others who documented them. But mostly it is about affecting the tipping point - of how to get the people on top, the people on the bottom and those in the middle - to change how they do things.
From CEOs to knowledge workers.
That is a big task, and it's supposed to be scary.
Until we get more material out there, you might want to register to the linkedin group here to get more news.
How to be an effective code coach
As a technical team leader, you might expect others to become better coders. You can also be a coach for them by pairing with each person for a few hours each week.
Being an effective code coach means that you pair with someone, but you write less code. You mainly sit there next to them and help them out as they struggle out writing the code on their own. You might jump in, but most of the site, you should restrain yourself, and let them solve their own problems - all the way asking them leading questions, planning with them effective implementations and overall being their coach and mentor.
It's all to easy to jump in and take the reigns from a coder with less experience than you. It's much more effective to not do that - but intend give them sense that you trust them, and that it's ok to go slower, but you expect them to challenge themselves and to ask tough questions, even if they seem silly.
You may find that being a coach coach, you struggle just as much as your pair - but you struggle at learning to lead and coach. they struggle with learning to 'get' code.
You Can't Fire Everyone
If you go through your leadership career wondering "if only I'd been stuck with a better team of developers - we'd do much better" - you're doing it wrong.
Management - done right, is a tough job. That's why you get paid more. But some managers prefer to go through life taking the money and not doing the hard work. (loosely quoting Jerry Weinberg).
Take a hard look in the mirror --
Your job as a leader and manager is to turn your team into a team you can be proud of.
If you easily resort to getting people out of the team - you're not doing your job.
Grow them -- invest time and effort. Do the hard things and the things that scare you.
PS
The title is from this book. it's not great, but the title is very nice.
Don't be afraid to become management
If you do it right, your fears can mostly be wrong. If you do it wrong - your fears will mostly be right. So I just made this late night video to talk about that:
A Manifesto For Sofware Team Leaders - Take 1
It occurs to me that a manifesto for a software team leader is not a bad idea. And, I intentionally not want it to be an "Agile" related manifesto, but more of a management/people/leadership manifesto that applies to the software industry.
Perhaps later we can say that it applies to a broader scope, but software is where I am focusing, until proven otherwise.
I would love to hear your thoughts on what items would appear in such a manifesto. Here are some things I would think would make a good fit, but I don't think I can articulate them well enough to be concise and to the point enough to make a manifesto:
- Adjusting leadership to the problems the team is facing, over blindly leading in your preferred manner
- Experimenting with humans, over status quo
- Challenging yourself as a leader to become better, over staying safe
- Embracing yours and your team's fear and discomfort as learning, vs. staying in safe, clm and cool waters
- Spending more time with your team , vs spending more time in meetings
- Also Focusing on People Skills vs. just learning methodological practices
- Taking Personal Risks vs. keeping status quo
- Challenging and teaching your team to solve their own problems vs. Solving everyone else's problems yourself
- new: everyday - you and your team are better at something, than you were yesterday
Dear reader - if you think you have more ideas, or that some of these are crap - I'd love to know, and why. if you think you can word these better (and I'm sure that should be pretty easy) - please help me out in the comments.
Trying this out in real life
In my upcoming team leader course in Norway next week, I will try to create a shared manifesto like this for the first time. We'll see what we get…!
Stoos
I'll be pondering this out loud in the Upcoming Leadership Summit in Stoos. I'm honored to have been asked to attend,and if you read that blog post carefully, you'll see that one of the things he writes there is "probably not another manifesto". so, there - our first disagreement? should be interesting!