I’m Harry Bailey and I help foster tech teams and the humans who help form and fuel them. My work creates better outcomes, more value, happier humans and solid autonomous teams.
My experience as a product owner, business owner, tech strategist and software developer enables me take a team-focused approach. I look to support value creation at every level from pair coding through to business strategy.
I was involved in a discussion on Twitter recently about the pitfalls of having a name which isn’t unique. Another person with your name who was, or is, more famous than you are.
To add insult to injury, in our cases there were people who’ve shared our names in the past who have been less than perfect human beings.
In my case for example, another Harry Bailey was a doctor in Australia and was using some pretty awful treatments on people. His wikipedia page is the top result for Harry Bailey, and has been since I can remember.
The second Harry Bailey that used to outrank me is a character in a well known black and white Christmas film. He’s the brother of the main character and is referenced across various websites.
Thankfully, my writing and link building for Harry Bailey replaced the later on the first page of several search engines with my own content.
There was a manager I worked with recently who was having serious trouble with their onboarding process.
Working with several teams of between 5 and 8 developers, the business was growing fast and recruiting at all levels. Some of the recruited developers were straight out of a code academy, with minimal experience of working in a team, on a regular release schedule, or with production code.
These less experienced developers were their primary challenge. The one they thought could release most value. But how do you get a developer enough experience to graduate them to being part of a team? How many of these developers can you put into a 5 to 8 person team and the team support their learning and progression so they might become independent? How do you introduce them to the team? What does the average day look like for one of these developers while they learn the ropes?
We’ve all worked with developers who prefers to get on with their coding alone. They’ll assign themselves a large set of tasks, tell everybody they’ve got loads to be getting on with, put their headphones in and you won’t hear from them for several days.
They might pin their name to a key change or issue, make all the required decisions alone and get it ready for deployment in record time. They may even be able to resolve complex issues with infrastructure or libraries, but not have the time to share those processes.
You likely know these type of developers by the names Ninjas, Wizards, Rock Stars, or 10x. These are terms of endearment used in praise of the activities above, or even in job advertisements looking to recruit developers with these habits.
What these behaviours actually do to your development team could not be further from a positive outcome.
Don’t get me wrong, the short term progress can be impressive. So impressive in fact that managers, and often less experienced team members won’t be able to help but praise our False Hero. Speed is always seen as a good thing in a word of complexity and deadlines. Solo progress without the need for peer input is often seen as something to aspire to.
Although I spend a fair amount of time at client offices across the UK with individuals and teams, I’ve now been primarily working from home in South Manchester for twelve months. I have a work space which doubles as a spare bedroom. I have all the requirements of an office space; desk, power, wifi, tea making fascillities, but there is something missing when you work from home the majority of the week, human contact.
Working from home can be lonely. Yes, you’re answering emails to other people and you have phone or video calls to make. You might even see the postman more often. But what you don’t have, and many of us need, is face-to-face human contact.
Just being in the same space as others, even if you’re focused on completely different tasks is enough to support mental health and general wellbeing.
There are reasons that tight deadlines and huge pressure often get results.
The first is that people get immediately more pragmatic about what the actual requirements are, and agree to do less. Less can be done more quickly, and completed items are less likely to be subjected to a full loop of subjective tinkering.
The second is that when faced with a deadline, and some pressure to achieve it, people focus on just the single most important task.
The single most important thing to do right now is abundantly clear in these high pressure situations.