Author at Hiring Engineers (previously Senior Software Engineer at Insider Navigation)
February 18, 2019#augmented-reality #front-end #product #startup #systems-programming
Hi, I’m Alexander, currently running HiringEngineersBook.com, where I’m creating tools and resources that help companies hire great software engineers.
I started this project because I’ve worked with many different software engineering teams. I realized that they could all be sorted into two categories: The ones struggling to hire seniors and the ones that had an easy time. The latter companies realized one fact about our market: When hiring senior engineers, you’re not buying, you’re selling. Based on this premise, I’m now creating tools and resources that’ll help teams hire great people.
Before that, I was a software engineer at multiple smaller companies and startups, usually doing native mobile development. The last company I worked with was Insider Navigation, where we combined Augmented Reality with Indoor Navigation. Working there was especially interesting on a technical level, since the tech stack involved so many different technologies - from low-level computer vision in C/C++ to high-level mobile and web front-end development.
It was a gradual transition that’s still ongoing. I always worked in smaller companies/teams with super flat hierarchies and without clearly defined roles. I just naturally gravitated towards managerial tasks like defining new features, architectural changes, talking to clients and helping to improve company processes. Later I also got involved in hiring, which was very interesting to me. Unlike many developers, I quite enjoy interviewing, and I developed a few short coding tests to help assess the technical skills of our candidates.
At my previous job, every day was different, which I loved. I'd spend time in meetings defining the architecture of our product, do code reviews, define new features, conduct technical interviews and help new team members get started with our codebase. Of course there was actual coding too, but there was less and less of that over time.
This mix of both technical and managerial tasks is something I find quite motivating, since you learn a lot of new things. It allows you to both improve your people skills, as well as your technical knowledge. I think it’s very important to always stay curious about new technologies and concepts, especially in management.
Now that I run my own company, there’s even less coding than before. When getting started, most of the tasks are marketing related. Thankfully, this can still be surprisingly interesting, if approached with the right mindset. I used to think of marketing as this sleazy and manipulative thing, until I realized that in essence, selling is just results-driven communication. You can totally do a great job at marketing your product while staying honest, which is super important to me. I think that’s also one of the most important qualities when working with people.
For me, making decisions about the direction of a product is often extremely difficult. There’s a reason why product managers are the highest paid workers in Silicon Valley, it’s a tough job. When deciding what to do next, there are so many options to choose from. It’s often hard to see what will have the most impact.
When you’re by yourself, initially this is a bit easier, since you can take your time and weigh your options carefully. But as soon as other people depend on your decisions to be able to do their work, things get stressful and it can feel like there’s a lot of pressure on you to make decisions quickly. It took me a bit to realize that the important thing for keeping others motivated isn’t actually making the decision, but instead clearly communicating your current state in the decision making process. Explain why the decision is hard, what the options are, and what your current reasoning is.
Once you realize this, it gets much easier - you empower your team mates to help you in making good decisions. You shift the mindset from “I have to give them the answer” to “Let’s figure this out together”. This is way more productive and motivating.
It was surprising to me how difficult it is to give clear instructions when delegating tasks. From the point of view of an engineer, I often got quite annoyed when people failed to give me clear requirements. I used to think “Why didn’t they give me that bit of information in advance? It’s obvious that I need it to do my work!” Well, now I understand that it very often isn’t obvious what the other person already knows. Communicating what the end result should look like is very hard. People don’t automatically know what you want, even if you have a clear picture of it in your head.
And then the old dilemma of delegation shows up. How can you explain what you want without it taking more time than doing the thing yourself? To explain a problem to someone else, you often have to fully understand it first, which is already a large part of the solution. I think this dilemma is why the best leaders try to empower their team to make critical decisions on their own. If your business falls apart when you’re not there, you’re doing something wrong.
When you adopt this style of management, one downside is that it becomes quite difficult to feel the progress of your work. You might have a great conversation with a team member, which really helped and motivated them, but they often won’t explicitly tell you that. Maybe they didn’t even consciously notice it themselves. I’m sure there have been evenings where I felt terribly useless even though that day was super productive.
A great manager I previously worked with once said that “The decisions I make should ideally never surprise you. When I make a decision, you should completely understand why I made that decision. Even if you disagree with my reasoning, you should know how I came to the conclusion. This requires a lot of honesty and transparency on my part, but it allows you to make decisions on your own when I’m not here.”
Other than that, a lot of the old clichés are true: Work hard on constantly improving yourself, listen more than you speak and most importantly, practice empathy.
I recommend reading Dale Carnegie’s ‘How to make friends and influence people’. Don’t be put off by the title, it’s not at all about manipulating people and much more about empathy. More related to software engineering, I recommend reading the classic ‘Mythical Man-Month’ by Fred Brooks. Good places are also Joel Spolsky’s, Michael “Rands” Lopp’s and Paul Graham's blogs.
If you’re considering the switch, the good news is that in many smaller companies you don’t have to go all-in. You can test the waters by gradually taking on more responsibility and still spend the majority of your time writing code. Engineers who are comfortable with management and also have great technical skills are highly sought after.
In any case, keep in mind that when moving to management, your job is to entirely define yourself in terms of the productivity that you enable in other people. Your job very much becomes a service job. Being a manager doesn’t by itself give you any more authority. People don’t work for you, but rather you work for them, trying to give them all the tools and resources they need to do great work. This can be stressful, but also very rewarding at the same time.
Come over to my blog and sign up for my low-volume newsletter. I regularly send out free advice on how to hire great engineers and engineering management in general. There’s also some really cool new products in the pipeline. If you have any questions or want to chat, you can also send me an email, I’d love to hear from you!