Let you team members be creative!

People in the software business are creative by nature. They have their own ideas of new stuff to do, new ways to develop things, etc. They just don’t have the opportunity to bring their ideas to life. In software development business people are usually overloaded with tasks that are boring and not interesting to them. They end up the working day squeezed like a lemon and they have no energy to work on the things they like. Day by day they are losing their creativity and are slowly transforming from artists to mere office workers.

So here are my advices:

• Give them some time to work on their own ideas. Make your plans in such a way that there should always be time for your team to think and work on the things they feel interesting for them. This way you will be able to keep them creative and to maintain their trust in you.
• Listen to their ideas. People need to share their ideas, thoughts and conclusions. Be the one who listens and you will become the one who they trust and who they are going to follow anywhere. Besides, sometimes their ideas might be very useful for your business.

What do you think about the best motivation? Please, share your thoughts with me.

By the way, Bas offers a free ebook version of his book “Surprise! Now You’re A Software Project Manager” to the one who gives the most interesting answer to this question, so you can go to his post and give your comment there to have a chance to win the book.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.

You may also find these posts interesting:

• How would you reward your employees – cash or gift?
• Who Does Money Really Motivate?

I started thinking and looking for some more blog posts on delegation and I came to some conclusions which I would like to share here with you.

Delegation is a two-way street, says Richard Lannon. Yes, this is an important thing that we shouldn’t forget. And when we assign a task to someone and we hold them responsible for it we have to have in mind our reasons to delegate and their reasons to accept it.

What are the issues from our perspective? There are two major questions we must ask ourselves: Why to delegate? and What to delegate?

The most common reason we refrain from delegating is our streak of perfectionism – we think we can do it better or faster than the others or we just don’t trust them. Krishna Kumar has a great post on the reasons of our distrust towards our team and how can we overwhelm them. Penelope Trunk says that our ability to do things perfectly isn’t as highly valued as we think it is. In fact, perfectionism isn’t valuable in 80 percent of the work we do and it is so unhealthy that it’s a risk factor for depression. We have to learn to let go. We can’t control everything so we must trust the people in our team.

Another common mistake is to outsource the most unpleasant and dirty work to the others. Penelope Trunk says that if you don’t do any of the crap work, your team will think you do nothing and you won’t be accepted as a part of the team. You must keep for youself only those tasks that are your specialty and to delegate all the other tasks to the people who can do them best.

On the other hand, you should put yourself in your team members’ shoes. They always ask themselves “What’s in it for me?”. Penelope says:

“Important work” means that it helps someone meet their own goals. So you should delegate to people not based on what is important to you, but what is important to them.

And more:

Your job is to help make people stars. Management is essentially an act of constant giving and constant patience. It entails giving people a little attention all the time instead of giving them lots of attention only when they mess up. In fact, if you’re managing people effectively they don’t mess up, because you play to their strengths and teach them how to move around their weaknesses.

People want to grow. and the most effective way of learning is by doing things. When you delegate your team members tasks, when you hold them responsible for those tasks fulfillment, they will learn a lot even if they make some mistakes.

The number-one factor in job happiness for young people is training. If they think they’re learning a lot on the job, they’ll like the job. You need to constantly coach these employees and teach them new skills and ideas. If you don’t, you won’t be able to lead them.

Perfectly said. Now that’s what is most important in delegation.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

You may also find these posts interesting:

• Krishna Kumar Did An Interview With Me On Software Development
• The 15 Commandments of the True Leader
• The Recommended Weekly Readings (2007-08-18). Project Management
• The 20 Qualities of the Inspirational Leader

Rich has created his own blog recently and there you can learn more about his book-writing experiment as well as about crowdsourcing. He also wrote a post in PM Hut where you can learn more about the relationship between crowdsourcing and project management.

