Being outranked for your own name in search engines

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.

Continue reading

Onboarding through pair programming

pair programmers looking at screen together

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?

Continue reading

False Heroes in Software Delivery Teams

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.

Continue reading

Pressure and pragmatism lead to more progress

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.

Continue reading

Death by Commute

I’ve recently been working on-site with clients, and with that has come a fair amount of rush hour travel.

I generally try and balance my week with some time working remotely at home, some close to my home and some with clients. This balance hasn’t been an option in recent weeks and I’m starting to feel the effects.

I have a strong desire for regular focused periods and to carve out time for deep work, and when the day requires two hours or more just transferring between my home and my place of work for the day, it can be hard to find a means to make progress, or a rhythm to create any measurable value.

There are some techniques I’m going to put in place on days where I have an hour or more of travel in each direction to see if I can make those blocks of time at very least supportive of work I do at other times in the day. No more black holes.

I will usually consider using a car when it cuts a commute in half (or more) by doing so. This rule of thumb comes from the acknowledgment that driving a car limits any form of work beyond thought. Public transport however can allow work, where legs of the journey are long enough to support ‘going deep’ and seating is available which suits work.

To get the most from time behind a wheel, a plan needs to be made beforehand which defines a challenge, or problem, and enough information to help more towards a solution. Given, A, B and C, I need to consider and decide upon X. Here X could be the draft of a blog post, or a report. It could be a talk, or presentation. X could even be a technical solution, or a process solution to document more thoroughly once I’m at a computer.

To get the most from time commuting via public transport, tasks need to be considered which don’t require internet access. They may also need to consider that only part of the journey will allow for a comfortable position to write or use a laptop. It’s best not to expect more than note taking, or draft writing.

I’ve stopped aiming to work a specific number of hours each day. Where a client requires hours as proof of value creation, a conversation is required about why that’s a terrible measure of the impact a member of staff or consultant is having.

I will generally do between 6 and 8 hours depending on the progress I make, challenges I solve and energy I expend. If I have to commute a long way at each end of the day, that’s likely to compress the hours I do on-site, which often means I actually get ‘more’ high value work done thanks to deprioritising the low value shallow work.

For much of my work, and indeed much of most people’s work, they don’t need to be in a shared space with other people. Even paired and team tasks can be successfully completed remotely using screen-sharing, voice calls and a shared location for progress reporting and transparency.

If you currently require your team to work on-site 5 days a week, consider testing out a remote working day each week and see how the team get on with it, and what impact it has on value creation.

If all of us worked at home just one day each week, imagine how much quicker and less stressful commuting would be for the rest of us?