I have just read First, Break all the Rules by Marcus Buckingham. I highly recommend it. There are many pearls in the book:
Here is a sure way to lose your best people:
Spend all your time helping the strugglers.
If you want to excel, invest in your best. Learn from your best, discuss things with them, understand what they do that makes them excel. Don’t spend all of your time investigating failures, study what is working really well. Challenge your best, leave the average, acceptable level of performance, push a little every day.
This doesn’t mean ignoring the weaknesses, handle those, but give you biggest focus to your best people.
Who are your best developers? What do they do that others don’t? How do they excel? Spend time with them.
Working in a Team is more then just allowing each team reaching there own goal. I talked before about Team work and how it is possible that by completing your own goal you will hinder the teams goals.
Lets see an example.
Team A wrote an encryption library some time ago, now team B needs encryption too.
Team A wrote the library without the use of an interface simply because they never needed one (they only use one encyptor). Team B now needs an encryptor which is slightly different from Team A’s. What would be the best way for the organization to proceed is for team A to modify their code and have an encryptor interface – something that wasn’t needed before. Team A has no real incentive to help by modifying their code.
Question: How does team B even know about the encryption? Does the organization facilitate this? How will the organization do what’s best and have team A modify their code.
How does your organization facilitate this?
This is really hard as there is too much pressure to do the opposite. As a self organized team trying to reach its own goal, Team A, will always put this rework low down on the list. I am sure that team B will then decide to just write it themselves instead of trying to convince team A to do the job and become dependent on them for maintenance. I know of many organizations where team B will just copy team A’s library and work from there, what a waste, how un-lean.
Integrity to the rescue.
Here is how it can work with integrity management:
At the team leader weekly meeting:
Team leader B: “the team will commit to writing an encryption.”
Team leader A: “we already have an encryption”
Team B: “great, can we have it”
Team A: “sure, but we will have modify our code”
Team B: “so can you commit to modifying your code?”
Team A: “well, we have other things to do”
Team B: “This is critical for our development, but we can use it only for ourselves”
Team A: “The company will benefit from it, so sure, we will modify this code”
Team B: “Do you know, when can we have it ready?”
Team A: “I will get back to you and tell you”
After Team A’s weekly meeting, Team B is told:
”We intend to complete the rewrite by the end of the week”
By Wednesday, team A understand that it will take some more time, they tell Team B:
”We need to change that, We intend to complete the rewrite by Monday EOD”
Monday EOD, Team B gets the new library to work with.
Notice that team B, doesn’t need a daily meet with team A just to ask for the status (all other tasks that they are doing are not really interesting), they can spend their time working. The end result is that the the organization did what is in its best. The communication is clean.
In the following week, while talking about the status, team B will say.
“We had a dilemma, we didn’t know if we should wait for team A or write an encryption library ourselves , but they committed and we never had to ask them about the status and even though there was a glitch, we knew about it and managed to do other things. This worked out really well!”
When managing integrity, the manager never talks about what to do. The manager can talk about goals, or even better ask the team what they think their goals should be.
Doing this makes delegation seamless as each employee commits to what they think will be in the best interest of the company.
Do Google get it? I think so, see this post
"Seems like many things at Google, are voted on, or managed by peer reviews. An example are their quarterly objectives and key results. They are done bottoms up with very little top down input. Google’s approach is to hire the smartest people they can and then ask them what they should be doing."
Although I don’t think that smart is necessary the trait to look for (although if you have the privilege to hire only the smartest, go for it).
I think that passion and integrity is all you need. Having the passion and managing your integrity will eventually lead you to being smart, more then just smart, becoming a star.
I have had this problem from a different angle. When asking some employees for their daily/weekly commitments, some employees take the task breakdown too far and have a really long list of stuff that they commit to. Its is normally a long long list full of small tasks.
For Example, Lets take a team who has a weekly commitment to validate the Disaster Recovery Program (along with other commitments)
On Tuesday standup one employee says that he intends to:
- Unpack a new detachable disk
- Plug it on the network
- Ask IT to help configure it
- Run a backup
- Install a new restore VM
- Run a restore on another machine
- Validate the restore VM
This is fine and it is a good way to manage oneself, but the team doesn’t really have to know about this, is such detail.
Group the items
The manager/team at this point should say: Ok, lets group that. So you intend to:
- Verify that the SVN backup works.
That person can (and probably should) make the list for himself, so that if he sees that he is not going to fulfill his commitment, he can tell the team
- I will finish the backup only by tomorrow noon
At which the team might find a way to complete its weekly tasks anyway, and no event goes up the stream, or they might have to tell management about the new time table.
When raising the event use the grouped task
The commitment to management was validate the Disaster Recovery Program this week. If the team can still do it, so there is no need to tell management. If they can’t, they say:
- We won’t finish the DRP validation, this week, it will be done by Monday Evening.
Here management doesn’t get the noise but get the status of the tasks without needing to go to any meetings at all. At this point the manager will try help solve the delay.
In the chart above the tasks are broken as we go right, When a delay event is risen the tasks are grouped as we go left.
If we manage to solve it (above), all is fine, if not (below) management can make the right choices as it knows exactly what the status is.
No need to wait till the end of an iteration to know where we stand and no need to go to standup meeting of all the teams.
Ahhhhhh! At one time, this sounded so true. I felt that my managers where hindered me from doing my work, just get out of my way. Now I couldn’t disagree more.
Some time ago I asked one of the managers about the ABC team. S/he answered, oh, they are doing fine, they are heading forward at great speed. They don’t need my management. They are a self managing team. I don’t want to touch that team, it is working, and anything I will do will just disturb.
The first question that popped into my mind was: Ok, so why do I need you? What value are you adding?
So how do you manage self directed teams?
(hint: The team does need a manager)
Due to the overwhelming request by the community, we have received thousands of e-mails from .NET developers, that almost crashed our servers. And after we have had serious discussions with a large software company, we have managed to find a way that will allow us to open source Typemock Isolator for the benefit of the community (and of myself
It will take us some time to clean the code, but in the meantime we have uploaded the sources to codeplex, you can download them here.
[Update: Got-Ya! This is an April fools]
- Product Status Peek – 2011
- Thanks Roy
- Typemock starts 2011 in a new location
- Agile Demos Smells
- I want loud disputes in our meetings
- .NET Tests
- Code Integrity
- Management for Geeks
- Time Management
- Unit Tests
- January 2011
- December 2010
- October 2010
- August 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006