What every manager must know about developer happiness
A demo with a client this week got me thinking again about happiness. More Specifically, developer happiness and the story of Swimm. When we founded Swimm it was clear we came to solve a pain that any developer or engineering manager was more than happy to confirm: It’s a hard and long process to onboard a new dev team, and a new codebase. It takes time, a long time (we’ve heard from managers that in some cases it takes up to a year!), and it is…well, painful.
We surveyed engineers in over 80 companies and quickly did the math*:* if you are an organization that onboards 100 developers a year and it takes an average of 4 months to onboard them, then as the engineering manager in charge of those developers, you’ll lose approximately 30 years of contribution, which sounds astronomic by all measures.
Armed with this simple but efficient formula we started working on the concept of Swimm, we raised initial funding and built our MVP. Once we started being in touch with CTOs and engineering managers, we pitched our magic formula and started to test Swimm with design partners.
A CTO of one of these partnering companies said something that made us, the founders, move uncomfortably in our chairs. When it was time to set up the KPIs for this pilot, we were (as well trained entrepreneurs seldom are) ready for the classic sales formula… but then he threw this curve ball: ‘Developer Happiness’.
Of course it was important for him to reduce the ramp-up time for his new hires, of course it made sense for him to find a better solution than the classic code documentation that becomes so quickly obsolete, and of course he wanted to find a solution to streamline their remote onboarding process. But these were not his main concerns. First on his list, was actually the very reason why we envisioned Swimm: Developer Happiness.
Simply put, we almost missed calling it by its name. Yes, of course it was part of our ‘why’ when we began this journey, but without noticing we almost morphed this ‘why’ into a math formula. Because developer happiness is hard to quantify and pin down, it’s easily overlooked and forgotten. But it is directly linked to the tools that ease your everyday work .
To this CTO though, it was clearly at highest priority. His cyber-security start-up had recently hired a few developers and for some of them, the process had been far from ‘happy’. Being onboarded onto a new codebase, on a new team is a tough human journey. How difficult can it be? Don’t just take our word for it, ask your developers.
Tomorrow is my first day on the job.— Martha Sharpe (@SharpeMartha) June 29, 2020
Excited to meet the codebase and feel totally overwhelmed and incompetent.
Such is the life of a developer. 😎
ME: learning takes time and it's important to be kind to yourself— bletchley punk is a fullmetal engineer (@alicegoldfuss) June 30, 2020
ALSO ME: wow it's been 2 weeks and I can't recite every moving part of this sprawling legacy codebase, throw me into the trash
But we entrepreneurs and managers invest so much time and money to source and hire the very best developers. We pay them the highest salaries, invest in their personal growth, present the swaggiest swag, the most photogenic happy hours and really the best food. And there is a reason for that: they are the magic-makers, the builders, the ones who execute our vision.
As in any relationship, true happiness is achieved through real, deep, meaningful investment. While it’s true that bringing your spouse flowers will get you a nice evening (though not guaranteed), or a fun vacation will create nice memories, it’s only through day-to-day dedication, deep investment in another person’s well being, and personal development, that they will flourish in a long-term relationship. The same goes for your developers, you can’t expect them to be on the front of your company, to fight your most important battles and not to truly and meaningfully invest in them.
Building the right training for your new hires is truthfully no fun at all, (the swag is an upside, I’ll admit), but building tutorials on your codebase for example is a hassle. However, throwing them in at the deep-end and asking them to swim without the right tools for success is another way of saying: “we want you to do your very best while we do what’s easy for us — paying you and hoping for the best”.
If you do invest in the happiness of your developers, they will pay it forward. Not only by being efficient and by contributing better code, but by becoming truly devoted to the company and its goals, because in a true long-term and happy relationship, you are ready to fight to make it work and when it gets hard, you don’t break.
To learn more about Swimm, sign up for a 1:1 Swimm demo.