Month: May 2021

Two “Magic Rules” for Achieving Great Things

~ Adam ~ Leave a comment

Ok, I lie – but it got your attention.

This week I want to talk about the two most important rules you can follow if you want to deliver great work and hit goals. Regardless of whether they’re software projects, books you want to write, or exams you want to pass. They are utterly underwhelming…

Rule 1: Start doing it

Rule 2: Keep doing it until you finish

There you go, I told you they were underwhelming!

However, I want to go a little deeper (otherwise this would be a very short post).

Failure to start is one of the biggest reasons people don’t do things. How many times have you planned to do something one evening only to get home and fail to do it? The reason (according to James Clear in his book Atomic Habits) is because it takes energy and effort to start doing things. Far too often our brains follow a pre-programmed pattern to avoid decision fatigue. Do you want to go running tonight or watch television? What do you need to do to start running? You’ll need to get changed, then you’ll need to find your trainers, then you’ll need to actually do the running… oh, and then there’s the shower. But the TV remote is just there.

In his book James describes ways to reduce the friction required to take on these individual habits and actions and make them easier to do day to day. I do this myself. I want to listen to audiobooks each day, so I leave my headphones by the side of my bed so they’re the first thing I pick up each morning. If you want to go for a run after work then put your kit on your bed before you leave in the morning – or even better put it on before you leave the office so it’ll actually be more effort not to go for a run than it will be to just get out the door!

Photo by mentatdgt on Pexels.com

Once you’ve got started that’s a huge step forward. But a single run doesn’t make you fit. A thousand words doesn’t make a book. So how do you keep that momentum going day after day to make progress until the work is done?

The first step is to understand what “Done” is. Is there a done? If it’s about fitness then you may be looking for a particular weight or time, but you may also be looking to maintain. If you’re building a product you may be looking for a number of active users. Just like in product management and software development we should always be clear about what we want to accomplish before we set off. We can evolve that view, but it helps to act as a beacon.

This leads directly into the motivation question. If we understand our objective we can track our progress towards it. Visibly seeing our progress towards a concrete goal is a very powerful motivational tool (as well as the other benefits of transparency and adaptibility). Burn up charts for your personal goals may seem like overkill, but they’re really not.

Here’s my burn up chart for my reading goal (you can see I actually made the goal far more ambitious because I was doing so well).

You can see I’m doing something similar with my cloud computing exams. This one isn’t going so well, and what am I going to do about it? Revalidate the goal, recalculate the effort and expectations, and then really myself. As with all things agile create transparency, inspect, and adapt.

I know this post started a little tongue in cheek but hopefully it helps and has provided some valuable tools to meet your own goals. Don’t forget, start… and then continue until you are done!

A Talk about Goals

~ Adam ~ Leave a comment

I was recently lucky enough to give a talk about Goals at the Hainton’s Community Group (currently online). Rather than doing a blog post this week I thought you’d enjoy this.

.A huge thank you to Tom and the team at Hainton as well as the participants for coming along and listening to me. It was really exciting to hear what people had planned and how they were getting on.

What goals are you planning? Drop me a message or comment below!

What I’ve Learned Since Writing Code Black

~ Adam ~ Leave a comment

Last year I finished wirint Code Black and published it on LeanPub. It wasn’t an easy challenge, although I enjoy wiriting I’ve never written a technical book before and had never really self published anything.

This week I wanted to share some of the lessons learned since writing the book which I took into my current project Donuts and Dragons.

Lesson 1 – You’re going to sell a lot fewer copies than you think you are! I had plans of the book becoming a runaway best seller, and to be honest I’ve genuinely been overwhelmed by the positive feedback I’ve recieved (even some suggestions I should enter it into competitions). However, I’m still working as a Dev Manager and have no plans of retiring and living off the royalties just yet.

Lesson 2 – Scheduling a “writing day” doesn’t work. Firstly, it’s too much to expect yourself to write for 8 hours straight. Second, if something cancels that day then you’ve lost a lot of potential words. The best way to write is to a schedule. When writing D&D I set myself a goal of about 500 words every week day. The book doesn’t appear overnight, it appears incrementally and inevitably.

Lesson 3 – Plan what you’re going to write. Maybe this comes down to personal style? Or maybe it’s because both of my books are trying to teach rather than just entertain but I would have got completely lost if I hadn’t had my trusty outline. Procrastination occurs most often when you don’t know what you’re going to write, having a plan – even a high level one makes it easier to hit that word goal.

