Burnout, Self-Care and Resilience

Share
Reading time ~3 minutes

First, a thankyou to Ceedee in New Zealand for prompting me to write again. It’s been far too long and I love doing it.

Close-up picture of a daisy

A very personal post today. (The next few posts after this will be back to agile, leadership, and management – probably more the latter two given what I’m up to these days!)

For those of you that have followed me on Twitter in the past, you may have have noticed that for a while last year I wasn’t my usual self. During mental health awareness week I ended up hiding away on my own in a hotel just outside Montreal on business so things hit a bit of a peak.

The good news is that for the last few months I’ve been feeling like my “best self” again and it feels sustainable.

So here’s some of my story – a cautionary tale with some lessons and important reminders.

About a decade ago I had a heart attack. I was 33 years old and had already had an incredibly stressful life – both professionally and at home. On top of that, I was taking no exercise and had a terrible diet. I’d been ignoring chest pains thinking it was an ulcer for a few years and when the pain moved into my left arm as a dull ache I started to worry but thought “I’m far too young, it must just be an ulcer.”

It reached a peak one lunchtime and within an hour I was on the operating table having a blood clot removed.

The good news (for me) is that I survived and recovered but it was a serious warning that life is far too short and precious to let it pass you by. I was also warned that the mental side effects from a life event like this are not to be ignored.

I’ve since learned to make decisions that are right for me, resolve past regrets where possible, recognise how lucky I am, and that I (and nobody else) am responsible for my situation, my wellbeing, and my impact on those around me.

I’ve also learned when to step back and recharge. Resilience is not about fortitude, it’s about your ability to recover and to make sure you have the time and space to do so.

For those friends that know me well, you already know I’m very open with my feelings (ok I’m a bit of an over-sharer) but I normally put a brave face on things for business and out in public. Only those closest to me see the bigger picture.

I wanted to take some time to encourage all of you to step back and be aware of and supportive of the mental health of your colleagues and friends.

In general people are starting to be much more open in sharing their feelings and issues than they were when I started my career. I believe this is a really healthy shift in working culture but bear in mind that even so, everyone is battling something – every day.

These battles aren’t new and many people fight on and show no outward signs of their struggles. Social media has exacerbated this to some extent. Many people only share the highlights – the best bits – of their lives.

Don’t compare your happiness, success, or well-being to what you see in others. It won’t help you.

I would remind all of you – as peers, friends, leaders, and managers to spend time every now and again to ask those around you (and yourselves) the simple question “Are you ok?” – give enough time for an answer to develop and be available to support or guide those that aren’t.

Before you worry, yes, I’m doing well. I have close friends and colleagues around me. I’ve learned when I need to take time out for myself, I’ve rebuilt long lost friendships, and I’ve (re)discovered that in order to be happy in my professional life I need strong social connections in an environment that doesn’t tolerate poor behaviour or hidden agendas (regardless of role)

That’s my needs (and lessons) for the day – what are yours?

9 Success Factors for Working with Remote Teams

Share
Reading time ~6 minutes

Some management archaeology from me this morning…

A photo of a sundial overlooking the sea and a coastal area

When I started managing teams and projects for the first time I used to write down my most significant insights and lessons I’d learned in a little Black & Red A5 notebook.

A couple of months ago I pulled it off of the shelf and thumbed through my old notes. They’re almost all still as relevant today as they were over a decade ago.

Hiding among the notes on capacity planning, estimation, reporting, change management, innovation, reward systems, performance management, situational leadership and even a list of personal “observed best practices” was a single half-page of bullet points that simply read:

“How to ensure offshore teams are successful”

Since not long after I started writing publicly I’ve not needed to use those insights.

I have the rare luxury of working with completely co-located teams (even “the business” sits with the team here). However I know many of you wonderful readers still face challenges with offshore or near-shore collaboration & quality. As Dan noted in the comments below, these apply to any globally diverse team, not just “offshore”.

So that these insights aren’t lost to time, I thought I’d share and expand them here.I’m bound to have missed many others and this is my personal view from being UK-based and working with teams all around the world so I have 2 requests for you as readers…

  • What tips and suggestions would you add to this list?
  • If you’re based in an “offshore” type team, please, please, please share your insights from the “other side” – we don’t hear enough here.

1 – Management & Team Mindset