I found the idea of crowdsourcing intriguing and I followed some of the links he recommended. So I got into the site of Cambrian House – the home of crowdsourcing. This is a very interesting place where people share their ideas and get help and advices from the others. I am not sure if it can really bring good results as it sounds pretty much like the OpenSource idea and I am not very fond of OpenSource but I will give it a try for a little longer before I make some conclusions. You can try it by yourself – the registration is free!

Rich’s blog is called Scope Crêpe, which sounds just like scope creep – the worst project manager’s nightmare – and was intended to be funny. I put his blog immediately in my RSS reader – there are a lot of things we can learn from Rich Maltzman and with such sense of humor I believe his blog could never be boring.

Good luck Rich! I wish you a lot of grateful readers!

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

You may also find these posts interesting:

• Techniques for Gathering Requirements
• Classic Mistakes Forever!
• Project Management and Hiking
• The role of the Business Analyst – poll results
• The Project Management Theories According to Bas de Baar

He says that there are two types of programmers – Type 0 (20%) are the people who program for fun. These people live programming, they breathe programming. They use Linux and they contribute to Open Source projects. In other words (although he doesn’t say it), these are the good guys, the smart guys. The other group are Type 1 (80%) – people who practice programming for living. They work from 9 to 5, they use only Microsoft technology and they don’t read the technical news. “They are not stupid”, he says but I believe it is just what he means because the final appeal is to the smart guys to swallow their pride and to hope the stupid guys become smarter.

If you feel that you belong to the Type 1 programmers, the stupid ones, don’t worry – one of the most important characteristics of the 20% group is that they read blogs, especially Jeff’s one. So you just need to read one article of his and you’ll automatically become a member of the elite group.

Sorry Jeff, I don’t buy it!

I would agree that we can separate the programmers into two groups – one for the people who like programming for the sake of the programming itself, and another for the people who provide value with the applications they write. But this definition is so archetypal that it doesn’t bring much of a value. And claiming that the developers belonging to the one group are smart and the others are dumb, is not only insulting, it is just wrong.

First of all, I have never seen a programmer, who had never read a technical web site or a blog. Second, nobody has counted the programmers and there is no evidence that the ratio is 20/80. I believe the numbers are just taken from the Paretto principle without any backup survey. Third, to accuse someone for being stupid just because they value their private time or because they use Microsoft technology, is just flaming another religious war.

The software development is a business like any other. It is important and powerful one. This business needs the two types of people – the ones who love the process of programming, who create and invent new ideas and new solutions, and the ones who make those ideas reality, the ones who implement the customer’s requirements and bring real value to them. Perhaps the real ratio should be 20/80, or 10/90, or whatever – it depends on the business area. The point is, all kinds of developers are valuable because they bring value in different ways. Their diversity is their richness.

You cannot call someone stupid or inexperienced only because he or she doesn’t write code during the night or because they write in Visual Basic .NET. One is inexperienced because she lacks experience. An if you are more experienced you can help them by sharing your experience and by showing them good sources of information. People learn and people change and very soon they will have more knowledge and more experience and will be professionals just like you.

This post is also available in Bulgarian language. 

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

You may also find these posts interesting:

• Funny Computer Quotes

Reason Number 5:
Pros: It saves energy. While you work at home you don’t waste time and effort for traveling.
Cons: It wastes energy. When you have to travel, you waste a lot more than if you worked in the same country and in the same office.

Where is the problem? Why these guys think so differently upon the same situation? My answer is very simple. The very definition of the “distributed team” they use is different.

When I ask myself the question “What does a distributed team mean?” I divide it into the following questions:

1. How distributed is the team? If the team works in the same town and they don’t work constantly in the office but instead they work at home I believe it really saves money and energy and this kind of distributed team works effectively because they don’t spend time traveling, they use their own computers and they only need a good internet connection to do their work (especially if the team doesn’t need any other special technical equipment). But if the team is disbursed through the globe then it might not be cost-effective at all. Especially if there are long time differences and there is a need to meet face-to-face frequently.

