The Meeting Before the Meeting

Have you ever attended one of these?  Not knowing what you were getting into until the end of the meeting where you thought everything had been discussed, ready to go but then only to be informed that now everyone was all prepped, on point, had the same message for the real meeting?

Did you then sit through the “real meeting” wondering why you were there, expect maybe for the proverbial show of team unity, wondering what code you could have eeked out in that total combined time block of 2 hours?

Getting your entire team into a room for a meeting, to discuss an issue, only to keep them in that room for another meeting right after where only 2 or 3 new members show up is not only a waste of your team’s time but it sets an adversarial tone with the new members joining the meeting knowing that you spent the last hour discussing the topic already and they now feeling left out, really only left with an option but to agree.

On the flip-side if the meeting before the meeting is used for you to meet with your team, discuss the topic and then leave your team to focus on other problems while you go and discuss with the other members of the main meeting, the tone automatically shifts.   It’s no longer becomes a numbers game and your team is not sitting through another session.  In essence, you’re taking the lead by representing the intentions of your team, being confident in not needing to have them all sitting there wondering why they are all there.

The only time I allow myself to have the meeting before the meeting is when I need to have it with myself and prepare myself with whatever content I need to get the most out of that upcoming meeting.  That’s on me to get that information so I can go in confident and assured in what is going to be discussed.

You can’t always reduce the need for meetings with your team (and larger teams), but if you can avoid (and hopefully learn to foresee) the implementation of meetings before meetings, your team will thank you… especially when it comes to delivering.

Letting People Fail

I’ve written about Failure a number of times – The True Cost of Failure and Insulating the Failure – and let’s be honest, so have many, many, many other people.

Some of my most spectacular failures were not the ones where I was up late at night coding by brains away trying to figure out some new problemset or use some new language – “Okay, so that’s what happens when you take up all the memory”.  No they were the ones where mine, the team, maybe the company’s back was up against the wall and I had to figure out things on the fly – maybe it was when I gave a technical presentation when the audience was expecting sales content or when I uploaded an older set of files to a new site and had to learn how to recover the files or when our demo wasn’t ready but I was asked to present what we had and build a story around it.

Perhaps my delivery wasn’t as polished as it should have been or the customer wasn’t as pleased with the latest “same” updates as they had thought they were getting and our internal team didn’t fall over in their chairs when my demo broke for the third time during the presentation (or fifth button click).

But…

I did learn that it was important to figure out your audience before doing a presentation and source control, versioning and labels are a great set of steps on way to pre-validation of a deployment and that getting customer feedback earlier in the demo cycle helped make the end product better.  In all those cases though, someone stepped back, let me run and let me fail.  They could have jumped in at any point, put the brakes on, told me what to do – but they didn’t.

They gauged the risk and let me try.

It’s not enough that we preach about failure and letting people try and try again if you are not going to let them do it when it really matters.  If it doesn’t matter, i.e., it’s something insignificant, it won’t matter to them.

Let the Fail… and in the end… watch them grow.

 

Keeping Up-to-Date

Near the end of every interview I always ask this question, there is some sort of a preamble to it…

“We work in a changing industry…”

“There are so many new technologies…”

How do you do it?  How do you stay current and relevant?

Many think it is a trick question, i.e., I am waiting for you to say one specific blog and then I will go “aha Hire them!” – not the case.  There is no one magazine, one blog or book that is going to make you stand out from the rest of the crowd.  Conversely, I have had people tally off the Top 10 blogs du jour in the hope that it will make me go – “well if they are reading all of those, they must be on top of everything, there is nowhere else to go.”

Both are incorrect.

No, the question is a way for me to figure out what shapes your views and opinions.  Many times, if it is a blog or book I have not heard, I will go look it up and take a quick gander of it.  Perhaps I’ll add it to my own reading list or perhaps not, but me aside – it gives me insight into who you are and what you are and where you are trying to go.

I love when the answer to this question is not technology focussed and instead is about someone learning to build and create something outside of code and listening to their reasons for wanting to do this.  Sometimes there are parallels, other times it is an escape from what they are currently doing so they can focus their attention elsewhere.

In both cases they are pushing themselves into something new and continually learning.  With any profession in today’s age, continual learning is key to your own future success, if you aren’t learning something new, then you’re stagnating and on your way to becoming a relic.  And this leads us to the worst possible answer which is for you to say “nothing” because it sends the message (albeit completely unintentionally from your side) that you are “too good” to learn anything new and you are an expert OR that you are too lazy to learn anything new.

