Feedback is Fun

Feedback was the most exciting part of the day for me today. It was in a meeting and everything, so what could be better?!

If you detect sarcasm there, oddly… you’d be wrong.

Our 12 person leadership team was doing an exercise with a 9-Box Model and our Head of Engineering tasked us to prepare a self-evaluation and feedback for others as well. Our 9-Box classified Leadership Potential along the horizontal axis, and Performance in the role on the vertical axis. It was a bit daunting.

I spent some time Wednesday evening shuffling names around in lists, trying to work out what made sense. I wrote a whole host of notes for the meeting for everyone. And then I didn’t use any of it when push came to shove.

The feedback session was a mix of some different levels of the Org Chart, which was an interesting concept. Listening to Manager Tools teaches one rule about Feedback above all else: “You do not give Feedback to your Boss”. So of course, I proceeded to give constructive feedback to both my boss, and my boss’ boss.

I think the way this session creeps through the eye of the Manager Tools needle is that this was probably not technically feedback in the sense that they use, in that from bottom to top there is no implicit expectation that all feedback must get taken up. Details.

It was fun though, and incredibly constructive.

Giving and taking feedback can be hard, but the more you do it, the easier it gets. It feels uncomfortable because nobody does it enough. It’s the proverbial rusty wheel of management.

For my part, two things stood out (there were other noteworthy items, that need more time to percolate):

  • I have probably not been mingling enough with everyone, shown by the fact most people had trouble finding feedback (and it’s not because I’m perfect already, thanks mom).
  • I make things sound more complicated than they actually are by over-explaining. Although I do suspect that there are times when I don’t explain enough of the intermediate steps of my reasoning as well in my excitement to draw people to the conclusion. I blame Scott from my previous job for just being too damn quick at keeping up with everyone.

The latter point is definitely the harder for me to fix.

When I get questions, my first instinct is to try to explain the full nuance of the subject in one go. Which isn’t helpful. But then… I hate the idea of people falling into pitfalls I could have warned them against.

I guess until we get neural up-links with better bandwidth than a human voice I’ll have to settle for being Mozart, because my skills are definitely not adequate to being Bach.

(If you don’t recognize the Douglas Adams reference in the last paragraph, click through… it’s probably my favourite quote of his… the whooshing deadlines one is seriously overrated).

On Communication

“We need more communication!”

Odds are, if you’re working in any organisation that isn’t small enough for everyone to know everyone, this is a complaint you’ll have heard at least once. Communication is hard. Everyone knows this.

Odds are, once you heard this complaint, you did something about it because you’re trying to be an effective manager and you want everyone to be informed… you added extra presentations, a regular newsletter, you wander the floor and talk to people.

And then the next time you ask, communication is still touted as the biggest problem everyone faces.

The bad news first; communication is always the biggest problem you’ll face in your organisation. And once you address it, communication will still be the biggest problem you face. Always.

The good news; you’ve probably misunderstood what people are trying to tell you. There is one very deceptive word in that first phrase. Okay, maybe two, but one in particular that sent you down the wrong path.

What can “more communication” mean?

  1. You don’t talk to us enough.
  2. You don’t talk to us about the right things.
  3. You talk to us too much.

Yes, really. Even that last one. Stick with me

1. You don’t talk to us enough

It is possible your understanding of what your staff and co-workers need to know about is too narrow.

Are the details of the next project a distraction while we are still finishing our current work? Or could advance knowledge let my staff make some smart decisions about laying foundations for the next thing while finishing the current thing? They’ll get annoyed if they never find out in time they could have done something smarter for the company.

Are competitive pressures just going to worry people about their jobs? Or am I missing an opportunity to engage the creative capacity of my staff to innovate us to the top of the pile? It is very dis-empowering to feel like you’re just sitting in coach while your life is in the hands of the pilot alone.

Is it actually better to not say anything when you have nothing worthwhile to say? Silence lets people imagine all kinds of far-fetched reasons for that silence. Sometimes a trivial or obvious update is less harmful than letting a fear of unspoken horrors fester and grow.

Cast a very critical eye over all the things you don’t tell staff and co-workers. Why don’t you?

But…

Even when there is a genuine lack of communication, be careful how you fill that void, or you’ll be back to re-read this post for points 2 and 3 in no time.

2. You don’t talk to us about the right things

So, how about I talk to everyone about the next big project that is coming up, and how I need to negotiate it past the VPs and legal team of the company we are selling it to…

Bzzzzzt, wrong…

Yes, talking about the next big project is a great idea. But your needs and concerns aren’t that of your audience. What possible use could your developers have for knowing you are locking horns with legal over whether the solutions you develop for their specific problem domain will entitle you to ownership of those solutions… *snore*. None of that can possibly help them do their own jobs better.