Lesson 4 – Be proud of what you’ve done. When I first released Code Black I found myself belittling it. When someone said “Adam’s written a book” I’d say something like “Yeah, but it’s only a self publish.” or “Yeah, but it’s not sold many copies.” Don’t put yourself down, you wrote a book. That’s amazing, it’s something millions of people want to do but few ever actually succeed. Don’t you dare undermine what you’ve done.

Lesson 5 – You’ll want to write another one. Writing a book is a lot like doing a marathon. At the time you’ll swear blind that you never want to do it again. Then your mind starts ticking and you starting having those ideas and before you know it you’ll be developing characters and outlines again. Why not!? You’re an author now!

Oh, and something a lot of people ask me what has been my proudest moment since publishing it? That one easy – when Gene Kim bought a copy!

There’s a certain irony that the characters in my book read The Phoenix Project, I do hope he smiled at that.

Have you written a book? Tech or otherwise – please share it with me, I love to read what other people have done!

Radical Candor Book Review

~ Adam ~ 1 Comment

Radical Candor, by Kim Scott is a book I’ve been aware of for a while but haven’t actually got around to reading.

I was expecting lots of information about giving feedback but I was pleasantly surprised that there was a lot more in there than that.

Scott discusses that to be great leaders and team members we must both care personally and challenge directly. Without these two qualities we fall into one of three other quadrants.

Feedback & Radical Candor | Our Simple Approach To Guidance

People who care but don’t challenge fall into Ruinous Empathy. These are the people who won’t tell a friend that they’re unzipped because they’re afraid of the conversation. They’d rather let their friend continue to embaress themselves rather than push themselves out of their comfort zone.

People who don’t care personally are split into one of two categories. If they do challenge but don’t do it with someone elses best interests at heart then they display obnoxious agression. Or, simply put are just jerks. If they don’t challenge then they see what they could do to improve and don’t do anything to help them. This is manimulative insincerity.

Scott teaches us that we must always strive to give direct feedback to people we work with because we care about their success and their feelings. She also discusses lots of ways to do that.

I’d been expecting much of this content before I started the book but what delighted me was the actionable advice on how to go about this. I want you to read (or listen) to the book so I won’t give it all away here (plus, you know, plagurism). Suffice it to say that if you do now feel you should give feedback there are lots of tips in there to help.

But this is just for managers right?

Wrong!

Kim discusses that everyone should feel they can give feedback. Peer feedback is one of the most valuable thing we can give, it shows we care about our colleagues.

So, would I recommend it. Absolutely – go and have a read. Stop being ruinously empathetic today and start supporting your friends and colleagues directly!

Waltzing With Bears Book Review

~ Adam ~ Leave a comment

I recently read Waltzing With Bears by Tom DeMarco and Timothy Lister, these are the same guys who wrote Peopleware so I was curious to give it a read as I found Peopleware useful, if a little dry.

Buy Waltzing with Bears by Tom DeMarco With Free Delivery | wordery.com

Waltzing with Bears is all about managing software risk. Specifically the risk that something will not be delivered on time. The example the pair give early in the book is an airport which couldn’t open because the software to operate the baggage carousel wasn’t working. A late software delivery had huge financial impact.

In the book the authors talk about different ways to identify, represent, and manage risk. Like their other book Peopleware Waltzing with Bears is very comprehensive walk through of software risk covering a lot of the basics as well as some really interesting topics such as how to show delivery dates in a graph format to show the earliest possible, most likely, and worst case delivery dates. Thereby giving far more context than a best guess (which as we all know has a bad habit of being communicated to clients and becoming a deadline).

The authors made a very nice point about the bold being the ones who start projects early, not the ones who set ambitious deadlines and expect people to hit them.

However, I couldn’t help feeling like the authors were missing a big piece. The entire book (which I admit isn’t a long one) is based around delivery date risk. There’s no mention of many of the other risks which software teams face including usability, tech debt, and the ever present security risks. I would have liked to have seen more (well, any) pages dedicated to risks which aren’t about the due date. I felt like we were given a comprehensive introduction, but at the expnense of a breadth of knowledge of how to manage other risks.

Overall a good book which is well worth a read to anyone getting started in project planning and wants to understand how to manage the risk deliveries will run late. However, only a 4* read for me.

What do you think? Have you read Waltzing with Bears? Post your comments below!