Engineering Growth

I was recently asked to prepare some statements for new hires at my company about engineering growth.

What does it mean to grow as an engineer?

This is a very personal question. The “right” answer seems to be “to increase your impact”. In reality, this often means working on projects with larger scopes that cut across multiple teams, doing more collaboration or systems design/architecture, and frequently less deep dive coding. But, just like not everyone wants to go into management, not everyone wants to coordinate across 3+ teams to get something done. That’s what makes this personal. Fortunately, especially at companies with a deep tech stack (e.g., infra/distributed systems), it could also mean understanding a particular area in extreme depth and becoming the go-to expert for this area.

Ultimately your goals are two-fold: you want to become the leader for a particular area of the product and/or tech stack and you want to drive it to market success in a way that is meaningful for the company.

Let’s break this down:

• Leader – This doesn’t mean a title or position. It means that you’re the go-to expert, and that you have a vision for where the product or tech stack should be going, backed up with data and other supporting evidence. Most importantly, you know why this is the right direction and can communicate it well; you understand the benefits it will have to the team and/or the company. You continuously solicit feedback from your colleagues and industry at large to refine this vision, and collaborate across the company to ensure buy-in. And you successfully drive execution, either directly by your team, or by influencing other teams and their roadmaps.
• Product/Tech Area – This could mean a single long-term project or product area, or it could mean a quick succession of small but meaningful wins. But this depends on where your product is in its lifecycle; the small rapid wins works well early in a product lifecycle, but to really advance in a more mature business or to the higher levels requires long-term ownership of an area meaningful to the company.
• Market Success – It could mean a project that boosts the top line revenue, or decreases costs to boost the bottom line profit. It could be that it improves customer onboarding (thereby increasing the trial-to-customer conversion rate), or increases retention (thereby increasing the customer lifetime value). It could be that you create or re-work the major test suites to improve quality and decrease the number of incidents, or that you identify security risks and mitigate them before an attacker finds them. It could be that you improve developer tooling, increasing productivity so that developers can ship features faster.
• Meaningful – There’s a lot of things that companies care about, and they evolve as the company matures. In the early days, its traction and product-market fit. Once you have some marquee customers, it becomes about stability and quality, expanding feature sets and reducing operational risks. As you mature, it becomes about operational efficiency, improving your margins, and profitability.

What are the top 3 things you think impacted your career? Tips, fundamentals, areas of focus, etc?

1. I encourage every engineer to learn design patterns, that it’s one of the highest ROIs you get as an engineer. Languages, frameworks, and toolkits come and go over an engineering career. But design patterns are adopted and adapted through them. This starts with some fundamentals inside a single component (e.g., immutability vs concurrency patterns) and then progresses to patterns and designs that span multiple components (service-based architectures, techniques for avoiding cascading failures, level-based systems, actors, events/streams) until you reach a point where you can conceptualize entire systems.
2. Another thing I advise that always sound very “old man” of me (even though I’m only 32) — understanding the history of technology is important. I don’t mean like the evolution from gramophone, to record, to CD…. Rather, what problems were service oriented technologies trying to solve? What did they do well at, and what problems did they create? What’s the difference between traditional config management and managing configs in containers? Why is Docker so popular, and what problems was it solving? What about k8s? What about streams, or functional programming? What kinds of problems is nodejs really good at solving, or golang, python, java, etc. and why? Really these things are just higher-level versions of fundamentals taught in CS school: what sort of problems is data structure X or algorithm Y best at solving. Understanding the why on these things is critically important to making the right decisions from first principles, and leads to higher quality software.
3. Lastly, stay curious and prioritize learning. People understand that with investing, your money compounds every day. It’s the same with learning. If you spend a little bit of everyday learning and perfecting your craft, you’ll be leaps and bounds ahead in 5 years, and a totally different person in 10 years. Every time I move to a new company, it feels a bit like starting over. When I joined my current company, I didn’t know golang, docker, kubernetes, terraform, multi-cloud deployments, and so on. So while interviewing, I was on the lookout to see if I felt my future coworkers would be both smart and caring, both good teachers and good learners. This sort of “you teach me, I teach you” relationship enables the whole team to grow together. And as a result, we’ve all gained the experience of bootstrapping a new multi-cloud SaaS product from the ground up built on these very technologies.
4. OK, here’s a bonus 4th tip. Remember that technology serves a purpose within a business. It’s a means to an end, not the end itself. If you can help bridge that gap between “what the business needs” and “what the technology can provide,” you’ll do well. A lot of technologists get caught up in the cool tech and miss the big picture. Always think of how does this benefit the company? As I’ve become fond of saying, “just because you can doesn’t mean you should.” Instead of thinking about individual tasks, think about the end-user experience. What problems are your customers trying to solve? What steps will they have to take with this proposed solution? What gaps will still exist? If you can speak the language of the product and that of your customers, your job will be that much easier. You’re more likely to build the right thing for your customer and your company.

Tell me a story about a period in your career when you felt like you grew the most.

When I started at my first company after school, it was a Series A-funded venture startup and I was a very early engineer (number 9, if I recall). All the other engineers were significantly more experienced. Our CTO and VP Eng had built and sold a company to Google (and then worked there for several years), and the other engineers were all very high-caliber. And I was just a kid out of school, so I had a ton of learning to do.

One of my first roles was working on a system to move a lot of data integrations (javascript “tags”) from the browser to send the same data server-to-server via APIs. We planned to build 100s-1000s of these integrations over time (and we did). One of the senior engineers had already built a POC using Apache Camel which was totally new to me. So, instead of just building “around the edges” on the framework he provided, I wanted to understand how Camel worked thoroughly. I knew we needed to make these integrations far simpler than they were to reach the scale needed for the company, and to do that we had to rework how we used Camel. So I started learning Camel from scratch to thoroughly understand this technology; I created a new Camel-based project, did a lot of different tutorials, made sure I understood the core components and knew what existed so I knew where to look more when the needs arose. And this understanding put me in the position later to help drive the first version of our zero-deploy style integrations, which was a huge leg up for the business.

Unfortunately, this youthful curiosity is sometimes lost over time. I encourage all engineers on my teams to hold on to it or re-discover it. This is vital to understanding engineering from first principles, which is necessary to continue growing as the technology industry evolves.