Budgets aren't boring
And here’s exactly why you should get one.
There are many aspects of a job as a Software Engineer that are not concerned with the quality of the code that you write. As you begin to level up from a junior to a mid-level Engineer, one of the things that you may find yourself doing more often is taking responsibility for the development of individual features. At Cleo, this is an opportunity that I have been afforded and supported in pursuing through our culture of trust and commitment to personal growth.
We're gonna score that victory.
Doing so will require a different set of skills to what you might have been used to previously; you'll need to have more of an eye on the bigger picture, a deeper understanding of why you're doing what you're doing, and an idea of what success looks like for the project as a whole.
I joined Cleo almost 3 years ago, back in March 2018; it was my first job as a software engineer. In that time, I've had the opportunity to take the lead with individual features, and learned a few things along the way.
Before the build
The most important thing to understand before you set out to build something is understanding why you’re doing it. Without that understanding, you'll have no compass to guide you when things inevitably do not go according to plan during the build. Ask yourself the following questions:
Are you trying to learn something? If so - what is the thesis you are trying to validate?
Are you trying to scale something? If so - what proof do we have that this is something we want to scale?
What will the challenges be in scaling this? Are you trying to pay down some tech debt? If so - what do you want it to look like by the end? When will you stop on the endless road of refactoring?
Thinking about these things up front can save you from wasted work and uncomfortable retros down the line. They'll also help you identify the people who can help you most in this project. User researchers will be great at helping you to discover something about your users, but probably less helpful in rewriting your notification infrastructure to scale to your next million users. Any new software feature is not just the work of Software Engineers, but the culmination of efforts from a wide group of people across different disciplines. Ask for help so you can be as successful as possible.
During the build
As you progress along the path of building Transformational New Feature™️, there'll be a few things to keep front of mind. First: communication. Make sure that all stakeholders, from other Engineers working alongside you, to your Product Owner and anyone else invested in this project has the right information. The same technical detail you share with your fellow engineers is probably more in depth than what your PO needs, but they’ll probably want a heads up of any stumbling blocks that might push back the completion date. More broadly, this is a part of making sure that the team is empowered to deliver. Make sure the team has the knowledge they need to be able to work autonomously - which means alignment on why, details in tickets (not heads!), and proactive communication.
Another thing to be conscious of is any follow-up work your team will need to do after this project has shipped. For an MVP, or features on a tight deadline, you might cut corners that you may need to come back to; do you need to? Why? But follow-up work is about more than simply paying down technical debt. As Engineers in the weeds of the project, we can identify what opportunities there might be to easily experiment with other things. For an engaged development team, it'll be valuable to capture these suggestions and think about how they get prioritised in The Backlog.
After the build
Yay! We made a thing! Happy days! So the question now is - how do we ship this? What QA have we done on The New Thing™️? Once shipped, what evidence can we see in the database, or other sources of information? What is the error monitoring like? How will we know that it is doing what is intended - not just that the code is behaving as it should, but that your team is achieving what it set out to at the beginning of the project? If you're A/B testing the rollout, when can you expect to see statistical significance - and if it's a while, what leading indicators might there be that you're on track or otherwise? As developers, we're not just code-writing machines (otherwise GTP-3 would have our jobs); we have a responsibility to take full ownership of what we create to ensure that it has a positive impact on the world. (lmao this line is super wanky i hate it it makes me sound insufferable)
See you around?
If it’s not obvious until now, I am writing this blog post because we’re looking to hire Engineers at Cleo. We've got an incredible team of driven, talented, and ultimately kind humans, working towards our mission of improving the world’s financial health. Check out our open roles or drop me a message on LinkedIn if you wanna chat about life at Cleo (or about either of Taylor Swift's 2020 albums) 🤙
