You can either be right, or you can be happy

On how being self aware is a bitch, why wanting to be right all the time is bad, and what that has to do with anything

The cruel irony about trying to become more self aware is that it makes you more aware of the dick moves that you’ve been making in your life until this point.

I recently started reading “The 15 Commitments of Conscious Leadership”. In it, it describes 15 principles which leaders should consciously commit to, prioritising responsibility and curiosity – the ability to be curious, rather than to be right. As I listened to the audiobook, something started feeling pretty uncomfortable. I started to dictate notes to my phone while I was driving, something I don’t often do unless what I’m listening to is really good

Paraphrased transcript of resulting conversation to sibling:

Me: “I’ve just realised, I think I often have an overwhelming urge to be right a lot. Do you get that?”
Sibling: “BWAHAHAHAHAHAHAHAHA”
Me: “Hmm. That’s not good. Why didn’t anyone ever tell me?”
Sibling: “I think we get it from mum tbh.”*
* That line was tongue-in-cheek – my Dad was biblically stubborn, and got pretty upset when other people couldn’t see his viewpoint.

Well shit. Another one to add to my development list. It’s already got “accountability”, “discipline” and “courage” on it. I liked it better in the good old days when I was in ignorant bliss about my emotional intelligence, and had no appetite for self-improvement. Well, not really, but it was definitely easier.

Common sense aside, it’s not as if it’s the first time I’ve read about this – Adam Grant’s “Think Again” is a great example with an entire chapter dedicated to “the joy of being wrong”. The book is about how not to define yourself by your beliefs and perceptions, and to seek out alternative viewpoints. But for some reason (maybe the slight tinge of spirituality in the authors’ explanation resonated with my faith), it only took two chapters into 15 commitments to trigger another back-to-the-drawing-board moment.

My wife of course has pointed this out on many occasions, having known me for 12 years, and of course I told her she was wrong. I know that she’ll read this and help me be accountable for making change. I’m way better at managing this at work than I am at home, but one thing I’m sure of in life is that you need to be your authentic self everywhere. It’s a lot easier making a change at work if you’re in a position of privilege or authority (I definitely do not have this at home).

I should probably link this to my industry at some point. Well, possible examples where people (who may or may not be me) have reacted the wrong way when they’ve been “right”:

  • When the sales / product team sell something without talking to the engineers about how long it will take
  • When developers’ unit tests weren’t “proper” unit tests and they needed to be written again
  • When leaders’ legitimate errors were pointed out to them at face value, sometimes in front of others (the moral high ground is a very lonely one)
  • When a solution has been architected the “right” way, but the business won’t sign off on it because it’s going to take too long

And the rest. Let me know if you can think of any common ones in the tech industry!

What can we do about it?

Wanting to be right is human nature. There is nothing inherently wrong with it. The damage comes when we are defensive, threatening, or even lie to twist the argument to make it sound as though we are right. We mix so much of our identity with our beliefs and ego that we physically feel threatened if they are challenged. Greater minds than me have talked about how we can work to avoid this and the books above are a good start. I’m not a fan of recommending “self-help” books but The Four Habits That F*ck You Up is rather good and rather funny, with some guidance about replacing your “Dogmatic Demands” with “Flexible Preferences”.

We mix so much of our identity with our beliefs and ego that we physically feel threatened if they are challenged

Me? I have an app called Habitica that’s a really fun way of gamifying your habits, and you gain or lose points depending on whether you’ve performed a good or bad habit respectively (for instance, I lose 4 points now if my need to be right causes me to flip a table). Also, I reflect every week using a personal survey relating to the things I think are important right now, commenting on things like how I’ve helped people, how much discipline I’ve had, and now how I reacted in situations where my beliefs were challenged.

And of course, it’s now open season for my family to keep me accountable for being “curious”. 

“You can either be happy or you can be right” is a deliberately provocative title. It is an adage often used as a humorous observation of dynamics in a relationship, but even then I don’t think it’s either-or. There is as Grant says joy to be found in being wrong. There is a time and place to stick to your guns – when fighting political / social / racial injustice, being a good Ally, and so on. But in the interests of creating and sustaining relationships, particularly in leadership, we need to embrace the spectrum in between right and wrong, and respect that the University of Life is always trying to teach you something new.

Photo banner courtesy of https://pixabay.com/users/ryanmcguire-123690/