Figure out what they actually need to know, and tell them that instead. And yes, maybe painting a little context is valuable, but do not turn it into an epic about the heroic way you are fighting through your own obstacles… it may be entertaining if you are a good storyteller, but they’ll resent the time they just lost once they realise they had their own jobs to do. To paraphrase Kathy Sierra, “it isn’t about you, it is about your staff”.

Tell them what the VPs want out of the product so they can tell you whether it is even feasible.

Tell them what is going to be non-negotiable so they can start thinking about solutions early and often.

Tell them how to firewall development of features if you are concerned over legal ramifications down the track.

Make sure the information is pitched so it is relevant to your audience, otherwise it’s not communication, it’ll just be talking and listening. And it’ll be a waste of everybody’s time.

And yes, this takes more effort, because you’ll have to think before you speak.

But sadly, that’s going to be unavoidable.

3. You talk to us too much

You’ve been trying to address the communication problem for a while now. You’ve added meetings, newsletters, presentations and extra face-to-face contact till you simply have no more time left in your day for anything else. You’re telling me that was all the wrong thing to do?

Not necessarily.

You may have started with problem 1 – not enough. And you may have wandered through problem 2 – not the right things. You have addressed both of those and there is still a communications problem. What happened?

Everything that isn’t “1” or “2”, is “3”.

Everything you added that wasn’t addressing one of the first two problems has now contributed to obscuring the real information everyone wanted. You’re talking so much that they cannot tell what is important any more. Or they simply cannot find what they care about in the deluge.

Luckily this is the easiest to fix. But it takes courage.

Trust that you’ve worked out what is important, and then ruthlessly discard what was not.

And yes, it may mean that you need to segment your communication. You may need to write a separate update to your staff, and to your boss, and to PR, and to support, etc. And it will take you extra effort to tailor all these messages. One message may feel more efficient, but when one tree falls in the forest and nobody can agree which one it is, does it really matter how quickly you could write it all down?

When “more” isn’t “more”

And by now you have probably worked out the problem with the opening phrase. “More” implies a quantitative problem. It calls for more of something.

But communication isn’t merely the combined acts of talking and listening. It requires relevance to both parties involved. So “more communication” can be either a quantitative or a qualitative problem; either “more talking” or “more relevance” or “more obvious”.

Here endeth the rant.

Day 293 – Quest For Time

73 – 100 Tips to Manage Your Time Better

I am slowly reaching a startling conclusion.

After looking at many lists of 100 items on the internet.
The suspicion is dawning on me.

That some of these lists…


…might be written by amateurs with very little application of thought.

I was hoping to discover the secret to more efficient time management, handed down the ages by an unbroken line of Tibetan monks. I didn’t need to read past item “1. Value your time” to realise I had taken a wrong turn somewhere.

Some days… nay weeks… it feels like there is just not enough time to climb the mountainous demand on it. It feels like the tasks pile up faster than I can ever hope to finish them. And I just need some kind of system to triage the list down to manageable proportions. Ah, screw it; I just want a Silver Bullet already. Anyone got one?

I suspect I really should give GTD a really good work-out. I am using a cobbled-together variant that has been serving me well, but I think I need a stronger dose of the undiluted stuff. I have many many bookmarks on relevant pages, apps and tools. I just need to read them.

I just need to find some more time to learn how to find some more time.
It feels very ironic.

Day 224 – Professional Juggling

Some days management feels like juggling.
With 7 clubs of differing sizes.
Whilst wading through 3 feet of treacle.

Oh, and one of the clubs may have sharp spikes coming out of it through half of the handle that you’d do best to avoid as well.

At the base level there is a certain routine to it. Things that happen every single week, such as catch-ups with staff and business interests, project meetings, team meetings, time sheets. Listening to concerns from others and then trying to take action on everything before I forget again what they have told me.

Making a routine definitely helps in leaving opportunities for people to remind me when something slips behind the sofa-cushions of the work week.

Where the juggling gets complicated is with the ad-hoc tasks that come my way. It’s a mix of all kinds, and because most of it seems non-recurring, it involves a learning curve each time. And often it’s not clear whether something is important or merely urgent. (And sometimes it’s the trivial disguised as one of the other two).

I really don’t know why I feel as swamped as I do, because objectively my team isn’t that large, and the number of projects we work on isn’t particularly overwhelming. There just is a lot of un-optimised process surrounding it all that I’m still learning to wade my way through most efficiently.

Maybe it’d help to drain some of the treacle though.
2 feet of treacle is plenty.

Day 203 – Management Self-Study

It didn’t take long for me to get hooked.
It amazes me that HR didn’t already know about it.

I am listening to a management podcast that is really good at providing concrete actionable suggestions on being better at routine management skills and tasks.

I think every manager should listen to Manager Tools Basics at least, which has some great foundational topics. And the ongoing Manager Tools podcast builds on those basics to cover topics like hiring, politics, reviews, and so on.

