Meeting

How, when and why we meet

Team meetings

Meetings are important. They're also susceptible to becoming stale or, at their worst, being abused to coerce behavior.

By design, we will have few regular team meetings. We want to emphasize instead open, frequent communication within the team. Unstructured conversations prompted by immediate needs will often be a better format to work with your peers on a small desk like ours.

Your editors' job is to balance that impromptu flow with your need to set regular goals and mark progress. That may mean setting up a popup meeting on a particular project. It will also mean designing tightly constrained regular meetings. We have two:

Morning stand-up

We hold a stand-up after the morning editorial meeting at 10:45 a.m. each day. The goal of this meeting is to share what you're planning to work on today, any interesting problems you confronted yesterday and to voice any requests for help or points for the good of the order. We want this to be brief, so you're encouraged to focus on a tight list of tasks.

Some design notes for this meeting:

• This is not to flash how busy anyone is. Better to focus on the top one or two tasks that will demand the most of you today than to run through a 12-point list of bits.

• No one is running this meeting. If we're calling on people, it's not working.

• Talk to your peers, not your editors. We're holding this to share what you're learning in your work. So talk about what is interesting or new to you. If it's just a roll call for us, it's pointless.

Weekly retrospective

Each Friday, we'll meet at 4:00 p.m. to review the Week in Interactive News.

The bulk of this meeting will be an open appointment for us to fill with whatever we like. You may run a demo of new tech or tools or talk through the design process on a recent piece. We may train on a new skill. We may update you on a decision coming down from our bosses. We can talk about something not strictly related to work. There may be beer. We may go outside the office.

There's only one set piece in this meeting: Each week we'll do What Worked/What Sucked. This is your chance to blow your own horn and to speak frankly about something that bugged you this week. We expect you to shamelessly boast and be savage critics in this section. Indulging both in a structured way is good.

Reviewing our meetings

As per the Burned Prairie Growth Principle, it's healthy to regularly burn down and cycle the way we meet and work. We will regularly look at our meetings, especially, with a critical eye. Is the format working, has participation stalled, is it adding beyond the interruption to our workday, is it catering to some team members' personalities but grating on others'? No meeting is sacred, so if it's not working we'll kill it and cycle through a new format. Remember, inertia is the cardinal sin of newsrooms.

Last note: It's every team member's responsibility to flag when meetings aren't working for them, not just your editors'. If you're making a good faith effort and it's just not working, there's no benefit to suffering through it.

Project meetings

The most important rule of meeting with other teams in our newsroom is to come prepared.

If you're organizing a meeting, you need to be prepared to drive the conversation, even when the purpose is discovery. You can always stray from a plan if a better path appears, but never organize a meeting you're unprepared to lead.

You should have clear takeaways in mind for any meeting we're organizing. What decisions need to be made at the end of this meeting? What questions do we need to have asked or knock-on effects do we need to have explored? What progress do we need to see?

On this team, it's our job to be thoughtful about UI/UX and the strategy behind how users will find and experience our pages. Come prepared with our best idea of what will or won't work. Listen to and affirm others when they have better ideas or point out things we haven't thought of.

If you're demo-ing a project, make sure your UI/UX is as complete as you can afford to make it. People you're presenting to aren't developers or designers, so don't expect them to be able to connect the dots the way you can. Especially, don't put them in a position to have to make a decision based on filling in gaps. If you can't afford the time to polish your project into a complete idea before you meet or need more direction before investing in the code, it's better to go completely abstract than semi-designed. Stick figure wireframes are your friend and can help people focus on the larger questions instead of trivial details.