The deck has three parts: team development and the team needs pyramid (slides 3–24), team models (25–34) and managing people (35–77). The pyramid (trust → conflict → commitment → accountability → results) is the spine of the chapter and of most exam questions on it.

Team development first: how a group becomes a team.

Then three of the pyramid layers in order: building trust, managing conflict, embracing accountability (commitment and results are covered between them).

Then the team models (how teams are organized) and managing people (motivation, selection, culture, leadership).

Section divider: Team Development.

Discussion questions to open the topic. As a team member you own your tasks and support others; as a PM you build the conditions for the team to work: clear goals, roles, trust.

The link to the project triangle: a weak team costs you on scope, schedule or cost. People are the resource that turns the plan into results.

Individuals vs. team: a team of strong individuals who don’t trust each other usually loses to a well-functioning team of average people. Team strength wins.

“Characteristics of a good team” was a real midterm short question. Answer it with the pyramid, from the bottom up.

McConnell’s two reasons projects fail. Knowledge: the team doesn’t know how to run a software project. Training, hiring and process fix this.

Resolve (determination, commitment, mental toughness): the team knows how but doesn’t push through. This is what team building, motivation and leadership fix, and it is what the rest of the chapter is about.

The types of influence a PM can use. Formal (legitimate): authority granted by the organizational hierarchy or role. The skills table above lists the PM’s team skills (planning, negotiation, hiring, risk management, judgement) and the bottom table lists leadership styles (directing, facilitating, coaching, supporting, etc.).

It works because people want the reward, and it stops working if you run out of things to offer. Reward also requires that you actually control something they value, such as bonuses or interesting assignments.

Penalty (coercive): influence through the threat or use of punishment. It gets compliance, not commitment.

People follow you because you know the answer, even without a title. That’s why a senior developer can have more real expert influence over a team than their manager does.

Referent: influence based on personal traits, charisma or likability. Formal, reward and penalty come from your position; expert and referent come from you, and they last longer because people choose to follow.

The rule from Maslow: lower-level needs must be satisfied before higher ones can be addressed. On the left is Maslow’s individual pyramid; on the right the team needs pyramid (Lencioni).

The team pyramid from the bottom: trust, then managed conflict, then commitment, then accountability, then results. You can’t have healthy conflict without trust, or commitment without having debated the decision.

Results sit at the top: the team’s collective goals. The ticks on the slide show a team that has secured trust and conflict but is stuck at commitment, so the PM works on that layer next.

New people are careful and polite, and they look to the leader for direction. Forming feels calm, but little gets done yet, because people are still working out what’s expected of them.

Once people relax, they start to push back and test who has influence. Storming feels like something’s going wrong, but it’s a normal stage. The PM’s job here is to surface and manage the conflict, not suppress it.

Arguments settle and the group agrees how it will work, such as how decisions get made. Norming is when people start saying “we” rather than “I” and accept each other’s strengths.

People stop spending energy on how to work together and spend it on the work. Performing is what you’re aiming for, and the team needs little supervision at this point.

People may feel loss when a good team breaks up, so a proper ending matters: adjourning is when you wrap up and capture what was learned. Order: form → storm → norm → perform → adjourn.

A production outage isn’t the time for meetings and approvals. Problem resolution needs a small group that can decide fast. Once it’s fixed, the team usually disbands, which is why it’s a temporary task force.

You can’t order someone to have a new idea. Creativity needs freedom to try and fail, so a looser hierarchy and mixed backgrounds help, and punishing mistakes would kill it.

Here the plan already exists, so success depends on precise execution. Tactical execution favors clear roles and tight controls, and creative freedom would only get in the way. (The instructor noted she spent time explaining this slide.)

Section divider: Building Trust, the base of the pyramid.

Everything else in the pyramid depends on this. If people don’t feel safe, they hide problems and avoid arguments, so trust comes first as the foundation.

Most people assume that trust means “you’re reliable”. This kind goes further: it means being able to say “I messed up” and know nobody will use it against you. This list was a real midterm question, so learn vulnerability-based trust.

Words can’t build it fast, as people need to see you keep your word several times. So it takes time, and since one broken promise can undo months, it must be maintained.

Knowing how a teammate tends to work removes a lot of misunderstanding: “she’s direct, not rude”. Behavioral profiling is useful as a conversation starter, not as a label, and it lets the PM give people work that suits them.

