Beyond Code: Exploring the Role of a Senior Engineer
Recently, I was part of a project where, for over a year, as a Senior Engineer, I was not allowed to write code.
The setup was complex and, as consultants, our role was to strategize and interface with the client, all the implementation was going to be done by outsourcing and staff augmentation vendors. So my manager explicitly told me "you cannot open a text editor, if anything you can only review code". This was a challenge for me, this was the very first time in my entire career when writing code was not part of my responsibilities, in fact, I was encouraged not to.
Even though I once wrote about Software Engineering being more than just coding, in this case I had a hard time making peace with the idea of not writing code at all. Looking back, I think I added value in many other ways during the time I was in the project.
Reviewing technical documents for non-technical team members
This was the first thing I saw I could support with, there was one of our Product Owners who was overseeing a technical team in charge of building a very complex setup for Customer Identity and Access Management, she's completely not technical, I mean, she has some idea of how things work, but digging deep into the tech world was not her strength. Because of this, she had the impression her team was taking advantage of her and stretching the deadlines to add more slack time.
She was constantly asking for technical documentation and architectural documents and questioning about the time to deliver and her technical lead was always explaining something in terms she did not understand. When she finally got some documentation about the software they were building and the architecture, she didn't understand it too much so she asked me to review it.
I've always thought that, as Software Engineers, we have knowledge disparity work in our favor, we deal with very complex topics not everyone is able to grasp quick, technical terms and fancy words and acronyms that makes it very easy to make others think everything is super difficult and fool others into thinking we are working hard, when in practice we are just researching or doing something that isn't actually difficult to do.
Technical planning and architecture
This wasn't a very obvious one, while our team was outsourcing technical talent who was supposed to be in charge of all the technical things, we were supposed to define, scope and digest and put everything in shape for them in a very organized way. So, all grasping and understanding the current architecture, seeing where the flaws were and helping the team coming up with a better approach was another challenge I had the opportunity to tackle. Of course, not alone, we had a great and very experienced Chief Architect with us who developed the initial concept from the ground up and then breaking the monster into smaller pieces and strategizing how to build it in an iterative way was another battle to fight.
In my case, the initial DevOps design, branching and integrations strategy and, after, giving clear requirements to the technical team to implement was something I didn't do before and found super valuable as the team was able to clearly understand what had to be done and executed it as expected. Again, not alone, I had a very senior DevOps technical lead who helped me put everything in shape and developed all the building blocks in a very modular way, which made it easy for new members to pick one part of the system and work on it.
Enabling and supporting other team members was another way I found I could add enormous value to the project. Because I already had a relation with the many of the client's technical teams, I could support other team members in reaching the right people to support solving the problem at hand in a timely manner.
Documentation and knowledge sharing
Coming up with top of the line engineering practices to be implemented in the client was something else I didn't think of as valuable, but turned out to be interesting for many people, specially technical folks. Architecture, DevOps and some other Engineering practices turned out to be not as common as I thought. Efficient ways of working and team alignment processes. Documenting all. technical and people-related processes and approaches and then sharing them in workshops was something very interesting to do, specially when it involved coaching some of the client's technical leads to do it themselves.
Generate, document and share was another way I saw I added value, sitting in a room with other engineers or product owners, discuss people processes or technical topics, put it on paper and then present to the relevant teams or stakeholders was something I didn't do before at this scale and also something I deeply enjoyed.
Cross-functional team collaboration
In a project where the core of the activities revolves around technical development and hardcore engineering concepts, to truly collaborate between different teams, the communication must be clear and precise in terms of what's needed. The ability to foresee issues in a given approach as well as tackle dependencies ahead of time so they don't become blockers lays on the grasp of technical concepts and engineering expertise.
Aligning in technical approaches with other technical teams and communicating the implications to Product and Business teams so that they adjust their deliverables accordingly was another thing I found myself doing on a daily basis
Streamlining communication
This was an unexpected one for me, I thought I was going to focus more on getting the most out of our engineering teams, not in terms of squeezing them, but more in terms of efficient ways of working and communication. But I turn out to have an ability to translate technical jargon into human language so non-technical team members can understand it.
Most of the time, when we were having issues, the reasons were purely technical and the non-technical Product Owners and specially the Partners were unable to fully understand what was happening and, hence, unsure about what to do and how to make a decision based on the information they had. I found myself multiple times explaining technical concepts behind the issue at hand and suggesting, from a technical perspective, what had to be done, using analogies from the real world or other fields they were familiar with.
Final thoughts
When not behind the code editor, Engineers can become real enablers for everyone in a technical project. I felt I was producing more code than ever, just not with my own hands. Watching the teams fly on their own building what was designed, planned and coordinated weeks ago was a magical thing to witness while planning and coordinating the activities 3 to 4 sprints ahead.
This experience was a complete eye opener and I feel like it widened my view of my own role in Engineering teams and the way I'll approach non-technical folks in future.
