Oscar Funes

Published on

One Year Later: Solutions Architecture

Oscar Funes

Last year I got promoted to Staff Software Architect. As such, the company has a specific ladder for this new track I began tackling.

When I was promoted, and switched tracks, from engineer to staff architect I felt like a natural transition. Also, at the same time, I didn’t know what to expect.

Thanks to collaboration with the principal architect of my business unit, I was able to start participating in different projects across teams, and domains.

Last month, the yearly reviews where given and in the 360 review people felt that I was doing a good job, switching roles.

While that felt good, receiving that type of feedback. I still feel that improving my effectiveness and communication skills is necessary.

Short after switching roles, I was explicitly appointed to work in the solutions architect role for a new project. The project is almost over, and I’m happy in all the participation I had in it.

I’m still learning to be productive with my time in this role. According to the ladder definition, I should still be 50/50 with development tasks. My guesstimate is that I’m around 60/40 for development tasks.

However, more than development tasks, I need to be more effective in saying no. Sometimes it’s not about saying “no” to others, but myself because I keep assigning myself tasks without anybody asking for them explicitly.

As my participation in this role has been more widely known. People have started asking me about participating in meetings with them to provide another set of eyes and input for their tasks.

Just after a few weeks, I realized that it’s an entirely different beast to being a software engineer.

I’ve dedicated myself to read about communication skills, influencing people, discussing, and sharing of ideas.

Through this nascent journey, there have been some insights for myself that I want to share.

It’s not about the technology

I think of my role, as a service role. I’m here to help other people around the company, and as such make the company more efficient in resource and time management.

While discussing new technologies is always nice, there’s some balance to be done. Especially around training, either for current or future employees.

For me, currently, it’s more important to make everyone understand the problem at hand and share ideas on how to solve the solution.

Doing risk management

Risk management is something new for me in a more tangible way than before. There’s always a risk in what we do. Especially around “agile” practices of redefining scopes of stories, and completely changing the way a feature should work or a customer should interact with our systems.

However, now helping in a different role for a project, I realized that most times my mental model of an application or service doesn’t match reality. Also, this comes at the cost of making engineers do some rework or not able to even start working due to misconceptions. Now it’s not only my time but other people’s time which worries me.

There’s a risk in 3rd parties not delivering on time, and not being able to hit the delivery date.

I have to keep my head on top of all of these moving pieces now, and while I enjoy it; it’s a new thing for me to focus.

Mentoring other people

{<>

</>}

My role is not a central piece of the system. My current understanding of one of the things I should be doing is mentoring engineers about design and architecture in general.

Providing context for prior system decisions, business requirements, and help with other points of view for a given task.

Adding to the context is something I had not done before, but I’m looking to improve. Sometimes by adding comments in an email thread, or story in Jira, or comments in Pull Requests.

Another thing I like about mentoring is that I get corrected if something is wrong. Mentoring for me is not about knowing more than others, but more about sharing our context and knowledge of the business and reaching a common understanding.

Documenting software architecture

Documenting is something I’m still learning to do. I started by doing diagrams with the C4 Model which is lightweight (if I can apply such term) and helps me get the idea across with different people across the company.

Documentation is something that needs some time itself to master, especially keeping the documents up to date. It should work as part of the day to day conversation for the project.

{

}

Work to unblock

Everything that’s not within someone’s scope, I take it and do it. Create a relationship with another team, whom to talk to, talk with business, or other requirements.

It’s an exciting change of scope for me, providing much value and knowing the inner workings of the company.

Also, I think that I shouldn’t stop doing development, to always stay in the loop of the different applications within the company.

{

}

Conclusion

I enjoy solving problems, and I’m a people person, so I feel at home most of the time. I especially enjoy solving people problems.

I have been enjoying this new role as it unfolds with every new thing that I participate in.

Here’s to a great second year!