Recently I was promoted to an L7 IC (Individual Contributor), an "Organizational Leader", at Square.
I'd announced this on Twitter and various other medias, and am truly thankful for all the love and support I've been getting from the community over the last few days.
In some of the replies there was a very interesting question:
What exactly do you do?
This post will take a look into exactly that. It will cover how levels work at Square briefly, and then go into my personal path starting three years ago at the company.
Levels at Square
This will be a brief overview rather than a comprehensive look at Square's process, but sets some of the expectations for the following sections.
Square is very public about its leveling system. In fact, they published a post on their external blog on their philosophy which you can find here:
https://developer.squareup.com/blog/squares-growth-framework-for-engineers-and-engineering-managers/
Inside of that post you'll notice a link to a spreadsheet which contains the actual descriptions of each level's criteria:
These levels do not strictly correspond to concepts of Junior, Senior, Staff, or otherwise. They can be, but I won't do that in this article.
Instead they seek to reflect the scope and domain one is expected to perform at in each level. Engineers, specifically, start at L3 as they're expected to have some experience and training going in.
To give a brief list of each IC level's scope:
- L3 - A New Engineer with Potential
- L4 - A Solid Contributor
- L5 - A Strong Independent Contributor
- L6 - A Team Leader
- L7 - An Organizational Leader
- L8 - A Company Leader
- L9 - An Industry Leader
Currently I'm considered an L7 IC, an "Organizational Leader", or someone expected to lead engineering efforts across an entire organization. In my case, platform engineering.
That all said, let's take a look into how exactly I got to this point and my personal path.
Square
Towards the end of my tenure at Playstation I figured out that one of my IRC friends, @eam (Evan Miller), actually lived close to me. We met, chatted, had coffee, and eventually he said the magical words: "Hey, you should come join us at Square!"
Granted it took Evan a year to convince me to make the jump, and a lot of coaxing along the way, but eventually I took the jump and decided to interview and eventually join Square.
It should be noted that before Square I'd had issues as an autistic programmer, and if you'd like context into that I'd written on article on just that:
https://dev.to/baweaver/tales-of-the-autistic-developer-senior-developer-3l0c
L5 - A Strong Independant Contributor - 2017
I was hired on at an L5. This is the stage of one's career where you're expected to be able to own projects and deliver them independently, write designs, and start to help mentor others.
What Was My Job?
Most of my work here was around leveraging Ruby and Javascript expertise to solve problems on the Developer team. My main focuses were around going deep and solving hard problems.
Thankfully my management chain introduced me to the concept of selling my work, doing presentations, and getting more into the external community.
When Did Transition Start?
It was around half a year in that I convinced Shannon to join with Developer Evangelism which was probably one of the most pivotal moments in my career there. Me and Evan had been on the Ruby IRC channel for years, and havenwood (Shannon) had been around just as long if not longer, so we talked him into joining us.
He convinced me that all that expertise I had swimming around in my head would do much better if I started talking about it more. That was the start of me speaking at more meetups, participating in the external community more actively, and eventually drafting the first ideas for what would later become the Lemur talk series.
Through this my job evolved from being a strong contributor to being able to lead others along with me and level them up as well. I was more actively involved in teaching, speaking, and making a presence for myself on Twitter.
He also convinced me to start writing more tutorials, leading to many of the articles you see here and on Medium.
What Caused the Promotion?
Through all of those transitions I also started to see a larger picture starting to form of how our related teams worked. In the above post I mentioned "coffee time" with various team members, and through that I started to gain an understanding of various parts of the organization.
Once I had that picture, I was able to spot fires more easily at a team scale.
My team was dissolved after around a year at Square, and I agreed with that decision. Our projects were being transferred to a new team, but that new team was just hired, creating issues with how they were going to deliver without being onboarded onto our internal solutions.
I raised this concern, and then volunteered to delay transferring to a new team until this was resolved. I flew to Seattle to help onboard the new team, great engineers by the way, and get them to a point to where they could deliver on our requirements for the quarter. They got everything done and more, and are still doing a great job up there.
Taking initiative here and putting out that fire at the team level was the key item in my promotion to L6.
L6 - A Team Lead - 2018
While L5 is expected to be self-sufficient, an L6 is expected to start leading more than just themselves, including teams of more junior engineers to help guide larger projects.
What Was My Job?
My first transitional role was on an operations team, and didn't quite work out as my unix knowledge was not quite strong enough to really cut it. Eventually another team came along called Frameworks, and after a conversation we decided it would be best for me to pursue that role instead.
This team was chartered to work on language level architecture and lead our language communities at Square.
In Ruby we already had an organization of volunteers known as Ruby::Core, and I would contribute to their solutions and tried to work more actively with them in this new role. Frequently I would help to solve some of the more difficult problems dealing with Ruby internals and help to teach more internally on how to do the same.
My speaking, writing, and other external activities were ramping up significantly during this time, to the point to which I had spoken at RubyConf, RailsConf, RubyConfAU, and several other major conferences in the Ruby community. This was about the point where I started to become very visible externally to the Ruby community.
When Did Transition Start?
One of the largest problems with expertise is there are more problems than you could ever possibly solve that you have insight into. You start to get a lot of visibility as you mature as a more senior engineer, but the curse is you can never possibly handle all of it.
Early on I wanted to solve it all myself, and as I matured in the role I learned to delegate out to others, to teach, and to level up those around me to get them to positions to where they could handle the issues that I'd found and qualified.
I started to take more delight in growing others than necessarily solving problems myself. It took a while but I could finally disassociate my idea of success with directly doing and delivering on work by myself.
Granted I still feel some guilt around not doing it myself, but I have to remind myself that that's selfish and creates bastions of knowledge which can severely hamper the progress of other engineers in the company.
What Caused the Promotion?
Because of that shift in mind-frame I landed upon a project which likely pushed me over the edge for promotion. It affected the entire company, north of 27 teams were involved, and was a task that had taken two years to the last time it was attempted. This project was something else, and with it came a whole new class of difficulty, and there wasn't a chance I could hope to solo it.
So I didn't.
I scoped out the work involved, talked to senior management, highlighted the risk factors, and gave them a solid list of what we needed to successfully finish the task. This ended up spanning close to 30 teams, 12 dedicated engineers, and various representatives across the company.
We delegated out work and helped to steer the direction of the project, maintaining high visibility with status reports and amending our requirements for teams to evolve with the growing understanding of the project.
Did I code? Yes, but I focused in on areas that were blocking the teams and helped remove blockers on more difficult and nuanced issues. By doing so it freed me up to focus on the entire project and to counter larger issues and negotiations as they were necessary.
In the end we delivered the project in around half a year, a good year and a half ahead of the time the previous attempt took.
L7 - An Organizational Leader - 2020
As an L6 I was expected to lead at a team level, once I got to L7 I was expected to expand that to an entire organization if not the entire company in certain cases.
So now that I've crossed that line what is it that I do as an "Organizational Leader"? Well that's going to take some discovery, but this section highlights a lot of the things I currently do in my role. It is by no means a comprehensive list as much as a brief insight.
Politics
Defining Standards
I help to define standards across the company through Ruby::Core as well as through various other language groups. We try and qualify existing options, interview teams, look into external offerings, run tests on those options, and make recommendations on what to use for various tasks.
Sometimes this also involves defining standards for process such as upgrades, deprecations, and other such tasks.
Negotiation
The larger the project the more likely that I'm going to need to do a lot of leg work talking to people before hand. This means talking to managers, roadmapping, making sure to time things appropriately, and giving them something tangible they can plan around.
Work at this level for me is political.
By merit of my visibility of the organization I can see things others might not, and it's my job to raise that awareness and projects that might be discovered from it. The terrifying thing is I'm expected to go out and find problems; that's a lot of discretion and power to work with, it's also a lot of potential to cause significant damage so it has to be used wisely.
There's still work for me to do here, and I actively seek mentorship to be more effective in it. I still have a lot to learn here and in other areas.
Networking
I'd joked in previous articles about getting coffee all the time and talking to whoever but this has been absolutely critical to my role. Through those breaks I meet new people, find out what they're working on, and through whatever level of visibility I have sometimes I end up connecting them to others to do some great stuff.
Sometimes this is external as well on Twitter or various other sites. Sometimes that turns into recruiting, though very rarely if ever will I bring that up unless someone explicitly mentions it or I know of a really great role I could see them in.
More often it ends up being a great friendship, a trading of ideas, and a lot of great knowledge gained.
Teaching and Mentoring
Teaching Classes
I wholeheartedly believe that teaching is necessary for growth of an engineering organization. Institutional knowledge contained in the heads of a small set of senior engineers leads to fragility, fear of review, and inevitably the loss of that knowledge should they move on.
To that note I teach and help others teach various Ruby classes at Square around book clubs, topical interests, square internal offerings, and other topics we learn from internal surveys of our developers. These classes are taught across the company.
I'm currently working on a system to spin up classes taught by other engineers by providing templates, resources, recording options, and otherwise linking people up to deliver on even more content.
Mentoring
I enjoy talking to people about their careers, and how they're doing. This has led to mentoring multiple engineers of all levels, and helping them advance and find ways to improve their careers. That said they're doing most all of the work, there're some really incredible people here, and all it takes is a small comment and away they go to really do some amazing things.
Personally I love to see others grow and succeed and realize their potentials, so I intend to do this as much as time allows.
Producing Content
Writing
If I can't find an article for something there's a good chance I write it. If there's a new feature I happen to see fly across the bug tracker for Ruby I try and get something out for first impressions once I become aware of it.
This has ended up with a significant cache of articles on Ruby topics from entry level to very advanced explorations of topical interests. Some of these even become conference talks later.
Recently I've taken to teaching writing as well, but that's a newer endeavor.
Speaking
If a topic gets a lot of interest and if it really takes off I tend to submit it to a conference as a talk. Of course me being me it typically involves some form of story and a group of magical talking lemurs teaching Ruby. I've ended up speaking at RubyConf, RailsConf, RubyConfAU, Let's Sketch Tech, Southeast Ruby, RubyHack, WaffleJS, internally at Square, and several other meetups.
Through this I end up meeting a lot of really amazing people in the industry and made some really amazing friends along the way.
Some of this network has even led to new coworkers and potentially other job opportunities I never would have known about before. That said I intend to stay put for a number of years yet.
Representation
Mental Health
I'm autistic and ADHD. Because of that I function differently, but I also have some insight into the problems people like me face.
Because of this I work with leveling and hiring to make sure we're more inclusive of mental health issues and give people like me the best chance to succeed that we can.
My goal is to write and speak about my own struggles so that people like me are able to find some hope and direction in their own careers that I may not have had when I started.
In pursuit of this I'm working, at the time of writing, as a global chair of neurodiversity at Square to facilitate more of these discussions at a company scale.
Programming
Expertise
Now to start, I dislike calling myself an expert. When I joined my current organization my director had come over and greeted me with "So you're the Ruby expert!" and I wasn't quite sure how to take that one. There's probably a significant amount of imposter syndrome here, but Shannon and Evan mentioned above both snapped me out of that one and helped me to embrace this a bit more.
What this means to me is that I've seen a few things in my career, and because of that I can solve some problems others can't or would have great difficulty doing.
These can be things like optimizations, legacy code refactorings with touchy APIs, automated code refactoring, research projects, and any number of other things.
The trick is that I have to be willing to delegate these tasks to others to allow them to build their own expertise. Continually fixing everything myself would be creating another knowledge silo, and my ultimate goal at Square is to automate, document, and tool myself out of existence as much as possible.
Wrapping Up
There is an important disclaimer here: There are many paths to this type of level, and mine is one of many.
I still have my weaknesses along with my strengths, and there are a lot of engineers internally I rely on and respect. It's not a solo effort, never was, and never will be.
So where does that leave me? Well you might notice that there's only one section here that explicitly mentions programming.
More often than not I'm not writing code, and in many cases I feel a lot of guilt around that as I've tied my identity and productivity as a programmer to writing and delivering code. Some at my level do write a lot of code, I'm not always one of them.
This has been an interesting transition for me, and there's still a lot to learn in this role, but that's a brief overview of the work I currently do in this role.
All that said I very much enjoy my role here, and will very likely be staying for many years to come. Who knows, I may even end up pursuing principal roles here in a few years, but that one is well beyond me for at least a few more years.
There's a lot more I intend to do in the future with my role, and a lot of potential around it.
I look forward to what the future brings, and if you'd like to join in on that feel free to DM me @keystonelemur on Twitter some time about roles at Square!
Top comments (1)
Really great article (and series), Brandon. Square seems to have a good growth path for engineers.
One thought, about expertise and being seen as an expert: to me, an expert is not only someone who can solve a variety of problems, but can also explain what they're doing to other people, which you amply do.