Hristina Nedkova Transform your teams to effective engineering community

Automatic Summary

The Art of Engineering Management: Herding Cats

In the world of engineering management, managing a team can often feel comparable to ‘herding cats’. This metaphor effectively encapsulates the intricate and unpredictable nature of leading a team of specialized individuals, each with their own unique skillsets and working styles.

My Journey into Engineering Management at Pay Safe

When I joined Pay Safe approximately three years ago, I found myself managing a mobile team, striving to grow this team into a larger, more effective mobile unit. With prior experience in various leadership roles and engineering, I was all too familiar with the common view that mobile teams are 'special snowflakes' - and not in the most complimentary way.

However, there’s a side to mobile team management that’s often overlooked - the distinct issues and challenges that come with mobile development, such as shipping compiled code for other people's devices and waiting for App Store approval.

Building Culture and Values within Mobile Teams

From my background as a free and open source software supporter, I believe that great software is built by great teams with an established culture, solidified by a strong sense of community. These values applied not just on a development level, but also operationally. One of our main goals was to achieve predictability in our teams, meaning regular schedules and stable velocity expectations to ensure smooth delivery of projects.

However, achieving this was no easy feat, as getting to consistent releases was indeed a difficult journey. It required hard decisions, persistence, and a lot of changes in our habits and systems. From my experience, I believe that the ownership of the release process and the predictable release cycle are the two core elements of any successful team.

Navigating the Challenges of Engineering Management

Despite our best efforts in navigating these challenges, unpredictability remained as conflicts arose from conflicting team incentives. Balancing user acquisition, engagement, and sustainable execution became a delicate juggling act that could quickly tip the scales into a hostile work environment if not properly managed.

To combat this, our focus quickly shifted to reinforcing common values such as engineering standards, quality standards, delivery expectations, and more. We leveraged style guides and best practices to establish a common language amongst our engineers and build consistent delivery standards.

Fostering Accountability within the Team

Peer accountability played a key role in our team as it’s a strong facilitator for individual growth and collaboration within the team. Encouraging accountable culture within a team requires nurturing an environment that enables people to freely express their ideas and admit their mistakes without fear.

Strategic Tech Decisions and Community Building

Our efforts to build a strong and responsible engineering team did not stop at mutual respect and communication. One of the subsequent challenges we faced stemmed from the architectural decisions carrying inevitable consequences for the whole app and team. To counter this, we implemented a more structured style guide and best practices, which are continually evolved based on our experiences.

Moreover, we organized regular meetings for discussing common topics, fostering cooperation, and giving engineers a platform to generate and share their thoughts for the future. This has not only encouraged collaboration but also resulted in significant improvements in our tools and systems.

Conclusion: The Importance of Growing a Community

In conclusion, the role of an engineering manager, particularly within mobile teams, is akin to 'herding cats'. The best an engineering manager can do is let the team create, test, and fight for their ideas. Giving engineers this opportunity fosters a solid team culture, facilitating the transition of a 'team' into a cohesive 'community' bound by common values and incentives.

Inspired by the concept of open-source programming, we have seen that great communities build great software, and have a definitive vision for future growth. Ensuring this growth and maintaining the strength of our teams is a continuous process, one which we are committed to in our journey in engineering management.

Be it resolving conflicts, fostering a culture of accountability, or making strategic tech decisions, the process of engineering management is an ever-evolving art of 'herding cats’. This journey has taught us valuable lessons and has undeniably strengthened our resolve to keep learning, adapting and growing.

Heeding the learnings from our journey, I hope you’ve found something useful to take home with you. Let's continue learning and growing together.


Video Transcription

Some of uh um my role models uh when they talk about engineering manager management, they talk about herding cats. And there is this quote that I quite agree with that a man who carries a cat by the tail or something that he can learn in no other way.Uh This is quite true for an engineering manager. And it also described my journey since I joined Pay Safe about three years ago when I find uh my self managing um mobile team and aiming to grow into a large and effective mobile area. Uh I come from engineering background and various uh leadership position. But I back in that time, I knew nothing about mobile. And the first thing I would was that the mobile teams are often described as special kind of snowflakes, but that was not in the most complimentary way.

