Jump to content
Site Stability Read more... ×
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1189 Excellent

1 Follower

About doeme

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Meetings are boring! Meetings are boring, overcrowded, take up much of your valuable time and don't produce the desired results. Or they can be interactive, efficient, goal-driven, interesting and sometimes even fun. So how to go about planning and running successful meetings? Five and a half Steps to successful meetings Running successful meetings is not difficult; it just needs some preparation and a bit of practice. Before I go into the details on how to plan and run an efficient huddle I would like to state two very important point: If you call in a meeting, you are the one responsible to get the most out of it. It's your show, so while you might not be the main contributor to the content be sure you are the one to drive the meeting forward. Be the facilitator of discussions, be the one to help everybody to keep the focus and last but not least be the eye that watches the clock. As Slayemin put it so aptly in the comments below: "The ultimate purpose of a meeting is to reduce confusion and uncertainty. If people go into a meeting and they leave less confused or uncertain, then it was a good meeting. If people go into a meeting and come out with the same or greater amounts of confusionion, it was a poor meeting. As a meeting attendee, you are either the one who is confused and uncertain, or the one dispelling confusion for others." Step 1: Send out the agenda before the meeting. When you schedule a meeting prepare an agenda and send it to anybody involved. Preferably early enough so anybody can read through it and comment on the agenda if necessary. Tell everybody what this meeting will be about and what its goals are. This helps you also to keep the meeting on topic later on, as it prevents people from shoving in an extra discussion about something else. Having a clear agenda also helps to decide who needs to be in the meeting and who will waste his time as an over-passive listener. Step 2: Have a well structured Agenda Try to keep the agenda short and on topic, as this also helps to limit the scope of the meeting, which in turn helps people to sty focused. I structure almost all my meetings very similarly like this (Although often in a paraphrased way): Introduction to the topic and the goal of the meeting. Take a few sentences to introduce the crowd to the topic you are about to discuss about. If there were any previous meetings to the topic do a short recap of them. And most important state the goal of this meeting as clearly as possible. Assess the points to discuss or the problems to solve. Break down the problem into smaller items that can be tackled in the time you have. Tell them something along the line of "In order to achieve XY we need to solve A, B, and C and I would like to discuss this in this order". Discuss the points or solving the problems. Now go along and discuss the items you brought up. Take notes or have someone take them for you. Define action items to carry out. Assign how to continue after the meeting. Assign the action items to a person and have them write their todos down. Conclusion & define follow up meetings. Wrap up the meeting by going through your notes again and communicate what you expect to be done until the next meeting or deadline on the topic. Step 3: Stop the babble, focus on the topic Time is money, so you don't want to waste it talking about irrelevant stuff. Often enough there are meetings where two people start to discuss something in a very detailed manner while five people sit there bored staring at the walls because nobody wants to interrupt. The solution is to create an environment where it's ok to stop runaway discussions. I sometimes distribute red cards at the beginning of the meeting and tell people that if they are thinking that a discussion doesn't contribute to the meeting they can raise that card. The people talking should then finish their sentence, write down the topic of the discussion and postpone it. In groups where I have done this regularly we now can do this easily without the red cards, because everybody knows that it's ok to tell the others to shut up for now. Step 4: Manage the time Try not to call in meetings longer than two hours and if you have to, plan in frequent short breaks. People cannot stay concentrated for longer than one hour without a quick breather. Be dependable when it comes to timing and duration of meetings. Be on time when starting a meeting, better yet be five minutes early and have everything setup and ready. Having ten people watch somebody fiddle around with a projector for five minutes is not funny. Have your handouts, Flip-charts, presentation and any office supplies needed such as post-its, markers and writing pads ready at the beginning so you don't have to run off to find them in the meeting. Ending the meeting on time is the harder part but with a bit of training this becomes easy as well. Start out by time boxing the items on the agenda, and have an eye on the clock during the meeting. Often it's better to conclude a meeting on time, even if you have not reached all the discussion points on the agenda, take a breather and schedule the next meeting at a close time in the future. Estimating how much time something takes is hard at first and needs a bit of training but a good guideline is to do a quick calculation along the line: "five people are in the meeting, everybody will talk 5 minutes about the subject, so 25 minutes it is." Step 5: Track the discussions This one is simple. Take notes, sort them after the meeting and archive them in a place where you can find them again. Distribute the notes to the people involved between meetings, so you don't need to raise the same issues over and over. Also encourage others to take (& share) their personal notes. Optional Step 5.5: Get Feedback Running meetings takes training and training needs feedback. Get feedback on how the meeting went from the participants. One quick way to get feedback is to prepare a flipchart with a pre-drawn graph on time invested vs. outcome and have everybody leave a tick-mark on the graph. Follow up with the people who think they wasted the time, ask them why. Also give others feedback when they run a meeting to encourage them to do the same. Using this on different kinds of meetings Meetings can span a very large range from all-out creative brainstorming sessions to the dry presentation of your new company regulation on home-office work. While the five steps fit any kind of meetings, they can be tailored a bit to fit any particular style of meetings. I tend to place my meetings into four overlapping categories to get a first grip on how I want to run a meeting and what to expect as outcome. The boundaries between the categories are fluid but knowing in which area I am usually helps me in setting up the agenda and time frame of a meeting. Informative: The purpose is to fill in the attendees with certain kind information, frontal presentation is often the way to go, but restrain yourself from droning away. Keeping your audience's attention up is one of the key challenges. Having a clear and focused agenda that helps people follow up the progress of the meeting and stopping any unnecessary babble helps to avoid losing the audience. Your job as the facilitator of the meeting is to get the facts across in a concise manner and answer any questions from your audience to their satisfaction. Creative:Usually the most interactive kind of meeting. You try to find out something new, whether an artsy brainstorming session or a technical design meeting usually you get the crowd to participate. Challenges are to restrain run-away discussions and actually find a conclusion while not restraining the people from getting new ideas in. As the runner of the meeting you are responsible that your creative process runs smoothly and ensure and document the progress of any discussions and ideas. Decisive: You got the facts laid out but you need to find a decision on something where the facts are already laid out but might be conflicting or not yet fully understood. Often combined with the informative meeting, the challenge here is to actually get a decision to made and responsibilities cleared. To keep these kinds of meetings short having a pre-read where everybody can get up to date in his or her own time helps shorten these meetings. Time boxing these meetings helps to avoid running a discussion in circles, sometimes one has to agree to disagree but still decide for one option. Analytical: You got a problem here but we don't know what (or who) caused it, so you call in the gang and to figure out the why. Collecting and consolidating any information on the problem before the meeting will speed up the actual process of analyzing the facts. Have an eye on conflicting information, check for any inconsistencies and bring them to the attention of the attendees. You might not be the one person with the deepest insights into the problem but your job here is to mediate between multiple different opinions on the state of affairs. Especially when the question borders on the "who caused it" avoiding slipping into a blame-frame is often a key. Analytical meetings are often followed or interwoven with creative or decisive meetings so be sure to track and document the meeting for further use. Now Meet up! The five (and a half) steps and the four flavors of meetings are tools for you to use, but said that as with everything it's practice and not the tools that make perfect work. To run meetings smoothly and confidently you will need some interpersonal and crowd control skills which will come with practice and time. Use the five steps as an anchor point for planning and running meetings, decorate them with your personal style and preferences and your meetings will never be boring again but efficient, goal oriented and successful. Article Update Log 26th Ocotober 2015: Added quote from Slayemin
  2. This is an excellent point and condensation of what I tried to tell. Would you mind if I quote you in the Article? 
  3.   Thanks for the appreciation but I disagree with your statement. While being creative is part of being a programmer and sometimes you have to experiment to find a solution, producing working software is the only thing that counts in the end. Any good working environment should make room for experimenting but I would rather have this not tightly integrated in any project with a deadline.  
  4.   Very good advice, for me this plays into becoming a teamplayer and being a "good citizien" for your team. 
  5. Everybody is a great coder It's now over fifteen years since I first got money for a program that I wrote, and since over ten years I consider myself a professional software engineer. When I started out programming I was convinced that raw coding ability and deep, innate technical knowledge of a few programming languages would be all it would take to make it in the industry. But over the years I learned that there is more to being a professional programmer than hacking together complex code. Having worked both in academics and industry, this often became most apparent to me when working with newbies fresh out of college. Often they are great programmers but lack some of the surrounding skills to make them look professional to me. So what distinguishes the common coder and/or hobbyist from the pros? Before I forget: This article is written on a purely subjective basis of my personal experiences, feel free to tell me that I'm wrong Diversify your knowledge Get things done with your code While being an able coder is not the only thing that counts, not being one immediately disqualifies you to become a successful programmer. Be sure to master at least one full-fledged common programming language such as C#, Java, C++ etc. Go into details of the language, know the standard libraries, know how to wield the language to great effectiveness and know how to cope with any limitations it will have. As a bonus to your main language, know at least one scripting language to automate small tasks, create quick experiments and do ugly proof-of-concepts. Don't be slowed down because you don't know your basic tool - the programming language - well enough. In short: Make sure you know how to get things done and get them done reliably. Show me your mind Getting complex things to work is only one side of the medal, the other side is that those complex structures want to be explained. Maybe your fellow code monkeys want to discuss a problem with you, maybe it's your boss trying to get a grip with your skills, maybe it's plain old documentation that needs to be written. Whatever the cause, sometimes just writing code comments is not enough. Know how to visualize (and read) software structures. Be it UML diagrams, flow charts, ERD or simply Venn diagrams, know how to draw a diagram that others can understand. You don't need to be fully proficient in the last details of the "official" iconography of any visual language, but not being able to draw a simple class diagram or state machine will leave your thoughts behind closed doors for others. On the other hand, learn to recognize (and name) patterns in these charts, however badly scribbled by one of your fellow hackers. Prove me that it works Yay, your great ideas and concepts are approved by your team and you've written that beautiful piece of code to solve the problems of the world. But does it survive the impact of the users? Testing, Testing, Testing is the only answer to this. Know how to test and debug your program. Relying on print-debugging and testing by "it appears to run correctly" may work for small projects and in the short-term, but there is a certain point where we want to guarantee that a program works in exactly 'that' way. While you don't need to embrace test-driven development in the full, know at least about unit testing, know how to use a debugger efficiently, use software asserts and read into design by contract. Learn how to do a performance analysis of your code and other non-functional requirements. Be able to write consistent and good tests for your software, know what is covered by your tests and what is not. Your code has a history While well-tested code is a must, sometimes the path that leads to any particular solution is also important. Sometimes you just have to see how code evolved to understand it or find the exact moment when a bug was introduced, luckily there are plenty of versioning tools out there which help with this task. Be sure to know about source code management and versioning systems. It doesn't matter whether this is SVN, Git, Mercurial, TFS or any of the others on the market, just be at home with the usage of at least one and get the basic concepts behind them. It's not just about versioning, but also about backing up code and traceability of features. It's astounding how many hours of productivity I've seen go down the drain because some guy in a team of coders just did not use versioning software properly. Be it in files lost, because of an accidental overwrite, being unable to merge a conflict with a team member or just messing up the workflow for everybody else by not following the basic concepts behind source code management. Take one for the team Now you're able to produce well-designed, peer-reviewed, tested and traceable code which greatly increases your chances to be seen as a professional software engineer. Time to start working together with other great professionals out there. Software development is no longer an occupation for loners who work alone, nowadays software development is considered a team sport by many successful companies. So be sure that you are prepared to work together with other humans and become a team player. Grasp the basic fundamentals of software development processes in teams, know about iterative vs. incremental software development, about defining deliverables and features. There are tons of development processes out there to read into, be it scrum, kanban, XP, feature-driven development - whatever floats your (or your employer's) boat. No need (yet) to get any certificate on anything about these processes, but be aware that they exist, and that they are used to great success by many software producing companies. Another major point is if you want to be part of a tight-knit development team, learn to be a "good citizen" for that team. Be honest towards yourself and others, learn how to communicate on a professional level if things don't go according to your plan and last but not least, sometimes you just have to bite the bullet, swallow your pride and take one for the team. That's it? Am I missing something in this article? Certainly. Of course there is more to being a successful programmer/software engineer than the five points mentioned above, and of course, not all of them apply to the same extent to anyone or any company. Working with a startup indie studio that needs to produce something now with limited personal resources puts a different weight on things than being hired by an AAA company where you are just a tiny cogwheel in a great machine. Also, some of the things mentioned above are easy to learn, while others need time and experience to grow. Learning tools is easy, learning people is hard. It's a catch-22 you need to work together with other professionals to gain the skills needed to be accepted as a professional yourself. Keep an open mind for well-meant critiques and be reflective about yourself and don't give up. Feel free to comment on this article or reach me over PM. Article Update Log No updates yet
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!