The nature of Elastacloud is beginning to change. Most of my advisors and sales team have never written a line of code in their life and yet they're steering the ship. I'm reminded of that remarkable silicon valley episode where Richard Hendrix wants to build Internet 2.0 and his sales team end up selling a box. This cost of our growth is this constant pressure to commoditise innovation and sell a "box" and I'm starting to push back.
As someone passionate about learning and building software it cuts to the heart of things when you spend your days endlessly looking at your bank balance to determine whether your company is performing well enough rather than be elated at writing code.
I decided to write this post to address one of the key concerns I have which nobody who hasn't worked in a software engineering role understands. This is all about key drivers for our devs to enjoy what they they do and keep doing it.
- Money
- Fun
- Learning
- Challenge
Simple techie mantras. When the bottom three in the list are out of whack then the only lever is the top one and it doesn't last long before someone leaves.
Many of our customers have quite a lot of churn in their organisations with technical people and where there's no churn they generally have a poor engagement with their developers. There are generally many reasons for this but we'll dissect my bottom three list for now.
Fun, this is a hugely important part of the day for technical people if you want to get the best out of them. Techies are a tribe, they are nerdy, competitive and have strong gaming spirits. Those that aren't are almost certainly not your best people and will only ever be nine to fivers, if that. Fun needs to be widespread and originate communities both virtual, in hours, out of hours and everything in-between.
In Elastacloud we've helped break the day up, we have an incredibly talented in-house dungeon master who both runs D&D games during lunchtime and teaches people how to be Dungeon Masters as well as use a plethora of other games both digital and paper-based and TTRPG. These games build individual confidence and team cohesion and also break the day up once or twice a week in our customers high-pressure cookers. Recently we had a tournament on Age of Empires, fantasy football and other key initiatives that allow people to break away from their business as usual hell.
The chatter between our people and our teams is rife on all things from pets to retro gaming. This should be inspired. A lot of our larger customers have failed miserably at creating these communities despite the level of investment. They don't grow organically because the work is boring and rinse and repeat that either people have given up or have left. Having customers misuse good devs is the worst, it takes all of the fun from our devs and we have to overcompensate internally. It's a hard line to walk.
As I sent this to Andy to be proof-read he added the following that I pissed myself when I read.
There's a whole bunch of people who are in technology who can't really understand technology. They're they same people doing the same functions in tech that they'd do for a garden centre or the world leading supplier of coconuts, and to them the world of technology is mysterious. And like a medieval villager who uncovers a hoard of Viking gold, they don't think of it as an exciting, fun, source of reward signifying an adventure of investigation and discovery. They look on the golden hoard with fear, for they don't know how it got there, what it all is and what to do with it; and their biggest fear is that someone is going to take it away from them.
Given a new opportunity, they don't share the same joys as a technologist. The garden centre worker fears the opportunity and just wants to water the petunias. When they see someone smiling about a new rose variety that could be created, they respond with fear: "you're not meant to be daydreaming, you're meant to be fetching me petunias to water".
Fun loosens the bullshit above and makes bolder techies.
If we go onto learning next. This is soooo important. I remember in my early career. I wanted to do nothing more than learn every day and everything. I ran out of things to learn in programming and crypto and started writing books to help me discover new features and ways of doing things that nobody had come across.
I co-founded the UK Azure Users Group to learn and put myself out there and spoke about everything. It's how I learnt big data in 2013 by doing talks and workshops on Hadoop. I learnt data science by helping arrange hackathons in 2014 for Data Science London
The techies that don't spend all their time learning in the early years usually end up being plodders in their later years. I met so many of them in the City (finance), vacuous and driven only by money, loud, full of their own shit. They were well-schooled in the bare minimum. Too stupid to learn and understand simple concepts like Agile and also embrace new beta features of .NET and other frameworks.
A healthy zest for learning is key in your best devs, as an example, Andy and I have an internal brown bag shortly called "How to build the Starship Enterprise if I had the money of Elon Musk and didn't want to spend it destroying Twitter". This was a great boon for both of us as we had to school ourselves on dark matter, dark energy, how the fictional warp drive worked (anti-matter reactors, nacelles etc.) as well as Casimir effects, Alcubierre's warp drive, the energy problems and how they had been theoretically solved over time, the horizon problem (crazy effect) and how field thought experiments could have moved this theoretical construct forward. That's what techies do, they seek to understand things they don't know. Giving techies space to learn and create, whether it's through blogs, talks, open source or taught material to inspire makes much more healthy dialogue and in many respects allows learning to be part of a business. The formula is easy, you need to continually encourage people to stretch themselves by showing them what's possible and then making this learning and development the lifeblood of everything you do with yourself and your teams. This needs to flow from the top down in any institution. Scott Guthrie, Bill Gates and others proved this concept that continual learning and development and striving for the art of the possible is a a fundamental key driver.
Lastly, challenge. I spend loads of time interviewing "data engineers". It's exhausting. Real data engineers spend their time dissecting data problems continually. A few of our seniors built some new ways to do internal reporting yesterday because it was something missing and was pissing them off. Our Intelligent Spaces team built a toolkit recently for ADX and open-sourced it because it simplified a bunch of stuff which was hard and they wanted to share it, etc. etc. When I meet new data engineers I can pick up whether they have solved real problems in data and understand the failings of some of our toolkit and how to innovate around issues. I can also sense whether they are monkey see, monkey do and just spend their days endlessly in Azure Data Factory (ADF) "pushing the button" - this is my imagery of repeat activity like in Lost where people blindly put 6 numbers into a console every 108 minutes (admittedly to stop the world from ending). Anybody that's happy to do that we don't want - but you'd be surprised how many people I've met who have spent their career "pushing the button". Challenge is key, good devs need to be challenged daily. When they aren't breaking new ground they will leave.
As I'm going into this year I keep thinking to myself that if I had the luxury of building software day in, day out I wouldn't be able to function if my balance on the 4 pillars were out of whack. I'm going to work hard to make sure that it's working this way for everyone that works for me.