First – stop thinking “offshore”. You’re a global team. Once you start treating your remote staff/suppliers/contractors as being “on your team” relationships start to build.

Pair team members and managers across locations. You’re working on the same goals, behave like it.

Manage all your team in the same way. Arrange 1-1s, feedback sessions, informal catch-ups, full team training. Have off-sites or outings for every site and share the pictures. Better still, do it together.

Your team includes your customers and suppliers too – involve them in your challenges and be rewarded.

2 – Shared Accountability

We often outsource to reduce effort, overhead, cost and risk. As soon as these become significant motivations, you’re already behaving in a flawed way. You’ll find your offshoring or oursourcing isn’t actively owned or managed.

You own the working relationship. It’s up to you to make it work. Find a counterpart on the other side to pair up with and make it successful.

A remote team will never be successful if your only reason for using them is cost. Figure out the unique strengths, talents and value they bring to you. Invest in partners and locations where you have better access to specialist domain knowledge, broader experience or better delivery capabilities.

A great example of this lies in the domain of one of my former employers – power systems. Power systems engineers are rare people at the best of times. In the US in particular, much of the power systems & networks domain knowledge is being lost through retirement. China on the other hand has a huge number of extraordinarily smart engineers in this space.

3 – Quality of Team

Perhaps it’s purely a capacity thing – staff availability in your home location may be a problem.

It’s a lot harder to hire a dozen amazing developers in Cambridge than it is in San Francisco or Mumbai. But given the size of the talent pool in those locations, it’s also a lot easier to hire mediocre or bad team members. Your bar should be set high wherever you are.

Expect the same from your partners or suppliers. If your supplier is competing on cost alone and not capability you’ll eventually fail – period.

4 – Selection Of Work

Don’t just farm out the dull stuff, the maintenance, support, and bug fixing. This is something very few people enjoy taking personal ownership of or pride in. I’ll admit there are exceptions (I love clearing down a massive bug backlog) but most technical people need a balance. All brown-field work wears people down eventually.

5 – Political Structures & Power Dynamics

Career paths and job titles are important.  The “senior” in someone’s title may even be seen as acceptance to push others around or exclude team members from important conversations.

Halt “pecking order” problems early.

Be inclusive, publicly encourage collaboration, and transparent communication from senior managers and give direct private feedback when you smell a problem.

6 – Management Style

Some countries and companies have a more top-down formal style than others. It may be unacceptable to “question your superiors” despite the fact that nobody can be right 100% of the time.

Learn about how things run. Who’s respected, who’s feared, who helps things happen and who gets in the way.

Encourage questioning. Explain that everyone is making rapid decisions all the time. If someone doesn’t understand, is worried or unsure about a decision, make it safe to call out, ask or correct. This capability may take months to build but it’s worth the slog.

As a tech lead in one company I worked at I used to run a game called “Captain, you’re wrong”. We made calling out errors fun and engaging rather than difficult and negative.

Recognise that career paths, job titles and management styles differ from country to country.

7 – Respect cultural and language differences

I had mentee that would say “I have a doubt” when they had a question or needed support. That’s quite an interesting translation. “Doubt” in English reflects personal uncertainty. Be supportive, take time to explain things clearly and most of all encourage questions and discussion.

Work ethic may varies from place to place and person to person but sometimes you just don’t see what’s going on.

I had a team member in Hyderabad who consistently outperformed everyone else globally. She was truly amazing at everything but more than that she worked relentlessly.

I’d come into work in the morning at 8 and she’d have been in the office for 4 hours. I’d leave at 6 or 7 in the evening and she’d still be working. The irony was that even when working sensible hours she was still smarter, more productive and delivered higher quality output than a lot of our team. The excess hours weren’t healthy.

Having spotted the excess working I’d check daily around 4/5 pm and if she was still Online I’d call her up and just and encourage her to go home and enjoy her evening. (Her home life was great too so I’m pretty sure she wasn’t avoiding going home).

8 – Spend Time Together

Seek ways to bring your whole team together for a day, a week, a month or even longer. If this really isn’t possible, how can you do the same for individuals and managers instead?

Spending time together helps you understand the working environment, the personal subtleties and nuances and communication styles. After you’ve spent quality time face to face with someone, those offline interactions become much easier to understand.

