Starting work at Applied and what Human Driven Development looks like
A reflection on my first few months as a software engineer at Applied.
Starting a new job is an exciting and stressful experience. I like meeting my team and getting to grips with a new code base but as my start date at Applied grew closer, I began to feel a healthy dose of new-starter angst as I reflected on my previous jobs. I recalled the overwhelming amount of information you tend to be bombarded with and the challenging months it takes to become productive in a software development role. As it turns out, however, Applied did an excellent job of mitigating the challenges involved in starting a new role and at short-circuiting the long road to developer productivity through an awesome onboarding process.
Onboarding can be (and often is) a painful process for a new employee:
- You need to quickly form a large number of new relationships in an artificial setting and in a short period of time.
- You must get to grips with a large number of company systems and processes.
- You need to tap into the undocumented ancestral knowledge of your colleagues to get things done, even if you’re experienced in the field.
- In particular for software engineering, you must familiarise yourself with the design and quirks of complex technical systems.
Most companies I’ve worked at have handled this process poorly, such that the experience is overwhelming and emotionally draining. But handling it well and enabling employees to set up positive relationships and working habits can be a great boost to early workplace satisfaction, buy in, and subsequent productivity.
When I started at Applied, I was really impressed with how quickly I felt like part of the team — happy to contribute in meetings and able to pick up ticket work across the platform. That initial anxiety and uncertainty so often tied to the new-starter experience lasted a really short time, and I was able to conquer my imposter syndrome very early because of how comfortable my colleagues and manager made me feel.
To see why Applied’s onboarding works so well, let’s take a look at the pain points associated with starting a new job and work our way to the 3 key takeaways for tackling them.
- Onboarding can be overwhelming
“So here’s your schedule for the first day”
We all know intuitively that it takes a while to really get stuck into a job, and bombarding people with far more new information than they can reasonably absorb and action doesn’t help. At Applied, the prescribed sessions were kept to a minimum and anything that could be learned by doing was learned by doing: no rapidly-forgotten architectural deep dives were scheduled, no report writing tasks were assigned, and training/document reading exercises were de-emphasised except where essential.
Instead, I spent half a day getting set up with our comms and version control software, and then got plonked onto my first ticket. I was encouraged to seek help from open internal forums and pair with other developers (not necessarily those in my own team) in order to get up and running with the app and my work.
This brings me onto pain point 2…
2. Joining a new company comes with a high degree of uncertainty and, in some cases, anxiety
This is the part of the onboarding process that’s most greatly affected by the company’s values. If a company has positive values and implements them in its systems, teams, and processes, it produces an environment where you can quickly stop worrying about all of these unhelpful questions and start focusing on just doing your job.
At Applied, trust and shared ownership were emphasised. I was given access to the systems I needed in order to do my job straight away (which is ok when you have a deployment process that makes it difficult to mess things up ;) and trusted to do what I do best and dive into them.
At the same time, there was a strong understanding reiterated by my manager, team lead, and colleagues that there were no deadlines or expectations for when I should finish my task by. There’s a lot to do when you first start a job and, if you trust the people you hire, you know that they’re probably working as fast as they can.
This is one of the cool parts of hiring using the Applied platform: it provides a high level of confidence that you’re bringing in someone who’s a good fit for the role.
Our deployment process also involves another developer reviewing your code and a third person reviewing your change in a small demo. Once more, my colleagues made it clear to me that if something goes wrong then it was the team that missed it and it’s the team’s responsibility to fix it. This was great for reducing anxiety and gave me the confidence to make several deployments in my first week or so!
There was a strong understanding of the human aspect of starting a new job. For example, I was assigned a buddy from another team who I met with regularly for 3 months. This is excellent because it lets you speak to someone who’s not only forced to listen (🙃) but who is outside of your direct work contacts. This makes it easier to raise concerns and ask for general advice. Your buddy can then encourage and empower you to discuss these topics in a productive way with your manager — or they can point you towards someone else who’s had a similar experience.
3. It’s easy to disengage from the company when you only see a small part of it
“So that other team comes up with work for us and sets a deadline, we come up with a plan for doing the work (it’s going to take longer than we have of course), once we’ve deployed it I’m sure the company will make some money somehow, and then they’ll probably ask us to redo the work we did ‘but better’ anyway” —
Does this sound familiar?
I’ve been in large companies where I was siloed into the backend team where we shared a mutual ignorance of the purpose and daily operations of the surrounding teams. I’ve also been in a company small enough that we knew where everyone was going to get their tan over Summer, yet we only found out we’d be delivering a new mobile app a week ahead of time due to the one-way and strictly hierarchical relationship between the product team and the engineering team. A lack of open, transparent lines of communication led to frustration and disengagement from the product we were building — we just built whatever we were told to because we had no input as engineers.
Structurally, Applied avoids much of the above tension and maximises our enjoyment and passion for the product by combining Product and Engineering teams together. We have separate duties of course, but, when it comes to designing and prioritising features, engineering is heavily involved. Personally, this helps me to care a bit less about the code I’m writing and a bit more about the product and user experience itself. There are suggestions I’ve made that are now visible in the platform, and there are certainly headaches that we’ve avoided because I’ve been empowered to speak up when I see use cases missed in design or features where we can get 80% of the value out of 20% of the work if we make some small compromises.
Onboarding plays a direct role in this process of engagement too. Me and a couple of other new starters were given 1 to 1.5 hour sessions with all the C-level executives in the company (separately), where they explained what Applied does and where we’re going from many different perspectives. Helpfully, they also contextualised our roles and explained not just how each of their departments’ works but how their work influences ours.
We also have randomised weekly catch ups with employees throughout the company using a Slack bot called Donut and are strongly encouraged to reach out to members of the company at any level and in any function just for a chat. Having that kind of freedom is awesome — especially when you work alongside such an interesting group of people — and being able to look at Marketing and think “Ah that’s what Candace does” or look at Sales and think “Ah yeah Ahanah’s got that covered” it makes you feel like you’re part of something tangible. It’s even enough to motivate you when you’re doing the dull stuff (looking at you, yearly reports script).
So what’s the takeaway here?
- I really appreciated being given real work to do early on — it onboarded me in a meaningful way and enabled me to add value to the company right from the beginning. Keeping the compulsory training sessions to a minimum made me feel less overwhelmed and allowed me to gain working productivity faster, while trusting me to do a good job emboldened me to take on new responsibilities.
- Implementing positive company values at a structural, process, and team level rather than in a scarcely viewed wiki goes a long way in engaging new-starters. It helps avoid that compartmentalisation effect, where we broadly know what the values are but we shut off to them over time because we don’t connect with them in our day to day.
- Open communication between and within teams makes it a lot easier for us all to engage with the company at a higher level. It’s motivating when you see how your work fits into the bigger picture, and it’s fantastic to meet and bond with the varied and awesome people that work alongside you.
If you’re about to start a new job, I wish you the best of luck! And if you’re getting ready to onboard a new employee, I hope you’ve found something of value here :)