A title makes people obey, but it doesn’t make them trust you. You have to show them through what you do, so trust is earned, not granted, starting from a natural wariness.

If people can’t tell you things, you find out about problems only when it’s too late. So open communication is risk management, and not just being friendly.

If the PM hides their own mistakes, everyone learns to hide theirs. Be fallible by owning an error openly, because that makes it safe for others to do the same.

People watch what you do far more than what you say. A PM who asks for punctuality and arrives late has told them what’s really expected. That’s why you lead by example.

Nobody expects perfection, but they do expect honesty. Telling people in advance that you’ll miss a commitment keeps trust, while a surprise and an excuse damages it.

Friendship ≠ leadership: warmth helps, but leading needs clarity and boundaries (repeated on slide 76).

Section divider: Managing Conflict, the second layer.

Think of healthy debate as a fight about ideas where nobody’s attacking the person. It only works if you trust that disagreement won’t be used against you, which is why healthy conflict sits above trust.

If everyone is always comfortable, tough topics probably aren’t being raised. So some uncomfortable moments are a good sign, not something to fix.

What’s normal in one team feels rude in another. Agreeing the rules up front, such as “challenge the idea, not the person”, stops arguments about how to argue. That’s what conflict norms are for.

If nobody challenges a weak design because it would feel awkward, the mistake ships. That’s the cost of avoidance, and groupthink is what it looks like: everyone nods, and nobody really agrees.

This asks “what’s really causing this?” and tackles that. It takes longer, but the problem doesn’t come back, which is why confronting isn’t the same as being aggressive.

Compromising: both sides give something up to reach a middle ground. Quick, but nobody gets what they needed.

These two feel peaceful, but the cause stays there and tends to return bigger. Withdrawal can buy time when emotions are high. Smoothing can suit minor issues, or when the relationship matters more than the point.

Each side’s view contributes something, so you may end up with a better answer than either started with. Collaborating takes time, so save it for decisions that matter.

Sometimes there’s no time to discuss, like during an outage. Forcing gets a quick decision, but people who were overruled won’t feel committed, so use it rarely.

Notice the first step: many teams solve the wrong problem because they jump to answers. The final step is the one often skipped: review whether it actually fixed the issue.

Conflict that’s ignored doesn’t go away, as it comes back in other forms, such as people refusing to cooperate. The difference is whether a team resolves it.

People can disagree and still work things out. It’s conflict once they’ve dug in, and each stops listening. Spotting that shift tells you when to step in.

Taking sides only spreads the fight and splits the team, so others stay neutral. The conciliator helps both sides listen again until it’s an ordinary disagreement once more.

Finally, aim for reconciliation between the two parties so the working relationship survives.

Ever left a meeting and found that everyone understood something different? Commitment fails that way, so a decision needs to be both understood and accepted.

A simple habit fixes most of this: end each discussion by stating what’s been decided and who does what next. Without that clarity, people act on their own assumptions.

People can accept a decision they argued against, as long as they feel it was fair and their view was heard. That’s why buy-in comes after debate rather than instead of it.

Waiting for everyone to agree can freeze a team. Great teams argue, decide, and then back the decision (“disagree and commit”). A common trap: “commitment requires everyone to agree” is false, because buy-in does not require consensus.

Section divider: Embracing Accountability, the fourth layer.

If only the manager enforces standards, you have one person chasing everyone. When teammates say “this isn’t up to what we agreed” to one another, problems get fixed faster. That’s accountability among peers.

If the PM lets poor work slide, the team learns that standards are optional. So the leader needs a willingness to confront it, and doing that respectfully shows others how.

Reviews work because the facts are in front of everyone. Note the tone in the slide’s example, about the commitment and what happened rather than who failed, in meetings and regular reviews.

RACI: Responsible does the work; Accountable owns the outcome and signs off (exactly one A per activity); Consulted gives input before or during the work (two-way); Informed is kept updated (one-way). Several R’s on one activity are fine.

It’s worth a mention because some companies use it, so you won’t be confused if you see RASCI. It’s for people who help out on a task without being responsible for it.

In the example, Activity 4 has the project manager as RA: one person can be both Responsible and Accountable for a task they do and own.

If nobody clearly owns a task, it tends to fall through the cracks, and two people may each assume the other has it. A RAM makes that visible, and RACI is just one way of filling one in.

During planning you assign the work, and during tracking you can see where a task has no owner. So it keeps its value after the first week.

