Put people first, and the rest will follow: Tips for building a highly effective engineering team

A blog post by Paul Reddan, Cloud Engineering manager at Deloitte Consulting LLP.

As companies embark on ambitious cloud-native transformations, leveraging bleeding-edge technologies that push products and engineers alike to their limits, it’s key to focus on building highly effective engineering teams. Critical milestones are often jeopardized by a new requirement, some indecision or oversight, or a technical barrier throwing the project into flux. In looking to develop a way to reduce and respond to these challenges, it’s essential to build an environment where people are treated as individuals, effective leadership is in place early on, and the ongoing technical constraints are constantly being addressed.

People are the first key to success

Building the right team is critical from the outset. Focus on finding the right people with the right skills. There’s only so much capacity for learning a whole new skill set on the job when delivering on tight timelines. Don’t hesitate to lean on associate contracts to get you there.

Team needs, individual engineer needs, and collaboration should be paramount. The team must be self-motivated and self-starting. This is especially important in a startup environment, where team members need to be adaptive, able to fail fast, and operate with a lean mentality. It’s essential to collaborate as much as possible and avoid working in isolation too often. Make space for one-on-one discussions, group brainstorming, and rubber-duck debugging. Finally, meet the needs and appetite of the engineers. It can help to assign work with some variety in both subject area and challenge across release cycles to keep their interest fresh.

Something that also can happen if not addressed early on is project fatigue. Running after impossible deadlines and constantly falling short will cause people to lose motivation, which can result in team-member burnout and a disproportionate loss of productivity. Saying “yes” too often to unreasonable or unrealistic requests can put significant pressure on the team and reduce motivation, job fulfillment, and workplace actualization if no adjustments are made. Encourage people to take a day off to revive after tough weeks or months.

And, though it may seem obvious to say, steer clear of a “them and us” mentality toward other groups in the overall delivery. Politics kills productivity.

Finally, celebrate success as a team, and do it often. Morale boosts from small wins or achievements are essential for continued team engagement. Be conscious about avoiding a relentless slog toward a single, far-off target.

Strong leadership is critical

Managing how a team operates and behaves is at the center of completing this type of work. So, in the interest of building a great team, practice strong leadership that both supports the team and leads it from the front. For example, being able to protect the team from and argue down potentially calamitous architectural decisions higher up the management chain will help you in the long term, as much as it’s uncomfortable to address in the short term.

It’s also crucial to assert strength of leadership when it comes to architecting integrations and entry points into the platform. Avoid the prospect of a shared PaaS or SaaS controlling data flow. It’s essential to avoid being at the mercy of a third-party integration where your platform’s resilience is concerned.

Something to address early on is enabling traditional development teams to be self-sufficient from day one. Whether you place a platform engineer into the squad or train each application developer in the squad to be a more well-rounded engineer, it’s critical to avoid thickening DevOps silo walls until one team ends up just servicing developer requests, with the developers unable to unblock themselves.

And, when it comes to multitasking, don’t try to overoptimize the team and its work patterns. For example, don’t encourage team members to switch focus to administrative or menial technical tasks to make efficient use of time while waiting for code to build and deploy. Instead, allow them to remain in a state of flow for the current task by planning next steps or thinking about improvements. To continue to be productive over a long period, don’t spread engineers too thin. Context switching is the enemy of an engineer in flow. This is especially impactful in an environment that’s bound by tradition and complex security processes.

Housekeep the technical environment

Believe it or not, most technology issues are “soft” issues that involve people and process, rather than hardware and apps. In fact, technology issues often revolve around workflow management, vendors, stakeholder expectations, technical working environment, and functionality concerns.

First, the thing to understand is that, sadly, nothing is ever simple. For every basic request that’s asked of the team, there will likely be an additional process to navigate or an oversight to overcome. Try to capture this when estimating on delivery.

You can also expect the goalposts around solution design to change more than once. This is especially common in designs with loose requirements. Don’t be disheartened if your efforts are made redundant when the architecture you were working to is deemed no longer viable and you need to pivot. Try to understand why it happened and how to avoid a repeat.

It’s also always key to engage with product vendors as soon as possible in the project timeline to ensure that their release schedules don’t affect project delivery milestones. Pull them in as closely as possible, work with them to enhance their products as they build them, and address defects as you discover them.

Crucially, when working with development cycle reviews, to keep up morale and team engagement, it is always good to ‘action the actions’ from retrospectives. This can often fall by the wayside and drive the team further into technical debt, which is more expensive to pay off down the line (as the team gets bigger, more new technology is added). It’s only realistic to expect to generate some level of technical debt. This can accrue interest over time and can be hard for stakeholders to accept, but it’s best explained in terms of software entropy.

Also, realize that sometimes it’s unavoidable to compromise on some level of quality to ensure that stakeholder demands and deadlines are met at all costs. Ensure they recognize that the technical debt incurred must be paid off at a later date, as must the impact on the project until that is done.

Finally, as with any IT project, expect the unexpected. Allow for delays in delivery or sprint outcomes, and account for inevitable, intangible, and unplanned operational work making it into the cycle. Baking in time to project timelines for unexpected work will give the team breathing room to reach deadlines and the satisfaction of having completed it. Although sometimes hard to quantify, it’s critical to communicate the value of this unplanned work to sprint stakeholders.

The bottom line

No IT project is ever easy, and cloud transformations can be particularly complex given their enterprise nature and the influences the people, processes, culture, and technologies already involved have. So, it’s important to understand where the focus should be, but more specifically how to build effective engineering teams to get the project off on the right foot and keep it flowing smoothly to meet stakeholder demands and deadlines. Companies that build effective teams in this regard will be far better positioned to experience fewer hitches and delays than those who cobble teams together as they go.