Experimentation
Welcome to another week!
I hope you had a good weekend and got some rest. Writing practice is always good, and in general, it has helped me understand what I'm thinking and better sell my ideas to other teammates.
I've been reading the book Smart Business(affiliate link*) for the past few weeks. It talks about what makes Alibaba a "smart business" and several examples of how this concept allowed them to scale to the behemoth they're now. In general, it's a good reading, but I become interested if there's something that I could apply rapidly at work.
That idea got me thinking about the idea of "proof of concept" and experimentation in general.
Make it easy to experiment
Have you ever thought about what it would take you to make an experimental service or a proof of concept? And in how much time? In my case, the experiment is taking longer than I would want. There are a lot of hoops I have to go through to get the service running in production.
When I initially scoped the proof of concept, the idea was to simplify the implementation as much as possible while allowing to iterate quickly. I got the basic idea locked up, but it took way longer than expected when I turned to make it to production.
The set of steps I had to follow took me through a journey of figuring out why some of the steps were in that manner or why some of these steps were needed. Generally, in large companies, you must comply with multiple departments like CyberSecurity, Production Operations, etc.
Organizations must allow people to experiment and create a proof of concepts to become prototypes for future capabilities and features we offer customers.
Just enough scope
One of the first things I come across when an organization is not used to experimentation, in general, is that people have differing views on a scope.
People like to go over things like what would happen in the theoretical future. This thing becomes "formal." That implies our experiment becomes the actual feature customers would use.
In reality, if you're building a proof of concept or a prototype of some kind. It's better to consider these artifacts as disposable, effectively throwaway code.
Internal discussions
These proof of concepts are meant to drive discussion, help other stakeholders avoid imagining things, and help people materialize what we're talking about.
First, it should help you and the team determine if the thing is feasible. Is building or scaling it to our customer base worth the investment?
Buy-in and approvals
Another good thing is that you can take these prototypes and have discussions when needing to get approval for getting this project approved and ready to start building.
These approvals can set up a team, have a formal slot in the roadmap, and report updates in the regular status update meetings.
Streamline the process
As a staff engineer, I see experimenting and creating proof of concepts as part of my role, helping teammates and other stakeholders know the value of ideas that might be worth pursuing if aligned with the business goals.
The other aspect I will focus on in the coming weeks is simplifying the process to scale the experimentation mindset across the organizations.
Are there steps we can simplify? Are there steps we don't need? Can we get the data or traffic in some other way? Is there a way to make them low-risk?
Your turn
Can you experiment at your current organization? Is the process easy enough for anyone to bring ideas to other stakeholders and sell them accordingly? How are you working to promote new ideas at work? Let me know by replying to this email.
Happy coding!
Things I discovered in the past week
- A Twitter thread about "Move fast and break things" is outdated advice for startups. And how this team did a "different" thing to reach success.
- I've been slowly reading The Effective Executive (affiliate link*)
- Tweet: Promotions are measured in quarters. Failures are measured in years. Therein is the problem.
- Been waiting for part 2 this year, but in the meantime, Why you should read Dune.
website | twitter | github | linkedin | mastodon | among others