Tag Archives: Work

Meeting Etiquette

If you have any kind of interaction with others during your working day, you have no doubt encountered terrible, time wasting meetings. Meetings where no one seems to know what's going on, the topic meanders here and there and very little is accomplished. Badly run meetings like that are a bug bear of mine. Though I have been caught behaving badly in meetings myself (talking too much, not listening enough, etc.), I have learned to be better because a meeting is one of the most expensive, least productive parts of the day, so it's better for everyone if the meeting is effective.

What makes a meeting effective? Well, for me, an effective meeting is one where all the attendees are relevant to the discussion, there is a clear goal in mind and someone chairs the meeting to ensure that goal is achieved. To that end, each meeting should meet four basic requirements:

1. Must have a realistic agenda stating meeting structure and goals
2. Must have only relevant attendees
3. Must have proper equipment prepared and ready
4. Must have a chairperson

Agenda

Contrary to the belief of a few individuals I've worked with, the agenda does not have to take up the better part of a novel. In fact, it should be short and concise so that there's a high chance everyone has read and understood it before attending the meeting. If you make the agenda too long, everyone will show up without having read it. Of course, there's still no guarantee that even with an easy-to-read agenda those who show up for your meeting will have read it. Therefore, the first thing to do in the meeting is read the agenda aloud so that everyone present is aware of why you're all there. Also, make sure to let everyone know who is present, especially if some people have never met or there are remote attendees via phone conference.

The agenda should also be realistic. Don't schedule a half hour meeting and then cram in an hour's worth of agenda. The goals of the meeting should be achievable in the allotted time. In addition, make sure that appropriate time is set aside for starting up and closing down the meeting. You'll need time to set up equipment, introduce the agenda and attendees and review actions; there is no magic clock at the start and end of meetings so make sure you account for these activities.

Relevant attendees

We've all been sat in a meeting wondering why in the world we're there. The right thing to do in those situations is leave, but that's a bit of a gutsy move 30 minutes into your boss' presentation. The point is, if you're not adding value to or getting value from the meeting, you shouldn't be there running the risk of taking value away from everyone else. If you receive a meeting invitation with an agenda that looks decidedly outside your bailiwick, ask the organizer why you're included and consider suggesting someone more relevant to attend. It is perfectly fine to not show up to a meeting from which you won't gain anything and that won't gain anything from you. However, it is not fine to accept a meeting invitation and then not show up. Show courtesy for the organizer and other attendees by either not accepting in the first place or by giving plenty of notice that you won't be able to make it (in some situations, this may not be possible, but those situations are exceedingly rare).

On the flip-side, if you're organizing the meeting, write the agenda first and then decide who should be present. Consider what value they will add to or gain from the meeting. Consider personalities and what might work for or against the agenda (that doesn't mean you shouldn't invite people who's personalities might clash, but it does mean that you should consider it and how it may impact the discussion). Make sure that everyone on the list is on it for a valuable reason (I personally dislike the optional attendee; if someone is optional, they aren't needed by definition and shouldn't be included).

When you do attend a meeting, try to be respectful of the others in the meeting. Be assertive but avoid talking over people, shouting and other overly aggressive conduct as it can stifle discussion. Try to give opportunities for everyone to have their say. This is something that I personally have had to work hard on in my career as I tend to talk a lot and repeat myself to get my point across. I can also be quite stubborn if backed into a corner. Being aware of your own personal flaws in meetings is important, so if you don't know what they are, ask your colleagues. You may not like what you hear, but you can use it to your advantage. If you're a talker, try to talk less. If you're naturally quiet, look for opportunities to assert yourself.

Proper equipment

In my office, it is not unusual for back-to-back meetings to be organized. This is quite frankly ridiculous. Before any meeting can begin, the organizer or their appointed lackey must have opportunity to check the relevant equipment is in place and working, but usually we don't allow time for this activity. Instead, the attendees sit and wait for this activity to be completed. This is the side-effect of our Outlook-driven, half-hour block meeting organisation habits. In a perfect world, I would like the first five minutes of every meeting to be set aside for the organizer to check that all the meeting equipment is ready – that includes the room, projector, telecommunications and anything else you might need. If you need more than 5 minutes, consider booking a bit of time before the meeting for just you and the room so that you can set up. No one likes watching someone else flail with technology and it can quickly derail any meeting, so get it done privately beforehand.

Chairperson

You've invited the right people, given them a clear agenda with achievable goals and made sure all the required equipment is set up, but without an appropriate chairperson, the meeting is likely to go nowhere. Every meeting needs someone that will keep everyone else on topic and on track. The chairperson should be someone that grasps the concepts being discussed in the meeting but isn't necessarily involved. This way they can have an objective view of the discussion and spot rambling, off topic discussions and other destructive behaviours before they get out of hand. If something comes up that was not on the agenda, the chairperson can note it as an action for another time, avoiding a costly sidetrack.