It works both ways. Spend some time (at least a couple of weeks) in the remote environment yourself. Go see what working life’s like over there. I promise you’ll learn something every day you’re out there.

9 – Re-learn how to communicate

A lot of communication on a co-located team happens by osmosis.

If some of your team are remote they won’t get that benefit. Invest in tools like slack and github that support asynchronous collaboration but don’t just use them for “work” – dial up the chatter and small talk so that everyone can feel part of a human team.

 

Shy? Try Exercising Your Asking Muscles

Share
Reading time ~4 minutes

Some Friday morning amateur social philosophy.

One of my current team is as shy as I am. We both agree that “we’d rather not deal with people”. It’s somewhat funny that even from the first day of my degree I had to work in teams and interact with external stakeholders. My ability to do so is my strength (but my dirty secret is that it’s also my biggest fear).

I’ve read and re-read loads of stuff on being an introvert, on being shy and assorted other musings for the “socially challenged”. I’m not socially awkward – I might be a bit of an over-sharer but once I’m up and running I can be the life and soul of the corner of the kitchen at a party, I enjoy sharing, I enjoy interacting with people but I’m like a dynamo – I need some winding up to reach that state.

I think my favorite term comes from Doc List who describes himself as an “Ambivert”. I think his observations closely define me as well.

Most people that I interact with in public or at work would never believe I’m shy. It’s one of the joys of the agile/conference scene – you know most people are just like you. They wear a mantle of bravery and a mask of confidence but after a week of conferences will happily spend the weekend recovering under the covers. Over the years those people become friends and the interactions become easier.

I gain short-term energy from talking to people but I’m exhausted afterwards. I find nothing more draining than leading planning sessions, demos and retrospectives but most people will never see it. In some camps that counts as introverted, in others extroverted – Let’s stick with ambivert.

Anyway. A challenge with being shy/introverted or even an ambivert is asking. Asking for help, information or even asking someone to do something you know is their responsibility or even pleasure to do for you.

As a project manager or leader this is a bit of a crazy situation. Every day I need to ask my team or external stakeholders for an assortment of things. The emotional effort needed to ask can vary from easy to terrifying and descends into experiences that are often addressed with Cognitive Behavior Therapy.

  • You believe it’s unreasonable to ask busy people for more of their time to meet needs you think are yours.
  • You feel (or have been told) you should ask someone for help or input.
  • You’re trying to make a difference, you know other people care but you don’t know how to approach the subject.
  • The list of doubts, “Shoulds” and “aughts” goes on.

From my experiences I’ve discovered the ability to ask is like any other mental muscle. If you use it regularly it gets better. If you don’t use it it wastes away. 

Unfortunately that shy moment freezes you up. It means you’re more inclined to not ask until it’s critical so you end up making life harder for yourself and the person you need to ask. All the while you’re procrastinating you’re expending mental cycles on stress and doing nothing.

But there’s more to it than that.

Each person you need to ask something of is a different muscle.

When I first started working as a PM in our DevOps group a few years ago I was new to the company, I had few existing working relationships and a number of key stakeholders I needed to learn to interact with.

How did I build up my asking muscles?

I reviewed my working relationships in the past to understand what I found easy and what was more difficult.  I found – even with my own team – that after about 3 useful interactions in a short period of time things became significantly easier so I decided to try an experiment.

There’s a neat idea in software development known as the “rule of three” – once you’ve needed to use the same thing 3 times then it’s probably time to make it generic and standardize it.

I bought a small (A3) sized whiteboard and placed it on my desk. On the board I drew a grid. Each horizontal lane represented a person I needed to learn to interact with. I wrote each name in the left-hand column. Each column after that was a placeholder where I’d mark an X every time I had an asking or collaborative interaction with that person. My goal was to get 3 X’s in each row over the space of about a month.

It worked – when there were only one or two X’s I’d figure out how I could build another interaction with that person that didn’t have to involve asking for anything significant.

One of those people came over to my desk and spotted my board – they asked what the “X’s” next to their name were. I explained and they immediately empathized. I wasn’t alone. That conversation counted as yet another X – It became easier to ask!

The tricky thing is once you’ve built those muscles up you need to kep them running.

If you neglect your asking skills for any time you need to rebuild them again (sometimes the second time is easier). If like me your projects and roles change a lot over the years you’ll probably find that by the time you’ve just got comfortable with everyone you need to ask that the world changes around you and you need to start again.

