Book review – Managing Humans by Michael Lopp

» 23 August 2009 » In books » Comments Off

Just a quick one today.

Michael Lopp, aka Rands, writes the most excellent and much recommended blog Rands in Repose. Managing Humans is, in essence, a collection of the best bits from his blog, re-mixed, re-mastered and refreshed for paperback.

I’m a big fan of the blog, so it’s no real surprise that I’m a big fan of the book as well. Like the blog, the book is written from the perspective of Rands – who presents a no-holds-barred account of tech management in Silicon Valley. The book is styled around a collection of stories, not necessarily true but always based around real-world observations that provide the user with a lesson or point to take home, more loosely structured around a guy starting out at a new firm and tackling the first 3 months of his time there.

The big sell for this book with me was the style. I really enjoy the way Lopp writes as Rands (check out the blog for examples of this). He doesn’t pander to some predisposed idea of what is and isn’t acceptable for manager-speak, at least compared any of the other books I’ve read on this subject, and in the process comes across as one of my mates, in the pub, giving me advice over a pint of addlestones.

The only final point I’d make is that the book isn’t exactly PC (the opening line is Don’t be a prick). I suspect Rands provides an outlet for Lopp to vent his frustration at times, and this certainly comes out in the book. If you’re easily offended or don’t have the time to listen to middle management ranting this might not be the book for you!

Continue reading...

Tags: ,

Learning to read

» 23 August 2009 » In management, rambles » Comments Off

This post forms part of my larger blog on starting out as a manager. See here for the full post…

Reading is good. New skills require practice and learning. New jobs require new skills. Maybe you were lucky and had a super-manager from the day you graduated and you can just emulate them. For the rest of us we have to aim to better our personal experience. Here’s a list of stuff I’ve read that I found really useful to help managing people.

Personally, I found managing the projects harder. There’s a lot of information out there but a lot of buzzwords too. Again, I could write pages on what I’ve learned here. I’ll try and keep it short.

  • Collate data on what work your team needs to do.
  • Collate data on what work your team is actually doing. This is quite hard.
  • Determine the goals of your team and how they fit into the goals of the company. Tell them to your team. This allows them to work effectively and make informed decisions.
  • Bin any notion of using Project Management software. Unless you’re looking after tens of people (in which case, what on earth are you doing listening to me) they just take up too much time and don’t work very well. Use a whiteboard or a wiki. I’d love to have a big electronic whiteboard to combine the advantages of both (and for Monday night Quake III sessions). I’ve not found the perfect solution for this yet.
  • Plan to spend a lot of time keeping all the information up to date. It won’t feel like work, but it is important.
  • Don’t give up! Nothing in project management is complicated. That does not mean it is not difficult. (Paraphrased from ‘Behind Closed Doors’)

Continue reading...

Tags: ,

Learning to communicate & empathise

» 23 August 2009 » In management, rambles » Comments Off

This post forms part of my larger blog on starting out as a manager. See here for the full post…

The facts are this. You can no longer sit in a nice, dark corner of the office, hacking away at a bunch of bug fixes and new features, ignoring the Marketing department. You are in charge of a team of people. People who need your guidance – not because they are less intelligent than you but because they are paid to sit in a nice, dark corner of the office, hacking away at a bunch of bug fixes and new features, ignoring the Marketing department – and you are paid to ensure they can stay there, without interruption. To do this somebody must talk to the Marketing department. And Product Dev. And the Senior Management, Account Management & Sales teams. That somebody is you.

You also need to interact with people at higher levels of management. People more busy even than you (as if that could be possible!). People who need accurate, informative and succinct pieces of information to do their jobs properly. Unless you’re very lucky you’re also going to have to get very good at communicating with your team. Changes will take place. A company re-structure, a large new client and you’re the poor thing that has to convince a team of techies that updating the iteration plan every day really is beneficial to them. No, really. It’s not a waste of time. And that workplace assessment is vital too.

To do all this, you need to communicate and to empathise. These are not necessarily skills that the average techie has used recently. Maybe you’re out of practise. Open yourself up to other peoples problems and try and figure out what you can do to make them less painful. Your job now is a facilitator, go facilitate.