On a large project you may not assign to named people yet, so you can start with a team or department. Row totals show if one person or task is overloaded.

A real RAM: project deliverables grouped by phase (initiate, plan, execute, control, close) down the side, and roles grouped as project leadership, team members, sub-teams and external resources across the top. Each cell holds a RACI letter, so you can read across a row to see who is involved in a deliverable, or down a column to see one role’s workload.

A RAM says who is doing what, while a skills matrix says who is able to. Use it before assigning work, so you aren’t guessing about abilities.

Skills can be high level or very specific (PHP, MySQL, React); cells can be X’s or numeric levels (the legend: expert, practitioner, novice). Use it to assign tasks to the right people and to spot gaps, e.g. only one person is an expert in a key technology, which is a key-person risk.

Everything below this exists for one reason. A team can have trust and good meetings and still have failed if it doesn’t deliver, so it’s judged by results.

A developer might want a clever feature for their CV, and a department might want its own goal. Team results come first, or everyone wins individually and the project loses.

If a goal lives in a document nobody opens, it can’t guide daily decisions. A public, visible goal also makes it awkward for anyone to quietly drift from it.

Section divider: Team Models, the ways a software team can be organized.

These are the two extremes. A democratic team gets better buy-in but decides slowly, while an autocratic one decides fast but depends on one person’s judgment.

The variation in between, controlled decentralized, has a leader who coordinates while sub-groups decide within their own areas.

Why is it so common? It’s simple, so everyone knows who to ask and who answers to outsiders. If a question doesn’t mention anything special, the business team is the safe assumption.

One lead keeps responsibility clear, while the rest of the team stay equal. Strong suits a new or inexperienced team, and loose suits a skilled one. It’s this flexibility that makes it general.

Trust has to come first. A new team asked to decide everything together would stall, so moving to a democratic team is something a team grows into.

Nobody hands down a decision, so people commit to it, and it takes longer. That’s the trade-off behind reaching consensus: strong buy-in in exchange for speed.

Someone still has to talk to the outside world, but that person isn’t the boss. As an external interface, they pass on information, and the team decides who does what.

People take the work they’re best at, rather than getting tasks by rank. That only works when everyone knows one another’s ability and experience, as you can’t allocate fairly otherwise.

If some members are beginners, they can’t judge decisions well and will either stay quiet or slow things down. So this is the condition to remember: all members experienced and competent.

Agile teams estimate and assign their own work, because they’re closest to it. That’s why they count as democratic variants, though someone like a product owner still sets priorities.

In XP, programmers work in pairs and take collective responsibility for the code: anyone can change any part, and nobody “owns” a module.

Why would you build a team this way? Some people are far more productive, so the idea is to free your best person from everything except the hardest code, like the surgeon in an operating room.

If the chief is ill or quits, everything depends on them. The backup exists to remove that risk, and also gives the chief someone able to catch their mistakes.

Each role removes one kind of distraction from the chief: paperwork, admin, tools, language questions. You don’t need to memorize details beyond the fact that they’re supporting roles, though the list is fair for a listing question.

Real superstars are rare, and those around them may resent the imbalance. So despite the appeal, it’s difficult to achieve. It can suit creative projects or tactical execution.

Think of a core group that stays, with others joining for particular parts. That kernel keeps the design consistent, as a few minds decide the system’s shape.

The motivation: the wide difference in ability between programmers. If the best are many times more productive, build the team around them.

If someone can do the work of several people, the efficient choice is to remove obstacles from them. That’s the logic of a supporting environment: everyone else exists to help them produce.

The whole model assumes you have a superstar. An average lead in this role becomes a bottleneck, so if exceptional people are hard to find, it fails.

If one person gets the praise for everyone’s work, the rest may stop caring or even work against them. That’s why resent is on this list: the human side can sink the team.

So much depends on two people that losing both, even temporarily, stops the project. This is key-person risk: the same thing a skills matrix would warn you about.

The organization’s structures and pay grades may not accommodate a team where one person is far above the rest.

Distance from the main organization removes interruptions and rules, and the team feels the result is really theirs. That’s the appeal of skunk works, and the reason for high ownership.

If they’re off on their own, nobody can easily tell how it’s going. Fine for exploring a new idea, but a narrow, well-defined job doesn’t need this freedom, and little visibility would just be a risk.

Compare the two: skunk works is about freedom to explore, while SWAT is about precise skills for a known goal. They already work well together, so they can be dropped into a problem and start immediately.

