How an IT team works: roles and rituals

Who's in a typical team

Developers. They write the code. Usually several people of differing experience: some carry the hard parts, others do simpler work and learn.

A tester. Checks that what was built works. Small teams may not have one, in which case people check each other.

A designer. Often not in the team but shared across several.

An analyst. Establishes what exactly needs building and describes it so it can be built.

A product manager. Decides what gets built and in what order.

A project manager or team lead. Keeps the work moving and removes obstacles.

At small companies one person covers two or three roles. At large ones there are more roles, not fewer.

How a task travels

Usually: the task appears → it's described and estimated → someone picks it up → they build it → someone else reviews it → it's tested → it ships.

Between stages a task may go backwards. That's normal and doesn't mean anyone is doing badly.

The important thing for a beginner: you aren't solely responsible for the result. Your code is read, your changes are reviewed, and that's protection rather than distrust.

Recurring meetings

A daily check-in. Fifteen minutes: what I did, what's next, where I'm stuck. Not a report to management but a way for the team to know who's doing what.

Planning. Every week or two: deciding what to take on next.

A review of the period. At the end: what worked, what didn't, what to change.

Looking ahead. Discussing large pieces of work in advance so everything is clear by the time it starts.

One-to-ones. With your manager, usually monthly: how things are, what's in the way, where you're growing.

Which of these are genuinely needed

Honestly: the set of rituals is often inflated, and half of them happen because "that's how it's done".

Genuinely useful:

• A short regular check-in. In any form, even written. Without it a team learns about problems late.
• A review of the period. The only mechanism that improves a process rather than enduring it for years.
• One-to-ones. A place to say what you wouldn't say in front of everyone.

The rest depends on the team. A good sign: if a meeting was cancelled and nobody noticed, it wasn't needed.

What a beginner should expect in the first weeks

A lot that's unclear. Normal: the team has history, abbreviations and agreements nobody will explain until you ask.

A slow start. Your first task will take three times longer than expected. Everyone goes through this.

A feeling of being in the way. You aren't: teaching a beginner is part of a team's work and it's budgeted for.

A useful habit for the first weeks: write down everything unclear and ask in a batch once a day. That way you neither drown nor interrupt people every ten minutes.

Preparing in advance

Team experience can be acquired before employment, in a project with other people. The same things appear: dividing tasks, check-ins, reviewing each other's code, the need to negotiate.

Someone who has done that enters their first team noticeably calmer.