Most of all stick with it – it gets easier.

Continue reading...

Tags: ,

Learning to focus

» 23 August 2009 » In management, productivity, rambles » Comments Off

This post forms part of my larger blog on starting out as a manager. See here for the full post…

I think this is a lot harder than it sounds. My current role requires that I Project Manage, Tech Lead, Line Manage, Develop, Account Manage & help Tech Support; a role where I go from meetings discussing the problems we’re likely to face with resourcing in six months time or where we’d like the products to be a year from now to advising a developer on exactly how that method should behave under those particularly esoteric set of circumstances for this tiny corner of the codebase – all in the space of time it takes me to walk the length of the office (about 15 seconds, we’re a small company!). Keeping an eye on what’s important at each of the different levels within a company is really hard work, and having to switch between them constantly is a huge drain on your time. Here’s my two cents for dealing with focus:

Play nicely

“There isn’t enough room for me and your ego” – Vesper Lynd, Quantum of Solace

Don’t let your ego get in the way of your job and, more importantly, your relationship with your new team. Yes, I know, you’re the new boss. And yes, I know you might be feeling a little insecure about that or at the very least wanting to cut your teeth and settle into your new role. However, I can assure you of two things:

  1. unless your new project is really fucking simple you won’t know everything there is to know about it;
  2. other people on your team will know more about some bits of it than you do.

So don’t let your ego tell you otherwise. If you do, you’ll spend way too much energy focusing on the wrong stuff – trying to prove that you’re superman – and not your job.

Get organised

Seriously. That list of tasks you kept in gedit was fine when you only had to look after yourself. Maybe you had 30 things on there. The last time I checked my tasks I had more than ten times that – far too much to keep in my head at once. How on earth can you keep all that under control? I tried a bunch of things. I’m still trying a bunch of things.The most important one is easy. Delegate. But keep track of what you’ve delegated as you’re ultimately responsible for seeing it through. Secondly, find a system that works for you and stick with it. For me this means, find a system that makes it trivial to record new items (more on this later) and fish stuff out quickly. Read lots if you’ve not looked into productivity tools before. David Allens book “Getting Things Done” is a great place to start (and a lot less self-helpy that the title suggests) as is Merlin Manns blog at http://www.43folders.com.Then find the tools to keep you using that system.

In the last 12 months I’ve tried using a Hipster PDA, ThinkingRock, Netcentrics Outlook plugin, Thunderbird add-ons, Omnifocus and a number of other apps designed specifically for task management. In the end Omnifocus won, not necessarily because it’s the best app (although I think it is), but because it’s super easy to input new stuff. Using OS X’s Services facility Omnifocus can grab text from virtually any application, store it quickly and let you get on with what you’re doing. I haven’t found anything similar on Linux or Windows. (The only problem here is that I don’t have a mac at work, but I do have a personal mac lappy that’s finding its way into the office quite a lot these days. If anyone can prove me wrong using something that works well with Linux please let me know!).

I could write an entire blog post in this in itself (I may well do), but the single most important point here is not context switching. I check my email maybe twice a day. If something comes in that I need to think about before my next bi-weekly with Product Dev, or it contains a point I want to raise at my next personnel meeting it takes me three keystrokes to stick it away in a special place where I can retrieve it when I’m preparing for those meetings sometime next week. I can file the email away immediately, keeping my inbox tidy, and know the issues it contained wont slip through the cracks. Then I can forget about it and get on triaging my inbox. Two minutes later I’m back on the task at hand. When you’ve got lots of information flying at you from all over the place this is really, really, really important.If you think you’re too busy to deal with all this productivity crap go and do it. Now. It probably saved my life.

Continue reading...

Tags: , ,

Learning to control without control

» 23 August 2009 » In management, rambles » 1 Comment

This post forms part of my larger blog on starting out as a manager. See here for the full post…

