Dc20 chris sewart - do unicorns' tech stacks solve your customers' problems
•Download as PPTX, PDF•
0 likes•56 views
This document discusses how the technology stacks of large tech companies like Airbnb, Uber, LinkedIn, and Facebook may not be the best practice for other companies due to differences in scale, resources, and customer problems. While these unicorns have developed sophisticated systems that work at massive scale, generating billions in revenue, their approaches focus on their specific problems and may introduce new issues. The document cautions that best practices from engineering blogs or unicorns are not automatically best for other organizations, and advocates focusing on essential complexity to solve customer problems.
Recommended
More Related Content
Similar to Dc20 chris sewart - do unicorns' tech stacks solve your customers' problems
Similar to Dc20 chris sewart - do unicorns' tech stacks solve your customers' problems (20)
More from ManchesterDigital
More from ManchesterDigital (20)
Recently uploaded
Recently uploaded (20)
Dc20 chris sewart - do unicorns' tech stacks solve your customers' problems
- 1. With thanks to our sponsors
- 2. CHRIS SEWART
- 3. © BJSS Ltd. 2020 Commercial in Confidence Do Unicorns' tech stacks solve your customers' problems? Chris Sewart, Chief Engineer
- 6. The Problem
- 8. How did we get here?
- 9. Engineering Blogs – Best Practice
- 10. Best Practice?
- 11. Best Practice?
- 12. Scale - Revenue Airbnb Uber LinkedIn Facebook $2.6 billion $3.2 billion $5.3 billion $70 billion
- 13. Scale - users Airbnb Uber LinkedIn Facebook 150 million 95 million 260 million 2.5 billion
- 15. Three Questions About Tech
- 19. Best practice For unicorns is not best practice for you
- 20. Focus on the essential complexity
- 22. © BJSS Ltd. 2020 Commercial in Confidence Do Unicorns' tech stacks solve your customers' problems? Chris Sewart, Chief Engineer
Editor's Notes
- By unicorns I mean. Tech unicorns.
- Not this. Not rocket powered robo unicorns. Although they’re cool.
- I mean privately held startup company valued at over $1 billion. Examples. Some are former e.g. FB
- I’m CE for BJSS in Manchester. Part of my job is to look at tech quality across all of our engagements I the north west This means I talk to a lot of people. I get an insight, an inside view of how many organisations’ engineering teams work, the products they’re buildign and the challenges they face. We’ve got CEs in our other offices across the UK and in the US. They do the same. And we talk. A common theme is to find organisations building things that are massively overcomplicated. Large amounts of time spent on tooling. On platform. On work that seems unconnected to the values and vision of the product they’re trying to build.
- We dig into the systems and we see a lot of technologies. We dig further. Trying to help. Trying to untangle. Trying to raise things back towards actually solving your customer’s problems. And we struggle to find a good reason for why these technologies were adopted. We see teams putting re-engineering effort into remove “legacy “tech that weas introduced less two years ago. Why? And how can we stop? In what other industry do people go out of their way to make their jobs harder for themselves?
- At our heart engineers love engineering. The simple problems are boring. The complex problems are interesting. We’re drawn towards them. We like to see the work we’re doing as complex. One big source, big driving force behind new tech, of emergent practice are the unicon’s engineering blogs
- Obviously these blogs are about all the cool and exciting tech. Spread best practice Engineers, people like me, and those building your products get interested. Excited. Want to have a go What’s wrong with that? It is all about engineering practice right? So it’ll be a balanced, considered, reflective, measured view of the pros and cons of each practice. They’ll talk about the challenges too Right? Right? Or is it? FB boom, wow Click: LinkedIn. Espresso – all devs love coffee. Coffee. Distributed. What’s not to like? Click: This last one gives a clue.
- Lets zoom in Click: Hmm. That’s an odd picture to use to illustrate a story on advanced high performance data processing strategies. An office. Click: Ahh.
- Click. Ah Note: There’s loads of great content. If you’re interested in what some of the best output from some really amazing people solving properly hard problems – take a look. I enjoy reading them. Just remember. They’re serving more than one purpose.
- So, the blogs might not be as balanced as they could be. Where they are, the tech unicons’ context is still different. They’re bigger. Much bigger. Big companies
- They’ve probably got more users.
- They’ve got more engineers. Do you have 107,000 engineers? They didn't start out looking like this. They started small. simple. They grew into these tech stacks.
- [recap] It sounds cyncial. .it is. You don’ have to understand the answers
- What does this tool or tech do for you? How does this help you? This is easy. Enthused from the latest blog / meetup / talk / video people are quick to answer this one.
- This is a bit harder. Good teams do this. Not all do. It’s pros and cons list. There are always downsides. What are they, and how are you going to mitigate them?
- What problems just get moved about? You intro thing here, you’re going to have to do thing there. Responsibility for something – things like security, validation, performance, monitoring – shifts – maybe even to another team. Turns out that this is often a lot of work. Far more than introducing the new thing. Often more than mitigating new problems the new tech introduces. Are we prepared to go do this work? To ensure that all the things we put in place to make reliable, robust, delightful products are still working? After all that, does it seem so shiny? Is it as much fun?
- Engineers like to engineer. We like solving the difficult problems. The tools and techniques of the tech unicorns are only best practice in their context. Not in yours. You may not be tech unicorns, with billions of users, 10s of thousands of developers. But you do have difficult problems. People are tricky. Customer behaviour is hard to understand. Product is just hard.
- Focus your engineers on the genuinely hard problems. Ask those three questions. What does it solve, create, move. The answers may be deeply technical. You really need to understand the answers. Just keep asking. Ask them to explain. Your engineers will start asking themselves. Be more honest about the problems they’ll introduce or move around. Know that they’ll need to justify their decisions. By pushing back against the whirlwind of new tech you’ll start to make space to talk about the real problems, the real complexity. And get those ingenious brains focussed on solving your customer’s problems.
- Thanks