Lessons from trying to be Agile in a Waterfall industry

Nine months ago my journey led me back into R&D in the life sciences industry, working with (amongst other things) software in a medical setting. The healthcare industry is clearly heavily regulated. Moving from releasing web products several times a week to software that’s released a few times a year (if you’re lucky) has been an eye opener. 

Tasked to bring in a new process, it would have been easy to slip into the wrong mindset – long spells of developer work, followed by copious manual documentation and a throw over the fence to a testing team for a few months. A few post-deadline back-and-forths between testers and developers thrown in at the end for good measure, obviously. I’ve seen it happen with installed software in far less regulated industries, and frankly, there’s rarely an excuse for it. Seven months later, we gained our ISO 13485 certification using the agile process we created. 

If you work where you don’t need to worry about your software telling someone they’re ill or not, and the thought of deploying anything less than daily horrifies you, this post might not be for you. It is interesting however that many of the fundamental principles and practices still (or should) apply even in a regulated industry. How did we steer clear of the waterfall trap? Here are the lessons we learned:

1. Get the right quality team

It would be easy for a quality team to force a process upon a new software team because that’s the way that they validate everything else – usually by using a hideously inefficient and burdensome quality software. Whilst that definitely exists, we were lucky enough to have a quality manager working with us that saw the need for agility, and how the systems that we implemented (in this case Azure DevOps) were a better match for compliance in an agile software development process. Having a quality team with this flexible mentality is crucial, and may require a lot of dialog upfront before anything new is implemented.

2. Get help from subject matter experts

Just to make sure we were on the right track, we consulted an external embedded software house that had experience implementing agile processes in the medical industry. There’s no way I was going to wave the Agile card if what we were proposing wouldn’t actually meet regulatory requirements. Luckily, there is a highly respected set of guidelines that offers some fantastic direction on the use of Agile practices in the medical industry (though the fact they felt the need to capitalise AGILE still drives me crazy).

3. Use DevOps practices

Turns out that if you follow the same good DevOps practices that high performing teams do, you’re most of the way to being compliant anyway. I was confronted with the unfortunate reality that most of our instrumentation products shared the same code repository, and relied on a gatekeeper to manually build the code in the correct configuration to produce the right product. The first task was to create a “master” build in Gradle that would take parameters based on which flavour software we wanted to build. Then, a separate build pipeline was built for each software flavour that built their respective installers and artefacts. We could then connect this to release pipelines for each flavour and have a record of all work items, pull requests and artefacts linked to a particular release was given to the validation team (and yes, there are rare occasions where a separate testing team makes sense – like when developers can’t use a pipette and people’s lives depend on it).

If you want to learn more about how good DevOps practices lead to high software delivery optimisation, read Accelerate or the latest State of DevOps report at the time of writing.

Start measuring your shippable work items so you at least know you’re moving the needle on deployment frequency. While a 10 day average isn’t ideal from start to ‘done’, it’s better than 60, and it’s getting more consistent.

4. If you don’t store your documentation in your QMS, you’re not going to burn.

Living, accessible documentation is essential for software teams to be agile. It’s no good gathering cobwebs in a quality system that takes an age to find anything (or worse, no one has access to). If you want to change your branching strategy slightly, you don’t want to be spending weeks getting a change approved by a QA who knows nothing about branching strategies.

Here is a blog by the consultancy I mentioned previously on the topic of living documentation for software teams in regulated industries. The idea is that your wikis / repos / markdown files are absolutely fine, as long as they’re kept up to date and go through a robust, audited pull request procedure and you’re able to produce them in an auditor-friendly format. This can all be automated, and in my experience, most modern software lifecycle systems are more secure and auditable than many quality systems on the market anyway.

5. Definition of Release

In healthcare, you’re not going to be releasing a product to a customer multiple times a day. At least not one that’s locally installed in a public sector environment. You generally have little control over the appetite for change of the various governing bodies and indeed individual sites. So then how can we conceivably aim to be an elite performing team according to the widely accepted DORA metrics? You aim to use all the previous steps to create validated, tested, shippable increments anyway. I mean everything – review lifecycle, packaging, deployment to an immutable release pipeline and signed off – preferably with automated documentation and release notes. If there’s a regulatory blocker, or the customer is simply reluctant to update their procedures with a new software module (even if it has features in it they’ve requested and want!), you’re still safe in the knowledge that those releases have gone through a complete release process in isolation and are ready to go. For us, that’s “production”. Just don’t let it end up like this:

