How to build an IT organization?

Frequently I receive requests mainly via linkedIn from people asking me how I built IT organizations during my various roles in various companies.

I’ve also noticed that a lot of start-ups as well as existing businesses are struggling to hire the right people for their IT department. This problem is not only related to tech companies but applies to all industries.

In this article I’m presenting my personal opinion based on a long working history in roles as chief architect, CTO, CIO, CSO and a lot of other O’s. You don’t have to agree with me, but please continue reading maybe you learn something that might help you in the future.

A typical startup

Many startups are started by a person with a business idea that they think can change the world. Sometimes the founder has an IT background and more often they don’t.

A typical approach is that the founder is starting a search for a co-founder with an IT background that will act as the Chief Technology Officer (CTO) of the company.

Many founders are between 20 and 30 years old and their co-founders (CTO) are also in the same age range, which is cool but also makes that the management of the company has a limited business experience after graduation.

The main task of the CTO in a startup is to build a Minimum Viable Product a.k.a MVP.

Based on the CTO’s experience, knowledge and personal preferences, programming language, software platforms and tools are chosen, where the main driver is what do I know and can use to start immediately and do this quickly.

When the hiring process for employees in the IT department is started, the search criteria will almost always include knowledge of the programming language and tools that have been chosen.

What’s in a role’s name?

I see daily job listings posted on sites where companies are hiring software developers, software engineers, front-end developers, back-end developers and full-stack developers. In the requirements you’ll see things like PHP, Java, Vue.js etc, etc. These are all skills that can be taught to people if they have the right competences.

So what’s a Software Developer?

In my opinion a Software Developer is a person that can write code in a certain programming language to solve business problems that have been worked out into some kind of technical specification. Many of them don’t have a real education in Software Engineering like a Bachelor or Masters in computer science.

They will spent some serious time on Google and Stackoverflow to find solutions for specific problems they’ve never dealt with before.

The code quality is often inferior since they are lacking the basics of software development like Object Orientation, database design, dependency injection, separation of concerns, refactoring, testing, etc.

The emphasis in their resumes is on the programming language(s) and frameworks they’re acquainted with.

You can’t blame the software developer, they just have had the wrong educational background.

And what’s a Software Engineer?

A software engineer has an education in computer science and learned all the basics that are relevant to build complex systems. With sufficient experience they can develop systems to match your requirements quickly, scalable, tested and maintainable.

Of course they are proficient in one or more programming languages, but because of their education, they can adapt/learn a new programming language in a very short time since the difference is often only in the syntax and structure not in how good quality software is developed.

How to hire the right people?
The interview process

Nowadays it’s popular to have a technical interview asking the candidate from the top of their head if they know all the popular buzz-words and standard questions.

I’ve never interviewed this way since the actual knowledge can be evaluated with a coding test. My interview questions are always about the person.

• What makes you happy?
• What keeps you awake at night?
• What do you expect from me as an employer?

If you feel a good connection with the candidate, it’s time to move forward to a coding test, if the candidate is just looking for another job, please hope your competitor will hire them.

What about coding tests?

Many companies use a coding test to evaluate the skills of a potential hire. I’ve done with every hire I’ve made in the past (1000+ of hires all over the world).

The reason for the coding test I’ve used was that I wanted to filter Software developers from Software Engineers, since I only wanted to hire Software Engineers!

The coding test is a four to eight hour test that someone can take offline in their own time, but they have to submit it within 24 hours after they’ve received it. Besides testing knowledge, I was also testing for accuracy and consistency. Some requirements I use in my coding tests are:

• You’re not allowed to use external frameworks (for iOS and Android engineers), purpose to see if they understand low-level native networking protocols instead of using a third party framework and try till it works.
• I’ve provided strict naming conventions for classes, methods and variables as well a style guide. If a candidate delivered a perfect solution yet the naming conventions where not followed, it was a no-hire.
• Unit tests for each class and method. You’ll be surprised how many that call themselves software engineer never written a unit test or understanding a test suite.

