Any developer worth hiring will tell you that the best meeting is the meeting that doesn't happen. Some will even be so kind as to tell you that at the beginning of every meeting they're invited to!
The one meeting that I always get value from, however, is the one-on-one. Whether or not I'm having the meeting with my manager or someone on my team I'll always come away with something that made the time invested worth while..
The one-on-one is a meeting where there may be venting, there may be difficult conversations, there may be awkward silence, but the manager's job isn't to be defensive or aggressive, it's to play the part of a good listener. If there is a slip up then the trust will be damaged, if not broken entirely, and will take a long time to repair. This isn't the trust that's related to integrity, such as failing to meet a promised deadline, but the "I won't tell you that I'm unhappy with what's going on and I'm looking for new jobs on Monster.com when you're not around" kind.
Although work status will frequently come up during the one-on-one I make it a point to never explicitly put it on the agenda. I want the meeting to be about the status of Fred, not the status of
Fred's work, which means the first question I always lead with is "How are you doing?". I'll also ask some variant of "what's getting in your way and what's on your mind?", which has a subtle, but key, distinction from being work status related as this could lead beyond a discussion of the issue that he's blocked on and into one about how he'd really like to get two days off to help his girlfriend move but he's not sure about taking it because of the amount of work that's piling up. Their response to that question leads quite naturally into "what can I do to help you?"
I've never encountered a programmer that has said "I really like that this meeting was booked in the middle of the afternoon, I really didn't need to be concentrating on finding that one rare concurrency bug." I could be wrong.
The team is being paid to do good work, and I'm being paid to shelter them from BS, so in order to shelter them from BS and allow them to do good work I try to keep meetings to a minimum and preferably at the periphery of the day. Putting a meeting in the middle of the day kills what your team members are working on, causing them to take a while to get back up to speed once it has concluded. I try to put my one-on-ones at the beginning or end of a solid work block, such as the beginning of their (not your!) day, and either before or after lunch, typically avoiding the end of the day because the end of the day can vary with whatever is going on. A good read on this topic is Paul Graham's essay, Maker's Schedule, Manager's Schedule.
Friday, June 29, 2012
Wednesday, June 6, 2012
Co-routines in C(++)
A little while ago I put together a small co-routine library in C targeting x86/Windows. It uses micro-stacks of about 4kb, minus a small tax for library overhead, for each co-routine which places some constraints on the work that can be done but I figured that it'd complement Windows' fairly heavyweight fiber library.
The code sets up a new thread context, by setting esp to point to the new co-routine stack, and then uses setjmp and longjmp to yield the co-routine to the main execution context and to resume the co-routine from where it left off.
One known issue is that if you build C++ code with Visual C++'s /EH command line options the compiler will automatically run destructors on stack objects as it unwinds past them, and so any objects you create in your co-routines will be destroyed prematurely. Building without exceptions enabled will work around this.
Code: https://github.com/maxburke/coroutine
The code sets up a new thread context, by setting esp to point to the new co-routine stack, and then uses setjmp and longjmp to yield the co-routine to the main execution context and to resume the co-routine from where it left off.
One known issue is that if you build C++ code with Visual C++'s /EH command line options the compiler will automatically run destructors on stack objects as it unwinds past them, and so any objects you create in your co-routines will be destroyed prematurely. Building without exceptions enabled will work around this.
Code: https://github.com/maxburke/coroutine
Management 102: Post shake-up stability
My last post mentioned a few points to keep in mind now that you're a fresh manager. In this one I'm going to go into the first tasks you need to accomplish in first day after the reorganization has been announced. The reorganization doesn't have to be a full company shake up, it could be something just as simple as two people shuffling around.
Hopefully you've had some advance notice that this was coming, giving you some time to plan things out, knowing who will be reporting to you, and possibly what you'll be working on. (Digression: I dislike the term "report" in the management-hierarchy-sense. I guess it comes out of industries where there's a more rigid command-and-control type of infrastructure. Like the military. But the people in your group aren't soldiers; no, you're paying them good money so that they can flex that brain of theirs, not just follow orders. The company's paying you to be their BS shield.)
Re-orgs are kept on the down-low to keep the hand wringing to a minimum, but see if you can suss out who else is in the know, and if they are currently managing some of your new group. Same goes with the new projects you'll be overseeing. The goal here is that once day one arrives you'll look like you have some clue as to what's going on and who these people are. You'll want to sort out a transition plan for your current responsibilities so that you don't appear to have bolted on your old job.
If you've got some time to kill before the big day you might want to start planning your schedule, where you'll fit in your new one-on-one meetings. Getting your one-on-one's setup is a great first step as this is where you put your finger on the pulse of the team; far beyond a face-to-face status report it's where you find out what's on their mind, what troubles may be lurking below the surface. I believe that the one-on-one is so important that I'll go into it in detail in my next entry.
It's a good idea to also have some plan of what you want them to do in the short term, until you can really start digging into the new problem space, even if the plan is to keep on keepin' on. Don't let them twist in the wind.
Once the one-on-ones have been sorted out and you've met them, it's probably a good time to get the team together for a lunch, to get away from the work and get to know each other a bit.
As the day winds down you should start seeing some semblance of routine; maybe you'll have your first official meetings with the team. Your old job should be fading from view, as you'll have plenty to do with your new team and you don't want to give them the impression that they're not the most important part of your work life.
In the end you want to make sure that there's no large clouds of uncertainty hanging over your team's heads. Don't sweat it, you're going to do great!
Hopefully you've had some advance notice that this was coming, giving you some time to plan things out, knowing who will be reporting to you, and possibly what you'll be working on. (Digression: I dislike the term "report" in the management-hierarchy-sense. I guess it comes out of industries where there's a more rigid command-and-control type of infrastructure. Like the military. But the people in your group aren't soldiers; no, you're paying them good money so that they can flex that brain of theirs, not just follow orders. The company's paying you to be their BS shield.)
Re-orgs are kept on the down-low to keep the hand wringing to a minimum, but see if you can suss out who else is in the know, and if they are currently managing some of your new group. Same goes with the new projects you'll be overseeing. The goal here is that once day one arrives you'll look like you have some clue as to what's going on and who these people are. You'll want to sort out a transition plan for your current responsibilities so that you don't appear to have bolted on your old job.
If you've got some time to kill before the big day you might want to start planning your schedule, where you'll fit in your new one-on-one meetings. Getting your one-on-one's setup is a great first step as this is where you put your finger on the pulse of the team; far beyond a face-to-face status report it's where you find out what's on their mind, what troubles may be lurking below the surface. I believe that the one-on-one is so important that I'll go into it in detail in my next entry.
It's a good idea to also have some plan of what you want them to do in the short term, until you can really start digging into the new problem space, even if the plan is to keep on keepin' on. Don't let them twist in the wind.
Once the one-on-ones have been sorted out and you've met them, it's probably a good time to get the team together for a lunch, to get away from the work and get to know each other a bit.
As the day winds down you should start seeing some semblance of routine; maybe you'll have your first official meetings with the team. Your old job should be fading from view, as you'll have plenty to do with your new team and you don't want to give them the impression that they're not the most important part of your work life.
In the end you want to make sure that there's no large clouds of uncertainty hanging over your team's heads. Don't sweat it, you're going to do great!
Subscribe to:
Posts (Atom)