Parallelism and Software Teams

I'm guessing I'm a pretty typical development team manager in that I would love to hire a dozen new people to my team tomorrow if I could, but the objective pragmatist in me recognises that there are some inescapable realities about running a business that clearly make that idea absurd. The obvious main reason is cost. Hiring new staff is expensive and it requires a time investment. No CEO is simply going to approve a new hire without understanding the cost and looking at how that factors into the company budget.

Parallel Teams

With Covid-19 redefining every market and economy the world over, this scrutiny is, quite rightly, even greater. So when my company expressed willingness to approve a new hire, my enthusiasm was quickly tempered by the suggestion that the board would likely need to understand the return on that investment.

On the face of it, asking to see the ROI for a particular project or undertaking is of course a very reasonable question to ask. You don't want to just throw money at a problem and hope it works without understanding what the likely outcome is expected to be. But in a SaaS product company, what is that ROI based on and how do you demonstrate a projected change in productivity or speed of delivery?

Before we get into exploring actual measures or metrics, let's all agree that software is complicated. Also, so are people. People writing software is very complicated. Software involves a lot of "it depends". "How long will this feature take to finish?": it depends. "Can we get the software to do this thing?": it depends. "How much would doing this cost?": it really depends. So when someone says "If you hire two new people, how much faster will we see this really important feature?", the answer is of course "it depends".

In reality, this is probably the wrong question to ask in the first place. If you're stretched for time, capacity, your features are backing up and your market is crying out for online services because Covid has just hockey-sticked your business, throwing more people at the problem isn't a solution you can just toss in and go about your day. New people means a fundamentally new team. It means examining your structures, dynamics, processes and strategy and being prepared to completely reshape them in order to work leaner and smarter.

People don't work at uniform rates - especially in knowledge work like IT. People's skill sets and areas of expertise are varied and sometimes individual contributors can be tapped out on one project while another one that needs their input has to wait. Junior and entry-level developers will work in different ways and at different rates than more senior, familiar contributors.

"How much faster will we get things if I hire more people" is the wrong question

Here's the problem I encountered in my department. We were stretched: tired after pouring our energy into responding to Covid and stressed from trying to deliver the things on our product plan on top of responding to numerous new customer support requests. The team of 10 had been run ragged and weren't able to invest time into other things like their Learning & Development or interest projects.

The challenge was partly capacity: people had too much stuff to do and not enough time to concentrate on properly completing one task before moving to another. Work In Progress was getting out of control. The other problem was roles and responsibilities. Everyone had a thing they were responsible for, but those things were somewhat randomly distributed and there were other tasks and initiatives that were not being picked up: there were no clear expectations around whose responsibility those initiatives should be.

These problems weren't going to be solved simply by adding more people. I needed to think through ways in which to implement a structure and workflow that would mean work could be taken on and assigned in a meaningful, understood and effective way.

← Home