Han-Shen (Han) Yuan juggles many-a-plate. From owning and running a successful incubator through various advisory positions and now, landing as an Associate Partner at AFK Partners, the eBay and Netflix alumnus’ experience is second-to-none. Here he shares his thoughts on honesty within delivery and why the future of technology is still looking bright.
Hi Han! Thanks for joining me today. What’s keeping you busy at the moment and how will your focus shift for the rest of 2021?
These days I run an incubator. It’s called Post-PC Labs and the original thesis was to effectively help other entrepreneurs make their businesses come alive. I would provide product and engineering assistance and full-stack development in exchange for a convertible node, so it’s a very different funding model from a traditional seed investor or a venture investor.
I started it almost nine years ago and for the first year I did not make any investments. So I started building my own things on the side which has been really fun and keeps me busy, and helps me build out my team and things like that. Very recently I started with an organisation as an Associate Partner called AKF Partners and they essentially involve themselves in three lines of business: due diligence, technology and leadership consulting, and interim CTO placements. I would expect to do more of that work as the year goes on.
How do you think technology leadership has had to change as a result of the pandemic landscape?
I think what you’re going to see – and not just in my case – but for people in all types of leadership positions is that Covid has, for better or worse, accelerated a digital transformation. If you were to come to the United States, you would see that formerly brick-and-mortar shops all of a sudden have become digital; they have a website and restaurants have been able to take orders online over the last several months. This rapid digitalisation is going to create an extraordinary amount of demand for people who understand and know how to build solutions in the digital space. That demand is somewhat of a double-edged sword: on the one hand, you’re going to see a lot more consumer problems come to bear. On the other, for leaders, it’s about being able to rapidly iterate both the teams’ response to customer problems (both new and unforeseen) as well as how you invent new things to solve problems that we didn’t think we had pre-Covid.
The other thing that I also feel is generally hopeful. Looking at the global economic expansions over the last 100-150 years, there have been very few synchronised recoveries; usually, they come about through world wars. In this particular case, every country has suffered and we’ll likely see a synchronised global recovery. So while things are terrible, I do think the future is quite bright and there will be a lot of work to be done.
Given the current digital transformation and the speed of the technological response to the pandemic, how do you ensure that the failures or mistakes made when releasing a product or bringing a service to market, aren’t fatal?
That’s a great question. I think in a world where there is less competition or you have a dominant position in your industry, you can afford to make mistakes, or allow the customer to pay for the education of your mistakes.
In a world where there will be more competition/more demand, which, you know ostensibly would encourage more people to enter the fray, I do think what you’re describing is going to be an issue.
What teams are likely going to need to do is really focus on two things:
- You don’t know if you’ve made a mistake if you have no way of measuring when you’ve made the mistake – Frequently as technologists we’re very focused on systems-level monitoring: are the machines up or down? Are they operating correctly? What people are going to need to start building into their organisations, is the ability to measure in real-time business metrics. You’ll need to be able to understand the telemetry of what’s happening to the business in real time in order to know when you build something that is a mistake. Organisations will probably need to develop – to the extent they haven’t developed it already – a deeper discipline around, A/B testing. How do you know if the product that you shipped actually works and is generating value or not? Do this in a very scientific way so that you have graceful fallbacks.
- Develop a rigorous discipline around post-mortems – As competition increases and as does the need to learn from your mistakes.Even young organisations need to take this idea of performing retrospectives thoroughly on a regular basis. But you can’t perform a retrospective if you don’t know you made a mistake to begin with.
With that in mind, in your view, what are some of the biggest mistakes made when estimating and roadmapping?
So that’s a tough one, because if I were to zoom out a little bit, I would say that sometimes there aren’t engineering mistakes but product mistakes. By that I mean, you can have an engineering team build something perfectly to spec, but once that it is in the sense that technology organisations often have people that deeply understand how things should work; they usually grew up with technology as children, they play with it very deeply and so they have a point of view. It’s important for those product and engineering teams to collaborate throughout the product lifecycle and so this is where I think more modern approaches like Agile and Scrum help to create the necessary collaborationto ensure you’re building the right product for the right market.
The other mistake that I see teams make frequently and is the other piece of the problem, is that they take too long. So you might have this amazing product and have spent many years building it, but things can change very quickly. For example, if you had a product in mind in 2019 and you wanted to start a business with it, the landscape has changed very dramatically in the last couple of years – especially due to Covid-19. And so speed is going to be very important.
The other piece, of course, is quality when you ship something very quickly. It’s the right product, but, if it doesn’t work very well or it’s buggy, you’re going to have customer adoption problems. I think teams need to be very good at understanding their customer and their market so they build the right product. That is a skill. If they don’t do that right, they will fail no matter what they built.
If they never ship it, that’s going to be a problem as well. And so, being relentlessly focused on shipping things very quickly, is critically important.
If you have the right product and you shipped it quickly enough even if your rollout is a little bit buggy, maybe you can survive that. The other two are very difficult to recover from.
Absolutely! Following on from and extrapolating on those points, what are some of the strategies you’ve either encountered, or deploy yourself, for better predictability in engineering?
A couple of things. I think there’s a common misconception – and this may be controversial – but I frequently see engineering teams very focused on estimation, and the dirty truth is that in engineering, when you ask an engineer, how long will it take to do something, they are, at best, giving you a guess. And the reason is that (and this is something they may not tell you outright) the truth of the matter is they don’t know. They have some sense of how long it might take to do something, but they honestly don’t know.
Imagine if I asked you, how long will it take for you to assemble a jigsaw puzzle that has 1500 pieces? Perhaps in your own mind you may have an estimate. A month doing an hour a day or maybe, you’re a jigsaw puzzle master and could do it in a few hours. Still, the reality is you don’t know unless you knew exactly where each piece was going to go and the precise speed of your fingers. And so, it’s similar for an engineer.
I think the way to solve that problem is to constantly check with the engineering team about whether or not they’re going in the right direction. Development approaches like Agile naturally build this in because they have sprint mechanisms that determine if we need to rebase this sprint, or rebase a future sprint and how do we look at our backlogs etc. But that exercise is critically important.
One approach I use – and it has served me well over the years – is asking teams for an estimate on when they think a particular sprint or project will get done. But I also say that if ever their original commitment is not going to be made, they must let me know immediately. As a leader and as a manager you need that information in real time so you need to create a safe place for your team so that they can reset expectations because of course, we’re in a world of imprecise science, so to speak. However, I do think it is also important for leaders to hold teams accountable to give that information in a timely enough way and so, create the accountability to do so.
What I like to do is I tell teams not only tell me as soon as they know, but make sure that they tell me soon enough such that the delay is twice the size of the early warning. If they told me it’s going to be delayed a month on the very day that it was supposed to be due, that is catastrophic for the business.
By doing this, you’re creating a kind of algorithm or heuristic, so that the business gets what it wants, which is visibility into project execution and the individual gets what they want, which is precision and the estimate. I think both sides can potentially win, but the idea of creating a framework for communicating estimates is often more important than the rigour that teams themselves apply to estimates, in terms of determining them. I’ve seen R&D organisations spend months trying to figure out how long it will take to build something, rather than spend those months learning from what it would take to build that thing.
Finally, what books would you recommend for Delivery Managers?
I would recommend three texts that you know have a very sort of contemporaneous relevance. The first hat I think is essential for managers at all levels is Andy Grove’s High Output Management. It’s a little on the older side at this point, but the kinds of concepts that it discusses help solve legitimate problems modern managers still struggle with today i.e you micromanaging too much versus too little. And those are the kinds of tactical things that I think that book does a great job of.
The second book is called Peak Performance by Brad Stulberg and Steve Magness. And the premise of that book is, how does an individual maintain peak performance through a long period of time. It is written in a much more generic form as it applies to both business people as well athletes. But the main point of the book is that it talks through various methods, among which is the idea of creating cycles where individuals rest, as well as practice.
I think in the technology field, technologists need to create those natural boundaries where they are working and resting, especially when they are exploiting the roles that they have today versus exploring new technologies. Those ideas are extremely powerful for the modern day CTO who is invested in extending their career for a long period of time, but wants to avoid burnout. Those are very real issues that folks need to think through, so I think it’s a great book for people interested in extending the longevity of their careers.
The final book is called The Art of Scalability written by Martin Abbott and the other co-founders of the organisation that I recently joined. It’s a more modern version of High Output Management and specifically focuses on software. It has a number of different stories around how CTOs scale organisations both from a people and technology perspective based on their experience of scaling eBay and PayPal during their more formative years. I think it’s a fascinating read!
Thank you, Han!
Find out more and get your tickets here!
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.