This is a good thing – it keeps us exercising our asking muscles.

Who do you want to ask something of today?

Go talk to them.

Have a great weekend

Simon

Seeing the Value in Task Estimates

Share
Reading time ~5 minutes

a list of task estimate sizes with beta curves overlaidYou might be aware of the ongoing discussions around the #noEstimates movement right now. I have the luxury here of rarely needing to use estimates as commitments to management but I usually (not always) still ask my teams to estimate their tasks.

My consistently positive experiences so far mean I’m unlikely to stop any time soon.

3 weeks ago I joined a new team. I decided I wanted to get back into the commercial side of the business for a while so I’ve joined our Sales Operations team. (Think DevOps but for sales admin, systems, reporting, targeting & metrics).

Fortunately for me the current manager of the team who took the role on a month or so earlier is amazing. She has so much sales domain knowledge, an instinct for what’s going on and deeply understands what’s needed by our customers (the sales teams).

I’d been working with her informally for a while getting her up to speed on agile project management so by the time I joined the team already had a basic whiteboard in place, were having effective daily standups and were tracking tasks.

The big problem with an ops team is balancing strategic and tactical work. Right now the work is all tactical, urgent items come in daily at the cost of important but less urgent work.

We’re also facing capacity issues with the team and much of the work is all flowing to a single domain expert who’s due to go on leave for a few months this Summer – again a common problem in ops teams.

I observed the movement of tasks on the team board for a week to understand how things were running, spot what was flowing well and what was blocked. As I observed I noted challenges being faced and possible improvements to make. By the end of the week I started implementing a series of near-daily changes – My approach was very similar to that taken in “a year of whiteboard evolution“.

Since the start of April we’ve made 17 “tweaks” to the way the team works and have a backlog of nearly 30 more.

Last week we started adding estimates to tasks.

I trained the team on task estimation – it took less than 10 minutes to explain after one of our standups. The technical details on how I teach this are in my post on story points. But there’s more than just the technical aspect. (In fact the technicalities are secondary to be honest)

Here’s the human side of task estimation…

  • Tasks are estimated in what I describe as “day fragments” – essentially an effort hours equivalent of story points. These are periods of time “small enough to fit in your head”.
  • The distribution scale for task estimates I recommend is always the same. 0.5, 1, 2, 4, 8, 16, 24 hours. (the last 3 are 1, 2 and 3 days) – It’s rare to see a task with a “24” on it. This offers the same kind of declining precision we see with Fibonacci-based story point estimates.
  • For the level of accuracy & precision we’re after I recommend spending less than 30 seconds to provide an estimate for any task. (Usually more like 5-10)
  • If you can’t provide an estimate then you’re missing a task somewhere on understanding what’s needed.
  • Any task of size 8 or more is probably more than one task.
  • Simply having an estimate on a task makes it easier to start work on – especially if the estimate is small (this is one of the tactics in the Cracking Big Rocks card deck)
  • By having an estimate, you have a better idea of when you’ll be done based on other commitments and activities, this means you can manage expectations better.
  • The estimates don’t need to be accurate but the more often you estimate, the better you get at it.
  • When a task is “done”, we re-check the estimate but we only change the number if the result is wildly off. E.g. if a 1 day task takes just an hour or vice versa. And we only do this to learn, understand and improve, not to worry or blame.

So why is this worth doing?

Within a day we were already seeing improvements to our flow of work and after a week we had results to show for it.

  • The majority of tasks fell into the 0.5 or 1 hour buckets – a sign of lots of reactive small items.
  • Tasks with estimates of 8 hours or more (1 day’s effort) were consistently “stuck”.
  • We spotted many small tasks jumping the queue ahead of larger more important items despite not being urgent. (Because they were easier to deliver and well-understood)
  • Vague tasks that had been hanging around for weeks were pulled off of the board and replaced with a series more concrete smaller actions. (I didn’t even have to do any prompting)
  • Tasks that still couldn’t be estimated spawned 0.5 or 1 hour tasks to figure out what needed to be done.
  • Large blocked items started moving again.
  • Team members were more confident in what could be achieved and when.
  • We can start capacity planning and gathering data for defining service level agreements and planning more strategic work.

