When building teams, leaders will often talk about wanting to hire ‘the best’. When it comes to cultural fit and enthusiasm, I find that hard to argue with. But they are often talking about perceived capability - ‘the best’ engineer in the world.

‍

‍

The problem is that you can’t always hire the elusive 10x engineer that lives in that rarefied atmosphere:

• Perhaps they don’t exist, or at least aren’t available
• Perhaps they do exist but they simply don’t want to work for you
• Perhaps they do want to work for you, but there is a cultural value mismatch - the “brilliant asshole”

‍

This approach to hiring also misses a key point - the most amazing builder in the world will be unproductive if the processes surrounding them are stifling, or the organizational culture resists progress.

‍

The productivity of your engineering team typically reflects the organisational context in which they work, their leadership, and how they gel together - not the individual’s capability.

‍

With that insight in mind, it makes more sense to “shift the curve”: hire the best people available to you, and concentrate more on improving the overall organisational context.

‍

Every step change improvement in context shifts the curve to the right, making a larger talent pool available to you.

‍

So how do you shift the curve?

‍

Getting the most out of people

‍

If the team is not rowing in the same direction, you won’t get the best out of individuals. Cultural values and a clear mission play a big part here, but that is well understood and perfectly well described elsewhere. In addition, the specific goals need to be clear when building a product; something which some interpretations of agile forget.

‍

As well as creating a documented end goal, intermediary steps can be plotted out. This is unrealistic in two week blocks, but setting a six week goal is perhaps more feasible. The six week surge sprint should have a clear definition of done, established in the first few days. If that is impossible, running a design sprint to drive alignment makes more sense.

‍

Even the best engineers will struggle to be productive in an environment that has been optimised for project administrators. Encouraging an engineering culture, where people have the freedom to build will reward those brave enough to do it.

‍

Some organisations try to “shield” the technologists from their customers (or perhaps it’s the other way around!). Unfortunately this leads to products being built that are not fit for purpose, or not a priority. Whether the clients are internal or external, the organisation should find creative ways for the technology team to interact with the end customer and hear their problems. Builders should watch their product being used by real users in silence. Nothing is more embarrassing than watching smart people struggle with your buggy and unintuitive application.

‍

Finally, creating cross-functional teams with combined objectives is a great way to help ensure the team is well-aligned, and sharing information effectively. Involving stakeholders early - especially in functions like risk & compliance - builds buy-in, and reduces the chance of a late surprise. Personally, some of the most fun and effective teams I have worked with have been cross-functional, and have given me the best opportunity to learn more outside of my usual field.

‍

‍

Getting the most out of people’s time

‍

Strong engineers working on the wrong features is a great way to waste time. Ensuring we’re building the right thing requires tight feedback loops, but unlocks a huge amount of team productivity. Getting your product in front of real audiences even when it is in an Uncomfortably Simple state allows for course correction and uncovering requirements that had been missed.

‍

We all want to minimise meetings, but they’re sometimes essential. Paul Graham eloquently laid out in Maker's Schedule, Manager's Schedule that not all schedules are equal. A Manager can slot in the “catchup” anytime. The Maker loses flow. The ratio of having meetings all morning, and Making all afternoon is 50:50. But so is a 30 minute meeting followed by 30 minutes Making on repeat all day. Guess which one is more productive.

‍

There are some quick wins from technology that can be rapidly introduced to your organisation:

• Moving from email to chat applications with broad channels; ideally cross-functional
• Ensuring engineers have suitable IT equipment - saving a one-off $1000 on equipment costs for a $10,000/month engineer is mathematically challenged
• Provide enough CI/CD pipeline capacity to ensure people aren’t unnecessarily waiting around for builds

‍

These ideas and more are further explored in Unlocking Agility.

‍

Finally, engineers sitting around waiting for tickets to be resolved or other teams to provide updates on errors burns untold brain cycles. Try to make your environment self-service as much as possible - whether that is automated permissioning flows, or centralised logging for self-service debugging across distributed components.

‍

In conclusion, by following the suggestions above, your team can operate at 10x. Focus on the team, not just the individual! I’m looking forward to hearing your feedback on other ways to shift the curve - contact me at ned@mission.plus.