Paul Grenyer

 The One Minute Manager Meets the Monkey by Ken Blanchard, Hal Burrows ISBN-13: 978-0007116980 When I made the move to lead engineer from senior engineer my instinct was still to try and fix everything for my engineers rather than get them to complete their own tasks, or as Ken Blanchard puts it, Monkeys. It was useful and interesting to read about someone in a very similar situation, how it affected them and their family and how they eventually overcame it with four simple rules: Rule 1: Describe the Monkey: The dialog must not end until appropriate “next moves” have been identified and specified. Rule 2: Assign the Monkey: All Monkeys shall be owned and handled by the lowest organisational level consistent with their welfare. Rule 3: Insure the Monkey: Every Monkey leaving your presence on the back of one of your people must be covered by one of two insurances: Recommend, then act Act, then advise. Rule 4: Check on the Monkey: Proper follow up means healthier Monkeys. Every Monke...

What: So you think you can lead a team? When: 2.45pm, Thursday 3rd April 2025 Where: Delta Hotels Bristol City Centre, 2 Lower Castle St, Bristol BS1 3AD More Info:   https://accuconference.org/  Get tickets: https://accuconference.org/booking Software engineering is hard. Leading a team, as an engineer, can be even harder. Many of us are better at developing software than we are with people and feel our value lies in actually writing code. When you step into team leading, there are more people than code and your value increases. Over the last 25 years I’ve been unexpectedly dropped into team leading a number of times, but three and a half years ago I chose to do it. It took at least twelve months for me to realise I was only starting to understand what leading a software team is and what it means. Join me for some of the highs and lows of team leading and an insight into some of the things I learnt to help me be a better team lead. I can’t promise a panacea as I...

In February 2025 I gave a 15 minute version of my "So you think you can lead a team?" talk to my colleagues on park in Devon. You can watch it here: So you think you can lead a Team? Software engineering is hard. Leading a team, as an engineer, can be even harder. Many of us are better at developing software than we are with people and feel our value lies in actually writing code. When you step into team leading, there are more people than code and your value increases. Over the last 25 years I’ve been unexpectedly dropped into team leading a number of times, but three and a half years ago I chose to do it. It took at least twelve months for me to realise I was only starting to understand what leading a software team is and what it means. Join me for some of the highs and lows of team leading and an insight into some of the things I learnt to help me be a better team lead. I can’t promise a panacea as I  still have much to learn, but I hope to help you avoid some of the mista...

Today I attended my first DataDog Summit. It was interesting, but at times, it felt like a bit of a slog. Registration began at 9am, and by 10am, we were in the main auditorium for two and a half hours straight - eight back-to-back 15 minute sessions with no breaks. The sessions were a mixture of introductions, customer experience and DataDog features. Of course the DataDog feature talks were just a little bit salesy and DataDog give the impression they think they’re the answer to everything, but it wasn’t too bad. The customer experience talks were really interesting, especially those from NatWest, WTW (big in insurance apparently) and the London Stock Exchange. It was good to see other organisations solving similar problems to my current employer and that we’re ahead of most. The new (to me) DataDog features were also interesting. I didn’t know that data into DataDog wasn’t just a one way flow. DataDog can also be configured to adjust your infrastructure to save cost or mitigate une...

In the first half of 2025 I presented a number of times on team leading. During the talk I reference a number of books which have helped me become a better team leader: The One Minute Manager Kenneth Blanchard ISBN-13: ‎978-0008128043 The One Minute Manager Meets the Monkey Ken Blanchard, Hal Burrows ISBN-13: 978-0007116980 How to Win Friends and Influence People Dale Carnegie ISBN-13: 978-8183631297 What did you say? The Art of Giving and Receiving Feedback Charles N. Seashore, Edith Whitfield Seashore, Gerald M. Weinberg ISBN-13: 978-0965043007   Nonviolent Communication Marshall B. Rosenberg ISBN: 978-1-892005-28-1   Extreme Programming Explained: Embrace Change Kent Beck ISBN-13: 978-0321278654   How to Make Friends and Influence People Terrorvision    The Work Rivers of Nihil

Async functions are a powerful feature in JavaScript and TypeScript, offering a cleaner, more readable alternative to working directly with Promises. However, it’s easy to overuse them or add unnecessary layers of complexity.  By understanding when and how to use async and await effectively, you can write more concise, efficient, and maintainable code. Let’s explore a common scenario where async and await may be overapplied, and how simplifying the function structure can improve code readability and maintainability without sacrificing intent. Take a look at this function which wraps an async function which deletes an entity form a database: const deleteEntity = async (id: number) => {     return await db.entity.delete({ id }); } You would also await deleteEntity when calling it, resulting in two promises, unnecessarily verbose code and less efficient execution.. Instead of awaiting the promise created in deleteEntity , it can just be returned: const deleteEntity ...