I’m not saying you have to estimate tasks but I strongly believe in the benefits they provide internally to a team.

If you’re not doing so already, try a little simple education with your teams and then run an experiment for a while. You can always stop if it’s not working for you.

 

 

A quick update – Janne Sinivirta pointed out that “none of the benefits seem to be from estimates, rather about task breakdown and understanding the tasks.”

He’s got a good point. This is a key thing for me about task estimation. It highlights quickly what you do & don’t understand. The value is at least partially in estimating, not estimates. (Much like the act of planning vs following a plan). Although by adding the estimates to tasks on the wall we could quickly see patterns in flow of tasks that were less clear before and act sooner.

As we move from tactical to strategic work I expect we’ll still need those numbers to help inform how much of our time we need to spend on reactive work. (In most teams I’ve worked in it’s historically about 20% but it’s looking like much more than that here so far).

Martin Burns also highlighted that understanding and breaking down tasks is where much of the work lies. The equivalent of that in this team is in recognising what needs investigation and discussion with users and what doesn’t and adding tasks for those items.

1,000% improvement is a statistical outlier

Share
Reading time ~3 minutes

This cautionary tale came up a few times at Agile 2010 (yes I know this may be old news!) – including one of the keynote speeches.

“For a million dollars we’ll make you Agile.

Here’s a list of previous clients whom we helped achieve a 1,000% performance improvement. Lead times halved, profits doubled and everyone was AWESOME!.

Here’s some REAL DATA …”

A graph going "up and to the right"

Axis titles shamelessly acquired from a recent company presentation

What you’ve not been told is that those testimonies are statistical outliers!

These are the top 1-5% of companies that have successfully undergone a major transformation. (or the bar was set very low to start with) There are thousands of companies out there that don’t reach these lofty heights.

The journey is longer and harder than the marketing will ever tell you but that’s fine as long as you know what you’re investing in and why.

Your organization is unique. There are many factors about your organization that will make significant improvements hard to achieve and most of them will not be technical. The forces of resistance will be many and will be a mix of institutionalized and personal.

Let’s replay this with a more realistic conversation…

A consultant visits your site, and does a “free” one-day Agile Assessment of your teams.

“OK Boss. Right now you suck at developing software. Give us a million dollars, a year of your time and a willingness to drop productivity for a while and we can make you suck a bit less.”

Furthermore, they won’t actually be able to tell you just how much less you can suck and by when.

Why not?

Back to all those forces of resistance – how many of those can you really prod, assess and quantify in a day or even a week?

Every company, organization and site differs.

The investment may still be worthwhile but it’s time to manage expectations better. Those assessments should highlight where unexpected limitations lie. Maybe they could offer alternative higher priority areas to tackle (rather than up-selling scope).

If product development and software engineering was like cutting coke cans, there really would be a “one true right way” of producing software products.

Moreover. There wouldn’t be a thousand consultancies promising you the moon on a stick, there wouldn’t be conferences on improving the state of the art and there wouldn’t be hundreds of books full of great ideas on how to do/be agile or perform software engineering a little bit better.

In fact chances are there wouldn’t be a competitive software industry.

Or would there?

• Maybe there really is a one true way and the entire software, consulting, authoring and conference industry is in on the joke.

• Maybe all those leading lights on their skiing trip a decade ago came up with one of the world’s greatest “Long Cons”

• Oh and they invited 3M to the party and agreed to promote stickies in the 21st century in exchange for a marketing budget.

Probably not…

There are no “best practices”. Stop looking for them, stop asking consultants and Scrum Masters to implement them.

There are only “best known practices for your current state, knowledge and context”.

When your state, knowledge and context change, it’s time to look at what’s next and more importantly – what’s beyond your current focus – what have you missed or not considered yet?

What did you discard previously because there were constraints or issues preventing them working? (I learned a great term for this from Chris Matts &/or Dan North – I can’t remember which – “Idea Wombling” – seeking out great ideas that were previously discarded)

You may reach a point where your organizational immune system (politics and process) blocks progress.

Sometimes you’ll need outside help to see what’s “better” or learn new ways of working. That outside help can often be more effective at delivering hard truths than you can yourself. It’s worth investing in “straight-talk” from strangers sometimes.

Figure out what is holding larger improvements back (and where) and determine who you could pair with either externally or in a different part of the organization to make a real difference!