This was a hard one for me. Just after I started this gig, our biggest client decided they wanted to use one of the apps I look after in a big way. Like two orders of magnitude larger than our current biggest client used it. There was lots of uncertainty. There were lots of meetings – internally figuring out how we were going to do this and externally convincing the client we could do this. I had to be at most of these meetings but, worse, I had to keep track of what my team were up to, how they were getting on, how likely it was that we were going to meet our commitments.

Timelines were tight. I reckon in that first month I spent 20 – 25 hours a week in meetings. I had days with solid meetings from 10am – 7pm. That really hurts. Then I’d get out and the guys would ask me questions. Everything was moving so fast. I’d get home from work and read SVN commits until my eyes no longer focused on the screen because I needed to know how everything worked, to understand exactly how the team were building all the plans we had, to be confident when I was asked how things were going that I knew because I understood every new line of code.

This was a mistake.

This was not very sustainable.

I’m glad I realised the error in my ways.

The trick here is to threefold.

  1. Trust & understand your team. I’m lucky enough to work for a company that only hires very bright people. People with energy, enthusiasm and a genuine desire to produce really good work. That doesn’t mean these guys are infallible. Trust your team to do what they say they’ll do, but understand them well enough to know how likely that is to happen and what you need to do to increase that likelihood.After a certain size a project gets to a state where one person can’t understand everything that’s going on at every level.

    As a Project Manager you need to learn to control the game without having control of all the pieces. Your job isn’t to be the most knowledgeable dude on the project. Your job is to be the dude who knows who the most knowledgeable guys and girls are for every piece of the puzzle. Sure, that’s going to be you for some bits – but it won’t be you for everything. Figure out who is, what makes them tick, and how you can keep them on your side. For most techies  I know, listening to them, showing you respect their opinions and, when they differ from yours, taking the time to explain why is a good place to start.

  2. Communicate. I guess this is part of understanding in the above bullet, but find a way to help your team communicate. This isn’t something you can just read about, as it’ll depend on the dynamics of the team – individual personalities within the team, the size of the team, how dispersed your are from one another etc. Luckily for me, this one was pretty easy. We all sit in the same office, in the same city & we all get on well. So I had a good starting point but we’ve improved on this in a couple of ways:
    • Daily standups: We get together every day and have a 15 minute chat about what we’re planning to do and what we got done yesterday. These are useful for me – the manager – but are actually really useful for the gang too. People get a chance to say what they’re working on and more often than not somebody else pops up with some interesting titbit on the subject. Knowledge sharing – for free (well, almost). Winner!
    • Beer: Yup, that’s right kids. Beer. Or whatever other non-work activity you and your gang fancy doing. Every couple of months one of the guys cooks for the rest of us at their place, rotating around the team. We leave work together, grab a few beers, eat some tasty food, watch a movie or shoot some bad guys and generally hang out. This sounds like a small thing, but it’s about bringing the team together. Inviting them into your home creates a bond and helps the team gel. (The last time we did this we actually had the team doing to cooking rather than the one guy – who was ill – and that was even better!). Fostering a sense of family will help you make the transition from a group of guys working on the same project to a team of guys working to help each other out.
  3. Define the goals for your team. This one seemed so obvious to me once I thought about it, but wasn’t something we were doing anywhere in the company. I’m not sure if that’s due to our past – a small company full of friends, where the goals are naturally shared by being surrounded by like minded people you know well. But as you grow you can’t continue like this.

    Why are they important? Simply because, as a manager if you’re to trust your team to get on with their work you need to ensure that you both understand which of the many tasks available are the most important. My team has responsibility not just for development, but for operational support, testing, maintenance & end user support (to an extent), so it’s not always straight forward to figure out what the most important task to be getting on with right now.

    If as a team you can’t agree on what you’re biggest priorities are how do you expect to operate effectively?

Continue reading...

Tags: ,

crouch, touch, pause… engage!

» 23 August 2009 » In management, productivity » Comments Off

BAM!

There I was, stuck in the middle of the scrum. Heafty, sweaty men all around me. Helpless. Hopeless. Struggling to breath amid the stench of stale sweat and testosterone. My feet start to slip in the wet mud and suddenly the scrum collapses on top of me, 15 0.1 tonne men cram onto every inch of me and their weight starts to squeeze the consciousness from my body…

