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.
]]>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.
]]>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.
]]>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:
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!
It is based on my experiences blogged here at http://5whys.com - but with much more details and exercises.
For registration and info click here.
NOTE: the course will run only if we have 5 or more attendees registered.
If you're in your own office, you're out of the loop. You're not hearing the rustle and bustle of things being done (or not done). You're not sensing happiness, or frustration, or lack of interest in all things to do with your project from your team. You're just not there to absorb what life is really like being in your team.
If you're in your own office, you can't lead by example as effectively as you can sitting right next to your team. If you're (mostly) always at your team's room, they can see how you act in various situations - from talking with the marketing folks who come by asking for features, to solving time-scheduling problems, to talking on the phone with people (when that conversation can be made in the team room), to managing your own work environment.
Act they way you'd like to see them act in these situations. Lead by example. If you keep your cool on tough technical problems, or dilemmas, or if you lose your temper - people will learn how it's OK or not ok to act in these situations.
If you're right next to the team, and you notice something that, based on your experience, will have important effects that need to be handled (choosing a bad technical route to solve a problem, inability to decide on something, people taking on too many tasks they can't handle..) , you can have a chance to deal with this before something has been 'committed to paper'. you can help either change the course of a decision before it becomes fact. How you act will depend on which team stage your team is in, of course, but regardless of stage, earlier is better, even if you intend to do nothing but shutup and watch people learn something the hard way.
When I suggest this to leaders, they tell me:
The book appeals most to developers *not* acting as team leaders (how to influence without influence, in a way).
To whet your appetite, here's just a simpe list detailing the subjects covered in chapter five (Tricks arising from social inadequacy):
Bonus Questions:
]]>