How the software industry is leaving essential knowledge behind

This post is part of a series on Creating Effective Teams.

I believe we have made delivering software more complicated than it should be. What used to be a process-driven industry has recently moved to a people-focused one. While this shift has made many things better, it changed a few fundamental aspects for the worse.

We need to understand why.

“Rusty cog” by grahnman is licensed under CC BY-NC-ND 2.0

Focusing on process

In the early 2000s, with the Agile Manifesto, the technology industry moved to lightweight management techniques, valuing software as a distinct engineering category.

It was highly effective. Smaller feedback cycles and more on-demand planning radically changed how teams could deliver.

How can I make my team(s) more productive?

That’s the constant question that engineering managers ask themselves. Managing a group of people working in a complex environment feels more like an art than a science. How much work can we do? What staffing decisions should I be making? How can I improve quality and deliver features at the same time?

All these questions are also made within the context of managing people, which makes it more complicated. Making a team effective means keeping people fulfilled at their job. How can an engineering manager strike a balance between company, team and…

A few tips on getting big results with small engineering teams

Technology is a fast-paced field, especially in early-stage companies where every hour and day count. The runway decreases, while the expectation to deliver results increases.

The typical scenario looks like this: a small team trying to deliver multiple features just in time to hit a launch date for customers. A company trying to exceed expectations and deliver more than thought possible.

How to outpace your larger competitors with a small team?

We just need to move faster

Startups usually have a strong bias toward action. A small group of motivated people, little bureaucracy, and a clear direction. Doing things fast is much easier than in a…

Views on a role that is more art than science

The Spotify model has been a de facto standard of organizational structure in the technology industry for the best part of the last decade. And recently an article outlining its failures has got a lot of attention. It shines some light in a model that nobody understood, but everybody tried to copy.

While I don’t want to dissect all that has been said on it (read it, it’s excellent), I want to go deeper in one topic that has been on my mind for a while: What should engineering managers do?

In the description of the Spotify Model, Jeremiah writes:

We should cross that bridge when we get there.

For any project, a team will make decisions on different levels. What to build, how to build it, in which order to do it?

High energy and time constraints within projects make it easy to fall into the trap of deciding to get things moving. Fast decision making leads to faster results, at least in theory.

Analysis paralysis is a problem. But I hope to highlight that:

  1. making decisions too quickly or at the wrong level is likely to cause more harm than good.
  2. delaying decisions doesn’t come for free, but the investment in it is worth the effort.

When fast becomes slow


A practical view of software engineering metrics

In one of my last posts, I’ve mentioned metrics as a tool I use to manage both up and down. Since then, I got a few questions about which metrics I usually track and how I use them. Metrics are an essential part of engineering management for me, so here are the details.

Why Metrics?

Besides the usual “you can’t manage what you don’t measure”, metrics are becoming more relevant in the industry, especially after the release of Accelerate.

There is an opportunity to use metrics more in engineering management. I believe this shift started as the industry focused on managing individuals…

with Zoe Gagnon

Although it’s always embarrassing to watch myself on video, here’s the recording of myself and Zoe talking about our experience implementing change at Meetup.

Link to Presentation

Thanks to QCon and Jason Yip for the opportunity to share our story!

The simple action that will change your team for the better

Teams are different, problems are different. But if you are running any kind of agile-inspired process, you probably have a daily standup meeting. Its format has been the consistent change I’ve made in all the teams I’ve managed in the recent past, always for the better.

I’m not sure exactly how you are working, but I could bet it will help you as well.

The problems with “What did I do yesterday?”

In most teams I’ve had contact in my career, the standup format follows the industry de-facto standard. Something on the lines of:

  • What did I do yesterday?
  • What am I doing today?
  • Any blockers?

It doesn’t…

Reporting up as an Engineering Leader

While I have been in technology and management for a while, for a series of different reasons, I hadn’t reported directly to someone until recently.

Being directly managed comes with its challenges. What is worth mentioning (or not) when meeting? How can you demonstrate you are still in control while being able to expose problems and get help?

The standard answer

There is an easy format to start with. It was the first one I’ve used and one I’ve noticed managers I’ve managed using. It is the status report that is quite common in meetings and focuses on what you have done or…

Some principles & tactics on software engineering management

A few engineers I’ve managed in the past have recently asked me for material on “changes I have done in teams”. They were being kind. What they were referring to is more honestly described as my frequent rants about a few principles I believe in.

This might be useful for other people out there. So I wanted to write down a few principles. But more than that, the ways I’ve seen teams work against them and practices I’ve used to change.

Before we start, nothing here is new or groundbreaking. These are…

Francisco Trindade

Born in Brazil. Living in NY. Engineering at Braze. Previously Meetup, (co-founder) and ThoughtWorks.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store