Leading Software Development Teams

1. Leading Software
Development Teams
ARNO HUETTER
(Based on a presentation held at GRZ IT Center, Austria)

2. About the Author
Arno Huetter
Arno wrote his first lines of code on a Sinclair ZX80 in
1984.
Over the years, he has been programming in C/C++,
Java and C#, and also did quite some database
development.
Today he is Development Lead at Dynatrace (APM
vendor).

3. Leading Software Development Teams
“The major problems of our work
are not so much technological as sociological in nature.“
(DeMarco, Lister in: „Peopleware“)

4. Cornerstones of Leadership Behavior
 „Leadership, like software, is built upon a foundation. For software, the foundation is
the architecture. For leadership, it‘s your character.“ (Rainwater, H.)
 Understand: The battle for market share is won by leaders who know the nature and
methods of software development. People who "see the forest AND the trees".
 Communicate: Be an evangelist, convey enthusiasm, share knowledge. Good
communicators are also good teachers. Be careful when making unprepared, casual
remarks.

5. Cornerstones of Leadership Behavior
 Delegate: Select the right people for the right tasks. You can delegate tasks, but not speed.
One effective form of delegation: Senior+Junior pair programming.
 Check: No expectation without checking. Daily builds. Automated tests. Obtain feedback
from employees. Code reviews. Weekly project status meetings. Four eyes principle.
Documentation.
 Participate: Participation of leaders in programming and tests (limited in time). The best
leaders are not only coaches on the sideline, but are part of the team. Important signal to
employees.

6. Cornerstones of Leadership Behavior
 Mentor: Enhance problem-solving skills of employees. Attract future leaders. Your own
effort will have multiplier effect. Knowledge sharing.
 Reward: Compensation for extraordinary commitment. Fair, reasonable and timely
procurement. Several forms possible (financial bonuses, concert tickets, etc).
 Revise: Prevent sloppy code and inadequate solutions. Suggest how to fix things, support
implementation, aim for team learning effect. No blame game, but identify employees not up
to the task. Bring them up to speed, and if that doesn’t work, replace them. Be a role model
- leader’s negligence damages quality awareness.

7. Cornerstones of Leadership Behavior
 Anticipate: Look beyond the day-to-day business, create an image of the future and inspire
and motivate employees.
 Adapt: Adapt behavior to the problem at hand, accept challenges, learn new skills.
Problems are also opportunities.

8. Win Followers
 Sense of duty: Loyalty to team and product. Have pride on what has been achieved so far. Be
part of a winning team.
 Admiration: People will follow leaders whom they admire. Keep consistency in management
style, leadership effectiveness and in communication with employees.
 Environment: Create a working environment which by itself is already rewarding.
 Knowledge: Knowledge is power, especially in software development. Be and remain an
expert, share knowledge.
 Other forces: Market and competitive situation, payment.

9. Developer Types: The Good
 The Architect: Works on large-scale tasks, problem solving by abstraction. Danger:
Disconnected with developers and their needs.
 The Designer: Works intuitively, solves problems by code. Danger: Lack of documentation.
 The Artist: Creative work, builds intuitive user interface out of requirement spec. Risk:
Inefficiency and lack of design.
 The Engineer: Handles complexity by reduction.
Risk: Lack of flexibility if requirements change.

10. Developer Types: The Good
 The Scientist: Problem solving according the principles of theoretical computer science,
purists. Danger: Impractical solutions.
 The Speed Demon: Rapid implementation, adherence to the timetable at all costs. Danger:
Hidden defects.

11. Developer Types: The Bad
 The Sloppy: Faulty code, poor structure, violation of coding conventions, no tests.
 The Intimidated: Missing own initiative, doesn’t know how to start, can't deal with
incomplete information.
 The Amateur: Lack of training and experience, overestimation of one's capabilities.
 The Ignorant: Close-minded towards technological innovations, doesn’t want training,
doesn’t embrace change.
 The Salad Cook: Badly proportioned blend of
Engineer, Sloppy and untalented Artist.

12. Software Craftsmanship
 Software development is more labor-intensive than ever before. Developers are often
considered the "most expensive resource”.
 Countermeasure attempt #1: Quick training programs: FAILED. Software development
requires more than the mere knowledge of the syntax of a programming language.
 Countermeasure attempt #2: CASE tools: FAILED. Forced developers to apply one way of
model-building and of (what was left of) coding.
 Code is still the best abstraction model. De-qualification and industrialization are
wrong approaches. Automation is useful, but has limits.

13. Software Craftsmanship
 Software development as a craft. Mastery of a craft is only possible after years of learning
and practicing.
 Once the craft is no longer actively exercised, skills will dwindle.
 Apprenticeship: Situational learning. Execute easy tasks unescorted, more complex tasks
under the supervision of the master, Learning by example.
 Don't see developers as "most expensive resource", see them as your most important
asset!

14. Successful Teams
 A cult of quality: Quality awareness is a strong team catalyst. Only works in conjunction
with entrepreneurial long-term thinking.
 A hint of elitism: People need the feeling to be unique in some way. Corporation-wide
consistency might seem desirable at a management level, but is counterproductive.
 Allow heterogeneity: It's OK to not be a corporate clone. Add value, e.g. women in
otherwise male-dominated development teams.

15. Successful Teams
 Successful teams should stick together. Take the momentum for the next project after
completion.
 Specify direction at the strategic level, but avoid micro-management: Identify key
