While developing the nickel-iron battery, a colleague of Thomas Edison became frustrated at the lack of progress. Edison had completed more than 9,000 experiments with few solutions to the lingering questions.
"Isn't it a shame that with all the work you've done, you've yet to see results?" Walter S. Mallory asked. Edison responded, "Results? Why, man, I have a lot of results! I know several thousand things that won't work."
Ultimately, Edison's batteries powered the first electric cars, but Mallory's skepticism is understandable. With so much time spent and so little to show for it, who could blame him?
This encounter highlights a universal truth in technological advancement: Experimentation, risk-taking and trial and error are inseparable from innovation.
Over a century has passed since Edison was working on the battery, but failure remains as integral to the learning process as it was then.
At Workrise, a culture of experimentation empowers team members to embrace failure — and all the knowledge that stems from it. A data and analytics professional at the company explained why experimentation is crucial for progress and what that looks like in practice.
Workrise is the network that powers the energy industry. By making it easier, faster, and safer to do business in the energy, we are accelerating the pace of growth and innovation, and empowering the industry to do more - both for society and for the planet - than ever before.
How do you signal to your team members that it’s OK to take risks, experiment with their craft — and be OK with potential failure in the process?
Leading by example is key to fostering an environment of taking risks and embracing failure. I share my concepts and unfinished projects with my team and encourage them to do the same. While many projects don’t go past proof-of-concept, seeing unsuccessful and successful endeavors is critical.
For example, the team wanted to build embedded analytics for our software. Instead of a complete rollout, we began with a proof-of-concept that originated from an internal dashboard. We were aware of certain pitfalls such as potential inconsistencies in data representation, issues with scalability and a sub-optimal authentication experience, and had to make initial tradeoffs. Throughout the process, we embraced stumbling blocks as an opportunity to embody our value of “Learn and Grow.”
The team excelled in iterating and getting out our proof-of-concept. Months later, it became a centerpiece of a revamped build, and we were able to take the learnings to deliver a vastly improved end-user experience that’s now fully embedded into our user-facing product. This was a powerful, shared experience that showed how taking calculated risks, with potential failure, can lead to a successful outcome.
We embraced stumbling blocks as an opportunity to embody our value of ‘Learn and Grow.’ The team excelled in iterating and getting out our proof-of-concept.”
Tell us about a time that you or a team member took a risk with their work and it did or did not work out. What was the outcome? How did you or the team benefit from the process?
In the time of “let’s throw a large language model, like GPT models from OpenAI, at any problem and see how it does,” I myself went down this path with a few different internal applications. One of them was around extracting data points from various documents that we have internally, and have already built some algorithmic automation around.
The goal of the project was to evaluate whether or not using a large language model could improve the performance of our existing process and applications. Ultimately what we found was that it could mirror the performance of our existing approach, but we were unable to show that there were tangible improvements to be made with a one-step large language model approach.
I have shown and talked about these projects with the team, and while we ultimately aren’t moving forward with adopting these in this case, it has opened myself and our team up to further understanding where these approaches could be applied. It has also built a pattern for how we could test and evaluate using them in the future, and we are continuing down that path.
How does encouraging team members to be experimental with their craft allow them to learn, grow and develop in the process?
Recently, I was having a conversation with a coworker about an experimental programming language they were building a side application with. I asked why they were working with this nascent language since I didn’t see where it could be applied. The primary reason they work with nascent languages is to understand when it could be applied to a problem they are facing in the future.
What still resonates from that conversation is that in order to apply new technologies or approaches, you need to understand how and when to use them. Hands-on learning in low-stakes situations like side projects, hackathons or one-off non-critical tasks helps you prepare for that.
Being experimental with your craft is essential in progressing your skills and making sure that you are always applying best-in-class methods. For me today, that might look like creating personal data visualizations in a trial of a product I haven’t used before or utilizing a new Python package that came out for a one-off task. Sometimes, it doesn’t end up being something I use long term, but every time it forces me to assess something new and utilize a different approach in my work.
