>
To share a personal example, I was building a system to provide medical workers feedback on whether they wore personal protective equipment correctly. The hospital wanted us to use computer vision/machine learning to automate their checking process. But when we went on-site, we realised that our camera setup, which provided workers a 360 view of themselves so that they didn't need to awkwardly turn to check their behind as they had to do with regular mirrors, was far more valuable than whatever machine learning model we had built. The real problem was actually how could we make it easier for people to wear PPE so that fewer mistakes would be incurred and thus less checking required.Yes. In https://news.ycombinator.com/item?id=22827841 (product development), I wrote the following:
>The analogy I use is that customers will ask for a robot with IoT and blockchain support that automatically integrates with Amazon API and orders mops, tracks the item, and has AI and image segmentation and recognizes Amazon drone, and receives the mops and automatically loads them. Because AI, blockchain, and IoT. Yes, it's not a sentence.
>Your job is to ask why, figure out they always find water on the floor, and then look up and find there's a leaky pipe, then fix the leak.
>In other words: do not really listen to the "implementation" or the "solution" customers propose. These only fix symptoms and are easily swayed by whatever piece with a clik-bait title prefixed by "This AI robot" someone with 2 minute attention span has written that the customer half read taking their morning coffee, and wanted to bring to the product not to be left behind by the competition.
>What one really looks for is the problem. The problem almost never manifests itself, you have to dig to get it. It's muddy. People could be pissed at you because "What do you not get in an AI IoT robot that orders mops?". This is where having social skills and getting good at interviewing comes in handy.
That is a very common mistake in many projects where you start with a solution (computer vision and machine learning) and try and fit it into a problem.
The sooner people learn to systematically go right to the "job to be done", the better.
We do that systematically through issue templates that try and pry the problem from the person writing the issue. Before that, whenever one of our data scientist colleagues opened an issue on our issue tracker for our ML platform, we'd ask "what are you trying to accomplish?". They'd open an issue going directly to the "solution", but with better issue templates, the message gets across that whatever solution you come up with is "your implementation of a solution to a problem, when we really are looking for the problem itself you are trying to solve".
Same thing with clients. Digging and peeling assumptions and distractions. I remember I was a "coach" on a "start-up" event. I thought they actually had started but they were just pitching ideas. One participant's pitch was "People wash their feet and then go walk on carpets. It's non hygienic. We want to use IoT and computer vision to detect the feet and solve this problem". I asked "So, kind of putting a hand dryer on the floor and putting your feet close enough to trigger it". They went "Huh.. but.. IoT, computer vision".
The hand dryer on the floor works. I use it myself.
That event was a shit show because the people in charge did it in the context of "Smart Cities" and "IoT".
You can witness this in Q&A websites like StackOverflow or similar forums. People ask a question about how to implement a solution. Seasoned contributors will ask the person what they are trying to accomplish. What's the motivation behind this. The person then explains what they're really trying to do, and the solution is often times way, way, simpler and could even be an existing utility or a flag in a CLI.
You must always clarify. Miscommunication is a thing. Here's an example a few days after that, we turned to a project that was stuck, because allegedly the "people at the client organization were dumb and didn't understand crypto". We assumed the client organization's people were smart. We ended up unlocking about $350,000 with the following trick during the meeting: slide a sheet of paper and a pen to their people and ask them to draw the data flow they thought we were going to build. What they drew wasn't what we were talking about. We drew the system as we wanted to build it, and their security and legal teams went "Oh... we thought..If it's like that, then we're OK with that". A sigh of relief from everyone at the table, and it was a big table.
>So my hypothesis is that being in an environment (BigCo or other Startup) where practices are being well-used to deliver a product will stretch my capabilities so that I can better execute on my own/in my own team.
Maybe, maybe not. The way I went about it is joining a company under a CTO/Co-founder as engineer number 4. One engineer left. Then a year and an a half after I joined, the CTO left without notice and we had about fifteen employees and ten projects, some with large organizations with which we had meetings scheduled. We had to turn that ship around fast. Learn the contracts, read hundreds of emails in a couple of days because we had meetings lined up with large groups a couple of days after that.
So one way to learn is to join a company and after a year and a half, the CTO quits. (overfitting joke).
The meta lesson of this is: how not to go through that? Touched upon that in https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen). Also, here's an excerpt from https://news.ycombinator.com/item?id=25037956:
>How we've done it: about two years ago, I got a bit paranoid about the fact we relied too much on people being present for work to be done, and was bothered seeing the team suffer commute at least 4 hours daily. We started experimenting with different schemes, sometimes working a full week remotely, seeing what 'broke', and addressing that. We wanted to get over the mistakes while we could afford it, and we wanted to be able to hire elsewhere after we had learned these lessons. The idea was to expose the crutches we relied on to get work done. For example, peculiarities in the code you tell your team over coffee about is a hidden crutch, because you unknowingly assume that the team is there and that you can address everyone. Working remotely for a few days exposes that because your colleagues hit that problem and you didn't tell them. Which means you have to document things, and institutionalize knowledge. I know it's a big word, but when you join a company and a year later the co-founder and CTO resigns without notice, you learn your lesson and establish processes so that if you disappear or are not in the capacity to help the team, there is enough knowledge to go by[0]. So the first few days, everything I did was documented in a git versioned handbook. I went so far as to document with pictures how to fill a cheque for taxes, what to write, where to sign, where to pay with a picture of the building, its GPS location, what floor. It was called an "Operator's Manual" so that anyone could take it and operate this. We have hired for that role later, and we just handed that person the manual so we could focus on other things.
>Everything went there. Our corporate clients, addresses, points of contact. I didn't want anyone to go over a crappy handover if I wasn't there.
>Things aren't always the way we want them to be.
>- [0]: https://news.ycombinator.com/item?id=25025253
You wrote:
>In your list of suggestions, how would you prioritise what practices to learn? Or is it about identifying issues in whatever project I'm currently in, having the backlog of potential practices in mind, and then figuring out in real-time how to apply those practices to improve your product/processes
This is an iterative process. The one titled "If I disappear, what will happen" goes a bit into how we went about it. Building a team is similar to building a product: solve problems that have a big impact and are frequent first. Amortize your time. Solve real problems (Judo with real and hostile opponents vs. Aikido with imaginary or compliant opponents).
I wouldn't establish processes before we had issues, except for obvious* things. Keep a loop that always counts instances of something happening. For example, when you onboard new people, you notice that you're going over pretty much the same thing, or that you forgot the same thing. Make a cheklist and an onboarding document (creating leverage). Here's an early version of an onboarding document, which we then sent to candidates who didn't get the job and who asked for resources to improve (https://jhadjar.gitlab.io/kbase/hiring/)