Both are bad reads and if I have to choose between the person who reads a number of blogs on a weekly basis, maybe writes their own, subscribes to Beta updates, goes out and tries new concepts that are not a part of his daily work routine this shows the willingness to consistently poke holes in the status quo.

It’s not a tough choice who I’d hire.

The Trust Factor in Version Control

Ever look at the emails in your inbox that are suffixed with; _v1, _1.1, _gt, _EditedByGT, etc, etc and wonder Why are we still doing this?

We have all these incredible tools for version control and yet we continue to add these suffixes to the end of most of our documents?  Is it because…

We don’t trust Version Control.

Or rather, we only trust it when we are in control of the implementation?  When we are able to purposefully define that I am setting this as a new version?  Or is that we are worried that people will not recognize the changes that have been made to understand that it is a new version?  I.e., I changed two lines, is that the equivalent of a minor change or a major?  Is it still in Draft mode or is this a Published update to a version control module?  When opening a file and deciding to work on it, where do your eyes skip to first?  Top left to see the filename and what version you are on?  If you want to see the actual version number and taxonomy requirements you more or less need to go the “Version Control” area to see all that information.  Its a few extra steps that can be quite bothersome to everyone who is in a rush to review and update.  It breaks our workflow and is a change to how we previously created and shared documents.

But is this a problem with the Version Control implementation or those that are using it?

 

How frustrating it must be for those that setup these systems to reduce documentation duplication and redundancy only to see files renamed as in the above example stored in their precious implementations.  And when things start to go wrong, the first blame goes to the system that was so carefully implemented and not the user itself.

But this isn’t a technology problem, it’s a people problem, an adoption problem, a cultural problem.

If the culture adopts the move to a new platform and invests wholeheartedly, then something as complex as multiplicated (new word) becomes a thing of the past as the culture pushes the adoption towards simplicity and constant effortless re-use.

Buying a new shiny toy doesn’t solve your problem, how you use it does.

 

Understanding the One on One

In any training there is always that one amazing point that you take from it that blows your mind…

Why have I not been doing this for years?

It was right in front of me all along.

That makes total and complete sense.

For me, this was years ago when I had just become a Software Manager and the suggestion that I have One on One meetings with my team every month to see how things were going.

Shocking…

But there it was, the replacement for quarterly reviews that would across as a surprise, the time to have each member of the team individually vent to me while I suggested ways to help them and/or took those concerns higher up the line.

I quickly learned what made a One on One very useful…

  • Don’t do it in a formal setting – most times I would go for a walk to a coffee shop with people or just around the building so we could get some air and separate from the office – if the mood was tense, this helped break things up
  • Write it down… later – You have a brain, use it, after each review block off some time so you can write down what was just discussed, but don’t do it while with them – this allows for the mood to be free-flowing and not formal
  • It’s not about the work – it’s about the individual, what’s on them, where are they struggling, where do you see them needing to focus more – avoid getting into releases and deliverables and instead talk about their work as it relates to a piece of the project – “What you are working on is going to x value to the end product”

In it’s most simplest terms, the One on One is about them, not you and this is where it becomes a little trickier because you are doing way more listening then you (me) are probably use to.  Over time the goal should be to add small probing questions and save your answers (yes at sometimes long-winded) for follow-ups with the individual.

Some Questions I like to pose during One on Ones;

  • What are you currently doing?
  • Is that what you want to be doing?
  • Is that work challenging you?
  • How can I help you get to where you want to be?
  • What can I do more/less of to support you?

Nothing mind blowing there, but definitely enough to open the doors to communication and discussion.  You might find when you start having a One On One that some people are reserved in their communication and it could take between 3 – 4 months for them to open up, but the more you do it, the more they will talk and that’s what you want.

The other bonus piece to One on Ones is that they are a good indicator to how far you are scaling towards as an individual to your team.  If you have a team of 20, you are close to blocking off a week a month to have these conversations with your team.  This isn’t bad, but in my very humble opinion, that might cause some extra stress on you as you to try to find that extra time somewhere else and you start to push through your One on Ones at a quicker pace to get back your time.  In that sense, they become an indicator that your team is growing too large and perhaps you can’t meet with everyone as you would like.  I’ve found over time that the perfect size to engage with people in One on Ones is somewhere to be between 5 – 10, it’s manageable, doable and not a scheduling nightmare on you or your team.  They can be a great signal to you in how you and/or your groups need to adapt to successfully keep moving forward.

As you  might have gathered, a One on One is not a Performance Review, those are different and should be treated very differently, the magic of the One on One is that it is not this, BUT it has the power to make those sessions a walk in the park when they do occur.

With that, I hope you take the time to have some One on Ones with your family this XMAS have a great holiday.