I wake up, sweating. Breathing hard. Tired. So tired. Just a dream. Phew! That one would’ve hurt! The irony doens’t escape me, even at 3am. A metaphore. My life – a constant struggle against forces bigger than I. Forces over which I have seeminly little control. Yes world, that’s right. I’ve recently become… <insert overly dramatic music> a Project Manager.

OK, OK. So that never actually happened. Not for real. But most mornings those first few months, it felt like it had. Long nights, stressful days, endless meetings. I was not ready for this.

What just happened? I went from a role where I thought I was getting a pretty good apprenticeship for work as a PM. I had dev responsibilities, client facing responsibilities, operational responsibilities and control over my day to day and week to week management.  These all sound like important skills to learn before taking on a position as a Project Manager. In reality, things were a little different. Why?

Update: This post got way, way too long, so I split up the main bits into four mini-posts. Hit the ‘More’ links at the end of each taster paragraph to read the rest of the post.

Learning to focus:
I think this is a lot harder than it sounds. My current role requires that I Project Manage, Tech Lead, Line Manage, Develop, Account Manage & help Tech Support; a role where I go from meetings discussing the problems we’re likely to face with resourcing in six months time or where we’d like the products to be a year from now to advising a developer on exactly how that method should behave under those particularly esoteric set of circumstances for this tiny corner of the codebase – all in the space of time it takes me to walk the length of the office (about 15 seconds, we’re a small company!). Keeping an eye on what’s important at each of the different levels within a company is really hard work, and having to switch between them constantly is a huge drain on your time…. More

Learning to control without control:
This was a hard one for me. Just after I started this gig, our biggest client decided they wanted to use one of the apps I look after in a big way. Like two orders of magnitude larger than our current biggest client used it. There was lots of uncertainty. There were lots of meetings – internally figuring out how we were going to do this and externally convincing the client we could do this. I had to be at most of these meetings but, worse, I had to keep track of what my team were up to, how they were getting on, how likely it was that we were going to meet our commitments…. More

Learning to communicate & empathise:
The facts are this. You can no longer sit in a nice, dark corner of the office, hacking away at a bunch of bug fixes and new features, ignoring the Marketing department. You are in charge of a team of people. People who need your guidance – not because they are less intelligent than you but because they are paid to sit in a nice, dark corner of the office, hacking away at a bunch of bug fixes and new features, ignoring the Marketing department – and you are paid to ensure they can stay there, without interruption. To do this somebody must talk to the Marketing department. And Product Dev. And the Senior Management, Account Management & Sales teams. That somebody is you… More

Learning to read:
Reading is good. New skills require practice and learning. New jobs require new skills. Maybe you were lucky and had a super-manager from the day you graduated and you can just emulate them. For the rest of us we have to aim to better our personal experience. Here’s a list of stuff I’ve read that I found really useful to help managing people… More

Still with me? Good work! Quick pat on the back.

So it’s been 12 months since I started working as a PM. I’ve got loads more to say about it but I don’t want to take up any more of your valuable time. Not just yet. Needless to say it’s been a rocky road and many a time things have felt out of control. As a company we’re growing up – fast. This has lead to some very ‘interesting’ times and I’m happy to say I’ve really enjoyed (most) of the them. There are bound to be more problems around the corner but each day I feel a little more capable of handling them.

Bring it on!

Continue reading...

Tags: ,

Volatile and Ordering

» 31 May 2009 » In development, tech » 1 Comment

I learned something interesting about the java volatile keyword the other day, and I thought I’d share it with the class.

First, some background:

What it does:

Volatile is a Java keyword which guarantees that any and every time the variable is read, you’ll get the most up to date version of the variable. This can be very useful in multi-threaded environments. Why volatile? From Dictionary.com (not in full):
vol⋅a⋅tile

  1. changeable; mercurial; flighty: a volatile disposition
  2. fleeting; transient: volatile beauty.

