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.
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…
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?
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…
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:
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:
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.
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…
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.
In most teams I’ve had contact in my career, the standup format follows the industry de-facto standard. Something on the lines of:
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?
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.