You'll spot any meeting where there is an ineffective or total lack of a chairperson (they're the meetings where long pauses occur as people decide who should speak next or what topic should be discussed), whereas a meeting with an effective chairperson will often end early. By being outside of the main discussion, the chairperson is free to focus on the goals and keep track of what actions and decisions have been made. This has the wonderful side-effect of saving time; when the goals are met, the meeting is done, even if it's done early. This avoids the common situation in meetings where someone says, "Well, we've finished early, so does anyone have anything else." This phrase is a sure fire way to run over time and get nowhere.

If you've never been a chairperson, find an opportunity to give it a try. It's a great learning experience as it gives a very different perspective on a meeting

One size fits all

There is no doubt that there are other things you can do to have more effective meetings (apparently, stand-up meetings are quicker at reaching the same conclusions as sit down meetings), I am certainly no expert, so tailor your meetings to suit your specific domain. However, these four basic requirements should fit pretty much any meeting so give them a try and let me know what works for you. Perhaps you've got some tips or tricks yourself.

Ann Arbor Day of .NET

On Saturday (29th Oct), I attended the Ann Arbor Day of .NET. I thought it would be nice to summarise what I heard. I doubt these notes on their own will be greatly useful, but I hope they act as a launch pad into deeper dives on the topics covered as well as a review of what topics were covered. There were five different tracks for the day: Cloud, Framewords & Platforms, Soft Skills, Tools and Mobile. I chose talks from the first four of these based on the talk itself, rather than the track to which it belonged (I ruled out presentations that I had seen a variation of before such as David Giard's (@DavidGiard) Introduction to Microsoft Windows Workflow and Jay R. Wren's (@jayrwren) Let's Go to C# On The iPhone, though they were excellent when I saw them).

Be A Better Developer

I started out the with Mike Wood (@mikewo) and his session, Being A Better Developer. This was a soft skills talk, meaning it was not there to show off some cool .NET feature or technology, or teach me all about C#. Instead, the focus was on what makes a great developer and what we can do to attain that status.

Mike explored the various roles that developers have to take on, the hats we have to wear. From the student learning new things everyday, to teacher imparting knowledge to those around them. From janitor—maintaining what already exists, to researcher—investigating and choosing frameworks, languages, platforms, etc. Using these roles as a foundation, we then moved on to some tips such as setting up time blocks in which to work. If the time limit is reached and the problem isn't solved, turn to someone else for help (or somewhere else, like the Internet[2]) to avoid thrashing and time wasting. This seems somewhat obvious and yet I'm betting that many of us don't do it as often as we should. The other tips were equally useful, obvious and often compromised in our daily development lives:

  • organize
  • prioritize
  • know your tools
  • set SMART[1] goals
  • be a catalyst for change
  • be lazy…

Right, that last one is maybe a little less obvious, but the point wasn't: don't do more than you have to.

One of the best pieces of advice from this talk was to choose a good mentor. I was very fortunate when I started out my career to have several excellent mentors and I miss working with them almost every day. Even now, I imagine what they might have said in order to guide my efforts[3]. For an hour, Mike filled that role.

There was much more to this talk than what I've written here. This session was an excellent way to spend an hour. While much of what Mike presented could be considered commonsense, it was reassuring and also provided some new tricks for my arsenal to be deployed in any situation, not just day-to-day software development.

Things to check out after this talk


How I Learned To Love Dependency Injection

Next, on to James Bender (@jamesbender) and his presentation on how he much loves dependency injection[4]. This talk started out looking at the way things were and the ideas behind a loosely-coupled system; a system where each component knows as little as possible about the other components in its parent system, whether it uses the services those components provide or not. Tightly-coupled systems don't promote reuse, create brittle systems and are inherently difficult to test.

James told a compelling story, starting out with familiar concepts—a constructor that takes various interfaces through which the created object can obtain various services, the factory pattern, etc., but soon we were looking at an overview of dependency injection frameworks, what they do and how they do it.

And then, code. Code about cooking bagels. The only bad part about this was the lack of bagels to eat[5]. The talk moved quickly on to the various features of Ninject, an open source dependency injection framework. I would've preferred it if there was more emphasis on dependency injection, using Ninject to provide examples, rather than the "how to use Ninject" approach that was given. However, this was still very informative and laid a path towards the next part of the talk which showed how dependency injection and TDD[6] go hand in hand. This in turn led to an introduction of mocking (the mock framework of choice in these examples was Rhino Mocks, but James recommended Moq for new work).

Things to check out after this talk


A Field Guide for Moving to the Cloud

We're back with Mike Wood (@mikewo) for this one. I've never done any Cloud development but I'm really interested in it and what it may do for me and the work I do, so I'm hanging a lot on this introduction (no pressure, Mike).

Mike started off with a Batman reference, tying the reason why I'm so tired (Batman: Arkham City) with the reason why I'm here. He then fired off some acronyms: IaaS, SaaS, PaaS. This is a great starting point for me as terminology is often the last refuge of miscommunication and I hate not understanding what all those acronyms and terms mean. One participant immediately asked, "What's the difference between IaaS and PaaS?" and most of us nodded, realising we didn't know either. To paraphrase, IaaS gives the most control as you're responsible for patching your OS, upgrading the frameworks, etc. PaaS manages all that for you. Mike did a great job explaining this (unlike my paraphrasing—Mike used a whiteboard and everything) and we moved on, that bit more informed and ready to learn more.

At this point, Mike gave us a run through of the Windows Azure platform, again making sure we're all talking the same language as the presentation progresses. Mike's presentation style is nice and fluid, taking questions and interruptions in his stride, and he clearly knows his topic well (Mike is an Azure MVP, after all). He walked us through the various parts of Windows Azure, Microsoft SQL Azure and Windows Azure AppFabric before we moved on to planning for our move to the Cloud.

Mike discussed identifying suitable applications for moving to the Cloud, scale of the application and the independence of scale, the services used and tight integration with loose coupling (not the first time we've heard this today but I would hope, not the first time in our careers either, otherwise, you're doing it wrong), usage patterns, latency, security and many other facets to be considered when moving to the Cloud.

The final point related to whether the move would save money or not and the importance of answering that question before making the move. This kind of information was great to see and may prove very useful when talking with project managers or business development types. Mike also pointed out using techniques like multipurpose worker roles and disposable compute instances to save as much as 50% in costs.

And then it was lunch.

Things to check out after this talk


Develop IT: Intro to PowerShell

I admit it, I have only ever used PowerShell for things that I could've done from a regular command prompt, so this talk was one I didn't want to miss. I want to know more so I can do more. I feel like PowerShell is an exclusive club for productive individuals and I'd at least like to take a look inside, so this was my opportunity. Sarah Dutkiewicz (@sadukie) was the presenter for this session, a C# MVP and co-author of Automating Microsoft Windows Server 2008 R2 with Windows PowerShell 2.0. This talk was entirely presented using PowerShell, which certainly made it stand apart from other presentations given so far today.

The initial examples given by Sarah quickly demonstrated how PowerShell provides similar behaviour to the traditional command prompt but also how it is different, providing .NET objects (dir w* | Get-Member demonstrated how dir provides an object—very cool). We then learned all about the standard PowerShell syntax that provides an easily dicoverable set of commands (known as Cmdlets in the PowerShell world) and some useful Cmdlets like Get-Help and Out-GridView (which outputs things to its own filterable grid in a window).

Sarah continued introducing us to a variety of PowerShell concepts and features including but not limited to:

  • functions
  • modules
  • manifests
  • PowerShell ISE[7]
  • providers
  • aliases
  • registry interaction

My biggest takeaway is how easy it can be to work with the registry from within PowerShell (just open PowerShell and enter cd hkcu: then dir to see what I mean). Overall, a great introduction that has given me a starting point for exploring PowerShell and becoming more efficient.

Things to check out after this talk


Stone Soup or Creating a Culture of Change

For the final session of the day, I rejoined James Bender (@jamesbender). I was really looking forward to this having faced many challenges in changing culture as part of my efforts for meeting the requirements of CMMI[8]. This was expected by event organisers to be a popular talk and I still feel that it should have been; however, the turnout was disappointingly low. This made for a more intimate session and certainly did not detract from the informative content. James expressed that this was probably the last time he would present this talk, which is a shame as I found the anecdotes and the lessons that were drawn from them to be very insightful.

The things I've learned will definitely help me in my work and elsewhere. Things like:

  • Go for low hanging fruit
  • Don't change too much at once
  • Support the change and let it simmer
  • Don't judge
  • Know your tools
  • Only introduce changes you believe in
  • Understand the business
  • Know when to say when
  • Evangelize
  • Build a network of like-minded people
  • Be a politician
  • Be a therapist
  • Realise that it might be difficult to reach everyone
  • When all else fails, buy doughnuts
  • Be patient

There's not much more I could say about this talk that would do it justice (not that my notes have really given justice to the earlier talks), but suffice to say this presentation was very relevant to me and I am very grateful to have been able to see it.

Things to check out after this talk


To conclude, I had a great day. The organisers, sponsors and speakers deserve a huge "thank you" for setting up and supporting this event. Wandering the hallways of Washtenaw Community College, attending talks in rooms and lecture halls reminded me a little of being back at university, but the speed at which the day flew by certainly did not. It was a very informative and enjoyable way to spend the day and among the best $10 I've spent this year.

Footnotes    (↵ returns to text)
  1. Use Internet search before you ask someone.
  2. Specific, Measurable, Achievable, Realistic/Relevant, Trackable
  3. Besides, "Shut up, Jeff!"
  4. An appropriate amount as allowed by law.
  5. Mmm, bagels.
  6. Test Driven Development
  7. Integrated Scripting Environment
  8. Capability-Maturity Model Integration