When you’re struggling to find the bandwidth to handle your development project, it’s tempting to turn to one of three obvious solutions: trim the project, get more staff, or look for ways to make your current staff more productive.
In fact, these solutions all come with problems of their own. Before we get into the nuts and bolts of how to really address your bandwidth problems, let’s clear one thing up: what are we actually talking about here?
What’s ‘bandwidth’ anyway?
It’s easy to think you know what the problem is when you’re experiencing it. But it can really help to stop and ask what we mean by bandwidth. It’s not the same thing as ‘enough people for the work.’ In any task more complex than piling up boxes, adding team members also means adding communication requirements. This can have unexpected implications.
Way back in 1975, Fred Brooks, who had been a software engineer at IBM, wrote a book called The Mythical Man-Month. The thesis laid out in the book, known as Brooks’ Law, is as startling as it is counterintuitive: ‘adding manpower to a late software project makes it later.’ (Brooks’ 1975-appropriate language notwithstanding, this is also true of female software engineers.)
Brooks wasn’t theorizing so much as reporting. He’d been a lead developer at a huge, well-funded organization, working on big projects. At IBM, when more staff were (perceived to be) needed, they were hired, and the problem was solved — in theory. In practice it was exacerbated.
The reason is addressed in Brooks’ title. If one person can do X amount of work in a month, logic dictates that to get, say, 2X amount of work, you can add another month or another person. But you can’t.
Hire more people and the number of workers increases linearly. But the amount of work done decreases more slowly than this, and slower for each new hire. That's because the communication and training overheads involved increase geometrically.
Partly this is a consequence of adding new people to any communication network:
Adding anyone to either of these structures increases the communications required of everyone else in the network. For this reason among others, team sizes don’t linearly correlate with productivity even under ideal circumstances.
The most reliable correlation with high productivity is for teams between five and seven people; the highest productivity overall is for teams of around two people!
We’ve seen that communication loads accelerate faster than worker numbers, acting as a brake on productivity. Also a brake on productivity is the requirement to onboard and train new engineers, especially when everyone is already overworked — as when a project is late. Even when working with widely-used, industry-standard tools, the project itself will be new to newly-hired engineers. Hiring new engineers can move extant staff off work tasks, and onto the job of helping onboard and orient their new colleagues. Pretty soon, everyone on the project who knows how to do anything is working full-time schooling the noobs. Actual productive work grinds to a halt.
The point to all this is that you may not have the problem you think you have. Bandwidth isn’t how many hands you can get on deck. It’s your organization’s global ability to do the task in hand, which may not be directly correlated to the number of people available to do it. That’s one reason why hiring more staff is often the wrong answer. The other is, maybe you’re not working on one project at a time. Most businesses aren’t.
What’s your project?
The common assumption is that every developer is working to build new software, or at least new features. But this isn’t accurate at all.
In many industries that utilize complex tools or large, multitool stacks, developers are needed to make the stack work. This can be true of outbound sales-centric organizations that need to have their Salesforce implementation dialed in. Salesforce is immensely powerful and versatile, but taking full advantage of these benefits might require serious developer time.
However, the organization’s efficiency-optimized two-person developer team is probably working flat out to build the product, and might not have the bandwidth themselves to work on other things.
Some businesses have large, complex stacks that they rely on to deliver their products or services and for internal processes. This could be martech, logistics or dozens of other sectors. Setting up the tools that make up the stack, and the API ‘pipes’ that transmit data from one tool to another, is a highly-skilled job. It calls for engineering chops and domain-specific knowledge, but the core dev team are usually busy building and maintaining the product itself. They already have a job.
Where this is the case, it can be helpful to hire out integrations, APIs and tune-ups of complex apps and stacks.
Where products are being developed directly, a common bottleneck is the development of new types of features. For simplicity’s sake, imagine we’re talking about a web app that, so far, has gotten by with just a front-end developer (HTML, CSS, JavaScript) and a backend developer (MERN). But now, it needs a better UX flow because it’s become more complex. You need a UX designer — your existing team doesn’t have these skills.
You might also be adding features your MVP didn’t have, building APIs for common stack components that your users want your product to interface with, or building the full-productivity version of an MVP.
Speaking of which…
Slimming down the project
This involves significant conceptual work but this is the most productive type of work per hour spent. Your balloon is losing altitude and there’s no more gas. So something has to go overboard. What ballast are you carrying? What features can you postpone or mothball?
This is a common consideration when crafting an MVP (Minimum Viable Product), for instance. But it’s also common whenever a new feature is being built: how do you correctly allocate limited resources? You have to identify the difference between the things you’d like to have and the things you must have.
The Eisenhower square, named for former US president and general Ike Eisenhower, is a tool for managing time and/or effort:
You can compare that with the MoSCoW square:
If it’s a Must-have, developing it is Urgent/Important, so core dev staff should be on that now. If it’s Should-have, developing it is Important/Not urgent, so plan it with dev staff for a later date or a future sprint.
So you could throw overboard everything you can do without. And you can restructure your development plans to take the best possible advantage of the staff you already have. There are a couple of other options too.
Increasing staff productivity
Telling people to work harder, or bribing or forcing them to, isn’t all that effective. It’s not how you increase staff productivity. Hiring more staff, as we’ve seen, isn’t a great solution either — at least, not in the form of throwing more engineers at a project.
So how do you increase staff productivity?
Structuring development for maximal efficacy
Some forms of development are simply more effective than others. As in most areas of life that are basically about craft skills, the fastest, cheapest and most efficient way to develop is the right way, the first time around. That means leaving space for developers to work at a pace where they don’t make mistakes and have to go back and correct them, and trusting experts to be good at their jobs without micromanaging. But it also suggests that there are some best practices which, at first glance, appear to slow things up and add more work; in fact, they’re the price you pay today to get a bunch of cool stuff for free tomorrow.
I’m talking about:
Fix bugs before you add features
This is the same principle as paying off high-interest loans before you buy new investments. You’re cutting yourself free from the drag incurred by lost customers and increasing instability over time.
Develop monolithically wherever possible
If there are compelling reasons to build microservices, that’s different; if there aren’t, a single codebase is quicker, easier and cheaper to build.
Minimize libraries and stick with big/open source choices wherever possible
Open source doesn’t mean ‘built by amateurs,’ it means ‘tested by professionals.’ Big, stable libraries are far less likely to contain code that breaks your application and has to be hunted down, rewritten and redeployed in a massive rush.
Encourage maintainable code
Make it a priority to write code that’s human-readable, annotated, and clear so that other engineers can quickly orient themselves. Engineers should ask themselves, ‘if I’d never read this code before, how much would I understand?’ This involves things like code reviews and the creation of a code style and documentation guide. It all sounds like a lot of paperwork that isn’t writing code — until you actually do get someone new on the team, whereupon it pays off in faster onboarding and reduced time to productivity. In the meantime you ship more efficiently-written code. Win-win.
Pair programming
Once called ‘extreme programming,’ which makes it sound like snowboards are involved somehow, this means one person writes code and the other watches for errors and ambiguities. It’s one of the most effective ways to quickly write high-quality code, which is why it’s increasingly just known as ‘programming'. Team less-senior and more-senior staff to let the seniors mentor (a valuable skill to learn in its own right) and the less-senior learn new skills.
Get more staff
Finally, when all else fails and you really do have to hire for new skills, you can consider getting more staff on board. But full-time hires are a lengthy, troublesome solution. There are definite benefits but you may not benefit from them. For instance, eventually, they’ll be engineers who know who your product is for, how your company writes code, and what you’re working to achieve. But initially, they’ll cost you FTE pay and benefits, and slow your productivity down, almost certainly. That reduction in productivity will be team-wide and outlast their official onboarding period by months. It might be permanent — through no fault of theirs.
So when should you hire new FTE staff? In general, don’t duplicate roles or function areas: hiring a designer if you don’t have a designer may accelerate your project, but hiring a second designer probably won’t.
If you'd rather avoid these issues, consider outsourcing.
Outsourcing the whole project
In some cases, it’s a one-off job or one that’s separate from your team’s major development efforts. Then, it makes sense to find an agency that can simply step in and develop the solution for you. If they’re good, they’ll leave you with clear, well-annotated code and a solution where you used to have a problem. When it comes time to address the same issue again — next time all your APIs need updating, for instance — you’ll be ready.
Bringing in team role replacements
Outsource the role of a single team member, or multiple team members. Add an outsourced rather than FTE engineer, for instance, and you could hope to reduce the communication burden; they’ll be skilled at dropping into new environments and getting productive straightaway.
Outsourcing roles and functions
Subtly different from hiring team members as outsourced workers. Here, we’re talking about hiring to replace whole functions — say, an at-will design department, or a developer with specific skills that your current team doesn’t have. The purpose of hiring for functions is to allow your organization to do things it usually wouldn’t be able to, without having to integrate and onboard new departments or new specialists.
How can AndPlus help?
Outsourcing development is a large part of what we’re here for. If you already have a solid product development team, but you’re ready to take the next step and create a UX as impressive as your product, we can step in and be your on-call UX team. If your core dev team is busy building your product, we can fix your APIs, dial in your stack, adjust big, complex tools, and do the work to make sure your business runs smoothly — so they don’t have to.
That’s not to say we can’t help with product. We’ve built MVPs for businesses that didn’t yet have a dev team at all, and we’ve worked with companies’ existing development teams to add features, build back ends for apps, and create front ends and interfaces that let their users easily access their value.
Takeaways
- More hands make more work; hiring new engineers or reassigning them internally creates a bigger team which is usually less effective than a smaller one.
- The ‘bandwidth’ problem really needs to be understood in terms of global capacity to do certain types of work or tasks — not the same thing as undifferentiated carrying capacity, and not fixable by throwing more workers at it.
- Develop with future stability, maintainability and readability in mind and future-you and your team will thank you. Develop in haste and you’ll be catching bugs and fixing cranky code forever.
- Hiring full time staff is expensive and time consuming. For some situations, it’s absolutely worth it. For many, outsourcing is a wiser choice.
