Harry Bailey is a technology and delivery leader who specialises in turning agency project chaos into clarity. With more than twenty years of experience as a developer, agency founder and fractional CTO, he helps digital and creative agencies build stronger engineering and delivery cultures and improve commercial outcomes. He focuses on practical, immediately actionable strategies, not theory, so teams can ship work on time and with less drama.
How many complex things can a human do at the same time?
It’s not a trick question. The answer likely came to you immediately. Correct, it’s one.
Doing more than one complex thing at the same time leads to terrible outcomes. Take driving and using a mobile phone as the extreme example.
In product teams — who often focus on a single goal for many weeks at a time — there are strict limits on work in progress. A person can be assigned to only one thing. Teams work on one thing per team member, minus one thing to ensure redundancy.
In agencies these rules are often less clearly defined, and sometimes don’t exist. People are commonly multi-assigned. They could be spending time across two or more projects, while also covering support agreement work.
It’s not uncommon for me to see people assigned to ten or more tickets. Yes 1-0, ten.
If you’re so busy doing the work that you’re struggling to find time to lead the others in your agency, you might be looking for ways to prioritise better.
When you’ve got lots on your plate, how do you choose the right things to do first?
Here are three approaches to considering when prioritising.
How often is there a mismatch between your agency sales and delivery process?
How often do we deliver something fundamentally different from what we thought was agreed with a client?
It’s rare for the sales process to include much time from the delivery team. It inflates the cost of sales, and unsuccessful pitches feel significantly more risky. So is it worth it?
Is it worth it?
For me, absolutely. Agency sales teams aren’t always able to consider the risk that’s baked into the projects they sell without experienced members of delivery. There has to be a better approach that isn’t many times more expensive.
I see this reduction of project risk, and the multiplying effect on team and client engagement as an investment in the future. An acknowledgment that project failure and client churn is significantly more expensive than bringing forward discussions about project delivery. Even if some projects never happen.
What would early delivery involvement look like?
Start with the ‘why’. Why now, why this, what will success look like and how will we measure it?
Stand-ups are used by most creative and digital agencies. Teams have daily meetings where they align around their progress, challenges and discuss what’s coming next.
At least 15 minutes a day is spent on those calls. The whole team attends. Listening is the primary activity for attendees. It shouldn’t be controversial to state that the time should be used wisely.
But what does wisely mean? Well for me it means that it’s a good use of time for all who attend. From the most experienced to the least experienced team member. No matter what the role. Everyone should walk away believing they benefited from the call.
The focus of these stand-ups however is all too often a turn taking exercise where an individual’s status is shared. They read out information that is stored in accessible digital tools that the team can access.
What if stand-ups were about planning instead of reporting?
Updated 6th October 2025 to reference new token requirement for loading instance meta data
So let me first confirm what won’t work. Whether Apache 1, Apache 2, leader_only or EB_IS_COMMAND_LEADER testing, you cannot consistenty get exactly one (not zero, or 2+) instances to run a cron job over a long period of time.
The issue is the the leader information isn’t safe. It’s only available during deployments, when you usually first set up the cron job. But when an instance replacement happens—for whatever reason—there is no related deployment, the test to check if the new instance is the leader fails, and you end up with no crons.
So for anything you do at the moment of deployment—database migrations, logging, whatever— that you only want to run once, even on multi-instance environments in an Elastic Beanstalk Application, you can use and trust the leader tests available to you.
But for anything you want to run regularly, on a schedule across weeks and months, you cannot trust those options.
After a lot of research, and trial and error there are two options available to you.
Worker environments
The ‘official’ way is probably via a worker environment. Essentially an instance set up specifically to schedule and run short or long lived processes.
You can learn more about them via the links below, but for the rest of this article we’ll be talking about the alternative option of ‘runtime leader testing’.
This option means running the cron on every instance of an environment, but the initial section of the code being run checks the if the instance id that it’s running on is the first to be returned in the list of all instances. That is, only the first instance id returned by the aws elastic beanstalk api will continue to run the task.
Below the examples are in PHP, but it’s a valid method for other languages too.
We’re assuming you’ve already set up a cron and know how to alter it to make it run on all instances of your environment.
The steps in this guide:
Create an IAM user just for this process and give it limited read permissions
Add the credentials to EB configuration
Write code to check the instance id from the api against the current instance id
Adding the user
Open IAM in AWS console
Click Users
Click Add users
Type your User name – we used “[applicationCode]-eb-read-user”
Click the ‘Access Key’ access type
Click Next: Permissions
Click the ‘Attach existing policies directly’ tab
Type ‘AWSElasticBeanstalkReadOnly’ and select it
NB: This permission actually gives more access than is required and you could trim it further
Click Next: Tags
Click Next: Review
Click Create user
Take a copy of the KEY and SECRET
Storing the key and secret in the environment
Open your environment
Click configuration
Click ‘edit’ on the ‘Software’ section
Add two new items, one for the key (examples use AWS_KEY) and one for the secret (examples use AWS_SECRET)
The code
So this is php, but the basic idea is:
Install the aws library – here we use composer
Add some code to call the library
Compare the first returned instance id against the id of the instance running the code
Then compare the API’s first result to the current one. If the same, so something, otherwise don’t.
if ($currentId == $result['EnvironmentResources']['Instances'][0]['Id'])
{
// do something. Only one instance will get here
}
else
{
// don't do anything. All other instances will be here
}