The programming language

There are many programming languages available, and I’ve worked with most of them over the past 35 years. The choice for the programming language and possible framework you’re gonna choose for your company is very important and really depends on what you’re trying to achieve.

From experience I can tell that the language that was used to build the MVP is often not the best language for the next generation of your product.

With the MVP the main target was to deliver ASAP a working system with limited functionality, so as mentioned earlier the choice is often made based on the CTO’s own experience and preference.

However the mid- and long term goals are different, hence become a sustainable business. Criteria you should take into account when selecting the programming language and framework for your next phase are:

• Scalability → if we grow to millions of users, can we scale up?
• Availability of resources → can I hire Software Engineers in my area that are proficient with this language.
• Proven → is the choice a proven one? a new language will have a learning curve and a lot doesn’t come out of the box when you open it.
• Performance → can it handle your expected traffic/resources?

The database

Each system need a database to store information. For decades a relational database was the main option to choose where information was stored in tables contained fields of a certain type.

Couple of years ago noSQL database’s where introduced and I saw many companies jumping on this, just because it was cool and new.

noSQL database make perfect sense in many cases however if you’re developing a system that handles transactions (like orders, invoices) and also has some serious reporting requirements, my advice is to use a relational database.

The importance of designing a database model is something that’s always underestimated. I’ve worked with thousands of software engineers during my career but haven’t seen more than a handful of engineers that where really good at database design.

A poor database design results in bad performance, bad code and a steeper learning curve for new hires.

Freedom of choice

Do you allow your software engineers to make their own choices on adding external packages, frameworks, services, etc?

In today’s world where agile has become the way of working it implicitly gives a lo of freedom to the software engineers.

I strongly advice against this since it can compromise your mid- and long term goals and have a serious impact on your cost of operation.

Recently I had to organize a company’s IT department that had given freedom to all software developers (they didn’t have engineers). During the initial survey I’ve discovered 6 programming languages, 5 frameworks of which one deprecated for 2 years, 56 external services and nobody understood the complete eco system.

After bringing in a real software engineer and jumping on the wagon myself and reorganizing and optimizing the operational cost where reduced with $1.4M/annual in just two months.

Offshore or Onsite?

I’ve worked onsite for many years and also build about a dozen offshore engineering teams for various companies.

The main difference between offshore and onsite is the physical presence of the people, putting more emphasis on standardization and communication. Another difference is the cost, where offshore is always cheaper in cash-out but not always in return on investment.

If the offshore team is not managed correctly and managed on deliverables the results might be inadequate.

I’ve build offshore teams in Vietnam, India, Afghanistan, China, USA, Ukraine,Belarus, United Kingdom, Australia and Europe all with different success.

Ukraine and Belarus have become my favorites, good work ethics, high quality engineers, never complain, affordable and reliable.

What about age?

It’s cool to have a group of people that are around the same age. Often in startups the average age is between 20 and 35. It’s nice to have a group of people with a similarity in age since they are often in the same phase in their life.
However adding an older engineer to your team, bringing more experience is a very positive thing.
The older engineer already made all the mistakes in their career that the younger group still has to make. The elder will learn modern stuff from the youngsters where the youngsters will learn from the elder to develop with performance and optimization in mind.

My first commercial software I wrote at age 15 on a Sinclair ZX-81 with 56Kb available memory, that was it. Nowadays even the smallest electronic device has a multitude of that available. This enforced me to write efficient high performance code that was continuously refactored to fit in the available memory.

Conclusion

Building an IT organization contains a lot more aspects as you might have considered before reading this article. Since each business is unique there is no standard approach or solution.

My general advice however is:

• Only hire Software Engineers and no Software developers!
• Only hire A-players.
• Don’t make your MVP choice the strategic choice for the future just because
• Don’t give to much freedom, but provide and explain the mid- and longterm strategy to your engineers.

First published on my medium page https://medium.com/@petervandeput/how-to-build-an-it-organization-709bf2e75308 in July 2019.