The DIY movement in IT – what does it take to succeed ?

A few days ago, my friend Frank Scavo wrote about the pendulum starting to swing from commercial software to custom built software .  Today morning, I listened to his podcast with another common friend Den Howlett .

I would highly encourage you to read Frank’s blog and listen to the podcast. The movement to DIY is real and I am seeing it in the field too. It is something I have wanted to write about and now is as good a time as any. I would like to focus on just a few aspects I have seen as critical to the success of custom building software at scale.

Do you have the right BRAND  to attract the top engineering and product talent ?

There are not a lot of talented software engineers to begin with. Attracting those few good people – be it a fresh CS grad or a veteran developer or product manager – to your company takes a lot more than throwing a lot of money at the problem. Your company may be the best retailer, or bank or automobile manufacturer on the planet.

Do these engineers you are trying to hire know of you as a place that works on cutting edge technology – and all that comes with it like great techies as your colleagues, modern work spaces, a thriving tech community and culture , cool perks and so on ? Do you have credibility in the market as an employer who invests in training people to keep up with the changing market ? Building that brand is real hard work and it takes significant time and investment . It is not a commitment you can make lightly.

Do you have the endurance to move from a project culture to a product culture ?

I have already posted my misgivings on IT shops using agile and scaled agile , so I will spare you those here. But in general – what sets apart professional software shops and rest of the world is the focus on products as opposed to projects. That is a culture shift that won’t happen without a lot of painful – and continuous – change management effort. Hiring has a direct influence on the culture .

The two largest pools of talent are other IT shops (commonly people jumping for better roles and $$) and SI companies ( commonly people who may even be willing to take a small pay cut if need be, but want to get out of their road warrior lives)  – both largely made of people who come from a project oriented background. May be ten years from now, this won’t be an issue – but today it is a definite issue.

One more thing while we are at it – If your team is global, are you willing to make the remote teams self sufficient and fully empowered and not just order takers from HQ  ?

Will your cutting edge team have the staying power?

If you are modernizing your IT function to enable a largely DIY culture – your economic model will probably need teams to be self sufficient on dev and ops, as opposed to one team having all the fun developing cool stuff and another doing the grunt work supporting it and answering the pager.

Will your software engineers hang around long enough if they are woken up at 3 AM by their buzzing pagers ? Do they have the skills to continuously automate ( the SRE types ) ? As you build follow-the-sun teams across the world – will your engineers have the skills and patience to work with people who are across time zones ? As you become more geographically distributed – will they be ok being further removed from the users for whom they are building software ?

Do you have a stress tested strategy for talent pipeline and IP protection?

Just as you want to build an awesome team, your competitors want to do exactly that as well . It is a lot cheaper to pay more $$ for your top tech talent than identifying them early and grooming them for a long time. Even if you are an amazing employer that checks every box, you have to assume a certain level of attrition.

Hence there are questions to answer about the supply chain for talent all the way from entry level to top levels in every geography that you operate. If there is anything more painful than attracting top engineers – it is in recruiting a top notch tech recruiting team and letting them do their job (often radically differently than what you have done traditionally).

Can you balance fun and discipline in engineering ?

Software development is not traditional engineering – developers are more artisans than engineers. On the good side, you will have plenty to choose from their creativity. On the not so good side – only a handful of engineering managers can balance it and eventually ship on schedule. Every good engineering team loves to create and evangelize their frameworks – and what they probably love even more is tearing down everyone else’s frameworks. I am as guilty of this as the next guy or gal.

The battle of frameworks goes like this typically – a new manager notices his teams are using 4 different frameworks . He brings them together and after a lot of debate they agree on a common framework . A few PIs later they find that they now have 5 different frameworks.

Needless to say – you need strong engineering managers, and ideally they are not repurposed from another function to fill a role.

So, can it be done ?

Despite all these uphill challenges – all this can be accomplished and to various degrees I have seen some companies do a decent job with modernizing their IT based on a DIY set of principles. I personally don’t know anyone who is still not struggling with it. The ones doing it better than others are the ones with extremely strong CIOs with the full backing of their CEOs (which is not common), and their boards (even less common).