On the other side. Mobile engineers often feel like the rest of the organization doesn't quite understand that. And while there are particular challenges about mobile development to which uh uh justify uh all of this, and there is quite a wisdom over the internet that would give you si silver bullets. So I react native or products, but I'm not going to, to talk about any of these today. Uh I'm just going to share with, with you how we build our values and how we created our culture within the mobile teams. Uh in my previous uh life, I've uh I was a, a free and open source software supporter. So one thing that, that I greatly believe uh in is that um great software is built by great teams with a solid culture and building and retaining such a culture requires community regardless if your teams are a special kind of kind of snowflakes. The sense of community is what makes the difference for an organization, a team uh is said to be great if it's predictable, this means regularly, scandal candles and solid solid velocity expectations.

So the management knows when things are going to get shipped and predict predictability and software development means uh ship constantly as many times a day as you can. And if you break something just throw back, but this does not work for uh mobile and definitely did not work for us. Uh because the challenges we have on mobile is that we ship compiled code for other people's faults and after waiting of hours or even days for the App store uh review and approval, people will decide themselves whether Antifa O they will install uh the update. And when I started, uh we never knew when we are going to release a new version engineers were working on features that need to be aligned. Product managers were taking um decisions about the release based on uh their, their product requirements and uh some features get deleted just for one more uh change in the product requirement or one more change, they delete others out of the sudden united topics of production issue, uh and postpone everything else.

And it was a complete mess and predictable release cycle is the core of a KOT team. And your only way to build a culture around your team. So I needed to figure out how we can uh commit to a released rain because it is a really difficult uh journey when you haven't shifted your habits. And uh it is very easy to break the rules and actually undermine them. This required uh me to play the back cop uh to everyone, uh the engineers, the product manager, uh my manager, uh other engineers. So, uh I, I was the bad cop and I needed to take a few hard decisions about the ownership of the, of the lease. It all started with having me approving everything for the uh I think it's not ready. We just go with the relations. We didn't care that it will go in the next one. Over the time we managed to pass it on to the teams, uh going into rotation for the ownership. And later on, we even picked a team that is currently owning it. But uh our uh work on the release and owning k uh changed the things from uh fighting uh for me as a manager to doing it together as a group, uh and being a joint effort that uh uh whatever we are shipping, uh every second, uh Wednesday, it should be deployed to the store up until we committed to the release train.

And no one felt like we're doing a release together. It was my feature against your feature. It was me uh that needs to release something and to you that you are blocking me with a pending fix. We never really had a true feedback to uh uh each other. Uh never truly talk about changes. We deliver the overall picture of the app and how uh the use cases will will work all together and uh this change with uh doing the release together. And another thing that uh I did is that I started running a shared uh sprint demo for all the engineers over uh all this time. The demo evolved uh multiple times. At the beginning, we were just sharing presentations uh of the new features uh and showing the youth case. Uh Then we had the involvement from our customer service department asking questions and giving feedback. More recently, we started adding more and more content like uh sharing future initiatives that are going to do sharing product matrix quality, matrix engineering update. Even we have updates from our UX scheme. That concerns Mobile. And I strongly believe that building a team uh requires that we create um a and regular releases and demos. Uh did, did uh did this for me uh today, the teams are owning both of them and the facilitation of both of them.

And I know that uh even if managers are uh missing or uh P OS are not involved in that, uh all we will have the release and the demo will deliver a true value around um U I consistency minor tweaks that we may find potential ideas for uh improvement. And um these to create the foundation for the connection between the teams. But uh at some point, they also created opportunity for conflict because the more feedback we give, the more we expect to uh from others to act upon this feedback. And the best way to get two teams to find is to give them conflicting incentives. If you incentivize one team to ship as many features as fast as they can and another team to maintain zero cos if you are a monster, you can take the popcorn and uh have a really great show. Similarly, uh in my situation, we incentivized one team to move metrics around user acquisition and engagement and another team to maintain sustainable execution. And this could have easily become a more like a war and less like a functional work environment. So my focus quickly moved uh to broaden common values in regard to our engineering standards in our teams, uh our common processes, uh quality standards, uh expectations for the ups stability and of course, the expectations for the delivery of any team.

And um many years ago, I started my career as engineering. Uh if I can say the best team I may have dreamed for. And this team um taught me that um uh how to, how to do the uh things, the right way and the right things uh and also encourage me to always become better. And the biggest thing that I learned is that you can't make someone hold themselves accountable, but you can encourage accountability within the team. One very powerful tool for peer accountability. Thank you. This is the place where people and others work, ask hard questions and give feedback.