Simply put, the compiler is told not to let the bytes making up the volatile variable hang around in any registers or other forms of cache and so each time you ask to read this variable you’ll go get the most recent write from any thread.

The Java Memory Model requires that both fetch and store operations on 32-bit variables are atomic, but this does not apply to 64-bit operations – which can be considered as two 32-bit operations – unless the variable is volatile (or guarded by a lock). Thus, volatile variables also guarantee readiness/consistency for 64-bit primitives, e.g. longs and doubles.

What it doesn’t do:

Volatile variables do not guarantee atomicity, so compound functions like:

int x = 0;
int y = x++;

are not guaranteed to make y equal 1 as two threads running the above code simultaneously would cause problems (i.e. second line requires a ‘read x’, then an ‘increment x’. Another thread could change the value of x during that time).

With me so far? Good. Now, before I get to the interesting bit, quick recap on some concurrency pitfalls.

Bad code – Do not copy!

/*
 * Not threadsafe!
*/
public class Foo {
    private int x;
    private int a,b;

    public Foo {
        x = 0;
    }

    public void setX(int newX) {
        this.x = newX;
    }

    public void setAandB() {
        a = x+1;
        b = x+2;

        // This could fail!
        assert b > a;
    }

}

This could fail in (at least) a couple of ways. Well, it’s the same way really, but there’s a couple of points I want to make.

Firstly, and most obviously, in a multi-threaded situation the value of x could be changed between lines 17 and 18 by a call to the setX() method. Ooops! BANG. :(

Now, let’s say we realise that we only ever need to increment x by 2 (and never decrement). So we try and fix the problem above by removing setX() and instead use incrementX(), like so:

Bad code – Do not copy!

/*
 * Not threadsafe!
*/
public class Foo {
    private int x;
    private int a,b;

    public Foo {
        x = 0;
    }

    public void incrementX() {
        this.x = x+2;
    }

    public void setAandB() {
        a = x+1;
        b = x+2;

        // This could fail!
        assert b > a;
    }

}

As x can only be incremented, surely b must always be larger than a and the assertion will pass? Wrong! This can still fail because the Java Memory Model allows the compiler to change the order of code if there is no detectable change on the output of that single thread caused by doing so, regardless of how this might effect other threads.

That is to say, after compilation line 18 could be run before line 17. Now, your assertion will fail because, even tho the value of x can only ever increment, line 18 can be called first (b = 2), incrementX() may then be called from a second thread and then line 17 is called (a = 3). Ooops! BANG :(

But what’s this got to do with volatile variables, mrtom? Good question. And the answer is this.

Volatile variables force the compiler not to rearrange the order of your code.

So, if x is marked as volatile the second code sample will pass.

Better code – still not great mind!

/*
 * Not threadsafe, but the assertion will pass
*/
public class Foo {
    private volatile int x;
    private int a,b;

    public Foo {
        x = 0;
    }

    public void incrementX() {
        this.x = x+2;
    }

    public void setAandB() {
        a = x+1;
        b = x+2;

        // This could fail!
        assert b > a;
    }

}

Personally I don’t really like using volatile in this way. It’s unclear and fragile. I’d much rather use a synchronized block or an explicit lock. But maybe because of that I don’t use volatile very often and, due to this, don’t know much about volatile.

If anyone can think of a concrete use case where using volatile like this has advantages let me know. I suspect there may be some performance improvement over a standard synchronized block but I’ve not got any data to support this.

Better still

/*
 * Threadsafe
*/
public class Foo {
    private Object lock;

    private volatile int x;
    private int a,b;

    public Foo {
        x = 0;
    }

    public void incrementX() {
        synchronzied(lock) {
            this.x = x+2;
        }
    }

    public void setAandB() {
        synchronized(lock) {
            a = x+1;
            b = x+2;
        }

        // This can't fail anymore
        assert b > a;
    }

}

References/Further reading:

  1. Java Concurrency In Practise and
  2. Java Language Specification (third edition) 8.3.1.4

Continue reading...

Tags: , , , ,