Episode 1 | A Changing Engineering Landscape

Here are a few of our favourite moments from the conversation

The expectation of engineering leadership has changed tremendously. Way back in the day, engineering leaders struggled to get to the highest level of an organization. Many times, the VP of engineering or CTO did not report to the CEO. Instead, they reported to CIOs or COOs or Presidents. Many times, even at startups, the Head of Engineering was not on the executive staff, which in 2021 would be unheard of. In fact, when you think about it today, if you have to list the second most important executive in most organizations, particularly pre-seed stage, it's a CTO.

In the early 2000s, there was a massive offshoring trend. Almost every large organization in the world was offshoring or near-shoring. And it was considered fiscally irresponsible not to do it, and it was almost exclusively Support folks and Engineers. That had cataclysmically bad outcomes for many organizations, and it had nothing to do with the people they were hiring. It had to do with how they thought of what they were doing.

Later, they realized that the value creation side of their organizations was in engineering, so they started, still offshoring but paying better and getting higher, more experienced talent, which gave them better outcomes. Then they realized, "well, the way we're doing this is wrong too," so some organizations changed early, but some are still trying to dig themselves out of that hole.

I think that, even up to 2008, engineering leadership was not considered real leadership. Engineering leadership was spreadsheet, jockeying, getting stuff done, all of that. The whole idea of communication and organization and all that sort of stuff, the height of that was Agile.

Particularly in early-stage companies, but I think this holds for a long time, the person you choose as your engineering leader, especially when scaling up, is someone who is already in your organization. So, you go into a room, the team has seven engineers, and one person needs to stand up and say, "I'm the engineering leader". And usually, that's the most technical person in the team. But I've always followed the rule of picking the person with the highest empathy, and secondly, the strongest system thinker.

I think Heroku plus GitHub, in a magical moment, was peak efficiency. If you did Rails, Heroku and GitHub, you had the best experience on the planet for developing software for a four, five, six-year period. Then I think a couple of things happened, and we're getting worse, and we're trending worse, in my opinion.

The worst developer experience, and worse professional experience, I’ve personally ever had, was working on J2EE when you needed five books on your desk to make the flywheel pattern, married with the factory beam method importer daofactory rappel, something. But it was one of the worst experiences of my life and almost made me want to quit tech. I feel like we’re back at that in the JavaScript world, which means that we’re due for a pendulum swing back to easier to use tools on that side of the fence as well because that always happens, here, you do go through pendulum swings.

I like the notion of pendulum shifts because I don't think it just happens in our tooling, it happens in our management practices, it happens in so many things, and in a lot of the ways that we work today. Let's take Agile as the foundation because I think Agile, with Scrum and Kanban stemming from it, is pretty much the foundation for most software organizations around the world, and it’s 20 years old. And while this has developed to some extent, I'm pretty sure if you and I open up a book about Scrum or Kanban from 15 years ago, it's not going to read very differently from today.

‍

🛠️ Agile

Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly. source: atlassian.com

Other concepts that stem from Agile are Scrum and Kanban, both process/planning methodologies which help facilitate the Agile approach. You can learn more about Agile, Scrum and Kanban here.

‍

🛠️ Systems Thinking

Systems thinking is an approach to problem-solving that views ‘problems’ as part of a wider, dynamic system. It is the process of understanding how things influence one another as part of a whole. Systems thinking involves much more than a reaction to present outcomes or events. It demands a deeper understanding of the linkages, relationships, interactions, and behaviours among the elements that characterise the entire system. source: futurelearn.com

There is much more to learn and explore when it comes to Systems Thinking. If you would like to dive deeper into the topic, we recommend reading The Fifth Discipline: The Art and Practice of the Learning Organization by **Peter Senge. We also like this article by Leyla Acaroglu, which goes over some of the tools one can use when adopting a Systems Thinking approach.

‍

🛠️ Tops-down and Bottoms-up planning

The top-down approach relies on higher authority figures to determine larger goals that will filter down to the tasks of lower level employees. The bottom-up style of communication features a decision-making process that gives the entire staff a voice in company goals. Each task remains fluid as employees achieve their goals.

Both the top-down and bottom-up styles of management offer significant advantages for the companies that leverage each approach. Both styles distinguish between high level and low level work, but how each management style achieves this process varies widely. As with any business, the goals of each is to appropriately and efficiently think, teach, gain insight, and develop an overall leadership system that works well for the company and generates revenue.  source: smartsheet.com

Jason believes that companies should not rely on an all tops-down approach, or all bottoms-up approach. Instead, each organization needs to find a balance between the two approaches in order to achieve their goals.

‍