So Long, and Thanks for All the Pandas
BigPanda IL Office, 2018
After three amazing years, my time at BigPanda and a significant chapter of my professional life, has come to an end.
During this time, the organization grew from a 30-employee startup to a well-established ~120-employee company with many Fortune 500 enterprise customers - and I matured with it.
I transitioned from an individual contributor to an Engineering Manager. I had the opportunity to learn countless important lessons, in various fields, from Product and R&D, through management to sales and marketing.
It would be hard to share everything I learned in just one blog post, so I’ll focus on 3 major lessons. These takeaways also reflect what’s special about the company and the excellent group of people I had the pleasure to work with.
1. A Culture of Transparency
“I have never regretted sharing information with my colleagues and employees”
- Elik Eisenberg
This is a quote BigPanda’s Co-Founder and CTO said to me during our first meeting. I remember thinking: “this is nice lip service”. Little did I know.
Fast-forward a few months, we had a cross-site meeting to discuss the company’s core values. Transparency was the one undisputed consensus in the room. It became so deeply rooted in our culture that we naturally practiced it everywhere in our day-to-day work.
Here are several examples:
- The vast majority of documents are open to everyone. This includes the Product Roadmap, deals progress and sales status, marketing plans and more. The only restriction was on private employee records.
- Postmortems after production outages are shared, both inside the organization and with the affected customers. This open approach increases the trust and confidence of the client.
- The OKRs of all the departments are shared, as well as the business unit’s KPIs and outcomes.
I honestly believe that practicing active transparency helps creates an open, constantly-improving culture of learning within the organization.
2. Software Innovation
“There are different ways to do innovation”.
- Mark Zuckerberg
During my last months with the company, I had a rare opportunity to work on a truly innovative project together with a team of brilliant and motivated engineers.
It was very far from the idea I previously had in my head of what software innovation was. And in retrospect, that’s the reason why it was such a monumental lesson.
Our company set a course to solve a challenging problem. The “Why” was known, the “What” was an abstract draft and we certainly didn’t have a plan for the “How”.
A few months after we had a beta version working in production, with half a dozen enterprise customers using the feature.
I could dedicate a whole post to how we pulled this off, but here’s the gist of my takeaways:
- Discussing the problem with as many people as possible leads to game-changing ideas. We’re surrounded by smart colleagues, why not take advantage of it. Our solution came up from a short conversation I had in our kitchen with one of the best Engineers I had the privilege of working with.
- You don’t necessarily need a fully written spec. Innovative projects don’t have to be planned in detail for a long time or orchestrated by a Product Manager.
- It’s OK to kick off the project with a basic validation.
- Don’t worry about starting without a clear technical definition of done. Many factors will likely change before you reach the final goal.
- Innovation features tend to last long. to lower the chances of that: iterate fast, accept failure along the way, and strive for early users’ feedback.
- If your team’s solution requires convincing specific stakeholders, make sure to prepare the strategies and tools to advocate for your idea. A good rule of thumb is to be able to articulate how your approach fits the organization’s agenda.
3. A Business-First Approach
Probably the most important lesson of the three, and an idea that was easier for me to acknowledge working in a startup that’s fighting to stay alive (like most are).
As Engineers in tech, it is easy to fall in love with a cool technology or a specific set of tools we use, and forget about the broader mission.
The company’s business goals should be the ones driving the technical strategy, which in turn drives strategic architectural initiatives.
Don’t make decisions just for the sake of using that shiny new framework that the cool kids are talking about.
It all comes down to moving the needle. At the end of the day, R&D and Product organizations exist to solve business problems.
The more our Engineering teams understand the broader context they’re better capable and empowered to make decisions.
“Induce Product Mastery: being proficient not just with the tech and codebase, but with the business aspects of the product as well. Invest in making your team understand what they are building…”
- Aviv Ben-Yosef
On a more personal note, to all you Pandas, I want to say thank you 🙏.
I am proud of what we’ve achieved together and am confident in the ability of this winning team to continue to innovate, deliver an excellent product, and achieve outstanding success.
#AlwaysAPanda 🐼
My first team at BigPanda (right to left): Dafna Rosenblum, Idan Cohen, Erik Zaadi, Ron Sherf, me and Oleg Mostepan
I hope you find these lessons helpful.
If you have any comments or other insights please share them below.