Faster Engineering Teams
The most common management question I am asked is how to make software development organizations faster. Many company executives I have talked to are frustrated with their engineering teams and have a strong suspicion that they should be delivering more features and products more rapidly than they currently do. Often there is an assumption that the team needs to work “faster,” whatever that means, in order to accomplish more.
It’s unlikely that the actual problem is engineers physically working too slowly (unless they are incredibly slow typists?). A bit of digging into this concern consistently reveals that the real problem is unreliable delivery and delivery of the wrong functionality. Too often, software is released long after the original deadlines and without the functionality that was promised. This gets misdiagnosed as the teams working too slowly.
There are a vast number of ways that the root issues can be addressed at various levels within both engineering teams and wider organizations. In this post, I will describe common areas of concern, some of which have bigger impacts than others. If you are leading a software organization, you will want to consider the entire range of possible solutions so that you can see which ones will have the greatest impact in your situation.
Adding More Engineers
Adding additional folks, either by hiring permanent staff or engaging outside teams, is often seen as the first and easiest way to increase the rate at which software is shipped. Increased staffing can certainly add more capability, but does not guarantee faster delivery.
To effectively leverage additional staffing requires clear goals, strong communication, and more effort by management. You need to know what the additional folks are expected to accomplish (their goals), and how the work can effectively be shared among them. More people always means more communication, both spoken and written, to ensure that everyone stays in sync. All engineers, whether permanent staff or project-specific contractors, require clear guidance, support, timely feedback, and a high level of organization.
There is so much more that goes into successfully scaling up an organization, but these are the broad strokes.
Before adding more engineers to improve your software delivery, you should ensure that your current people, environment, and systems are working effectively. Don’t try to run before you can walk! Adding more people to an organization that has issues will magnify already-existing problems.
Leveling Up Your Current Engineering Team
The usual thinking is that if software is not being delivered as quickly as desired, the fault lies with the software teams. If you are an engineering leader this is definitely an area you should investigate to see what can be improved. But—spoiler alert—don’t stop here, assuming that every problem originates with the software engineering teams!
Assess your current engineering organization in order to determine what might be holding them back. Do you have the right people for the challenges you face? Do they need tools, technical training, or process guidance? Are there motivation issues? Pro tip: talk to your team and get their assessments. If they are struggling, they have likely thought about the challenges they face.
As mentioned in the previous section, there may be scaling and communication issues. These problems can arise at a fast-growing company where delivery used to be great, but increased product and team complexity (size) began to get in the way.
Is your software organization aligned with the company’s (or overall organization’s) goals? Engineers (and anyone, really) vastly prefer roles in which they can help drive the success of their company. They do their best work, going above and beyond, when it is clear how their efforts will help the company succeed. Conversely, it is extremely demoralizing if it is not clear how their work is important to the company. This happens far too often! Alignment is important—I’ll go into this more later in this post.
When prioritizing solutions for the challenges in your engineering organization, it is key to focus on reliable software delivery before targeting faster delivery, even if you are getting pressure to move fast. You can build speed off of a reliable base, but you cannot build reliability off of a fast but unstable base. Moreover, reliable delivery is by itself a great achievement. From a reliable base, you can make realistic plans, more accurately weigh options, and hit target dates. And, what’s more, improved reliability usually looks like “faster” delivery!
Addressing the challenges that your software organization is facing is an ongoing challenge that every engineering leader grows accustomed to. But don’t get complacent, or so caught up in every minor engineering concern that you do not spend time on potentially bigger issues outside of engineering. Often what appears to make a software organization “slow” is the direction that it is getting from outside the team.
Working With The Product Management Team
The work of the Product Managers (PMs) is extremely important for ensuring that the software organization gets clear, focused guidance. PMs generally determine what the software teams work on and prioritize when they do so. The PMs ensure that the deliverables meet the (external and internal) customer needs. They are responsible for scoping the projects and specifying the tasks on which the engineers work.
Work with your PMs to cut projects down to true Minimum Viable Products (MVP), which involves paring away all noncritical features until only the necessary ones remain. Smaller projects are easier to plan, more likely to deliver on time, and enable quicker feedback. Push back on the tendency for projects to bloat as stakeholders horse-trade for features.
A key tenet for reliable software delivery is that the work an engineering team commits to should not change. So the team should primarily work on (and commit to) tasks that are clear, concise, and part of a stable project plan. These are additional reasons that you and your PMs should be biased toward MVPs, as they help meet these requirements.
Of course there will be times when projects do need to change. But if this happens too often or arbitrarily, it is a sign that the PM team does not have control of the products they manage.
If the software team is receiving clear, focused, and stable guidance with the right level of detail, they have an excellent shot at delivering the right product within a reasonable time frame. Engineering leaders must work closely with their PM counterparts to ensure that they are receiving the necessary guidance and be willing to challenge their PM colleagues when the guidance is not up to par.
There is still one more critical requirement for effective software delivery. If the product and engineering teams are not aligned with the company’s goals, the work they do, no matter how rapidly, reliably, and in a focused way, will never be fast enough.
Aligning With The Company
Your software organization’s work must be aligned with the company’s (or overall organization’s) goals. Doing the wrong work quickly is of no use, and it’s actually counterproductive, leading to wasted time and effort and frustrated staff.
Company goals are often expressed in terms of OKRs, KPIs, or some other goal-setting system. However your company determines its goals, you should strive to be part of this process. You will want to ensure that you fully understand what it is that the company needs to accomplish, and how progress and success will be measured. The work your team takes on, either directly or through your product team, should align closely with the needs of the company.
A couple of common mistakes a company may make are choosing vague goals or having too many goals. Either creates a substantial challenge for the engineering organization (and the company in general). As mentioned in the previous section, it is critical that your teams are working on clearly defined tasks. As many of these tasks as possible should directly align with the needs of the company. And there cannot be too many tasks, or your team will be spread too thin. As we used to say at Salesforce: “If everything is top priority, then nothing is top priority.”
Another common challenge is presented when different company divisions have different priorities on issues like security fixes, bugs, features, customer requests and integrations, and performance issues, among others. Too often companies allow divisions to fight it out over priorities, and often the loudest voice gets its way.
You must work with your management to ensure that the company’s goals are clear and concise and that prioritization of work is agreed upon. You can add people to your software organization, tune your team, and effectively partner with your PM organization, but if you are not able to gain alignment with your company goals, you will never deliver the right work. To ensure that this happens you must actively participate in the creation and refinement of these goals.
Making Your Engineering Organization “Faster”
Despite the fact that I have repeatedly been asked about making software organizations “faster,” I believe that the deeper question is how to deliver the right functionality in a timely manner. There are many possible ways to answer this question. Resist the pressure to spread your efforts (and your team’s efforts) across too many areas at once. As Steve Jobs and others have said: “Deciding what not to do is as important as deciding what to do.”
Do not attempt to hire your way to better delivery until you have assessed and improved the current situation, or you may further compound existing problems. Start by working with your engineering team to improve the relevant people, processes, tools, and techniques. But don’t stop there. Work closely with your PM team so that the guidance they offer is clear, accurate, and well targeted. Ensure that your company (or organization) has a workable process for goal setting, alignment with company goals, and prioritization of engineering efforts.
Of all the possible areas to which you can devote effort, you need to figure out which are most important for your situation, not which appear to be the most urgent. (This is known as the Eisenhower Principle.)
Many executives ask about making software organizations “faster,” but this question often masks the real problem, which is reliably delivering the right functionality. Even if you investigate the engineering organization’s challenges and then spend the time to address the most important of these, you still may not make the engineers any “faster,” but you will solve some of the real problems.