I cut my teeth during my first decade of my working life experiencing the software engineering job family, starting as a junior engineer in 2000 and working my way up to principal engineer by 2010 (and then spent eight years from PE to CTO, then switching down to engineering manager in 2021). In between senior engineer and making principal engineer, I switched from coding to software engineering management and project delivery. Just before going back to technical, as a principal engineer, I was performing at the level of a senior technical program manager and software delivery owner for a very large software stack.
I was fortunate to have worked for pure software product companies in that time, focused on consumer applications as well as infrastructure systems. The companies were led by people with an engineering background, CEOs/VPs/Directors with PhDs in the sciences, who had practiced as engineers before getting into leadership positions. As such, the culture of those companies were very engineering focused - leaders took the time needed to develop clear guidelines for career planning and development. The job family framework NDS created was super helpful in level setting expectations with engineers and managers alike. People had a map to reference, removing the ambiguity and suspicion that often comes with promotions. A clear job family framework, in my opinion, is a must-have for any engineering organisation because it provides people with direction to chart their career path. It is an extremely powerful mechanism especially when the company is diverse and allows a spread of career options. Having this map allowed me to experiment with different roles myself, switching between business units and trying roles out, until I figured I'd explored enough or reached my aspirations.
I'm talking about years 2003 to 2011, working with what was at the time, the world's leader in TV software and encryption systems, with offices world-wide (NDS/Cisco/Synamedia). I left that company with solid engineering management experiences and upon returning to South Africa, was well positioned to help raise the bar of engineering excellence. Surprisingly, more than ten years later, working in Amazon AWS, I marvel at NDS's high bar in the early 2000s - pretty much working now for Amazon AWS, I'm pretty much picking up from where I left behind in NDS from an engineering excellence perspective, I'm glad I schooled with NDS.
When I led one of the largest consumer device initiatives in the history of that company, in 2011-2013 - I was quite surprised that the engineering organisation was missing a vital mechanism for its engineering workforce: The Engineering Job Family guidelines Career Ladder. As a program manager without much direct hierarchical influence, all I could do at the time was provide feedback to engineering leaders about the quality of their engineers and managers, as not meeting the high bar expected from the industry. I influenced quite a bit of change indirectly, helping overhaul the entire technology division's structure and engineering practices that was needed to get the program delivered. However, I couldn't do much about the HR guidelines when it came to job specifications. Instead, I wrote a blog post about my experiences and shared this with the HR/Tech executives in 2013.
Here's some proof of the indirect / referent influence I had as a program manager overhauling the engineering org, that if we didn't do would've cause the project to fail:
When I branched out on my own doing management consulting, I was invited by the business HR & Tech executives to talk more about the technical career ladder framework, which I picked up from NDS days.
[P.S. I'm sharing material I created as a management consultant. If you'd like a copy of the frameworks, please reach out to me via my contact page.
Disclaimer: I write about my past work experiences to showcase to prospective employers, future clients if I decide to consult again. I'm publishing my work portfolio so that recruiters / headhunters or hiring managers have easy access to my work products, saving you time. If you like what you see, let's talk!]
I created this slide deck to talk about the concepts:
Naturally, the company wanted me to provide examples from industry that applied similar concepts. Drawing from my previous experience and pulling information by re-connecting with my colleagues, I showed my client a model that Sky (who is the seen as the best in the world of PayTV) & NDS engagements looked like:
I also created a template for what the Systems Architecture guidelines and freely gave my material to HR to use (incidentally, the HR person has taken this framework and introduced it to other companies):
Accompanying the technical requirements for the job, we also had a competency framework. This was quite powerful in terms of making clear expectations of behaviours, attributes and other culture values:
Creating a new structure for my engineering org - reset career ladder
In 2017 I took over the mantle as engineering leader for a large technology platform with the job of turning around the platform and raising the bar on software engineering excellence. Under my leadership there was at least 100 engineers that I was responsible for. Finally I was in a position where I had direct control and influence to lead the changes I wished for so many years go since returning to SA in 2011 and seeing the opportunity that awaited to help my new company level up!
So I went to work with HR and my senior managers, and then created the following job guidelines for software engineering in my org. As a result of my initiative, HR took this to other tech divisions, created a unified version across the group company for technical roles. In addition to the software engineering framework, I introduced new job families covering "Agile Specialists" - a novel way of capturing a broad agile competency than the textbook scrum master / agile coach roles.
Before the job family framework, the org was flying blind and couldn't offer clear direction for new and tenured engineers alike. Promotions were hit and miss, resulting in suspicion, rumour mongering and other misplaced assumptions that wasn't healthy. With a clear framework showing the levels and bands, managers were now equipped to have meaningful conversations with engineers on their career pathing, as well as having clarity on compensation related questions. The framework folded in nicely with the business-wide job levelling and grading, aimed at providing a level of consistency and transparency.
I find it interesting that years later, I'm working with Amazon, who since NDS - I can say have raised the bar on job levelling guidelines. Amazon makes all job roles, families and guidelines available to every employee. The job family document takes the form of a narrative that explains the context of the role, where it fits in relation to team/division/org/business context, and also shows how to move from one level to the next. For example, if you start as a junior engineers, L4 SDE 1 - from Day One this engineer has enough information to understand what it will take to get from SDE 1 to SDE 2 - because the job family documents provides the map. I've never seen anything like that before! And what's more remarkable is how Amazon handles promotions. Managers and individuals have to work on a narrative promo document - referencing data points and customer anecdotes / testimonials as a way to market the promotion. Then the promo doc is reviewed by a diverse group of managers and senior individual contributors - to ensure we calibrate against the wide population of engineers and also insist on maintaining the high bar...promos are not the discretion of just the direct manager! It's amazing, super intense and demands a lot of attention to detail on the manager and engineer... At NDS we didn't go to that extreme, but our managers had to write at least a 1-2 page recommendation, along with taking feedback from other sponsors too.
No comments:
Post a Comment