Being an effective technical manager in 2020

In recent months, many folks have transitioned into a full remote work capacity. This may seem like a blessing for some, but not ideal for others. Given that so many of us have varied responsibilities outside of work at home, it can be easy to overlook some of these circumstances.

If you’re an engineer, you might be fortunate enough to be able to do most of your work without being in the office. And managers have a number of other tools available to enable their teams remotely — a lot more so than ten or even just five years ago. These can be grouped into workflow planning, culture, technology, and training. As a current and former manager of developer teams, here are some things I’ve observed to work well:

Focusing on small ‘ships’ or deliverables keeps momentum and morale high. Many of the most complex tasks can be broken down into smaller deliverable pieces, and some of the best engineers I’ve known over my career are the ones that are able to logically separate the working they are doingand incrementally deliver.

Looking back you’ll find that all those small ships have led to a pretty big difference.

This was something I learned from my old VP of Product. Your goals are going to change over time. Plan for uncertainty and leave adequate margins, but still pick a date. Picking a date gives a forcing function to achieve a goal or make a release and creates a sense of urgency. As the saying goes, time is money.

And don’t forget to celebrate those wins when big goals or milestones are met — either virtually or in-person where appropriate.

Almost half the time the thing you’re working on will take longer than expected, sometimes much longer. Leverage an initial design and planning phase to control the complexity and size of solutions. It can be tempting to skip this step and jump straight to implementing, but almost every time we’ve skipped it here at Stavvy we’ve had to come back to revise work.

That isn’t the CEO or cofounder. This product owner should be able to give the stamp of approval on features in a given domain without having to consult the founding team. The product owner should also be responsible for ensuring that the progress is moving along according to the dates or goals set.

The founding or executive team is there to help with vision, but the implementation should be the divided work of the underlying team.

I try to still dedicate a majority of my time on doing fast peer review of work. You might not know how important or blocking a given task is, and I’ve found that enabling others work can be a multiplicative factor in terms of getting things done. If there’s something I can’t look at within 1–2 hours, I try to let the other person or engineer know.

This doesn’t just apply to engineering; if an individual on any team, marketing, sales, design, etc. comes up with something big that could help the business, a second opinion can always help refine it. Embrace feedback and avoid cultures where sharing work early or raw invites fear of criticism.

To some degree.

In engineering, these automated tasks are typically things like testing and deployment. I’ve been at larger companies where these are given to you on a silver platter when you join. Procedures are defined, testing tools are built, product delivery pipelines are already made. The moment you join or start at a smaller or different company, you realize you may have taken these things for granted.

Many of these automation tools were built over years; your ability to automate will depend a lot on whether you actually have the staff to focus on this or not. Early on, focus on simplicity of deploys rather than building a robust CI/CD pipeline. Even short scripts and hacks can work.

Figure out ways to automate that work well for your team.

You may think that documentation is an optional step, but if you’re building an organization or any product that you want to be used by folks beyond just you, good documentation is essential.

How do you know what to document? Anything that you’ve explained more than 2 times to different folks is a candidate.

This ties into automation as well. A good document might save you 10 or more conversations about the same topic as your company grows. Even an article or page with a few screenshots of things could be a start.

Understand that not everyone works the same way.

Take a step back and consider an issue from your peer or employees perspective. Often we get locked in our own view of a subject which can introduce conflict and make it harder to move forward when working on teams.

Such skill translates to things like sales and building products people want. Ask the question: if I saw this situation or product, how would I respond to it from the other side of the table?

Not everything has to be your main line of work.

Balance is important. If you need a walk at 1pm, do it or get permission to do it. Stay healthy and continue to exercise. Let your team know it’s ok to step away and take a break.

Don’t get stuck in a compare loop to your peers either. You might not feel as good as your colleague that used to work three offices down from you, but you might have a bunch of ideas in your head that could push the company or project forward in other ways. Explore them.

— -

So yes there are only 9 items in this list, and this article is titled on “being an effective manager in 2020”, but many of these points are timeless. And many of these apply outside of software.

I hope you picked out a couple things out here you can apply to your own daily routine. If you enjoyed this article please give it a like.

Building things @Stavvy