Podcast notes: Engineering Managers

I hadn’t really heard of Engineering Manager before, but what they had to say, was really cool. Here’s what I wanted to take notes of.

Ufuk from Spotify

Ufuk Kayserilioglu is the Engineering Manager of the Ruby Infrastructure team (Jemma’s team!) at Shopify. After transitioning his career from physics to software development, Ufuk has had the fortune of working with lots of interesting technologies at various levels of the stack. He, Jemma and Brittany chat about management philosophies, why he remains excited about Ruby and what is the ideal role for Shopify in the larger Ruby ecosystem.Show Notes: The Ruby on Rails Podcast #410

Ufuk is aked what his Management philosophy is. Here’s what I (meta-)heard him say, regarding the team and the individuals in it:

• Team Level

  • the team should be able to cover all the aspects of the work that has to be done
    • one should help the team becoming skilled enough and/or being trained to solve the problems themselves
  • he tries to push as much information to the team as he can, targeted to empower the team to find the best solution on its own
  • he tries to enable the team to take code ownership as much as possible
    • but he still shares his (very specific and detailed) domain knowledge, when possible, so it doesn’t go to waste

• Individual Level

  • make the colleagues own their path of growth
  • if whenever possible create opportunities helping colleagues grow (like he was guided towards his position in management)

Success / Philosophy

Ufuk states that valuing management on technical artifacts isn’t possible on the management level. Engineering can be measured via PR, issues completed, code quality and such. When asked how he measures his success, he states that this is a tough question to answer. He himself considers this more a thing of hidden “counter-“facts, rephrasing it to: “how successful would the team be, if I wasn’t here”.

Brittany from Textus

Brittany is an Engineering Manager of the Frontend Team at Textus.Show Notes: The Ruby on Rails Podcast #436

Brittany, too, wants to make sure that her Engineers are empowered to grow in their best personal track, whether it be Individual Contributor (IC) or on the Management Track.

What I heard her say between the lines is, she describes her job as sort of being the task gatekeeper for the developers. At one point in the show, she says this is crucial, as every engineer when asked:
“Hey! Can you do feature XYZ?”,
then the engineer will almost always say yes, because:
“Engineers love to build things”.
Brittany totally nails it with this one and I am very happy to hear that she adapted her way of management due to this expectation.

Knowing how developers tick, enables Brittany to protect her developers from overzealous feature demands coming from either customers, sales or else. To her it is super important to minimalize the footprint of a planned release as much as possible. It’s her job to identify the minimal, true minimal MVP 😉
She won me completely over, when she said, that she targets small releases. Of course she understands why Marketing/PR wants the BigBang® release, but to the developers the pressure of delivering it right from gun is massive. A big release can cause cracks and will most definitely scramble the time schedule as the work after a release often takes more time than everybody thinks.

When asked where potential conflicts lie, speaker identify one in Product Manager vs Engineering Manager.
It’s natural as the Product Manager wants the customers as satisfied as possible, while the Engineering Manager tries to have the developers productive and delivering and protect them from burning out.

My personal closing thoughts

I highly recommend both episodes, because their scope is not developing itself. The podcasts shed light on what’s going on around our developers’ desks.
Hearing other roles perspective can help developers bridge the gap, better communicate in and out. Enabling a rewarding collaboration across roles and positions in a company/team.

There are some hints given regarding how to enhance the communication between developers and customers or managers.

And from the vibe, I felt that a strong and clear company culture. They call it “build a tribe” at one point, reminding of how important it is to stay open for outsiders. Culture is very hard to measure or explain in detail, but may be the most underrated factor of success on the long run.