Are you developing self driven teams?

During the course of helping clients execute their projects, I observed a common theme across industries. There was a disproportionate amount of project leaders who were strong “drivers” and were “making things happen”. However, beneath the surface revealed teams that became dependent on having such drivers in place.

So I went and re-read Steve Yegge’s landmark article on “good agile, bad agile”. He talked about emergent properties versus the whip. In most organizations, CEOs put “whips” in place to drive projects to completion.

How do you know, if you are in a similar organization? Here is a simple formula:

Take the number of meetings you have every week and multiply it by the number of written status reports you have to provide. If the number exceeds 5, you are probably in an organization that has multiple layers of “whips”.

Ask yourself the question: if no one were to tell me, would I have a clue about what I needed to do for the next 3 months? If you are having trouble coming up with the answer – you are probably in an organization which has not worked on creating emergent properties.

Now surely, there could be a healthier way to promote self-organizing teams. Are we inherently flawed such that in absence of strong direction and push, we are simply incapable of reaching a goal? As teams within organizations, have we just accepted the fact that instead of strong team players with single minded vision, we need to rely more on strong drivers who can push people to get things done?

Ricardo Semler set something in motion at his company. Google believes in emergent properties and incentivizing teams towards self-driven launch goals. Southwest Airlines practices what they call “warrior spirit yet servant’s heart” . But such companies stand out among hordes of other companies. These are companies that are not only ahead of their competition in terms of the best workplaces, but also outperform others in the long term.

Recently, at a conference, I had a chance to interview ReadyTalk co-founder Scott King. ReadyTalk was recently chosen as one of the best places to work in Colorado. According to Scott, their main goal is to be a great place to work at, rather than be the largest company in their chose market space. They intentionally avoid external investor pressure and work hard on their organizational culture as they firmly believe that employee satisfaction reflects directly on a company’s bottom line.

In conclusion, look for signs of a “whip” on your team, don’t panic. Understand the motivations and work with your team on being self-propelled towards a common goal.

This entry was written by Amit, posted on October 30, 2009 at 5:09 pm, filed under leadership, teamwork and tagged leadership, readytalk. Leave a comment or view the discussion at the permalink.

10 ways to ensure failure to produce great enterprise software

Where do most enterprise software projects go wrong? As a software manager, how can you ensure that the next application your team is about to build will revolutionize your enterprise? Here are my top ten ways to ensure failure to raise the body of work beyond mediocrity:

1. Have no real vision behind the project: If the application is not really going to solve any real pains for the consumers of the applications, don’t do it. Cost savings, ease of maintenance – are all noble goals in themselves, but not as worth doing as making that application more useful for the end users.
2. Outsource everything to a consulting firm: Firms like Ideo are great when it comes to pinch-hitting that creative idea for you. However, they are not you. Consulting firms cannot replace the lack of in-house talent. They are not a sustainable model when it comes to creating innovation from ground up within the organization. So send your staff to learn from companies like Ideo, but give them fertile ground to grow the organization from within.
3. Implement only the customer’s stated desire: If the innovative direction of your product is purely driven by the “stated” features desired by customer, you are putting the customer solely in-charge of the product. Listen to the customer, but don’t put them completely in-charge. Listen, observe, re-learn – from both stated and unstated desires.
4. Shield developers from customers: Developers develop software. But have they put a face to the end user who may use the product? Do they feel the connection on a human level? Do they understand the frustrations experienced by the end users? A relationship with the users will result in better product than a relationship with a requirement specification.
5. Time-box everything: Letting deadlines drive launch decisions rarely proves to be sustainable. Do it if you can really be ready, but don’t sacrifice quality to meet a launch date. It’s not worth the negative karma from customers.
6. Deny mistakes: Nothing is more refreshing than companies admitting they got it wrong. Nothing will restore the respect for you as a leader if you admit a bad decision. Refusal to do so will build a culture around you in which failure is seen as something terrible and to be avoided at all costs.
7. Don’t take time to play: If you want your team to be excited about coming back to work on any given Monday, then you have to make time to play. Channel play time into concrete innovations.
8. Don’t talk to everyone: Don’t get second hand information from the layer of hierarchy that reports directly to you. Take time to wander around, mingle and get a real grip on problems that may prevent the software from being successful.
9. Don’t harness everyone’s ideas: You are the boss. Are your ideas are the most important? Wrong. Ideas that will solve your company’s problems may be closer and cheaper to find than you can imagine and they may not be your own. Start by asking your staff. Continue by inspiring them to improve every single day.
10. Have two different game faces – one for employees and one for investors: If your team has no idea into the strategic decisions and direction the company is taking, and they have no idea of company’s financials, they may never understand some of motivations for project decisions. Bring their heads into the game.

This entry was written by Amit, posted on May 17, 2009 at 10:10 pm, filed under innovation, leadership, teamwork. Leave a comment or view the discussion at the permalink.