LeadingIn Tech #7: Working Backwards to identify the right talent for your team

June 2021

Jun 30, 2021

Hi there!

Welcome to the new edition of the LeadingIn.Tech newsletter.

Now that we are done with the first half of 2021 we are getting into what it might feel like a peak season of tech (or non necessarily tech) companies hunting and competing for the best talent of software development family roles. It's no secret that the demand is significantly higher than the offer available. Still many companies spend too much energy on finding the best programmers, that know the latest frameworks or worked with the latest technology leaving behind some high potential candidates because they didn't tick all the boxes in the assessments.

Let me first step back and try to dissect what I actually mean when trying to find the right talent. To do so let's use the concept of Working Backwards as the process solving a customer problem or need starting by imagining what is the experience we want to deliver and then work backwards to figure out how and what will be built. Werner Vogels wrote about this process in 2006 in his blog All Things Distributed where he described it in 4 steps:

A Press Release
Frequently Asked Questions document
A description of the customer experience
The User Manual

A Press Release

"The press release describes in a simple way what the product does and why it exists - what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product - not just how we think about it internally."

Understanding that writing a press release is the exercise of setting the vision and imagine how a product launch will look like and be advertised to the customers. The importance of this exercise is to help the team visualise the value being delivered and identify WHY we want to build such products and also understand whether it should even be built at all. The Senior Engineers in your team should be able to set a long term vision for the product and technology but also identify the technological challenges to materialise it. Being able to communicate this vision in a language the easy to understand is also a valuable asset for any engineer in a leadership position.

Frequently Asked Questions

"It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have."

Building a product is not only about what it can do and what problems does it solve but also is about how you solve those problems, how the value being added is perceived from the customers viewpoint. As engineers working in a project being able to understand the importance on how your users will interact and understand the features of the product being delivered is a crucial aspect for the product's success. This part of the exercise also helps the team to identify what parts of the solution will need refinement. It's also a good space to address on the tradeoffs made and setting alternative solutions to address customers concerns.

A description of the customer experience

"Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product."

Reaching this point being able to detail the customer experience and the use cases is an aspect every engineer needs to work on with a lot of attention to details, thinking about not only the expected happy path but also the behaviour of the product when something fails. Being able to detail and be a few steps ahead of potential issues when designing technological solutions is required for ensuring high quality products that reduce frustration for their users.

The User Manual

"The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product."

Finally being able to write proper user manuals is what helps products grow and scale by allowing the customers learn by themselves how the product is used and what steps they need to execute in order to achieve their objectives. Making more effective the adoption of the usage of the product. Writing good documentation unlocks the team to continue to work on improving the product rather than giving first hand support to their customers, which in results makes the whole product development scalable.

How is this related to finding the right talent for your team?

In past editions I've talked about building teams that can outlive their original members by focusing your company's vision and its reason to exist.

While this time its intentional that in a post related to finding talent for software development teams I've talked very little about technical related traits. I've used the Working Backwards process to highlight the importance to "Start with customer experience and work backwards to the technology" because in the end it's all about solving problems for people and helping them understand how you are trying to solve their problem.

Finding the right talent for your company is more about finding the people that is able to work on solving the problems for your customers. Of course having solid technical skills is vital for being successful in a software development role but the ones that take the most advantage of their talent are the ones that use them to solve real customer problems.

The right talent for your team will be able to identify your customer pain points, set a vision on how they want to address the problem while making the right tradeoffs. They will be able to detail a plan to execute it and deliver a robust solution. They will also be able to communicate effectively. The right talent for your team is also a force multiplier that creates an environment that facilitate others to participate and help evolve the product.

The right talent for your team will start with people’s problem and work backwards to find the right technology for it. Having this foundations will give the tools to your team to make the right choices in terms of technology. They’ll be able decide what is the best tool, language, framework, design pattern or database technology to serve your customers. These are the tools that they'll use to serve the mission of the company.

As technology evolves faster than most of us are able to catch up. What it is important when finding the right talent for your company is to look for those that are able to understand the technology, have solid foundational knowledge and able to quickly adapt and learn new ones when needed while still being able to understand that in the end its all about the customer experience.

For extra points, see below: "An incomplete list of skills senior engineers need, beyond coding" by Camille Fournier (@skamille):
1. How to run a meeting, and no, being the person who talks the most in the meeting is not the same thing as running it
2. How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time
3. How to mentor an early-career teammate, a mid-career engineer, a new manager who needs technical advice
4. How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid
5. How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it
6. How to influence another team to use your solution instead of writing their own
7. How to get another engineer to do something for you by asking for help in a way that makes them feel appreciated
8. How to lead a project even though you don’t manage any of the people working on the project
9. How to get other engineers to listen to your ideas without making them feel threatened
10. How to listen to other engineers’ ideas without feeling threatened
11. How to give up your baby, that project that you built into something great, so you can do something else
12. How to teach another engineer to care about that thing you really care about (operations, correctness, testing, code quality, performance, simplicity, etc)
13. How to communicate project status to stakeholders
14. How to convince management that they need to invest in a non-trivial technical project
15. How to build software while delivering incremental value in the process
16. How to craft a project proposal, socialize it, and get buy-in to execute it
17. How to repeat yourself enough that people start to listen
18. How to pick your battles
19. How to help someone get promoted
20. How to get information about what’s really happening (how to gossip, how to network)
21. How to find interesting work on your own, instead of waiting for someone to bring it to you
22. How to tell someone they’re wrong without making them feel ashamed
23. How to take negative feedback gracefully