Engineering teams working together in the same physical space every weekday will be a rarity. Fully remote and flex work was a phenomenon on the rise before 2020, and the pandemic exponentially accelerated these trends. Tech firms had to adopt a work from home culture overnight. After some initial growing pains, most companies found their productivity didn’t tank, and many of their engineers weren’t eager to head back to their open floor plan campuses. Today even companies with a strong office culture (Google, Microsoft, Salesforce) have shifted to a hybrid setup with the workweek split between the office and elsewhere. Other high profile tech companies (Square, Twitter, Shopify, Facebook) now allow employees to work fully remote.
There will be some holdouts like Apple that retain an in-office model. Still, momentum favors more distributed work setups over time. This new reality makes remote team management skills not just nice to have, but essential.
Having managed a team across the U.S. and Canada for several years, it can be challenging to keep meetings productive and helping the team gel together. If you’re read or listened to any other remote first advice, this isn’t revelatory news. But your actions in response to these headwinds can have a positive impact.
Smart engineering managers foresee what actions maximize long term impact and prioritize those actions accordingly. That is challenging to pull off in practice. The linkage between an EM’s immediate action today and its ripple effect a week, a month, or year from now can have little connection to time spent on the act itself. It also commonly lacks a paper trail or concrete “proof” of action taken. And managerial outcomes often depend on the fickle influences of human psychology and plain luck.
I’d argue individual contributors, a.k.a. developers have an easier time making the connection between action today and impact tomorrow. Most engineers deep in code have clean artifacts of their work to show progress. Developers edit files, merge pull requests, close Jira tickets, and pass automated tests. When they ship features, there’s often a tangible outcome, be it a new set of UI, a performance boost, or a database migration. Past performance across similar technical challenges becomes a predictor for future velocity. This factor is why more experienced engineers become more accurate at making estimates for their work, and why task estimation is such a core tenet of software development.
1:1s are deceptively hard. On paper, they look straightforward: set aside some time to let your reports talk through what’s on their mind. Actively listen, give them feedback, repeat. But no report shares the same personality, seniority, career trajectory, or learning style. Add to that mix a changing agenda and office politics, and you learn early on good listening alone won’t cut it. Knowing how to react at the moment in a way that’s tailor-made for your audience tends to elevate 1:1s from so-so to stellar.
But flexibility challenges aside, some principles work well for every report regardless of their background or environment. If you’re new to 1:1s or been doing them for a while and want to get better, adhering to these four basics will help.
Every engineering manager juggles multiple priorities: managing the velocity of the team, serving as a cross-team engineering representative, making sure the engineers are happy, and weighing in as a deciding voice on hard decisions. There’s never enough time to do everything which forces prioritization.
Unfortunately, promoting career growth among a manager’s reports can be the first item to get lost in the shuffle. It rarely carries the visibility that managing team velocity or a substantial presence in meetings can. Put another way, when you hit your deadlines, ship software on time, and take decisive action on the weekly sync, your boss notices. If you’re not promoting a report on schedule, you might have an unhappy individual, but it can get lost to the larger company view.
An engineering team’s formal processes — how you track sprints, run meetings, handle release cadence, and manage code reviews — helps set team velocity and impacts the happiness of individual team members. As the engineering manager, you’re in an impactful role to shape and improve these processes over time. Remember when making any change in process, be patient yet firm.
Engineers tend to dread meetings, and for good reason: bad ones can be soul crushing. Not only are bad meetings a waste of everyone’s time, it can make the meeting’s organizers look incompetent. Paradoxically, as engineers grow in their career, meetings grow more important. You attend and organize more of them, and as a senior voice in the room, your words can have an outsized impact.
Meetings get a bad rap. Well run ones are an efficiency multiplier, leaving people energized and productive, and a team more cohesive. The right meeting can even turn around an otherwise doomed project.
One of the easiest ways to improve the quality of your meetings is to prepare for them. Without preparation, you’re fighting an uphill battle against context switching; one minute you’re coding and the next you’re in “meeting mode” without clear direction.
I like design teams built around collaboration and transparency with outsiders, especially engineers. Yet that openness has to be balanced against productivity. Even with formalized designer-engineer connections, I still structure meetings to give designers as much uninterrupted time as possible.
An open structure largely derives from designer/engineer ratios. Across technology, from hot startups to well established brands, designers are almost always heavily outnumbered. And given it’s a fairly young industry, design is often underrepresented in company leadership. Granted, with “design thinking” surging in popularity, that’s changing. But across many companies, it’s still an uphill battle. If you box your design team in, you’ll stack the deck against you.
Capturing and organizing tasks is a highly personal exercise. Some turn to simple tools like pen and paper or a Google Doc. Others prefer complex systems with filtering, contexts, and customization like Omnifocus.
After trying several options, I’ve found a sweet spot between these extremes with Todoist. It provides some structure for work, but remains flexible for whatever flow I’m managing. That said, the basics I outline here should work with most task management systems.
Andy Hunt, one of Agile Manifesto’s original authors, wrote a controversial post recently. He makes several arguments about Agile’s failings, and this one especially resonated with me:
Since agile methods conveniently provide some concrete practices to start with, new teams latch on to those, or part of those, and get stuck there.
I’ve seen this phenomenon firsthand. A team settles on a system as the solution to their productivity problems. They get bogged down in rules and convention, and integrate too quickly. The process stalls and dies. As Hunt argues, without flexibility, the company loses sight of their productivity goals.
What defines an experienced web developer in 2014? Looking back on my own progress, I transitioned from entry level to senior roles and became “experienced”. Yet it was surprising to reflect on what skills and traits led me to that point.
Programming chops also contribute; practically any position requires a baseline technical aptitude to sustain a team’s momentum. Yet as my career has gone on, I’ve found three traits outside of tech that usually separate the experienced from the entry level: wisdom, communication and “T-shaped” skills.
Wisdom is experience defined by long-term development cycles. It’s working through projects over months or years. For solo, agency and freelance developers, it’s defining a long term relationship with one or more clients for an extended period. Developers with high wisdom levels know how to work with other tech personnel. They quickly assess their team’s strengths, weaknesses, and who’s best to delegate for different aspects of the job. They also give assured estimates and know how to best integrate their tech skills into a larger team.
Communication centers on verbal and written skills. Part of that is back and forth with the rest of the tech team through succinct bug tickets and clear project status reports. And on most front end development projects, tight communication with the designers and project managers is essential. In addition, business staff often notice and gravitate towards developers with strong speaking and presentation skills, regardless of their technical aptitude.
T-shaped skills aren’t directly related to web development yet are helpful for the overall company. Aesthetic design, UX, analytics, marketing and business are common examples. T-shape skills are especially important for front end web developers, as they are often faced with many client-facing micro decisions due to lack of time or definition from other groups. For example, there may be a high fidelity spec for a new page design, but a few elements don’t quite match, so the developer adjusts some spacing and padding. Or a new web app is launching and a developer realizes select user actions aren’t being captured by analytics; he or she makes a quick correction. Many of these details aren’t noticed until well after a product is shipped but can have a cumulative benefit for users.
All three of these attributes have one thing in common: there’s rarely shortcuts. It takes time, earned from months and years of work within a team. When you run through an entire dev project cycle – tech assistance to early design iterations, developing a feature set, fixing QA bugs and launching the product – there’s invaluable knowledge gained that can’t be gleamed from a blog post or weekend workshop. Admittedly, some developers are naturally gifted communicators and are equipped with a T-shaped skill base by the time they reach their first web gig. Yet having worked with a large variety of web developers in my career, that’s rare.
So, some advice to those starting out: it’s ok to take a break from learning the hottest web framework to brush up on your speaking and writing skills. It’s also smart to ask questions and have interests in the rest of your business. And if you get the chance to work with well-respected, senior developers, do so. Be patient and take in everything you can. Experience takes time.