2. How often do they need to meet? It depends on the nature of the project. If the project is a more R&D-oriented then it would require more frequent meetings, which is not good if the team is dispersed. On the other hand, if the work is more routine and there aren’t much things to discuss, it wouldn’t be a problem that the team members work at different locations and meet rarely. But nobody said that the structure should be fixed all the time! If you are allowed to play creatively with the budget, you may find that the best way is to gather the team for a short time in one place, do the brainstorming and the research, make all the decisions and then split them back so everyone can work from their location for the next period. Later, you can bring them back again if necessary. You just have to make your calculations and to judge the effectiveness of the team working together and working from their homes or local offices.

3. How urgent is the project? If the project is some kind of a “Death march” it is obvious that the distributed team wouldn’t be able to handle it right. You need your team to be with you all the time so you can keep their motivation and work energy at high volumes. But if the project is well-planned and it allows people to work with a normal pace, a distributed team may be a more effective solution since it wouldn’t require a “management pressure” on the team members.

I strongly believe in the effectiveness of the distributed teams where the people are not far away from each other and the nature of their work doesn’t require them to meet too frequently or to respond urgently to user requests. It is difficult to manage such a team but if you do it smartly you can make your project more profitable. but before you decide should your team work at one place or at different locations, ask yourself these questions and judge carefully.

You may also find these posts interesting:

• Project Management 3.0

There are two extremes about this approach. On the one side is the management’s urge to shorten the project’s duration leading to unrealistically short schedules. Sometimes the developers (usually younger and inexperienced ones) get infected by the flowing optimism and make unrealistic estimates, which you know are impossible to meet. Then, when you make the final schedule you add some percentage of time (usually between 10% and 20%) to make sure that even after the management shortens your schedule you will still have the necessary time to complete the project on time.

On the other side there is a different story. Your team members are experienced enough, “old dogs” who know that whatever estimate they give, the management will cut it. Then they add this padding by themselves and their estimates become unrealistically longer. This way they want to make sure for themselves that after you or the upper management shortens the schedule, they will be able to fulfill their tasks within it.

And here are the questions I ask myself and because I can’t give a straight answer I want to put them to you:

• Do you know how your team members make their time estimates?
• Can you judge if their estimates are accurate?
• Do you know whether they estimate the tasks duration too optimistically or they put reserve time (padding)?
• Do you make any corrections to their estimates?
• Do you add your padding knowing that the management will shorten the schedule and will put you in a “Mission: Impossible” project or you shorten it by yourself knowing that your developers already had added extra time in it?

Thinking deeper a more serious question arises:

• Do you communicate your opinion within your organization honestly (your team members to you and you to your upper management) or you try to outwit each other?

I am waiting for your comments impatiently.

You may also find these posts interesting:

• Project Management and Hiking

I wrote a post in Bulgarian about the role of the business analyst in a software development team and I put a poll to survey how the people in the software development business in Bulgaria evaluate it. Now the poll is closed and I am giving you the results.

Question: How do you evaluate the role of the business analyst in your team?
Total votes: 27 (little but I still have few readers).

Answers:

1. Very important role. The BA investigates the customer’s needs and represent them before the team – 14 votes (52%)
2. All roles are equal. The BA is responsible for the functional (requirements) specification, which the developers implement – 6 votes (22%)
3. We don’t need such a person. The developers do the client’s business analysis themselves – 4 votes (15%)
4. What is a “business analyst”? – 3 votes (11%)
5. He just hangs around here and looks silly. He cannot write a simple JavaScript – 0 votes (0%)

How to interpret the results? Obviously, the first thing that has to be noted is the small number of the votes. For me, the main reason is the fact that still very few people visit my blog and most of them weren’t impressed by the poll. I think I will open it again in the future when there will be more visitors to my blog.

