One of the joys of leading a technology team is the opportunity to engage with many smart, passionate and creative engineers. A big part of my role is to feed off their energy and channel it into as many productive ways as possible.
A Short Trip Down Memory Lane
I’ve been in the tech arena now for almost 37 years, almost the entire time in software. I’ve seen lots of changes in terms of how code is created and managed, how teams operate and collaborate, and how individuals evaluate their careers. "How quickly can I become an architect?" "What does it mean to be a lead?" "How do I grow into a manager role?" "What skills do I need to advance to a senior position?" I don’t think a day goes by that someone doesn’t at least hint at one of these questions!
Back in my days at Microsoft (1987-1998) there wasn’t much concern for rank. I recall my first day in the Unix Business Unit (that’s right … Microsoft sublicensed more copies of Unix in those days than all of the other Unix vendors combined).
The Unix team had a bunch of super smart people. Creating stuff like high performance memory management, along with dealing with issues like process transitions from ring 0 to ring 1 protection (on what were still pretty limited devices) was tough stuff. None of these people wanted to be a manager. Being a lead was cool because it was possible to direct a tiny team, but it also could mean that the developer had a level of knowledge beyond others on the team.
For Developers, the Key Traits for Success are Timeless
It’s an absolute given: technology changes at a rapid pace. Rather than find developers who are experts in the latest programming framework, I always look for solid fundamentals, along with an intense curiosity to learn new things and an extreme fondness for problem solving.
During my Microsoft days, we saw the rise of desktop systems follow multi-user distributed computing systems. The desktop evolved into the client-server paradigm, which necessitated developers to be better grounded in networking concepts.
Later, this gave way to the rise of the Internet and web-based applications. Performance and scalability concerns remained, but were concentrated in different areas of the technology stack. Moreover, new frameworks and programming languages arose, and finding developers who were well versed in things like markup, managed code, etc. became challenging.
We had new development frameworks from Microsoft and "open systems" companies that further challenged our hiring capabilities. For my part, while I wanted engineers with these skills, I opted to hire based on smarts, passion, and creativity. I find that people with these qualities can do anything. A smart, passionate developer can quickly master the latest programming language; however, you can’t "teach" a programming language expert to be passionate and creative.
Eventually, I left Microsoft and worked at big companies like BMC Software and Citrix Systems, and then some much smaller Silicon Valley startups. As we worked on tough problems like scaling UI presentation to tens of thousands of users or managing billions of data files or email folders/messages, developers who were well grounded in architecture and proper coding techniques were sought after. BUT, any developer I hired needed to have smarts, passion and creativity.
Depth is Good, but so is Breadth
When junior members of my team ask me about career growth within Engineering, here’s what I tell them.
In the past, a developer could focus on just the back-end or front-end, but that won’t cut it today. Developers need to be balanced. This includes having decent SQL and/or NoSQL skills for the implementation of database-driven applications. Indeed, engineers with really sharp database skills are in high demand. Similarly, developers who can build highly scalable, performant search or analytics apps are keenly sought for their algorithmic prowess. The latter, in particular, takes us into the realm of Big Data.
Our products must also adapt to myriad desktop and mobile device constraints, so we’ve also had to master responsive designs based on HTML5, bootstrap, LESS, etc. Then there’s the platform itself: our solutions are available on premise and in the cloud.
The latter presents a whole new set of considerations, particularly around bandwidth utilization, network utilization, service framework optimization, database optimization, service resiliency, component management and deployment, testing, service monitoring and much more.
Indeed, the cloud has also brought with it a new class of engineer who is a mixed breed of development and operations ("DevOps"). When unable to find the right person with the requisite technical skills and paranoia (you don’t meet relaxed operations engineers) we have to pair people.
What We Look for When Hiring Developers
So what do we hiring managers look for in today’s developers? I still go for smarts, passion, and creativity. But over time, I’ve also added "results focus." The reason is that, in the end, our company is only as good as what we deliver.
For an engineer, whether this is completion of a module, integration of a set of components, or completing a research spike, it’s all about results. We need people who can get things done, working in a very agile manner. I’m not saying that stuff like research always pans out; rather, I’m saying that it is completed in a thorough and timely manner which coincides with company objectives.
So when I review resumes that simply list someone’s projects or the tools/services they’ve used, I’m usually not impressed. When they write about challenging problems, then they have my attention. If the developer can also demonstrate a holistic, systems-oriented view of their challenge, they get closer to being hired.
That’s not to say that I don’t care about skills in general. A DevOps’ experience with tools like New Relic, Chef, Puppet Labs, Splunk, etc. are very important. That’s like the ante in a poker game for a DevOps role. But again, smart, passionate, creative, results-oriented people can do or quickly learn most anything and help teams meet critical company goals.
Be Honest with Your Self-Assessment
With this in mind, we come to the inevitable questions about career progression. It used to be that in deciding seniority, we just considered a person’s years of experience. That criteria is still relevant, but gets combined with an assessment of an engineer’s problem-solving abilities, leadership skills, vision, and adaptability.
These qualities also pertain to whether someone grows as an individual contributor or a manager. All too often, an engineer aspires to be a manager when they are really best suited to being a principal developer (because they enjoy and are really awesome at coding) or see the big picture as a tight system (as an architect would).
That’s not to say that developers should not be managers; really good managers are hard to find. At my company, technical managers are expected to be very hands-on in terms of working with our products, tightly engaged with team members, and very organized when it comes to task management.
If they demonstrate the ability to envision and articulate technical directions in a meaningful way, they have the opportunity to become leaders: people who set the way forward and don’t just manage tasks.
A closing thought for engineers: it’s all about change. All great engineers love to change things. They are wired to see challenges as problems to be solved, and things that must be changed.
Too often, however, engineers struggle to adapt to changes that occur to them. So my final tip is to embrace change. Those you make and those which happen to you. Your success in this area will ultimately determine how high in the career ladder you climb.