Build your company the same way you build the best products
The methods that we use as software developers can be highly impactful when applied to HR, business operations, and life in general.
As a software engineer, my career path was always clear to me: Senior dev → Team Lead → VP etc. I am writing this blog post today to say that this is not how things transpired. In fact, today, for the first time in my 20-year journey as a developer, I am developing without using code. I am developing our most important product at Simply (formerly JoyTunes) — our company.
That said, I am still using the methods that I learned as a developer, and that all developers know too well. Let me explain.
Go where the impact is
At Simply, we approach building our company the same way we approach building software products, using methodologies used in product teams:
- Data driven thinking: Raising hypotheses and testing them against data, A/B testing.
- Agile: Setting work goals in short iterations, OKRs
- Lean startup: Releasing ideas as quickly as possible, building what is needed, talking to users, working with an MVP.
I’d like to give an example of each to show you how we tackle all sorts of problems using these methods, to show you how these methods, that are so obvious and natural to us as developers, are incredible tools for solving problems and can bring significant value to other areas of a business, and life in general.
This text is a shorter version of my talk at Reversim Summit , where I speak at length about Simply’s unique company (full recording below). You can also read more about it in our CEO Yuval Kaminka’s blog post: Scaling the Small-Startup-Get-Things-Done Mentality @ JoyTunes.
- A/B Testing in talent acquisition
In our talent team they recognized that many job titles are quite vague and weren’t sure which job description would attract the most relevant candidates. When looking through LinkedIn to see what jobs it would offer me, here are just some of the positions I was targeted with:
- Senior software engineer
- Senior software developer
- Software development engineer
- Senior principal engineer
- Principal staff software engineer
To be honest, I don’t really understand the difference between them.
What would we do when developing a feature in a product? Test it! So why not test the job titles as well?
Our talent acquisition team took two job titles that describe what we are looking for, and tested which one worked to attract the candidates who were most relevant to the position: 1. Senior Mobile Developer or 2. Senior Software Developer.
They may seem different but they are the same position and job description and the exact same day to day work. Just the title is different. We did not just test how many people applied to each position, we also looked into the relevance of the candidates for the role, so we could see which title attracted the most relevant candidates.
The test ran for a couple of months until we had the results we were looking for, and we now work with the title that won:
This basic methodology helped us improve our reach to relevant candidates.
Key learning: Use A/B tests when possible. It will help you improve your bottom line.
2. Agile: A company offsite is just like a product feature
It’s probably quite obvious to you to work with agile methodology, whether it’s SCRUM or Kanban. You probably retro your work every now and then, and use best practices to improve your sprints. But outside of product teams, this methodology is anything but obvious.
At Simply, we apply this software development methodology to (almost) everything we do:
- We work in short iterations, aka sprints.
- We have regular customs that allow us to break things up into small steps and minimize risk as we move forward at speed.
- We even have a company retro. That’s right, a retro for the whole company. The topics range from how we can do better, to expanding our offering to new verticals, to how we diversify our hiring or improve the WIFI in the toilets.
Recently, one of the company retro notes raised the concern that as we grow as a company we lose the intimacy that we once had and this affects how well we work. There are many ways to tackle the problem of lack of intimacy on the company level. We mapped out the resources and risks of each and came to the conclusion that the best solution to this problem would be to plan an offsite.
Applying agile and product thinking to a company offsite may not sound intuitive, but it works really well. Here’s what we did:
- We made sure we understand the problem: Lack of intimacy and how it comes into play.
- Assessed the impact and effort and decided on the best solution accordingly.
- Interviewed the “users” to understand what sort of behavior leads to intimacy, or blocks it. As part of this process, we held 3 group sessions presenting ideas to get feedback and improved the plan accordingly, starting from the proposed date, to the suggested activities while away, to the actual location of the event.
- Then we thought of what would work as an MVP and started testing it, iterating and improving it until we got “product market fit” and felt certain it would meet our objective.
The results: We recently returned from the retreat and the responses were beyond our expectations. Every activity and setting was optimized for increasing intimacy and from the feedback of our team, it really hit the mark.
Key learning: Agile is a great way to take a big problem, break it down, and gain confidence that you’re on track to solving it with the plan you’ve put into place. This is as true for as it is for software products, and an offsite is effectively just like a new feature in an app.
3. Lean startup: Testing our way from JoyTunes to Simply
Now let’s look at another example of how this thinking can be implemented, this time from the marketing world.
We recently launched our new brand Simply. When we started planning our rebranding, we discovered that most branding processes work something like this: You think about a concept, get approval for it, and then roll it out across products and channels hoping that it resonates.
In other words, branding is not usually done in iterations. But it can be, and that’s what we did at Simply.
We used OKRs to break up the branding process and build it from the ground up, rather than top-down. We started with a minimal viable product (MVP, or in our case MVB — a minimal viable brand!) so that we could get feedback from our audience, and rolled it out in iterations. This helped us build confidence that what we were building would meet out objective and resonate with our audience and our team.
We started by releasing an android version of the new brand in one of our products and iterated from there. We also worked with a model that enables us to test the fit of our brand — like product market fit. We call it story audience fit, and this is what we are testing as part of our released MVP, looking for measurable indicators that our brand story resonates with our target audience, such as surveys, 2nd day retention rates and 30 day retention rates.
Objectives in HR and branding are not easy to stick to and most of them are seen as fluid. But if you don’t break up the long term objective, such as an annual hiring plan, into short term key results, you may get to the end of the year without hitting your target and you won’t know until it’s too late.
Key learning: Lean startup thinking can be used across the company, and point out the fastest and most effective way to achieve your goal. To dive deeper into our lean rebranding methodology, check out this blog post by Nadia Hitman, who led the process.
The challenging road ahead
We’ve seen in some examples how product development methods can impact areas in your organization that aren’t traditionally seen as products. But it’s not a copy paste solution for everyone. These methods demand looking at problems with an open mind and a willingness to learn. I found that if I don’t go into the meta and stay on very practical terms, I am able to get more buy-in and accelerate solutions and adoption of this methodology.
My main message to you is this: Don’t limit yourself to developing using java or iOS. Your toolkit is so much larger and if you think outside of the box, it can make you incredible problem solvers in other areas as well, at work and beyond.
I’d love to keep this conversation going, so If you have any questions or comments, feel free to reach out to me via email: lital@hellosimply.com or on Twitter: https://twitter.com/LitalHassine
