CTO at TrustYou GmbH
January 07, 2019#data-science #natural-language-processing #product #web
I'm the CTO at Munich-based TrustYou, a fascinating company that combines big data, NLP and web development together in one diverse engineering team.
When you look for a hotel on Google, KAYAK, hotels.com, Skyscanner and many smaller sites, you'll see a little sentiment summary above the reviews (“Location is great …”). That data comes from us, and I have the pleasure of both overseeing technology and product development to make this kind of thing possible.
My background is in multi-media computer science, plus I studied technology management at the CDTM Munich on the side. This gave me a combination of skills in visual design (good foundation for product management), software engineering and also knowing how to talk to business people ;)
Going into management was not at all something that I planned, and I was encouraged to give it a try (i.e. promoted) by my bosses, who for some reason believed in me. What they had noticed was that I cared a lot “why” we were doing certain things, and that I was able to motivate other engineers to work on a common goal.
While that’s a good prerequisite for engineering leadership, the actual transition was bumpy. We were a startup, and I didn’t get a whole lot of formal management training in the beginning. Hard to improve if you don’t know what you’re doing wrong! Over time, this improved as I received some one-on-one management coaching, and hired more experienced people whose skills I could steal.
The biggest hurdle to take in the beginning was knowing when I was actually performing well, and knowing when to trade short-term wins for long-term sustainability. Yay, you shipped a product on time, but was it the right decision to accrue technical debt? (The answer isn’t always ‘no’!) You hired a great engineer, but do their aspirations actually align with the kind of work you have to offer?
It took a while for me to accept that coding will no longer be part of my job, and for me to find a way to stay in touch with the technical side of things. In the beginning, I stressed myself out by committing to small sprint tasks in rotating teams, wanting to help in the “time that I didn’t do management”. Since a long time now, I no longer participate in sprints, but actually review code, and dabble in small open source endeavors to stay in touch with coding. Plus I learn a lot from the engaging architecture discussions with our senior engineers.
Since one year, my company now has a very experienced VP of Engineering who has relieved me of most direct management duties, as well as recruiting, allowing me to focus on our product management team.
While a good chunk of my time is dedicated to group meetings and one-on-ones, I actually have the luxury of getting to decide how I spend about 50% of my hours in the week. I find that I work most effectively when I’m able to reflect calmly, i.e. without fires burning in the background, think what are the highest-leverage activities I could spend my time on, and arrange my weekly and monthly plan based on that.
In my first days as a manager, I fell into the trap of complaining that there were “too many meetings”. This implies that a) meetings are bad and you should spend time in solitary work (depends), and b) as a manager you can’t do anything about bad meetings (you can, and actually you must!). Only with experience did I realize that it was my responsibility to establish an efficient organization and communication patterns, that meetings were one facet of that, and that they had to be constantly balanced with emails, documentation, one-on-ones, informal communication etc. This is a fascinating trade-off, and I still make tons of mistakes here ;)
Leading people when you don’t understand in detail how they do their work. As an engineer this is counter-intuitive: You get on a new project, then obviously you first grok the tech stack before you start hacking. Not true for a manager. For a while I thought being an engineering manager meant always having an answer when your team was blocked, over time I discovered that the best way to build a sustainable organization is moderating and enabling your teams to learn themselves.
Obviously you need to have a high-level understanding of the technologies and their tradeoffs (especially true for me since I’m CTO), but let’s face it, the same trade-offs of space, CPU time, human time, consistency, availability, partition tolerance … ;) kind of repeat themselves all over, so with a good common sense of software engineering, you’re actually good to go for most projects, and can focus on learning management, which often isn’t recognized as a formalized skill by young engineering managers.
That you can have a very effective one-on-one just by asking the right questions and knowing when to shut up.
Try to find out if you’re being considered for leadership just because you’re the best engineer on the team. This is a good way to fall into the trap of the Peter principle, and also, if it doesn’t work out, your company will have lost on reaping the value of your engineering skills.
Recognize that management is an established field where you can formally learn a set of skills (not silver bullets though). So don’t “learn by doing” for too long, but find a good book or two on the subject early on. Also, talk to managers from other industries. Sometimes they got the basics down decades ago, while the field of software is just now catching on. You know how the MongoDB kids are excited about new features which relational DBs have had since the 80s?
And finally, seriously consider this move, since learning management skills will make you a more well-rounded employee, human being and maybe even set you up for entrepreneurship.