Anyway, the good news is that despite the few voters, the results show that the position of the business analyst exists in the software teams nowadays and it is appreciated positively. No matter if considered as very important (answer #1) or considered equal to all the others (answer #2), the business analyst takes his/her well-deserved place in the software team (totally 20 votes for both answers, which gives around 74%)

Answer #5 is rude and represents the vulgar and arrogant attitude of some developers to the surrounding world that doesn’t write code. I am glad that nobody voted for it. It probably means that this attitude was already buried in the past.

Answer #4 is a little silly. How can you be a self-respecting developer and not know what a business analyst is? I put this answer on purpose with the intention to be chosen for fun and to make the poll more colorful. I believe that this was the intention of the three guys who voted for it. And if they really don’t know what this is – keep on reading here – there will be more posts devoted to the job of the BA.

The most interesting answer for me is answer #3. It has a double meaning. There are companies, on one hand, that work on small projects or such that work on products and don’t use project principles at all. In such companies, every developer, having been working long time on the same product and having been communicating with the field experts from the business area being automated, gradually begins to gain exactly that knowledge and experience, which make him or her a business analyst. And if you add the aspiration of the company for more exploitation of its employees we come to a natural merging of the role of the BA with the role of the software developer in one person.

However, there is another interpretation. The team (or the company) could consist only of “great programmers” – people who think they know, understand, and can do everything. It was the ideal of the past socialist society in Bulgaria – so called “multi-dimensionally developed persons” – people who believe that a developer should be skilled in every aspect of the software business and there is no need of a narrow specialization in particular areas like business analysis, project management, testing, user education, etc. The developer can do everything!

I really would like to know what were the reasons to vote for this answer. I hope some of the voters will post a comment about it. And if you have an opinion about the role of the business analyst in your team – please, share it with me. It will be useful.

You may also find these posts interesting:

• My day-to-day work as a Business Analyst
• How Did You Become a Project Manager – Survey Results
• How Can a PM Become a Real Leader?
• The 20 Qualities of the Inspirational Leader
• The 3 Most Important Qualities of a Project Manager

But in a while, after reading his post and the article he cites I started to realize that there is nothing new under the sun – it’s just a new, fashion name for the thing we already know.

Obviously, the version numbers 1.0 and 2.0 were created by the agilists. To put it roughly, PM 1.0 refers to the classic or heavy methodologies in project management. They focus on large projects, large budgets and big teams. Ugly Gantt charts, many stakeholders, horizon and beyond timelines and (note!) expected failure! PM2.0 respectively has only positive characteristics: small teams, made of smart and motivated people (does it mean that the large projects are performed by dumb people?), fast pace, feedback, responsiveness, etc.

It smells like a religious war from very far and isn’t worth mentioning. As Glen Alleman says in his blog Herding Cats, if you want to show the advantages of the agile methodologies you shouldn’t compare it to Waterfall because “Waterfall is dead, dead, dead“. The modern version of the “classic” PM approaches like PMBOK and Prince2 also embrace change and calling them “heavy” or “rusty” is not relevant anymore.

What caught Bas’s (and mine) attention is the idea of “Social Project Management”. As he states:

The Project Management style, and the supporting tools have to be “social”, and now more then ever. The project landscape is turning mobile, multi-cultural, 24×7, highly distributed and in ever flux.

But this situation will increase the risk of getting into some social “booby” traps and he points out the three most important ones:

1. Communication trap: proper understanding of what the other stakeholders need in the project;
2. Trust trap: letting go of control and hoping people still do what they are supposed to do;
3. Isolation trap: no sense of belonging to the project through geographical, cultural and timezone differences.

This is the Project Management 3.0 and the real challenge for it will be a social one. According to Bas, this is the place were social software can help a lot. Not only in collaboration but more in building a sense of community, enhance trust and stimulate open communication.

You can read his entire post here.

You may also find these posts interesting:

• Krishna Kumar Did An Interview With Me On Software Development
• Top-down Planning – Good or Bad?
• The Pros and Cons of Distributed Teams
• Project Management and Hiking
• The Recommended Weekly Readings (2007-08-18). Project Management