In large teams communication paths grow with roughly the square of the team size. The exact formula is n(n − 1) / 2: 50 people → 1,225 paths (the slide rounds to 1,200); 7 people → 21.

With that many paths, informal chat can’t keep everybody informed. A hierarchy reduces the paths, since people talk within small groups and leads talk to each other.

Why so small? In a small team, everyone knows what’s going on and feels their work matters, and that’s what builds cohesiveness. The other roles sit around this core so it stays small.

Section divider: Managing People.

Equipment can be replaced, but people carry the knowledge and make the decisions. Calling them the most important assets means a PM should plan for people as carefully as for tasks.

A manager’s tasks are essentially people-oriented; without understanding people, management fails however good the technical plan is.

Notice that “using available people” is a real limit: you rarely get to choose your ideal team. And motivating comes up here because a plan only happens if people want to do it.

Plans and estimates can look purely technical, but “how fast” depends on who’s doing it. The same task can take one developer a day and another a week, so estimating is about people too.

Controlling doesn’t mean micromanaging; it means knowing whether the work is on track. Organizing is about who works with whom and how, which shapes how well they do.

Needs-based means that to motivate someone, you first ask what they’re lacking. The same reward can motivate one person and do nothing for another whose need is different.

Think of the groups as moving outward: staying alive, feeling valued, then belonging. A manager has most influence on personal and social needs, since those arise at work.

Maslow’s hierarchy: physiological → safety → social → esteem → self-realization (self-actualization).

A paying job with a safe office usually covers the basics. So a manager can start higher up, which is why physiological and safety needs aren’t the usual focus.

Once the basics are covered, what makes people try harder is belonging, feeling respected and growing. These are the needs a manager can really act on, so social, esteem and self-realization matter most.

But if a lower need stays unmet for a long time (e.g. job security during layoffs), people shift focus downwards to it until it is satisfied again, and higher motivators stop working.

People work better with colleagues they know. Break rooms and casual chats look like wasted time, but they’re how social needs get met and how information spreads.

People want to feel their effort was noticed. A specific “thank you” in front of the team can matter as much as a bonus, so recognition doesn’t have to be expensive.

Here people want to grow and be trusted. So training and real responsibility motivate strong staff, while doing the same simple task for years drives them away.

Maslow suggests everybody wants the same things in the same order, and real people aren’t like that. Two teammates at the same level can want very different things, hence personality type.

Task-oriented: the motivation is the work itself (they love solving the problem).

The same project might be a means to a promotion or to buying a house. Self-oriented isn’t a criticism, but it tells you these people respond to personal benefit.

For them, an isolated task with no contact is demotivating, even if it’s interesting. Interaction-oriented people keep a team talking, and that has real value.

Real people have elements of each class, and the balance changes with personal circumstances (a new baby makes someone more self-oriented for a while).

Even someone working mainly for money may stay because they like the team. So building a good group and culture is a motivation tool that doesn’t cost much.

Real software is too big for one person, however talented. Working out how people fit together is therefore central, because this is a group activity by necessity.

Group interaction is a key determinant of performance, so how the group works together matters as much as individual skill.

You rarely get to hand-pick a dream team, so plan around who you actually have. That’s why group composition is listed as limited: adapt the work to people’s strengths.

About 50% of an engineer’s time is spent interacting with other people (meetings, reviews, discussions), so communication skills matter far more than people expect.

Don’t plan a person’s time as if they code all day. With only 30% alone, an estimate that assumes eight hours of solo work will be far too optimistic.

Mixing types is deliberate. People with identical motivations tend to clash or leave gaps, just like a team of only goalkeepers, which is why having the same motivation is a problem.

Each extreme has a weakness on its own: nobody coordinates, everybody competes, or nobody finishes. That’s why you look at the mix, not only at individuals: task, self, interaction.

Since most engineers enjoy the work itself, you’ll often lack people who keep communication going. So value the interaction-oriented member, even if they write less code.

A manager with a title can be ignored in practice if nobody respects them, while a respected senior developer gets followed. So respect is what actually makes a leader.

Good engineers aren’t always good at budgets and reports, and vice versa. Splitting the role into technical and administrative leaders lets each person do what they’re good at.

Skilled people often know more than their manager about the problem. Letting them contribute to decisions gets better answers and more commitment. That’s why democratic leadership works in software.

Support a technical career path so good engineers don’t have to become managers to progress.