If it’s management, there’s an episode for it.

Day 133 – Surprising Jobs and Dice

No Dice

What could be simpler than dice?

If everyone has a fair un-weighted die, all have the same chance to win or lose.
P(A wins over B) = P(B wins over C) = P(C wins over A) = 0.5

You win half the time, you lose half the time.

We can change the dice to make the battle less equal. We can give some multiple sides marked 6, and others multiple sides marked 1. We can shift the balance to give A an edge over B, B an edge over C… and then overall C is the big loser.

Mathematically we call this the transitive property.
If A > B and B > C, then A > C.

Obviously and intuitively this must be true, right?
You’d be wrong in thinking so.

It is possible to design a set of dice where A on average beats B, B on average beats C and C on average beats A. We call these non-transitive dice.

An example of such dice could have sides marked (if you don’t want to click the link):

  1. Sides: 3, 3, 3, 3, 3, 6
  2. Sides: 2, 2, 2, 5, 5, 5
  3. Sides: 1, 4, 4, 4, 4, 4

Die 1 beats die 2 in 21 out of the 36 possible combinations.
Die 2 beats die 3 in 21 out of the 36 possible combinations.
Die 3 beats die 1 in 25 out of the 36 possible combinations.

Obviously, intuitively, this isn’t possible, yet there it is.

Best Man for the Job

Which is where a recent management dilemma comes into the picture.

I somewhat flippantly summarised my problem as related to explaining a potential budgeting issue due to non-transitive aspects to skill-to-project mappings. That was really a slightly hand-wavy allusion to the dice above.

Let’s make it a little more concrete.

Let’s say we have 3 IT projects:

  • Web project; no complicated coding, but it does need to look good
  • Banking system; routine processing, but it does need to be fail-proof
  • Page-rank; a very mathy problem, but once understood easy to code

Let’s say we have 3 Developers (all parallels to real people is coincidental):

  • One genius: Steve Yegge
    Great at almost everything, except graphical design
  • One average developer: Jeff Atwood
    A flair for design, and knows enough transaction-safety, but no maths-whizz
  • One manager who shouldn’t be coding: Bill Gates
    Passable design-sense, passed maths, but don’t trust him with your money

Let’s say we have to estimate how long it will take to complete the 3 IT Projects with the Developers we have available. We could specifically allocate names to the projects, but the projects are due to start at different points in the future that we do not know yet.

Well… how about we just estimate everything for a general average developer and then work out the names later? Intuition says that some will be over and some will be under, but on average we’ll get our estimates right… right?

Web Banking Page-rank
Yegge 50 days 10 days 10 days
Atwood 10 days 30 days 50 days
Gates 30 days 50 days 30 days

On average, each of the projects will take 30 days.
On average, Yegge is faster than anyone else.
On average, Atwood is average.
On average, Gates is slower than anyone else.

But let’s just step away from the averages and have a look at what could happen once reality unfolds in three different ways:

  • Yegge does Banking, Atwood does Page-rank, Gates does Web
    Result: 90 days total, 30 average per project
    A truly average result
  • Yegge does Banking, Atwood does Web, Gates does Page-rank
    Result: 50 days total, 16.7 average per project
    The best possible outcome
  • Yegge does Web, Atwood does Page-rank, Gates does Banking
    Result: 150 days total, 50 average per project
    A learning experience for everyone; also: OH GOD, WHY? IT BURNS!

So, depending on who is available when the projects kick off, either through chance or because we planned it to be that way, it could take as little as 50 days or as many as 150 days.

It could be 40 days under (almost 50%), or 60 days over (more than 60%).

And note that this is with a relatively mild skills gap.
Some developers are order-of-magnitude faster than others.

Also note that in this example I’ve glossed over the other project work that would make it impossible to assign Yegge to both Banking and Page-rank, which would leave Bill no coding to do (arguably an even better outcome for everyone).

Again, our intuition is wrong.
And for very similar reasons to the dice.

What this means is that it’s almost always a mistake to try to estimate project work based on an “average” developer. It is better to always have a specific developer in mind, and if that changes, adjust the effort estimate accordingly. You will end up with far fewer counter-intuitive results to explain after the fact.

Try Science!

And that brings me back to an earlier point.

If possible, always try science first. Even on problems that you cannot completely “solve” mathematically. An approximation will at least warn you if There Be Dragons before you get et.

Day 121 – Try Science!

Today I found myself trying to explain a potential budgeting issue due to non-transitive aspects to skill-to-project mappings. I was attempting a conceptual explanation, but I’m not sure it connected. I think I should do a numerical example to illustrate the point I was trying to make.

It occurs to me though that this might lend itself to a good blog post. I just need to figure out how to set it up and then explain in a way that is more generally applicable.

Courtesy of xkcd, Try Science!
Courtesy of xkcd, Try Science!