https://www.comicagile.net/comic/done/

In summary

In the time that we’ve had I’m pretty proud of my small team taking a 12 year old codebase that had no automation to speak of into a cloud-first, DevOps driven compliant process. Not only that, but we’ve learned a ton going through this process that will help us build our next generation of digital products. 

We’ve still got a long way to go. If anyone has any other insights in remaining agile in a medical setting, or you can see some hideous oversights in these lessons, please do let me know. Just don’t be mean.

It’s a cliché, but don’t accept the status quo or your environment as an excuse to abandon an agile mindset. Get the right people around you, make noise, and move the needle – one day at a time.

Why we should think before labelling someone as a millennial

My degree was in astrophysics. When I mentioned that I studied astronomy to people, the response, “can you read my horoscope?” was more common than I’d have liked. Why did that bother me? It wasn’t that people didn’t know what astrophysics was, or even that they were probably just trying to wind me up (success). It’s the idea that a huge swathe of the population can have the same characteristics based on when they were born. This perception is particularly bad news for Virgos in China applying for a job, for instance. So, when a seasoned manager described me as a “millennial” based on my wanting to understand the feelings of people, I set out to figure out why that evoked a similar response and why something so seemingly harmless could be a problem.

In the discussion, I was describing the Insights Discovery colour wheel (other personality profiling tools are available), explaining that I tend to align with the supporting-coordinator role. I explained that while this doesn’t define me, it indicates that I have strengths such as empathy, and taking a coach-first approach. I’m concerned with how people feel, myself included. The response was, “Oh, you’re definitely a millennial then”. They might as well have said, “Ah, got it. You’re a Taurus.” (I am, by the way).

There’s absolutely nothing inherently wrong with what the person did here. There was no call-out needed, no discriminatory slur, and to be crystal clear, I am not comparing this to any experience of marginalised or persecuted groups (based on race or gender for instance) who are still unfortunately attributed to dangerous labels on a daily basis. So why then in this “harmless” case can labelling still be damaging?

The story that I told myself I heard was, “Oh, you value people and care about how they feel? That’s a weird thing for a manager to do. It must be because you’re a millennial”. Far-fetched, I know (we’re all human, and we all fill in the blanks with stories). Even so, there were two implications here that didn’t sit well with me: One, that my generation could be branded so easily as all having the same characteristics (and controversial opinions abound as to why this could be). Two, that my values and purpose – the things that I’ve worked so hard for years to define and curate – have been given to me and my fellow snowflakes by the inevitable product of bad parenting, as Simon Sinek calls it a “bad hand”, and a series of unfortunate economic balls-ups.

millennial – noun – “a person reaching young adulthood in the early 21st century”

Google Dictionary

First of all, the definition of “millennial” from Google Dictionary (and many others concur) is “a person reaching young adulthood in the early 21st century”. So yep, objectively I am one. No argument there. If we’re looking at things the timeline can affect, I was raised by baby-boomers, in a time where I probably got a participation award at some point, thought I was entitled as a teenager (ever met one who didn’t?), and led a privileged, economically stable upbringing. I did go through the economic crash of 2008, losing tens of thousands in the housing market, and I did have crippling student debt. Whilst there’s evidence to suggest things are objectively harder for us as a generation, I question how any of this could have an effect on the values and characteristics of effectively an entire generation and why that would lead to a labelled generalisation.

At the end of my reflection, I think the issue was the implication that because I was an empathetic, coach-style, feel-first type personality, it must be because I was a millennial. I think it was the reduction of my self-awareness journey over the last few years to a label shared with an entire generation that made me contemplate how powerful labels can be. Lord knows I wasn’t always empathetic. I had some shameful experiences with junior developers early in my career. It’s taken some painful life events, some deep self-reflection, and learning how to support these values with resilience (not to mention a qualification in coaching) that I’ve defined and developed these values.

Here’s the reason why I try not to use labels. When you attribute a person’s individuality to an arbitrary group of people – when you reduce their life experiences to a label – you are dehumanising them. People’s lives are not just shades of grey, they’re rainbow coloured, an infinite spectrum filled with nuances and life experiences that shape them as humans. Don’t get me wrong, I like being labelled as a ‘coach’ – but I’d probably take issue if someone said “you’re a good coach, you must be a Taurus”.

