Engineering Management

Drawing the Line Between the Roles of a CTO and an EM

A small company with less than 20 engineers needed to formalize the role of a de facto manager, and the CTO and the EM had to decide where the boundaries of their roles should be drawn. They agreed that the CTO would handle external matters and the EM would be responsible for internal matters, but there were many exceptions. The transition took three to four months and the EM learned a great deal about how to structure the team and organization. They also learned that being a manager can be a lonely job and that different companies have different needs and titles with different responsibilities.

How to Transition Your Employee Into a Better Role

A manager hired an employee who had difficulty adjusting, but eventually was able to unlock their potential and become a successful and high-performing employee. This was achieved by changing the type of work they were doing and gradually increasing the complexity of the tasks. The manager learned that it is important to separate different areas of performance when onboarding someone and to add gradually a more specific type of work.

Leveraging Diverse Peer Groups for Tighter Feedback

In order to break the isolation of small teams of senior people working on advanced technology projects, a manager had them stage review sessions with each other. This allowed them to communicate with peers who had a shared culture of pushing the envelope, encouraging skill-transfer and creating unexpected collaborations. Unexpected network effects were also observed.

Testing, Learning, and Improving: Building a Successful System Progressively

A collective of six teams distributed across the world and several time zones needed to bridge knowledge gaps. To address this roadblock, the Spotify squad model was adapted to match the company's needs. This involved creating dynamic squads around customer-focused problem statements. After gaining buy-in from leadership and the engineering team, the new system was tested and improved upon. After three quarters, the problem was solved and the team leader gained a newfound sense of confidence in their ability to lead. The experience also taught the value of a test-and-learn approach to problem solving and improved communication skills.

Structuring a Large Team: A Two-Phase Approach

When the VP of Engineering joined their previous company, they inherited a team of 18 engineers. The processes remained the same, making the team inefficient and difficult to work with. To address this, they implemented a two-phase approach consisting of deciding on the right structure and conducting a domain analysis to establish what each team owns. This allowed them to form five smaller, self-sustainable squads and create consistency across the teams. They also learned lessons about standups, success metrics, ownership, and visibility.

Securing Support For a Revamped App

This article discusses the revamping of a cloud desktop app that was helping users download updated software. The revamping project included user research, prototyping, and data collection to showcase what users wanted/needed. The biggest challenge was convincing internal stakeholders, which was done by aligning the initiative to the overall benefit and conducting user research, prototyping, and data collection. The revamping was a success and lessons learned included understanding the product life cycle and how to get key internal stakeholders on board.