employees and equip them with corresponding liberties. "Flow of free electrons".

16. Destructive Forces
 Defensive management: Decision making without consulting employees, shows lack of
trust.
 Bureaucracy: Pointless production of paper, actual work comes in short.
 Physical separation: Distribution of a project team. Phone calls rather than direct
interaction.
 Fragmentation of work time: Allocation to multiple projects.

17. Destructive Forces
 Compromise on quality: Reasoning for cost reduction, but actually increases costs. Low
employee identification.
 Artificial deadlines: Most probably not taken seriously anyway.
 Inspirational slogans: Triumph of the outer form over the inner substance.
 Permanent extra hours: Can not be delivered by everyone (consider family situations,
etc).

18. Motivational Factors
 Two-Factor Theory (according to Frederick Herzberg)
 Hygiene factors: Prevents emergence of discontent by means as income, safety, interpersonal
relations.
 Motivation factors: Motivation to perform, e.g. work content, recognition, responsibility.
 Motivation factors are of particular importance for developers who identify with their
profession. Usually these are the employees that are key for successful software projects.
 Set up for success: Many software projects fail, good developers
do not like to fail and therefore look for an auspicious environment.
Have professional project management, be a competent
development partner, ensure quality consciousness.

19. Motivational Factors
 Excellent people management: Know your staff, include team in decision-making, show
loyalty to employees.
 Variety in tasks and constant learning: Software developers likely have chosen their
profession exactly for those reasons.
 Problem-solving: Programmers love challenges, e.g. voluntary nightly coding sessions
until a problem is solved. In contrast, being under-challenged can have fatal effects.
 Find hearing: Developers usually sit in the front trenches, and might be the first ones to
register looming problems. When they speak out, they should be heard.

20. Motivational Factors
 Recognition: Being part of a successful product is motivating by its own means. In
addition, individual recognition should be articulated frequently.
 Take part in something that makes a difference: “Conquer the world”. Get rid of manual
routine work, improve communication. Don’t produce paper, produce a cool and successful
product.
 Non-bureaucratic decision making: Let employees take part in decision-making without
having a committee convened for every small thing.
 Deal with contaminated projects: Maintenance of legacy code or working under a lot of
constraints is not satisfying in the long term.

21. Hire the Right People
 "The most important practical finding involves striking individual differences in programmer
performance“ (Glass, R.)
 "Within a group of programmers, there may be on order of magnitude difference in
capability" (Schwartz, J.)
 "A few good people are better than many less skilled people" (Davis, A.)
 "The best performers are clustering in some organizations, while the worst are clustering in
others" (DeMarco, Lister)
 But: Large skillset deviation even among graduates of the same university. Formal
qualification criteria are insufficient. It’s the individual drive that matters most.

22. Smart and Gets Things Done

23. Interview Techniques
 Several interview rounds, including a test in practical programming. Form a hiring
committee, one NO-vote implies "no hire".
 No prejudices (e.g. due to formal education or the opinions of others).
 Introduction: Relax situation.
 Open question: Let candidate talk about a project he has worked on.
 Can he/she explain more complex relationships easily? Is he/she enthusiastic? Has he/she
overcome difficulties by own initiative?

24. Interview Techniques
 Solve a simple programming problem: Separate the wheat from the chaff. Quick but elegant
solution preferred.
 Solve a difficult problem of programming: "Understanding pointers is not a skill, it's an
aptitude". The approach is more important than the solution. Spark discussion.
 Applicant’s questions.

25. Chose the Right Employer - The Joel Test
 Do you use source control?
 Can you make a build in one step?
 Do you make daily builds?
 Do you have a bug database?
 Do you fix bugs before writing new code?
 Do you have an up-to-date schedule?
 Do you have a spec?
 Do programmers have quiet working conditions?
 Do you use the best tools money can buy?
 Do you have testers?
 Do new candidates write code during their interview?
 Do you do hallway usability testing?

26. Working Environment and Productivity

27. Working Environment and Productivity
 Separate offices rather than have cubicles: Plan for two to four persons per office with
sufficient space. Focus on people and their needs. Workplace equipment costs are low
compared to human resource costs.
 Freedom instead of uniformity: People need individuality (up to a certain level).
 Have phone-free times, avoid interruptions: "You never get anything done around here
between 5 and 9".
 "The Flow": Work under high concentration, maximum effectiveness (touch of euphoria),
only possible after a certain period of diving into a task.

28. Sources
 DeMarco, Lister: “Peopleware”
 Glass, Robert L.: “Facts and Fallacies of Software Engineering”
 McBreen, Pete: “Software Craftsmanship”
 Rainwater, J. Hank: “Herding Cats: A Primer for Programmers Who Lead Programmers”
 Spolsky, Joel: “Joel on Software”

29. Sources
 Spolsky, Joel: “Smart & Gets Things Done: Joel Spolsky's Concise Guide to Finding the
Best Technical Talent”
 Walling, Rob: "Nine Things Developers Want More Than Money“,
http://www.softwarebyrob.com/articles/Nine_Things_Developers_Want_More_Than_Money.
aspx
 Weinberg, Gerald M.: “Becoming a Technical Leader – An Organic Problem-Solving
Approach”
 Weinberg, Gerald M.: “The Psychology of Computer Programming”

30. Thank you!
Twitter: https://twitter.com/ArnoHu
Blog: http://arnosoftwaredev.blogspot.com