When you attribute a person’s individuality to an arbitrary group of people – when you reduce their life experiences to a label – you are dehumanising them

When we’re about to label someone based on their characteristics, even if it’s just a subconscious bias in our head, it’s in our power to stop and think – is this label really a part of their identity that they’re proud of? Or are you taking away from their individualism as a beautiful, worthy and fallible human being?

Of course, my response in this case was not a 900 word essay. It was, “yeah, I don’t really like labels.” But then, that was a very millennial thing to say.

Being an engineering manager and a coach

TLDR: Listen to people and have good intentions. Read time ~ 6 mins

For anyone who’s spent five minutes trying to understand me, they know that my purpose is to grow myself to grow others. My path in the last few years seems to have been driven by a deep need to understand how to be a better coach, so I’ve captured some of my thoughts from that journey from both successes and failures. I’m not expecting any of this to be ground-breaking, but hopefully it does encourage a few managers particularly in the digital sector to have better coaching conversations with your team (If you want to find out the fundamentals about being a coach as an engineering manager from a better writer than me, check this out).

I’ve written this post from the perspective of an engineering manager, but most of these observations could easily relate to any manager who wants to be more of a coach.

Start with understanding your coachee’s values and purpose

I’m assuming here that you’ve already built up some basic rapport with your team member, the next step is truly understanding their values and purpose. I’ve already written about this in a previous post with a good practical exercise to do this. If you haven’t figured out your own values, do this exercise yourself first. Understanding others’ values and intrinsic motivations leads to empathy, a key skill in coaching. Empathy leads to objectivity, trust, and a quicker path to goal resolution.

I notice that engineers in my experience are reluctant to spend a lot of time digging into themselves like this. This may be because of more common analytical and logical thought processes that go on in engineers. During a team building exercise, I once heard an engineer interrogate the facilitator’s fundamental understanding of neuroscience, missing the irony that the psychometric test proposed that overanalysis was a team weakness.

Whatever the reason, persist with good intentions. Performance, behaviour and beliefs usually stem from these values and builds a solid base for the following points.

Coaching only works if people want to be coached

That’s not an excuse to avoid coaching conversations. If you’ve done the work to discover what people value, most of them can be coached – even if it’s to save their job. But hire for a growth mindset and coachability and it will be so much easier. I’m not a fan of hiring top tech talent if they’re not able to handle feedback.

With those team members that don’t want to be coached, your job then is to actively listen, with compassion, empathy, and consistency, to find out why that is. Do they feel like they’ve peaked and don’t need help? Are they sceptical of the process? Is there not enough trust there in the relationship? 

Dr Ron Westrum categorises organisational cultures into pathological, bureaucratic and generative, made popular in the digital industry by the book Accelerate and the work by DORA which discusses how important this is to create high trust, fast-flow environments. Thankfully I’ve not worked in a pathological culture, but what I can tell you having worked in bureaucratic ones is that engineers seem to be reluctant to accept their manager as a coach. This could be because their managers have climbed through the tech tree and found no other way to progress other than management (you don’t need me to tell you why this doesn’t always end well), or simply that the culture puts more emphasis on managers to favour product over people. Either way, the best way to break down that barrier is a consistent attitude to a coaching approach, trust, and time.

Westrum’s typology of organisational culture, “Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations”, Nicole Forsgren, Jezz Humble

It’s worth mentioning that as a manager, you can’t solve everything with a coaching approach. Knowing when to make something a coaching conversation, and when not to, can be a tricky business.

Know when something is not a coaching conversation

It is a fine balance being both a coach and a manager. A good coaching relationship is based on a sense of equality, and as autonomous as I like to feel my teams are, being a manager means there’s a power dynamic there that makes equality tricky (this article has an interesting take on managing those power dynamics). You may find a scenario where you are helping someone on an improvement plan, which by design does not facilitate impartiality. Coaching techniques should still be used (active listening, empathy, evaluating options with pros and cons, accountability), but be very aware that sometimes the agenda is necessarily yours, not theirs.