Uh However, as the team grow and you uh you are uh expanding it, accountability needs to also expand outside the, the cultural review and encouraging, it requires creating nonjudgmental space where people can open up. They won't be um afraid uh to share ideas. Uh And uh will never feel uh feel a sense of a blame uh that something has not gone uh uh as plan or they have a problem to solve regardless what your team is. And um how much uh you try to encourage uh openness and cooper operation as they did. At some point, engineers are going to get a bit wild, especially in mobile, what I found out that is that there is no way for one team's architectural decision do not affect the rest of the people working on, on the app. And there was no way one product feature to be isolated from the rest of the UX uh experience or even a crash, it is a burden for everyone. So, uh even I, uh even though I facilitated the communication of uh feedback, uh it became overwhelming and it was very easy to follow uh the slippery swap and turn normal situation into Apr wall or a hostile conversation uh about a coding problem.

And uh one of the things that I strongly believe in are style guides and best practices. And I strongly believe that we should have them written uh because, you know, the main purpose of style guides and uh best practices is that we have them, so we never need to discuss something again. And um another thing that I strongly believe is that nothing is more motivating for engineers than just feeling the pain. So uh is a, a reaction to uh one or two pr wars and a hostile conversation. Uh When engineers stepped on their toys, uh when writing a code in the same screens or, or, or having a dependent features, I just push them hard to create their own style guides uh to write their own uh best practices uh and be aligned around to this. So they needed to, to create their common language uh that they are going to use. And uh currently, as a result, we have various style guides, architectural ones, coding standards, uh linking the testing practices, these processes and so on. All of these were composed as a joint effort by the engineers without um involvement from the management.

Um Other than what I mentioned, my push uh for them to create them and uh these down guides currently evolve based on our experiences, what we learn in our um work, what gaps we find. And um starting with uh this uh situation of uh a potential conflict that we resolved with the um multiple meetings of collaboration, iteration over our ideas and trying to, to reach common ag ag agreement, giving compromises and uh agreeing on indus uh on best practices and in industry standards or disagreeing with some of them, uh We created the success story uh of collaboration.

Uh And um as a result, some of the most uh senior engineers I started to gather uh others in regular meetings for discussing such common topics uh around the issues we tackle together or issues that arise and trying to cooper jointly how we are going to resolve this or uh arise ideas for potential improvements over some burdens they notice.

So, out of this community meetings, uh uh engineers started to, to write uh ideas and they started to, to shift uh some of their uh focus in generating thoughts for the future. Uh the truth is that uh e every software and, and location. So the API architecture and one is going to pay for that every day. If you have um a foundation code, that is a mess, it will bleed through your entire application and through any new feature that you develop. And uh if you invest in a thing that makes someone more productive, it is probably going to make everyone from your team more productive. Normally, uh engineers find it hard to uh explain such um uh such things to product and business. They, they used to arise them as problems that they need maintenance time for. So um product and the product and business are not happy about this. And uh at, at the other uh hand, these things can be strategic for your app for the technologies, tech and the team productivity. And I uh truly be uh believe that um engineers uh try to unite against the common, common enemy and normally they are co common enemies are technical debt, productivity issues and uh process burners.

Uh And as a manager, I can be one of their enemy or I can be their greatest supporter uh for tackling their enemies. So my strategy throughout the process of creating the communities and uh uh our uh guidelines uh and our thoughts for the future has always been to push them to generate ideas and to challenge them uh what they would like to change and what they need. Uh in order to feel more, more successful and the more, the more I challenge, the more they share. So out of that today, uh I can say that we have introduced uh together significant improvements in our tools. We completely changed our C I systems, we change our testing strategy, we automated bunch, bunch of manual stuff that we do repeatedly. Not only tests uh all kinds of man uh stuff. Uh We work together on improving our uh on boarding process for new members of the teams making it more from engineers to engineers. We maintain back work for stuff that would welcome better new people on board and we even built together a successful internship program program.

Uh What we are most proud of today is that we have a solid technical roadmap uh about our architectural improvements in the app and our technologies um within the uh both applications. And this roadmap is supported and funded by the business. So what I can say is that the more we work, the more work we have to do, we have uh uh lots of all, all of our issues, but we have grown today. We are nine, we have uh um uh a goal to grow even more and uh out of this journey, I can confirm that engineering manager month, especially in mobile teams is like herding cat, uh kids. Um And the best thing actually, a manager can do uh is to let the engineers arise ideas, try them and fight for them. Uh This is the opportunity that strengthens uh a team's culture. And um it turns uh a team from a team to a community that shares common values and incentives. And this is proven from the open source world, great communities, build great uh software and they know how they want to uh grow in the future. So, thank you. Uh I hope that you found something to take home and would love to connect.