Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "wk353"
-
A wise man once said that,
The most productive meeting is the meeting that has been cancelled.
- unknown legend. -
How to run a productive meeting?
Have a written agenda (provided before the meeting, of course)
No "Lets talk about the service architecture" nonsense. Provide the exact details of what the outcome of the meeting should be. Even been lucky enough to cancel meetings when the agenda points are answered in a reply email. Its awesome.
As conditioned as we are about agendas, a few mgrs still skip the agenda and it ends up as you would imagine. At the end, everyone is like "Why are we here? What did we decide? Looks like we need another meeting..."4 -
Ask yourself as you plan the meeting:
1. Is an email a better solution to this?
If the answer is yes, plz just send the fucking email. Else, try and find a way to make it an email instead. If all else fails then yeah go ahead and have your stupid meeting. -
End the f*ckin meeting on time! I don’t care if you still have more to say, 30 minutes should be 30 minutes.4
-
just plan ahead? there's no point in doing a meeting where no one has thought about the subject beforehand or, even worse, if the interested parties are not present1
-
Stay the fuck on topic
The amount of dailies, sprint reviews or the likes I had where someone started to discuss super specific technical details that only concern like 2 out of the 12 people in the meeting is just insane -
I’m rarely at the initiative of a meeting, but when I am, my approach is: what questions need to to be answered? Time spent in the meeting is answering those questions without beating around the bush. I request precise answers, no "we shoulds" or vague responses. Meeting usually ends with clear answers/resolutions written down and shared so there aren’t any "that’s not what we agreed upon"1
-
What are peoples thoughts on taking a sort of backwards step in their career in order to get more experience?
I took my current job as I thought it would be a stepping stone to go on and do more development work (it was my first dev role), but I’ve been here 4.5 years and I rarely do anything other than maybe fix a bug every now and then.
They mainly have me doing non-dev support type stuff, and they don’t use any best practices or anything like that, and I feel that I am falling behind where I should be experience wise.
I am doing a degree (distance learning with the Open University) so I am working on personal development but that’s not much help when I go to interviews.
Should I think about trying to go for junior jobs, rather than just developer jobs, and the pay cuts that may go with that, or should I just grind out leet code etc and keep booking interviews?6 -
Send an email.
Or, more seriously: invite only people who must be there, and can add something to the discussion, have an agenda, stick to it, and plan the meeting so that it ends at the start of lunch break. That way everybody will be interested in finishing on time or earlier. -
1) Have a plan for what's going to be talked about (and what will not be mentioned)
2) Could this meeting be an email or done async? Then don't schedule a meeting
3) Send out the calendar invite at least 72 hours before. Include details in the title and description, such as join link and if video will be on or not
4) Join 5 mins early to ensure everything is working
5) Start the meeting right on time, no matter who isn't there
6) If someone joins late, don't recap what's been mentioned
7) End on time, the time that was set when the calendar invite was sent, ending early is also fine
8) At the end say thanks, and know who will send out the notes which include tasks mentioned and the deadline. As well as who to contact if have any questions
9) If a select portion of the meeting attendes is going to have another meeting regarding this, then meet elsewhere
10) Actually send those notes before the end of day -
A productive meeting requires:
1. an agenda that covers every aspect that the meeting should be about
2. Everyone at the meeting gets a chance to provide feedback and or speak about their role in the project and what's the hold up.
3. All participants or at least a dedicated one takes notes about what is covered so that people aren't asking the same questions the very next day. -
Not asking a dev to do a whole document rundown of built components and then asking creative to fucking add new shit making the document worthless. Oh yes. Then complain why the document was not up to date.