There are times when it’s just not a good idea to try a coaching approach. 

  1. When you have the definitive answer, and they don’t. See, “How do I put a support ticket in to IT?”, “Where do we keep the project repositories?”. Trying a coaching approach here gets annoying very quickly.
  2. When they don’t have context, and you do. When I’m coaching someone outside of the work environment, a coachee definitely has more context about their problem than me. But employees will often not be able to come up with good solutions if they don’t have the same business context as you do as a manager. See, “What am I supposed to work on if I don’t know the roadmap?”, “What technology should I learn next?”.

Other than these, try to look everywhere for the opportunity to make interactions with your team a coaching conversation, and provide early and candid feedback as often as possible (see Kim Scott’s excellent book Radical Candor).

Ensure actions and accountability

This goes for any coaching programme, but it’s so easy to slip out of the habit as a manager. Any good coaching conversation, particularly in a structured format (such as a 121 or an appraisal) must result in actions for the employee, accountable to the employee, and preferably set wholly by the employee.

A trigger for me is when someone says “Yeah, I should actually do X about that.” Especially if there’s a strong degree of trust, it’s all too easy for both parties to be satisfied that this is the end of it, both genuinely believing that this will happen at some point in the future when the dust settles and the next big feature’s over the line. Well, there are always more features, and expecting the dust to settle is like expecting a magic supercoding ninja to swoop in and clear all your technical debt for you. 

Try creating a new habit. When you hear the “I should”, instead of assuming it will happen, create accountability by asking questions like “Will you?”, “When will you?”, “Is that all you need to do?”, “How would you feel if you completed that sooner rather than later?”.

Coaching the individual by coaching the team

If coaching an individual isn’t getting the desired outcomes, coaching the team as a whole can encourage a positive attitude in the individual and reach the same outcomes. Human beings are social animals, and desire acceptance and validation from the troop (“The Chimp Paradox” is a really fun book that explores tribe mentality and is essential reading for coaches). If you coach the behaviours in others, eliminating the validation of negative behaviours from the rest of the team, you instantly create an environment where the undesired behaviour is not accepted within this troop and thus seek other forms of acceptance. Or, of course, they find another troop.

Summary

The key in trying the coaching approach as a manager is persistence. Sure – adapt, learn, try new things, ask different questions – but the gold comes only after a long period of truly trying to understand others and genuinely wanting them to be their best self. The proudest stories I have in my career are seeing people excel as a result of the actions they have set themselves from coaching conversations. Sometimes the eureka moment with a coachee just happens, when you least expect it, way down the line when something just clicks. It’s a culmination of the small things, the small iterations of listening, questions and actions, that deliver people to greatness.

Resources:

6 lessons I’ve learned from working with Agile Ninjas

TLDR; Eliminate waste.
Read Time ~ 5 minutes

Boy has it been an odd year. A year of volatility, uncertainty, complexity and ambiguity (VUCA), and having an agile mindset has never been more important.  Despite the sombre backdrop of 2020, good leaders have definitely learned, grown and adapted to the challenge during this time. Thankfully, one of the things that got me through this year was working with a team of awesome engineers, ScrumMasters, coaches and managers trying their best to adapt to change and lead in uncertain times. In the last 9 months, I’ve had the privilege of working with some of the most experienced agile coaches I’ve ever met. A pang of guilt rushes through me as I write this blog, as the contents are primarily a reflection of observations made possible by these awesome people. 

Whilst I’ve been on my own personal journey of growth and discovery, I thought I’d share with you some of my takeaways from those colleagues with an agile mindset so that others can take away something good, however small, from this otherwise sucky year.

1. The value of a good Product Owner

In the past I’ve worked in places where there was no clear product function, and found myself subsequently explaining to each new company-volunteered product ‘champion’ what their role should be, and why they should be passionate about it. So, it came as a nice surprise once I started working for companies who had product owners, where their job title was actually ‘Product Owner’. They not only showed up on time, but actually owned the product backlog and were held accountable for ensuring that the right thing was being delivered. Companies trying Scrum “because it’s Agile” often fail at the first hurdle because there is simply no representation of the customer in the work that engineers do. The benefit of having that PO role embedded on value aligned teams potentially saves months of wasted effort.

2. The team retrospective is the most important ceremony