When people care about the group, they help each other and protect its standards, rather than only their own task. That’s what cohesive means in practice.

Standards the group sets for itself get followed, while rules imposed from outside are often dodged. Working closely also means people quickly learn what they don’t know, rather than hiding it, which is how ignorance shrinks.

If only one person understands a module, you have a risk. When people learn from each other, the team can cope with someone being away.

Egoless programming: members try to improve each other’s programs and don’t treat code as personal property.

You can’t simply order people to bond. A blaming organizational culture works against it, and some personalities need more time, so treat it as something to encourage.

A shared name or space sounds trivial, but it gives people something to belong to. Group identity is what turns individuals into “us”.

Openness with information is the simplest tool: when everyone knows what is going on, everyone feels part of the group.

A close team defends its members, which helps morale. But loyalty can also stop people from speaking up when the group is wrong.

Groupthink: preserving the group regardless of technical or organizational considerations (defending a bad design because the group made it).

A team can’t easily see its own blind spots, so bring in someone who isn’t invested. That’s what external involvement does: outsiders can ask the awkward questions.

If one developer changes a design and nobody hears about it, others build on something that no longer exists. So status and design decisions must be shared, and sharing them also makes people feel included.

Juniors may have the answer but stay quiet. A good PM deliberately asks them first, so the status of a senior person doesn’t shut the discussion down.

If everyone is quiet, nothing gets raised, and if everyone is dominant, nobody listens. A mix of personalities helps conversations work, the same point as slide 45.

If everything must pass through one person, they become a traffic jam, and messages get distorted along the way. Direct channels are usually better.

More people mean many more communication paths, so past a certain size you spend more time coordinating than working. That’s why you break big projects down instead.

With so few people, formal roles and procedures would only slow things down. An informal, democratic setup works because people can simply talk to each other…

…while a chief-programmer team takes the opposite view: if skills are scarce, arrange the team so your strongest people do the critical work.

Hiring mistakes are expensive and hard to undo, as a poor fit slows down everybody. Good selection is a major responsibility that prevents problems no process can fix later.

Each source has a weakness: a CV is written to impress, and an interview is a short performance. That’s why you use several, and why meeting co-workers matters: they’re the ones who’ll work with this person.

Don’t assume a test score predicts good work, since experts disagree. If an option says these tests are proven to work, it’s wrong: the slide says there’s no agreement.

A developer who doesn’t understand banking can write clean code that does the wrong thing. That’s why application domain knowledge often matters more than knowing a specific language.

Good programmers pick up a new language fairly quickly, so it’s only critical when there’s no time to learn. Platform knowledge counts when you’re working close to the hardware. A common trap: it is not the most critical factor.

A degree tells you what someone has probably been taught, and how well they can learn. As real work builds up, it says less, which is why education counts for less over time.

Software is a people job, and half of it is interaction (slide 44). Technology also changes constantly, so communication and adaptability can outlast any one technical skill.

You can’t measure these from a CV, so they’re hard to judge, but a bad fit can harm a whole team. There’s no ideal “programmer personality”; what matters is whether they fit this team.

People who are too hot, or who can’t see properly, work worse and get tired faster. So the workplace is a real productivity lever, and cheap compared with salaries.

These aren’t luxuries, since people concentrate better when they’re comfortable and undisturbed. Privacy is singled out because of how much focused work depends on it.

This one isn’t optional, because it’s about people’s wellbeing and is often a legal duty. Health and safety covers the basic conditions a workplace must meet.

Privacy: each engineer needs an area for uninterrupted work, because deep work is destroyed by interruptions.

Windowless rooms affect mood over time. It seems a small thing, yet natural light comes up often in research on satisfaction at work, and it costs little to consider.

Allowing people to arrange their own space and way of working tells them they’re trusted. Personalization helps them feel at home and work the way that suits them.

Each interruption costs more than the interruption itself, since it takes time to get back into a hard problem. That’s why individual offices raise productivity, even with their cost.

But teams also need shared spaces for formal and informal meetings. Balance focus and collaboration.

Words shape how we think. Calling people “resources” puts them in the same category as desks and servers, which comes from the economic origin of the term.

If you see people as parts, you assume one programmer can simply replace another, and that’s rarely true. Treating them as interchangeable also makes them feel disposable, so the good ones leave.

Treating people as partners changes how you act: you ask instead of telling, and develop people instead of using them up. Psychological safety then lets them speak up, which protects the project.

