Managing Software Engineering Teams

Managing remote teams is founded in trust, personal responsibility, direct conversations, and genuine care.

Trust: It goes both ways, so leading by example is key here. Owning up to mistakes and apologizing for missteps is crucial when in a management position.

Personal Responsibility: For some people, personal responsibility is what naturally drives them. For others, this comes from trust, care and clear expectations. It should be cultivated, but never abused (e.g. making and holding someone responsible for a part of the system - good, guilting someone into working over the weekend or through an important event - bad).

Direct conversations: I genuinely think you need at least a few years of direct people management to feel truly comfortable in this one. It's simply hard; but no one can improve without hearing the hard things, and you hurt your employees when you don't share the truth directly. You'll feel that especially hard the first time you fire someone you had tried and failed to help along the way. Sometimes you do everything you can, and sometimes, on reflection, you only did everything you could within your comfort zone, which is not the same as everything. Clarity and directness also applies to expectations - they should be written, clear, and measurable by the employee and manager any time. It should be a mix of subjective and objective criteria that the pair can compare notes on.

Genuine care: Listening in standup and sending messages to folks afterwards to help resolve issues. Giving people a couple minutes to settle into a meeting. Noticing something new in the background. It's so important, especially in remote teams, to remember to be a human and ask questions.

Weekly Operations Sync

Software engineers should be responsible for their changes as a whole. Performance improvements, features, code changes don't end at the merge or even deploy stage - the effects of the changes on the rest of the system must be monitored.

On a weekly basis, the team rotates responsibility for running our operations sync meeting where we review the current state of the systems we own: db query load, honeycomb metrics, and grafana metrics. It's nearly never a very smooth meeting and changes a little every time, and that's the point. We follow a general plan of dashboards to look at, find problems, make notes, and create issues.

Weekly Planning

Planning happens on a weekly basis for the engineering team. Once a week, engineering management, customer success, product managers, platform engineering, and one or two engineering system owners meet to review the work for next week. First, the new and in-progress customer-reported issues are reviewed, then the in-progress and product-requested features. Product shares progress on the POVs and CS shares information about which customers are doing well and which aren't so we can make sure to prioritize looking at those environments. We take a little time to discuss any larger unaddressed issues that have come up during the week.

We write it all down, and it happens in less than 45 minutes. Then we review the features board and the list we wrote down with the whole team the following Monday, which usually takes us about 15 minutes. Short and to the point.