I think science is a great tool.

Maybe not so much to get a final answer for a management problem, because the soft skills are just hard to quantify numerically. But I think there are mathematical and scientific tools that could fit in a management tool-belt to assess some of the situations I’ve already run into myself.

Explaining these in the moment is hard.
I never feel prepared enough.

I really enjoyed writing the post exploring contract resourcing, and I think I might want to do more in that same vein.

An occasional series of posts with concrete examples and, where applicable, formulas so that the next time I need to explore the limits to certain problems or explain what is possible, I have some read-made “tutorials” to draw upon.

Day 120 – Meeting

There’s nothing like 4 attempts at doing the same new thing in a single day. I don’t feel I was very consistent from one to the other, but they were all variations on a general theme. And I think I have some ideas of what I should be taking into the meeting myself.

I’m a big fan of taking notes collaboratively.

I would like to use a OneNote document in a location the direct reports and myself share, so I can create a new page for each weekly meeting and have a separate tab to track outstanding action items and future plans. Unfortunately a slight technical difficulty is preventing me from doing so. According to SharePoint, OneNote documents aren’t quite like any other document. Who knew?

For now, I am using Lync to screen-share an email with the developer, and then I type up the notes as I go along. No hidden agendas, and we both keep a copy of the notes afterwards. It also means that the notes to share are typed up right at the end of the meeting, because I write them as we go along.

I really recommend always keeping meeting notes as you go along and emailing them out straight afterwards. Notes that need to be “typed up later, and I’ll get them to you ASAP” have this habit of ending up on the back-burner, and the backlog just nags at my sense of what I should be doing. It’s less mental effort to do it along the way and then be done as soon as the meeting finishes.

The content needs some tweaking. I figured out different things that I should be asking everyone in each subsequent meeting. I’m keeping notes on these points so that I can be better about that in future meetings.

I also need to see if I can book a room for the not-me side of the meeting. I don’t mind taking frankly wherever I happen to sit, but I really want to be able to give everyone the opportunity to have privacy if needed. Anything to minimise barriers and discomfort.

Also, I’m wondering whether I should arrange similar weekly meetings with my direct business customers. I think the format and structure have something to offer to keep in touch with business needs and keep them informed of what is going on. I might go gauge interest tomorrow.

Now it’s the end of a very full day though, and all other thoughts can wait till tomorrow.

Day 119 – Prepping Meetings

Tonight I am preparing for something new in my management routine. Or rather, modifying something existing to try and make it more effective.

I’ve been listening to Manager Tools, and they very heartily recommend a weekly meeting with a very specific structure. So I’ve scheduled all my meetings on the middle day of the week and I’m trying to take some notes beforehand about what I want to talk about.

The podcast suggests that Thursday is the ideal day, but they do not quite explain why, other than not to make it the start or the very end of the week. For one thing my Thursday is already taken.

For another, I like the idea of putting this meeting in the middle of the week because on the one hand it leaves enough time for direct reports to remember what they were doing after coming back from the weekend, on the other there is enough time left in the week to actually do something substantive with any feedback that might come out of the session.

I have no idea what to expect.

The timing worked out interestingly too, because this first time around I am actually in Melbourne, so my otherwise-local-developers will start off remote, and my remote developers local.

It’s one big experiment!

Back to preparing notes now 🙂

Day 92 – Makes J a Dull Boy

Red has swallowed my calendar. I colour code meetings based on their nature and importance, and red is pretty much the top of the pile. Nothing moves them.

I think this is the first time my calendar was booked solid before I even arrived in Melbourne. And that’s taking into account spending an extra day down here.

I’m not sure exactly what happened.

And today is not over yet. The office-portion of my workday ran from 9am till 5pm with a quick break for lunch. Now, the hotel-portion of my workday is still ongoing; I even had my dinner in my room. I think around 9pm I’m going to call it a day and move on to the Jerry-needs-to-relax-now portion of the day.

I am blaming the Development Department Planning Day for taking over my calendar. Basically I managed to pick up a charter that includes responsibility for the planning day. And I don’t like half measures. So I learned about SWOT analysis, and a process for planning out from Objectives down to Projects.

And tonight I am preparing my input into all this analysis so I can lead by example tomorrow. Maybe somebody else in the group will know how planning days work, but I’d rather not gamble on it.

Which means, I must make sure the only person I have direct control over (myself) is across this stuff.

And then second half of tomorrow and first half of Friday will be dedicated to a split-day-planning-day. Also done on purpose, because I imagine that about halfway through we’ll come to the conclusion that we finally understand how a planning day works, and not everything we’ve done up to that point is quite right. So, the break in-between the two halves will give everyone a chance to re-group and re-think.

I try to be prepared for any eventuality.
I should have been a boyscout.
(But maybe not, because I hate their organisational politics)

Anyway. That’s my evening; how is yours?