Become a Generalizing Specialist or T-Shaped

A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in both his or her existing specialties and other areas. A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few.

A generalizing specialist does one kind of job very well and some other jobs adequately. With generalizing specialists your teams enjoy the benefits of high productivity, while lowering the risk of bottlenecks, and retaining flexibility. There is another similar concept called T-shaped people:

We look for people who are so inquisitive about the world that they’re willing to try to do what you do. We call them “T-shaped people.” They have a principal skill that describes the vertical leg of the T -- they’re mechanical engineers or industrial designers. But they are so empathetic that they can branch out into other skills, such as anthropology, and do them as well. They are able to explore insights from many different perspectives and recognize patterns of behavior that point to a universal human need. - Tim Brown, “Strategy by Design”

There are many benefits of having T-Shaped people in team

• Better communication even with less documentation, if someone has an enthusiasm or curiosity about many different subjects and disciplines, then they can be more flexible, more empathetic, and more engaged with the world
• Better bottlenecks management, as T-shaped person can do other jobs adequately, he can contribute in other jobs if required.
• Better solution of the problem , If the only tool you have is a hammer, you tend to see every problem as a nail. ~ Abraham Maslow , The T-shaped person can explore the problem from many different perspectives and that helps in driving better solutions.

How to become T-Shaped person? You need to find your own answer, some suggestions

• Reading is a good method: There are some great books and Web-based resources available; you need only to invest time to take advantage of them, follow some good blog, one need to read more than just technical publications.
• Participate in community activities, thanks to internet and many popular social media sites ,its easy to participate in online and face to face community activities , join some good groups 
• Do some experimental projects in your non core areas, say if you are C# expert, try to make something on python.
• Share your knowledge , if you do this other will also follow and that will help you in acquiring new skills
• Find a mentor for a target skill, mentor could be junior to you…but he has to be expert in the skill you want to acquire  

Avoid making people Indispensable

Every individual in a team has a important role to play, but in the interest of individual, project and organization, leaders should not allow people to become indispensable. Lots of career articles have been written about “How to make yourself Indispensable..” the tips like doing more than expectation is essential for professional growth but it should not let person become indispensable. The important part is we should motivate people to become more knowledgeable, productive, friendly and professional but not indispensable.

Indispensability can create issues like 

• Poor Team Productivity , the person become too busy and as a result there may be many tasks kept waiting ,and because of his queue other may not be able to start their activities
• Create Risk for project timeline, if the person is not available because of any reason it puts project timelines on risk
• Monotonous work, as he can only do some of the work, people keep coming to him only for the same work.

Some of the measures Project team can take to avoid Indispensability

• Continuous knowledge sharing, team should create environment of knowledge sharing. 
• Task rotation, we should keep rotating people between modules, so there should be more than one developer who codes for one use case.
• Educate team to become more professional, the growth in career happens by sharing knowledge not by keeping secrets.
• Put process in place, process like one codes and other does the review, one codes and other fixes the bug, peer programming and group design can institutionalize the knowledge sharing. 

Murphy's Laws of Project Tracking

1. Projects progress quickly to a 90 percent completion factor, and then stay at 90 percent forever.
2. When things are going well, something goes wrong.
3. If the content of the project changes often, the rate of change will always overtake the rate of progress.
4. A poorly planned project will take three times longer to complete than expected; a well-planned project only takes twice as long to complete.
5. Members of the project team will ignore your progress reports because the reports portray the limited progress that has been made.
6. When you know you've thought of everything, you haven't.

Classic Mistakes in Software Projects

I am Reading “Rapid Development: Taming Wild Software Schedules”, this book talks about Four Dimensions of Development Speed

• People
• Process
• Product
• Technology

It talks about classical mistakes ; here i have list out mistakes from book and some from my own experience, do add to it..we need to learn from others mistakes

People Related Mistakes

1.   Undermined motivation

2.   Weak personnel

3.   Uncontrolled problem employees

4.   Heroics

5.   Adding people to a late project

6.   Noisy, crowded offices

7.   Friction between developers and customers

8.   Unrealistic expectations

9.   Lack of effective project sponsorship

10.  Lack of stakeholder buy-in

11.  Lack of user input

12.  Politics placed over substance

13.  Wishful thinking

14.  Lack of team sprit

15.  Communication gap , No knowledge sharing

16.  Lack of Assertive communication

Process Related Mistakes

17.  Overly optimistic schedules

18.  Insufficient risk management

19.  Contractor failure

20.  Insufficient planning

21.  Abandonment of planning under pressure

22.  Wasted time during the fuzzy front end

23.  Shortchanged upstream activities

24.  Inadequate design

25.  Shortchanged quality assurance

26.  Insufficient management controls

27.  Premature or overly frequent convergence

28.  Omitting necessary tasks from estimates

29.  Planning to catchup later

30.  Code-like-hell programming

31.  Poorly managed critical path or critical chain

32.  Poor task prioritization or Sequencing

Product-Related Mistakes

33.  Requirements gold-plating

34.  Feature creep

35.  Developer gold-plating

36.  Push-me, pull-me negotiation

37.  Research-oriented development

38.  Not using value engineering

Technology-Related Mistakes

39.  Silver-bullet syndrome

40.  Overestimated savings from new tools or methods

41.  Switching tools in the middle of a project

42.  Lack of automated source-code control

43.  Lack of Automated test tools