Earlier this year we were introduced to the team at Tryolabs by a mutual collaborator. Where the Alloy team focuses on hardware – mechanical, electrical and firmware engineering – Tryolabs focuses on software with expertise in AI, machine learning and IoT. While there’s little overlap in the services we offer, we thought that there might be something to learn from each other about how we approach client work and consulting as a whole.
Through a series of discussions and a written Q&A exchange we learned about how Tryolabs goes about delivering value to their clients and in what ways our teams could compliment each other in future projects. The biggest differences in how we work came down to the nature of our disciplines: Changes later in development are more difficult to manage in hardware than software and require different ways of mitigating risk. But when it comes to the basics of how we each provide service and value to our customers, we have very similar approaches.
As service organizations, we both have found that focus and close client collaboration are critical to ensuring we consistently meet and exceed our client’s expectations:
Our team members focus on one client at a time: We both have adopted approaches where each of our engineers are fully dedicated to one project at a time. This keeps our clients and internal teams focused on the task at hand, responsive, and aligned on priorities. Yet we can still draw on the experiences of our greater team for input.
Our teams keep client goals and project risks at the forefront with frequent check-ins and deliverables: Tryolabs works following Agile methodologies which is built on 2-week sprints after which they deliver something of value to their clients. This structure is a great mechanism to “recalibrate based on what the client considers more important to tackle next.” While our approach at Alloy is more akin to a waterfall style, we still use weekly check-ins to keep our goals aligned and quick proof-of-concept prototypes early in projects to assess and define product requirements in more concrete terms. Recognizing some of the integral benefits of the Agile approach, Alloy has been experimenting with ways to apply elements of this to early stage hardware development as well.
We also found that the value proposition to our clients is often similar:
Clients need a team that is ready to hit the ground running: Whether it’s a small company that doesn’t have an engineering team in place or a larger company whose existing team simply does not have enough resources, our clients recognize that it is difficult and time consuming to build or grow their own teams. Hiring a team like Tryolabs or Alloy gives them quick access to a team of engineers who already have experience working together with proven processes and tools in place.
Clients turn to us when faced with a unique challenge: Developing class leading products pushes the boundaries of how things are done. Often we are both tasked with trying to do something novel or bring together pieces of technology in a unique way. Clients draw on our broad experiences in different industries to bring a fresh perspective to a problem. And with typically tight schedules, our tuned development processes can help us move fast, assessing and addressing major risks along the way.
Our clients rely on us to help make decisions easier: Product development is a series of decision points, some independent but frequently interrelated. We both help our clients navigate these decisions maintaining a “whole picture” view. As these inflection points approach, our goal is to generate real-world data – functional prototypes or testing results, for example – to enable well-informed decisions. Finally, we both understand that the best path for the client or project isn’t always the easiest or most direct.
Our clients need us to be flexible and transparent: While we both recognize the long term value of following proven processes to reduce risk and achieve a more predictable result, we also understand that we need to adapt to each of our client’s particular needs. When we do deviate, we are transparent with our clients in regards to any new risks or concerns this may introduce.
We’re looking forward to teaming up with Tryolabs on future projects as clients look to build high-quality, robust hardware with a tightly integrated cloud and/or machine learning component. We foresee collaboration opportunities on systems or devices within a broad range of industries: IoT, medical device, consumer health, retail and agriculture.
We have included below the transcript of our written Q&A with Tryolabs. Our learnings shared above originated from both this written Q&A as well as our related conversations with Tryolabs. We would also like to invite you to see Tryolabs’ Q&A learnings on their blog post.
Tryolabs’ Answers to Alloy’s Questions
What is the most challenging step in your development process for you? For clients?
Probably the bottleneck for a machine learning project is the quality of the data. Some clients come with the fixed idea of doing ML, but only later realize that they are unable to do so because they need to gather or manually label a lot of data.
How do you prototype? How do you iterate?
The short answer is: each project is unique. Before trying to expand this answer, we should differentiate between two broad type of projects: machine learning research projects, and the rest. By the rest, we mean backend-only projects (may or may not have machine learning), IoT projects and, let’s say, a more-classic-project with backend and web frontend.
Some machine learning projects start as research in order to perform a feasibility study of the client’s needs, the quality of the data available, constraints, etc. This allows the client to save time and money before engaging in a longer term project. Usually for these projects there is a small proof of concept prototype to validate the approach and a document with a proposal on how to move forward.
For the rest of the projects, we work as an agile team and thus on a cycle of continuous improvements. Ideally, we work very closely with the client’s team and more importantly the product owner. We usually work on 2 week sprints that allow us to validate our work periodically and adjust the priorities as needed.
What challenges do you have with working remotely with clients, partners, etc.?
Used to face-to-face work, one could think that there are several difficult challenges in making remote collaboration work. However, nowadays we have such a wide range of communication tools available that the lack of physical presence has a greatly reduced impact.
There are some challenges though, and we work really hard to minimize the perception of the distance, so far with great results:
• All of our team members have very good English communication skills and we have conversational training in order to keep improving them.
• All of our developers are fully dedicated to one project at a time, so they can focus on delivering a high quality product that aligns to the business goals of the client, instead of juggling priorities from different customers.
• We often travel to the U.S. For example, when kickstarting a project, for a major release, when there is a critical feature that requires a lot of planning or discussions, or just to get to know the client’s team. Nothing beats the bonding that is generated in face to face meetings.
We also have some advantages that make our life easier. For example our location is on a timezone one hour ahead of the east coast and 4 hours ahead of the west coast, and the teams adapt to maximize the overlap of working hours with our U.S. customers. Moreover, Uruguay’s internet speed and infrastructure are top notch.
How do you decide what processing takes place on the device and what takes place in the cloud?
Usually the limitations are in the processing power and RAM the devices have. We have had projects that use Single Boards Computers (SBC) such as the Raspberry Pi; quite powerful compared to embedded devices. In those cases, we are able to perform more compute intensive processing in the devices, and also evaluate if some not-too-demanding machine learning algorithm can also run.
In cases when there there isn’t that much computing power, we do the bare minimum and upload the data to the cloud to do the processing. For example, we had a project with a wearable that gathered user’s data to be analyzed for pattern extraction; the analysis was so intensive and the model so big that we needed to actually push all of the data to the cloud to be analyzed in more powerful servers.
There is a promising type of IoT project that we haven’t had the chance to work on yet that requires special hardware such as the Nvidia Jetson, or Intel Nervana which are embeddable graphic cards that can be used as dedicated Deep Learning or machine learning chips. With this hardware, more complex machine learning algorithms could be ran on the edge. We hope we can get to work on projects like this soon!
How do you decide what hardware to use for prototypes? For the product?
What hardware to use for the final product is generally not our call. From our experience, it is the product owner, based on suggestions from the hardware team, who decides. When choosing the hardware for the prototypes, we want to keep it as close as possible to the specs of the production hardware, so we would also follow the advice of the hardware team.
How do you determine the communication protocol & connectivity method between device and cloud?
We do not reinvent the wheel and use standard protocols, like BLE for device to hub (or phone), and standard REST-like APIs for the cloud. We try to send the minimum amount of data that makes sense, i.e. we could do data aggregation in the phone and only send aggregate data to the cloud. Or the cloud might need it all for more advanced processing. Depends on the case.
How do you handle software updates?
When it comes to handling new versions of libraries or frameworks we use, we always keep an eye on them to get familiar with the upcoming features and be aware of any critical updates. Depending on if there is a new feature we need or if it is a security patch, we explain this to the client’s team and try to push the update tasks into the next sprint (or if it’s too critical, let them know that we should tackle it immediately). It is always useful to have a good set of automated tests in order to minimize the impact of a software regression.
When it comes to delivering our updates, it varies between backend / frontend / IoT projects. The delivery of updates of a backend / frontend project is usually deploying the work done during the sprint to the cloud so the users can start using the updated application right away. We haven’t had many IoT projects where we were in charge of delivering updates. This is usually the responsibility of the hardware team. There is one exception though: the SBC project. In this case, we used the flexibility of having a full Linux system running on the SBC and we delivered the updates using private APT and PyPI mirrors we built (in order to distribute our own private packages). The distribution consisted of publishing the package to our mirror, and the devices would update periodically from there.
How do you handle security on the device? In the cloud? Across the communication channel?
Again, we don’t want to reinvent the wheel and we build our communication protocols on top of well known and reliable standards such as SSL, private/public keys, GPG signatures and such. When it comes to storage, we follow the latest security recommendations from Cloud vendors.
It’s also important to mention that we can build the infrastructure to follow regulations such as HIPAA when it’s necessary.
How do you pair the proper devices with the proper cloud accounts and services?
This usually varies from project to project because it depends a lot on the field and its particular constraints. A high level answer is that we would design a database model with relationships that properly abstracts and reflects the relations between devices and users. Cloud providers have a wide variety of database services; different databases for different volumes of data and processing requirements, etc. So they are pretty agnostic, and usually their cloud offerings can be adapted to the backend requirements that come from the way we want to use a particular device.
How do you find your clients?
Our process to find clients can be split into two big areas: referrals & inbound.
The referrals are pretty straightforward. When we do a good job with a client or a partner, usually this partner later refers us to their colleagues. The up-side of this method is that the clients who are referred to us are usually very onboard to working with us since they trust their colleague who recommended us. The downside is that as it grows organically, it’s not very scalable and predictable.
The inbound strategy is wide, but can be also split into two main actions: content & networking.
• The content side has a lot to do with our R&D area, our open source products and our blog. This content strategy brings traffic to our website that then is attracted with our offering and contacts us. As a reference, in the past year we had nearly 400k visitors to our site.
• The networking action is basically to meet potential clients in conferences, meetups or events, understand their needs, let them know about our expertise and see if there’s a project to collaborate. Lately we’ve been speaking in several conferences which also facilitates networking.
The upsides of the inbound strategy is that is more predictable (since we can take direct actions) and it’s more scalable. However, on the downside it has big opportunity or direct costs attached (writing blog posts or attending conferences respectively) and it’s hard to close the deals, since they don’t have a reference to trust your work immediately.
What is your ideal project to work on?
Excellent question! But it’s tough one to answer, because there are so many things to consider. Let’s break this into categories.
Client and team wise, the ideal project is one where the client is aligned with our way of working and understands how agile methodologies work. We also appreciate having a technical point of contact. This person doesn’t need to be a technology guru whatsoever, but someone who understands the technical implications of the requests coming from CEOs or product owners, and can help them in turn understand that not everything that seems simple actually is, when you try to implement it.
Project content wise, we try not to be a software factory that does mostly simple and standard web apps. We like challenges. For example, do you need a research phase because your machine learning project is unique? Good. Do you need an infrastructure that can cope with thousands of requests per minute? Bring it on.
We like to think about the products we are developing. We like to collaborate with product owners. We like to think and view the whole picture instead of just writing code. We like to innovate in the solutions we are creating. We like to put the latest ML research into practice, where it makes sense, to help make a difference.
What was your favorite project?
We have worked on many fun and challenging stuff in our 8+ years of serving customers in the U.S. Answering would be too hard, and we don’t want to hurt anybody’s feelings 🙂
What’s your biggest challenge working with hardware developers?
Historically was the “you have to change this component in the circuitry” because since we are software guys, we would struggle with soldering and wiring. We have overcome this by adding electrical engineers to our team that double as software and hardware experts. We found out that EEs can be very versatile!
How do you stay aligned with your clients needs or goals?
As we mentioned in the prototyping question, we are constantly adjusting and realigning our goals. Remember that we split our work in 2 week sprints and then recalibrate based on what the client considers more important to tackle next. Sometimes 2 weeks is a long time, so we also have meetings specifically to discuss the longer term view of projects, etc. Even if clients sometimes don’t mention their goals explicitly during sprint plannings, etc. we still like to find out.
What do you do to keep the team fresh and excited about what they’re doing?
It’s not a coincidence that when we were asked how our ideal project looks we mentioned we liked challenges. Challenges keep the team motivated more than anything else. Apart from a challenge and not just doing maintenance, trying to take action if a project becomes “boring” (why? what changed?) and mix with formation opportunities such as open courses for learning more about interesting technologies, like machine learning.
What markets or types of products do you see growing in the coming years?
Lately, we’ve been analyzing specific markets where we think AI can have a large impact in the near future (3-5 years).
• Retail / E-Commerce: in this market we’ve been seeing lately high traction with our machine learning services. We think this is due to several factors but we can sum it up with the following ones:
◦ A lot of ML applications for both the digital and the brick and mortar space. For example, recommendation systems for an online store to boost their sales by offering exactly what the user is looking for or physical world analytics to know where the users look when they are in front of a shop window or what are the hot areas where people pass by in a shopping mall.
◦ Opportunities to grow revenue and improve operational efficiency. Since there are numerous large sized Retailers (+500 employees) there’s not only opportunity to boost their sales but to reduce costs (i.e. improve logistics, improve warehouse operations, etc).
◦ Amazon’s threat. In terms of automation, Amazon is way ahead of many retailers and they perceive it as a real threat to their business mid-term. This threat makes these business seek automation solutions now in order to compete.
• Agriculture: the largest opportunity we perceive in this market is due to the rise of satellite and drone imagery + Deep Learning that are able to provide better forecasting models.
◦ That being said, we haven’t seen much traction yet (probably because we are not visible to these kind of companies) and we think that this opportunity is already being tackled by some companies with a high degree of specialization (i.e DescartesLabs & Orbital Insight).
Additionally, we perceive that the API business model is already mature. A model that we think tends to grow is one that either tackles a specific industry (say retail) or a particular problem (say dynamic pricing) all the way through.
What technologies or services do you see growing which would disrupt how we do hardware or software development?
We believe that more powerful devices capable of doing heavy processing such as neural network evaluations on the edge without the need to uploading everything to the cloud all the time will be a reality in the near future. Hardware wise, it will push the industry to have more efficient chips and will pose a challenge with power consumption, heat dissipation and miniaturization. Software wise, it will enable the developers to locally run many things that, until now, were limited to powerful servers in the cloud.
In the near future, we expect to see more capable IoT devices that don’t need an active internet connection all the time to evaluate the data. And this will be a game changer for the industry.
What made you choose the Bay Area / San Francisco as an area to focus your business development?
Back in 2010, our founders had the goal to build outstanding products with machine learning, since they considered it a useful and exciting technology that was also fun to work with.
At that time, machine learning was still not very mature and only innovative tech companies were willing to invest in powering their solutions with it.
It’s not news that a lot of innovative tech companies are based in the Bay Area, thus this was the most attractive market for them.
Fast forwarding 8 years, the Bay Area is still the focus of our commercial efforts. It is where most of our clients are located now (network effect), and also a hub for innovative companies (not only tech!) where demand for ML skills is high. That being said, we have had clients outside the Bay Area: Boston, New York, New Mexico, Tulsa (!), Kansas, Missouri.