We want to build skyscrapers and cities

I started my leadership journey with confidence. I felt that I was ready. Looking back now, I realise how little I understood about the shift from engineer to manager. Not difficult, just profoundly different.

One of the toughest parts was getting into the room with new peers. No longer was I exchanging ideas with my engineering and product counterparts. Now I was debating and aligning with finance, marketing, compliance, legal, and customer success leaders.

The debate was always about how to move faster, and in many leaders’ views engineering was the bottleneck. Why can’t we make that change. Why is it taking so long. Why do I have to prioritise. I should get preference.

As a startup, processes were not defined. Getting work to engineers still involved shadowy direct messages and the occasional surprise PR. Usually, by the time we discovered the requirements, the changes did not align with what was implemented.

All that aside, the most challenging part for me was the constant debate about the role of engineering and engineers.

I recall an early strategy session in my leadership role. A marketing executive, a peer of my CTO, likened engineering to construction, with engineers as the bricklayers and me, as head of engineering, the foreman. I was taken aback. I had worked with some amazing engineers, all with deep experience in their craft. I chose to protect my team from hearing those remarks. For me, it was a shock how, at an executive level, engineering could be viewed primarily as construction workers, no offence intended, rather than as the people who create and enable the product.

In a follow up strategy meeting, it was my turn to present. Being young and new to leadership, I countered. The exact wording is a vague memory, but I used an analogy. Microservices were the next big architectural trend, and we were in the process of breaking down a distributed monolith we had inherited. I described each microservice as a building, with us as the construction workers. We were building without hardened plans, another topic entirely, and discovering things along the way. We were also delving into the unknown, with walls hiding implementation details.

I remember saying that our microservices were not just buildings. They were skyscrapers. And we did not want to build houses. We wanted to build cities.

Don’t get me wrong, I have no issue being compared to the construction industry. I DIY’ed many projects and learned a good deal about construction. It started with building alongside my dad on various small projects. We built walls with bricks and blocks, took down walls, and did plastering and the odd bit of plumbing. Teenage me loved it. It was about constant improvement, and when paying someone was out of my parents’ reach, we did it ourselves.

When I got my own house, I followed the same principles. I took on many projects, building furniture, painting, and improving things. After five renovations, using a builder and architect of course, I still found myself diving into minor projects and some overly ambitious ones.

I could see the surface level parallels that construction and software engineering shared. There are key differences, though. Construction evolved over hundreds of years. There is a predetermined way of building houses depending on the country and construction laws. In software engineering, we are still trying to figure out estimation methods, architectural choices like microservices, monoliths, or serverless, and which database to use and when. Not to mention the constant arrival of new frameworks claiming to be the best solution.

I do not think construction has everything figured out either. The point is that we are still developing as a craft. Construction too, however, is largely manual labour. Mixing concrete and laying bricks or blocks has remained mostly unchanged for many years. There have been improvements, but nothing like the disruption software engineering has experienced through milestones such as the internet, blockchain, and now AI.

The point I was trying to make is that software engineers do want to move fast and deliver, at least most I have worked with. What holds us back are ill defined processes and tech debt that we sometimes inherit. What I should have realised earlier was that I needed to present a clearer plan for how we move towards cities, and why that is difficult. I should have created better visibility, ensured architectural work was tied to business problems, and focused on moving at a predictable pace. Similar to construction, keeping owners, or stakeholders, in the loop, not just engineering and product, helps clear up the narrative.

There are simple and achievable things we can do to demonstrate progress. In construction, owners get a clear view of progress. With software engineering, you often only see the external interface. The backend work is frequently neglected.

In my teams, I have advocated for showing the not so easy to see details. Demonstrating before and after states in the backend. Showing logs, traces, simple diagrams, state machines, and actual code differences. You do need to target the audience. Some are willing participants. Others engage only if they are intrigued.

Reviews and demos are not just for the product team. Expand them. Bring in stakeholders. As an engineering leader, bring in peers. But this requires a polished presentation, similar to an architect showing final renders.

More broadly, many companies I have been part of have run showcases that demonstrated both product and technical improvements. These were company wide and gave everyone a glimpse into how the product was being built, while also soliciting feedback through internal testing and dogfooding what we produce.

These practices help reduce the black boxes engineering can develop inside companies. They also help create a shared understanding of what it means to build at scale.

Engineering leadership advocacy matters. When engineering is treated as a stakeholder rather than a delivery function, it becomes possible to plan, prioritise, and build systems that are meant to serve far more than a single use case.