Think of these as different jobs: interpersonal skills are how you deal with one person, and shaping culture is how you influence how the whole team behaves…

…managing is about getting today’s work done, while making people better is about what they’ll be able to do next year…

…and leadership ties these together, by giving the team a direction they want to follow.

Too little and people work on outdated information; too much and they stop reading. Effective communication means a known way of sharing, so everyone gets what they need, on time.

A PM often needs help from people who don’t report to them. They can’t order it, so influencing the organization depends on credibility built earlier.

Exam trap: someone with no title can lead and a manager can fail to. Leadership is about whether people choose to follow you toward a goal, which has little to do with authority.

Money works up to a point, but it fades quickly and can’t make a job interesting. The surprising point is that financial incentives are among the weakest motivators, so try recognition, growth and meaningful work first.

Differences may only be perceived, so listening can dissolve them. A PM rarely has the power to simply impose an outcome, so negotiation is an everyday tool, not a rare event.

Most project problems are poorly defined at first. So the first skill is working out what’s really wrong, and then progressive elaboration means solving complex problems in steps rather than all at once.

You can’t build a culture that fights the wider company for long. So learn how your organizational culture treats projects first, and shape your team’s habits within those limits.

Some companies have impressive process documents that nobody follows. Knowing whether real practice matches the “fanciful” version tells you which rules you actually need to work with.

Someone’s education and past experience shape how they work and what they’ll accept. A person’s background can tell you what kind of role they’d do well in, so you need to know your people.

People tend to play a natural part in a team, whatever their job title. Knowing each person’s cultural role lets you give them work that suits it, which the next slide explains.

These describe how people behave in a team, not their job title. A tester may be the team’s expert or its charger, and a healthy team needs a mix…

…and the complainer/naysayer, who habitually voices negative or skeptical views but raises concerns and challenges assumptions, often the first to spot a risk.

Don’t confuse these with the cultural roles: these are assigned jobs. The team leader looks after people, and the development leader looks after the product, and on a small team one person may do both.

It’s easy to label a critic as a problem, but they may be the only one seeing a risk. Being non-judgmental means asking what each role can contribute, rather than trying to change who they are.

A young PM may struggle where age earns respect, regardless of the org chart. So authority doesn’t only come from a title, and your authority in one culture may not carry over to another.

What’s normal in one country may be illegal in another, and a change of government can change the rules. So on international projects, local laws and customs are real planning inputs.

If half the team sleeps while the other half works, every question can take a full day to answer. These mundane details can quietly cause much of the delay on a global project.

Culture problems can kill a project just as a technical flaw can, and yet nobody tracks them. Treat team culture as you would technical issues: look for it, discuss it and fix it.

People who are unsure of their role either overlap or leave gaps. Clear roles stop that, and telling someone you value their style helps them accept the role.

People work better when they know the rules for hard moments. The slide’s example shows it: equal in normal times, and one decider in a crisis. Stating your view of the team up front avoids a fight later.

It’s far easier to deal with one person dominating early than after others have stopped talking. So recognize the warning signs, and act before they harm the team.

A role that seems fine on day one may turn out badly, and people rarely volunteer that they’re unhappy. Keep asking about satisfaction, especially during launch, when a change costs almost nothing.

Don’t assume a job title means someone can do the task. A role mismatch shows up late as missed dates, and checking early is much cheaper than finding out after the schedule has slipped.

You won’t find team mood in a report. Watch how people talk in meetings. Your behavior sets the tone too, so the cultural climate responds to your own example.

A project rarely fails because the technology was impossible. It’s more often poor communication or a team that doesn’t work together, and that’s what sociological means here.

Peopleware (DeMarco and Lister) is the recommended optional reading on managing people.

Promoted engineers tend to treat people as a puzzle with a correct answer. But people aren’t logical systems, so one person’s idiosyncrasies, like needing quiet, can decide whether they do great work.

Gain visibility without micromanagement: know the status through boards and reviews, not by watching over shoulders.

Criticizing someone’s ability makes them defensive, and they stop listening. Discussing the process puts everyone on the same side against the problem, as the slide’s two sentences show.

Tricking or pressuring people may work once, but it destroys trust. Coordinate by explaining why, and if someone’s effort is going to the wrong place, redirect it rather than discouraging them altogether.

People notice when you’re protecting your position rather than helping. When your attention is on what the project and team need, they respect you without being told to. That’s why you focus on needs.

