Managerial Duties

Weekly Check-In Meetings with Engineers

There is a weekly check-in that happens between the engineer and the management team. A special private Slack channel, <firstname>-weekly-check-in is created for this purpose. All members of the management team along with the engineer are members of this private channel. Even though all members of the management team are there, only 1 of them conducts the meeting. This allows for easily transitioning to another member of the management team if needed, as well as providing a way for everyone to better understand the needs of the both the individual and the team at large.

Weekly Check-In Meetings with Product

Engineering management is expected to check in with the Product team once a week for 30 minutes. This is to provide updates, discuss any new work in the pipeline, and address any concerns that have come up in the preceding week.

Weekly All-Hands Meeting

There is a Weekly All-Hands Meeting that is conducted by the engineering manager. This is to discuss any pressing issues and important changes that are coming. Oftentimes a concern that an engineer has in their weekly check-in is something that should be addressed to the team as a whole. If one engineer is having an issue, it is quite possible that the other members of the team are as well.

Members of the engineering team should contribute to this meeting as much as possible. Any new projects that are assigned to a Dev Group should be discussed by that group. Engineers should be encouraged to discuss any questions or concerns they have in these meetings with the team. This promotes ownership and helps them to grow as engineers as they get used to presenting their ideas to a group.

Technical Leadership

An engineering manager is expected to provide technical leadership to both the engineers as well as the Product team. Determining the technical feasibility of a feature is important for helping the Product team determine where they can add that feature on the product road map. Engineers also need that technical leadership in order to make sure that the engineering efforts are heading in the right direction.

When possible, the engineers should be encouraged to solve the challenges they face on their own. Management is there to guide the team but the success should ultimately lay at the feet of the engineers. If an engineer can help the Product team with a technical assessment, they should be encouraged to do so.

Deployments

All deployments are done by an engineer manager. This allows for the manager to do one last review of the pull request before it goes live. As most engineers tend to focus on the problems that are immediately in front of them, a manager is in a position to understand that there might be wide reaching ramifications that the engineer is not considering.

Project Management

Acting as a project manager, an engineer manager is well placed to understand the progress that the team is making. This helps with maintaining the necessary mental model required to guide the team along with being able to assist the Product team with any inquiries they may have.

Some projects come over as a single ticket asking for a feature. To set the team up for failure, it is wise to break the project down into smaller tickets that lay out the broad strokes that falls along the lines of front-end / back-end work. From there the engineers are strongly encouraged to break down those tasks further.

Remote Management Best Practices

Managing a remote team of developers across multiple time zones can feel like a herculean task at times. To help with that, a number of best practices should be followed to have a successful team that delivers on time.

Before discussing those, it is important to point out one important detail that relates to the make up of the engineering team: all engineers are contract works from Upwork. They are more accustomed to working on a single project for 1-3 months, and then moving on to the next thing. A variety of bad habits have to be unlearned so that they can adopt the proper mindset that is needed when working full-time at a fast-paced start-up.

Promoting Ownership

Working with full-time remote contract engineers, an engineering manager might soon discover that those engineers may not have the same sense of ownership on a project as they would a full-time, salaried employee. Cultural differences may also play into this. "The most I have worked on a project is 3 months" is a phrase that may be heard from time to time. Contract work is typically short and quick. In an effort to create a team where engineers feel like they are having a meaningful impact, promoting ownership amongst the engineers is a vital part of that process.

When faced with a difficult challenge, it is tempting for the engineering management team to concoct a solution which is given to the team to implement. In some instances, there is no other choice. However, when a team comes up with that solution on their own (with a little bit of help from their managers), they will feel a sense of ownership that one does not get when following a set of instructions. An increased sense of ownership can lead to better results in terms of software solutions along with a happy engineer who wants to stay with the team long term.

This can require patience as varying levels of skill and experience make it difficult for remote teams to fully understand the scope of the problem in front of them. If a tight deadline is looming, by all means give them the map and send them on their way. But if time permits, an effective manager will ask the right questions at the right time, helping to guide the team from darkness into the light.

Permissive > Prescriptive

It is not uncommon for an engineer to ask for permission to make a small change. Not used to the empowerment that comes with working at a start-up, contract workers tend to ask their managers if it's okay to use tool X. It is important for them understand that they are empowered to make changes, and should be encouraged to discuss those changes with their team if needed.

There are exceptions of course. Can we use this plugin? You probably don't need to ask. Can we update our whole build process, causing countless man hours to be wasted on upgrading something that doesn't really need an upgrade? It's a possibility but it needs to be discussed first.

Another important lesson to learn is deciding when to discuss a small change vs simply implementing that change and submitting a pull request. 30-60 minutes on a PR might be a better use of time the same 30-60 minutes spent discussing it on Slack. Worst case, the pull request gets denied and a small amount of time was spent on something that ultimately was not worthwhile. That is okay.

It's a fine line between being pro-active and knowing when to ask for permission. This will come up in the weekly check-ins, and should be discussed in the weekly all-hands as well.

Dev Groups

A Dev Group is a small team inside of the larger engineering team that typically consists of two engineers, one back-end and one front-end. Each Dev Group is responsible for a certain part of the product. One group is designated to handle bugs and miscellaneous requests, along side assisting other groups when needed. This bugs / misc group is where all new hires go when they first join the team. As the needs of the organization change, the Dev Groups can be updated accordingly. Some engineers can struggle with the obligations that their Dev Group requires; maybe they are not ready to work on large term project. This might make them better suited for the bugs / misc group where they can still add value to the organization.