Software engineering is all about managing complexity. Every choice a programmer makes can affect the cost of everything thereafter. It’s vastly cheaper to write perfect software than software of unknown quality; the upfront cost of time and resources is greater, but teams save several times that amount by getting the code right from the beginning. 

At the core of everything are your teams, and the people on them. They do the actual work that succeeds or fails, so continuous improvement for teams and continuous learning for people are the best investments you can make.

What Kills Your Team

No product market fit: If you don't have product market fit, it doesn't matter how efficient or effective your software organization is. What you produce is only as valuable as your market makes it.

Poor quality: It’s much less expensive to write code of substantially perfect quality than it is to write code of unknown quality. Errors in the code cause not just bad customer experiences, but rework for the team, which increases labor costs and takes the team away from further progress in building the system. Waterfall projects without automated tests are taught to expect to take five times as much time testing and debugging as it took to write the code. A team that spends as much time writing automated tests as it does writing its code takes two times, rather than six times, that amount of time, and can move three times faster. And an absence of trustable automated tests makes it expensive and risky to make changes to simplify the code, which makes the team move even slower.

Cost of change: Adding to a code base naturally increases its complexity, unless intentional steps are taken to reduce complexity. Higher complexity makes it more and more time consuming, and therefore expensive, to make subsequent changes to the code. Pressure from stakeholders or management to move on quickly to the next task drives teams to skip the refactoring steps needed to keep the cost of change low. The effects of this aren’t always detected when they happen, and the ultimate effect is to make system changes unaffordable, and to rob teams of the bandwidth they need to correct the trouble they’ve gotten into. For a small software company, runaway cost of change, or the discipline to control it, can mean life or death.

Bad team dynamics: A jelled team is worth more than the sum of its parts; a dysfunctional one has difficulty functioning at all. Hiring for people who will be good teammates, giving teams time to get through the forming-storming-norming-performing curve, and keeping well-functioning teams together for the long term leads to better-performing organizations.

Bottlenecks: Some organizations define development processes involving handoffs from one role to another as code moves toward production but fail to adequately staff one or more roles. QA is a frequent victim here, which also exacerbates quality problems. Other organizations organize their teams in such a way that multiple teams depend on the output of certain teams, which may not be able to deliver all the things the downstream teams need in a timely fashion. The whole organization is only as fast as the slowest bottleneck along the value chain.

Toil: There is no standard work in software. If any is found, it must be swiftly automated out of existence. Repetitive manual work is error-prone and expensive, and manual processes don’t scale as your system does. Deployments, system patches, and other manual work can quickly eat up time that a team can’t afford to spare. 

Friction: When it takes a long time to edit, build, test, and deploy software, progress is slow. Slow automated tests, written using end-to-end testing tools, manual testing, long deployment processes, code review processes inserted in the middle of the edit-to-deploy cycle, and so forth all add to a team’s cycle time. Faster tests, continuous delivery, exploratory testing, continuous review through pair programming, and other such optimizations can turn a release cycle of weeks into one that can happen multiple times per hour per pair of developers. Conversely, lacking these things raises the stakes of each deployment and makes progress slow.

How to Hire the Right People 

Code doesn’t write itself, so for any organization, the biggest asset is and should be your people, especially the technical people on your engineering teams. You need smart people with a track record of getting things done, who aren’t difficult to work with and who are comfortable with ambiguity. Finding those people, and supporting them with the right know-how and structure, adds up to an organization that’s going to be effective. You need people who are lifelong learners, but you also need to support them with opportunities for growth and development. This goes for current employees as well as external applicants.

There are two types of people when it comes to applying for jobs. There are those who will look at a job description, see they have 60-70% of the requirements and assume they aren’t qualified; and there are those who see they only have 60-70% of the requirements but see it as a chance to learn. The former won’t apply to your open positions; the latter will apply, and your hiring team needs to recognize their potential and not dismiss them out of hand.

Focus on the Team

In the battle to overcome complexity, organizations must be aware of the factors that hamper or even destroy their ability to efficiently develop software. Building a better, more efficient software organization includes an examination of the seven biggest hindrances that can thwart this goal. Ultimately, your team will determine your success. Investing in their ongoing training and support will go a long way toward accomplishing the goal. Hiring people from within and without who possess the potential to succeed rather than excluding those who don’t check all the boxes is also an important strategy in creating and maintaining an efficient engineering organization.

Susan Davis is CTO of Certn.