Factory methods assume that identical work gets repeated. Software is different each time, so applying production-line thinking to it causes the errors listed below.

On a line, an error is a defect, while in design it’s often how you learn. Someone staring out a window may be solving your hardest problem, so treating that as goofing off drives out your best thinking.

A new person takes months to reach full speed, so people aren’t interchangeable like machine parts. Plans that assume a smooth steady state ignore the expensive start and end of work.

Strict rules suit repeated tasks, but software keeps meeting new problems. If trying something new isn’t allowed, you won’t find better ways, so eliminating experimentation is harmful.

It’s usually the first thing dropped under pressure, unless it’s a stated goal. Treating professional development like any other goal means time and money get set aside for it.

You need both. Short-term learning helps this project now, while long-term learning keeps people growing, and it’s a large part of why good staff stay.

People work harder at goals they chose. A competency framework just gives them a useful list to pick from, so that “improve” turns into something specific.

Most people don’t know where their time really goes, and the results often surprise them. It only helps if it’s safe, so stress that this is for their own awareness, not for monitoring.

A weekly timesheet is too rough to teach you anything. Tracking daily gives a developer real evidence, such as how long testing actually takes compared with what they guessed.

With your own numbers, your next estimate gets better, and you stop promising what you can’t deliver. That’s how the PSP helps developers make commitments they can meet.

Having a title doesn’t get a group to solve hard problems. Mobilize is the key word: people have to want to take it on, so it’s wrong to equate leadership with authority.

If the problem has a known fix, the team just needs someone who knows it. Technical leadership is direct and efficient, and asking “what do you all think?” would just waste time.

If nobody knows the answer, a leader giving orders is only guessing. Adaptive leadership helps the group learn its way there, and good questions do more than instructions.

When people are exploring, it’s easy to drift. A clarity of purpose gives everyone a reason to keep going without a clear path, and lets the leader pull a discussion back.

Ask first: does anyone know how to solve this? The answer decides which approach fits, and using the wrong one either wastes time or gives false confidence.

Technical says “here’s what I see for us”, and it works because they know the way. Adaptive doesn’t have that map, so it uses a sense of purpose: why it’s worth working through.

Tool for motivation: technical relies on personality: charisma, expertise, confidence, decisiveness. Adaptive relies on progress: learning, iteration and visible movement toward clarity. In short: technical = “follow me, I know”; adaptive = “let’s figure it out together.”

Neither style is always better, so diagnose first. Fixing a known bug doesn’t need a discussion, and a brand-new product can’t be directed by a checklist. Known means is the deciding question.

One project contains both: routine deployment work and a new algorithm nobody’s tried. So a PM has to switch between them, which is why a mix matters.

A leader doesn’t need to handle everything personally. Delegation lets the person who knows the answer lead that part, which frees the leader to work on the problems nobody has solved.

Exam trap: consensus doesn’t require full agreement. People can accept a decision they’d have made differently if they feel they had a fair hearing. That’s why it’s about being heard.

On a five-person team, a 3–2 vote leaves two people who may quietly stop trying, and you need all five. That’s why majority rule can do harm, even though it seems fair.

Everyone being heard doesn’t mean every argument is good. The leader should strengthen the good points and gently remove the bad ones, because they must curate what the decision rests on.

Don’t start with solutions: agree on the problem first, and collect options before anybody defends one. The order is what keeps the discussion from turning into a contest.

People who were simply overruled will resist later. Spending time to persuade now costs less than dealing with resistance during delivery, which is why the extra time pays off.

Beware passive-aggressive agreement: people who say yes but don’t act on it. It is just hidden (subsumed) conflict.

The same habits that build trust are how you lead day to day. If a question mixes these slides, the answer is the same, as this is a reprise.

A nervous leader makes a team nervous. Be confident, without pretending you can do it alone, and you’ll get more from people who feel their talents are being used.

A good relationship helps, but a friend may avoid saying hard things. You must sometimes give tough feedback, and that needs boundaries, even with people you like.

Asking for what people can’t realistically do leads to burnout and resignations. Knowing the human factors tells you what’s reasonable to demand.

A good exam summary of slide 53. Domain experience and adaptability often count for more than knowing a specific language.

The reason is communication paths: small groups share information easily. Status matters because juniors may stay quiet, even when they’re right.

Don’t wait for a culture problem to show up as a missed deadline. If you monitor early, you can act while it’s still cheap to fix. Your environment also affects output every day.