The Great Resignation & strategies to out perform the resource crunch

Globally referred to as “The Great Resignation” many industries are affected by a seismic shift in the availability of workers.

We’re certainly seeing this is the case in the IT Sector. The volume of available jobs is significantly out paced by the volume of available candidates. You may have already seen the obvious by products of this with rising salaries and employees seeking out improved conditions.

The less obvious, and less discussed is what can be done to counteract the lack of talent and less obvious again is to ensure we "still deliver". Most advice I’ve seen is largely generic. The simpler answers are the usual management adages of “do more with less”, or ask employees to do #overtime. But we all know in IT that the more overtime we do the worse quality becomes – so we can’t turn there.

I went looking for inspiration, and found some in the book and movie “Moneyball” – it’s based on the story of the 2002 season of the Oakland A’s baseball team. They’re trying to compete with teams which have 6x their budget. The GM is convinced they can’t compete head on with their rivals, in the war for talent. However, the GM discovers, through some uncommon thinking, a mathematical formula to bypass “traditional thinking”. Their strategy was to field a team of people who would win runs, regardless of how they managed to do that. This approach pays off and they win their season. In the most obvious of outcome’s all the other teams in the league emulate their success. Strategy based on statistics transforms the entire sport, and trickles across other sports as well.

This got me thinking – What is our moneyball moment in IT? We've already removed the commute with most people Working from Home. Surely there are other things could we do, beyond just trying to get bigger budgets to win the war on wages…

Productive Time is not Valued – we need “Productive Time” to do the work. Most developers I know say they need long stretches (3-4 hours) of time without the interruption of phone calls, emails, instant messages or meetings. Yet most calendars are crunched in teleconference calls about strategy, architecture, triaging bugs, product backlog refinement, recruitment, company meetings, daily standups, training new staff and more. What would it mean to value productive time?

Multiple Priorities Remain – people are not great at multi-tasking. When you have to support multiple streams of work, your efficiency drops. Most organisations struggle to help the individuals make prioritisation decisions, insisting that everything is important. Context switching is a killer for productivity. Can we be clearer on priorities?

Interesting Architecture isn't necessarily productive - I see organisations decide to use new and novel code libraries/technology or approaches, imitate the FAANGS (Facebook, Apple, Amazon, Netflix, Google) - because it's "interesting" to their developers. You can solve a problem with an event driven architecture because Netflix did it, but first hand experience tells me finding developers who are truly productive with that approach is difficult. You can adopt that latest hyped up UI framework, but experience tells me if you fast forward 6 months, you may be left with diagnosing framework issues yourself, complaining on github about the lack of updates, and be unable to hire developers who don’t want to work in an obscure technology, all while living with productivity issues. The more complex you make your technical environment, or the more obscure, the more experienced the developers will need to be to work on it, the longer the work will take, and the greater the cost. This is especially true if your “interesting architecture” ignores critical things like automated test coverage. Can you achieve the same result with a plainer architecture, less complexity, less experienced developers?

Minimising Time Wastage – thinking through the activities team performs there is often time wastage - information doesn't flow, people are forced to be idle or multi-task to be productive. Some organisations put up with builds taking 30 minutes or more. If a developer does 3 builds per day that’s 1.5hrs a day or 7.5hrs per week of time waiting on a build. If you read the State of Devops report annually you'll see a strong correlation with minimising build time with organisational profitability. It's not just build times, there are so many other factors like hot reloading of the UI, reducing the chance of issues being caused by disparate environment configuration through increasing the similarity between local/dev/test/prod (e.g. through docker & infrastructure as code) to avoid chasing config issues as code moves through environments. Even just having testers or subject matter experts verify the functionality is fit for purpose, as soon as it’s done, not after the sprint ends! Can you speed up the feedback cycle time to developers through faster builds or faster subject matter expert feedback?

Strong Product Ownership – A strong product owner will think through and list out all of the weird and wonderful scenarios you need to cover in building that new feature. They not only cover the typical use scenarios but all the squirrelly edge cases like first use, different user roles, core business logic (e.g the start date must be before the end date). If your Product Owner doesn’t proactively perceiving the problems, your developers will spend their time going back and forward to get clarifications. If your developers and product owners miss the mark, your users will raise bugs, and you'll be amending the features anyway. Can you reduce the number of cycles between Product Owners, Developers and Users to get the features just right?

Streamline Agile Ceremonies – I’ve observed organisations schedule ceremonies around the availability of their stakeholders. One example is running a showcase 24 hours after the sprint closed, just to get stakeholders available. If this holds up planning the next sprint till after showcase, it leaves 1 whole day of development team limbo! If you can run all of your key Agile ceremonies back to back there is some serious efficiency gain. For a Scrum team I usually prefer to run these sessions back to back covering showcase/sprint review, retrospective, estimates, sprint goal / sprint plan and task decomposition. If you get it right you can be all done and dusted in one morning and be starting a new sprint in the afternoon. What if your stakeholders cleared their calendars to keep the developers productive?

Useful Links:

Harvard Business Review Who is Driving the Great Resignation
https://hbr.org/2021/09/who-is-driving-the-great-resignation

Aaron McEwan (https://www.linkedin.com/in/aaronmcewan/) of Gartner discusses the Great Resignation https://www.abc.net.au/radionational/programs/this-working-life/the-pandemic-driven-great-resignation/13536416

Film Moneyball 2011 - different thinking to get outsized results with capped budgets https://en.wikipedia.org/wiki/Moneyball_(film)