The only ceremony that’s actually mentioned in the agile manifesto, at regular intervals teams should reflect on how to become more effective. I’m not going to cover well trodden ground about why they’re important (here is a great dedicated article to it) but it’s amazing how many teams either don’t do it or don’t find it useful. The reasons seem to be either:

  1. “We don’t have time with all the other meetings”. Answer – skip the other meetings. How can you possibly expect things to get better if you’re not taking dedicated time to figure out how?
  2. “They’re pointless”. Answer – give them a point. Make sure that actions are actionable, within the team’s control, written up and executed. Keep track of these. Don’t write an action that only “the company” can solve – this is the time to be accountable for your own team’s improvement.

A great way to encourage people to just T-off with retros is making something the team look forward to. Make it fun, and encourage discussion. Some ideas I’ve seen over the years:

  • Ask everyone to bring a gif / movie / weather icon / picture / emoticon that they would use to describe the last sprint
  • Pictionary – draw the last sprint and let the others guess what you’ve drawn and why!
  • Have a theme for the retro – themes I’ve seen include Mario Brothers, The Beatles (with accompanying music), Avengers, video games etc.
“How would you describe this sprint in a GIF?”

3. Real actual deadlines exist

“If you’re really agile, you’ll get rid of deadlines”. I’ve heard this so many times. Try telling that to the people who write software based on government legislative deadlines. Or those that write education software based on a hard back-to-school date. Or ask those that write payroll software to ignore the constant stream of changes to job support schemes and tax changes this year. Product roadmaps in these cases are very useful things, and should even include other non-deadline features based on changing markets, customer demand and engineering improvements. This is not the same as the people that promise the customer a feature that hasn’t been built yet by next week, without talking to the developers. There is still a special place in Hell for those people.

4. It’s about the mindset, not the process

The ScrumLords are not going to cast you to eternal damnation for not having a backlog refinement session

I was (and still am) a massive fan of Scrum, having championed it as the way of delivering agile software. The cracks started appearing when I tried introducing it to mechanical engineering and chemistry teams – they just couldn’t practically work to a regular cadence. After learning a little more about Kanban this year, that really could have worked. 
The ScrumLords are not going to cast you to eternal damnation for not having a backlog refinement session. But you should be confident that you’ve tried it as a team, reflected on it as a team, and come up with an even better prioritisation process as a team.

5. Communities of practice rule

I mentioned in a previous blog about the value of talking to other teams to better reflect on how your own team can improve, and communities of practice are a great way to do this. The DORA 2019 State of DevOps report states that 57% of elite performers use a “Communities of Practice” model as a transformation strategy – more popular than any other strategy, including proof-of-concepts, grassroots and centres of excellence. The Agile and DevOps principles crossover sufficiently enough that we can apply the same logic.

“The best strategies for scaling DevOps in organizations focus on structural solutions that build community”

“State of DevOps REPORT 2019” DORA / Google


Even if you can’t see tangible progress from your community, the sense of belonging, psychological safety and oneness it creates in a large organisation will pay dividends down the line. It gives members a sense of purpose which in turn creates a positive attachment to the organisation. An excellent article on how to get your agile community of practice off the ground can be found here, and having read it in retrospect, I’m pleased to see we weren’t far off the mark.

The golden rule – eliminate waste

All Lean principles revolve around eliminating waste, and it is hard work finding where the waste might be for your team. The process of estimating, for instance, can necessitate a useful conversation around acceptance criteria, encourage a definition of ‘done’ and eliminate waste for the team by ensuring they’re building the right thing. The controversial #NoEstimates movement however argues why estimating may be waste in itself, where time could be better spent writing software and concentrate on making all stories small enough to fit in the sprint. The retrospective itself can be wasteful if not used correctly. 

“Simplicity–the art of maximizing the amount of work not done–is essential”

Agile Manifesto (Agile Principles), 2001

The agile principles state that “Simplicity–the art of maximizing the amount of work not done–is essential”. I have learned that regardless of whether or not your agile teams are software teams, getting value quicker to the customer involves frequently asking this question of your process – “Is this eliminating waste?”.

In conclusion…

Gratitude is the key to resilience. It is an indicator of high emotional intelligence (written about in my previous blog) and is an essential part of withstanding a VUCA world. In the horror-show that was 2020, we must reflect on the lessons we’ve learned and find gratitude in our journey through it. I can say with confidence that I am grateful for those that have shared these lessons with me.

Feature image taken from the book “Agile Samurai” by Jonathan Rasmusson