Do you know what it takes to be a CTO?

We start our careers at the bottom of the stack trying to cope with all the assignments, pushing trough the overload of information to grasp some knowledge from the seniors. We have the luxury and it is expected of us to make all the mistakes and we bare almost no responsibility for it — if the code breaks, the person sitting next to us will fix it.

Than we go up a level and we know what we are doing (almost!), we tweak and we refine code, we are actually starting to use some of the best practices that we used to only read about, we are the people now that can share a bit of wisdom with the rookie. We still do mistakes all the way, but maybe we cover ourselves now most of the time.

The next stage comes when we feel nice and cozy in environment that we have worked in for years, but also when we rise above the mundane daily code problems to the more strategic view of the things, and we get included in the new feature talks, or we are asked to shape the architecture. We are probably responsible for other people as well. At this stage the wrong decision, or a mistake takes longer to repair, and cost more money.

As the level goes up, the tasks get more abstract, and we gradually shift the management vs. coding percentage in our tasks. We are more and more supposed to create value for the business with our actions, and not just perform the vision of the others.

That can be quite challenging for a somebody that has almost purely software developer background. We can easily spot the leap from absolute beginner to junior developer, from junior to a senior developer, from senior to lead developer, but how does one become a CTO and what would that mean? What is expected of us, and is that a role we really want to take?

That is why we organize Stacktrace. At Stacktrace, in a friendly and informal atmosphere CTOs go deeply into the technical stack and explain how the scaled, justify their choices and share their failures and mistakes. Beside the technical scaling, a company scales in employees, code management etc, so management tasks increase greatly. How do we deal with that?

At Stacktrace, you can hear advice from experience like this:

Do it piece by piece. Trickle between the urgent forward moving steps. For every 3 or 4 days that you spend adding code, spend one day cleaning up. Done with something at 3pm or 4 pm? Don’t start something new, but spend the rest of the day cleaning something up. Grab “to do” in your source directory and go, but, have boundaries.

Once you start refactoring something you will inevitably find another thing close to it one layer of abstraction above or below and you will immediately want to expand your effort in cleaning one bigger chunk in one session. This is when you can easily get lost out of scope and blow up the problem. Try and stick at only one issue at a time, and make sure you get it done. Do the other thing tomorrow. By consistently applying this, frequently doing small steps, with emphasis on frequently and small, you might manage get to eliminate the biggest and most obvious problems and prevent them from hitting you on the head later on.

Also, try and have the courage to remove features and delete code. Some features might not turn up as exactly as you hoped, but you might still try and keep them around as they may add some value here or there. You should consider simply removing it in order to allow you to focus on the parts of your product that actually move it forward. As a benefit, by removing the feature you’ll also remove code that you don’t have to maintain any more and you won’t spend time refactoring the code and also you won’t spend time fixing test of a piece of code that isn’t actually used any more.

That was said by at Oliver Seemann, CTO ADSPERT during his presentation at Stacktrace RC.2.

To hear more about how they manage the huge amount of data and their special choice of database architecture, as well as more advice on how to lift a startup from the ground up, check out the whole lecture:

https://soundcloud.com/webcrowd/stacktrace-berlin-rc-2-mp3

At Stacktrace RC.3 we had Ramzi Rizk, from EyeEm, telling his story. Listen the talk below.

https://www.youtube.com/watch?v=yXgfEZ8nUc0

Next we have Stacktrace RC.4 at Wooga, and we have their CTO, Jesper Richter-Reichhelm, speaking on how Wooga does it. You can ask question, and get to know their offices.

If you join the Meetup group, you can suggest a person to speak and we will try to make it happen for you!

See you at Stacktrace!