Engineering is the easier part of my job

I joined the current team relatively recently - about half a year ago. I moved there from another team at the same company. The team focuses on big data, but is transitioning to apply a lot more software engineering practices within that space. All of my engineers are good engineers who can code and want to do it right, but they were lacking guidelines on how to do it, especially in the context of our company. People aren’t automatically aware of certain practices, like the value of deployment automation, what level of unit testing to do, and so on. So my official responsibility is to make sure that the whole team is aligned on technical aspects and that we share the same engineering mindset.

I am, and definitely want to be, very close to engineering. You could say that this is actually the easier part of my job. This whole deployment automation, writing microservices, UI development, and so on - it’s fairly basic things that have been applied elsewhere in our larger company environment, so it’s nothing super challenging or something that hasn’t been solved before. The thing is, I’ve been working in writing microservices and UIs for the last 2-3 years in the exact same context, same company, and the others from my new team basically spent 0 days on it before I joined, because they were focusing on different aspects. They had maybe 1 or 2 APIs, things got manually deployed, the architecture wasn’t what I would choose today, and so on.

A lot of my job is to do training, I would say, because our people come from very diverse backgrounds - many focus on data or DBA operations. The way I drive good practices is by showing people various options that are available. I just don’t want people to reinvent the wheel and start from scratch on how to do things, I want them to start at step 5 out of 10, and not from step 1. It’s really more about getting the team together and move them into more of an engineering mindset.

I always assume that the other person has good intent and wants to contribute just like everyone else. They’re usually not here to destroy the company or anything. I mean those cases may exist, but I’ve never come across one, luckily. So if something doesn’t work out, if someone isn’t performing, that means something isn’t setup correctly. In those cases, I try to think what it is that’s not setup correctly, and try to set people up for success. To do that, I believe you need to work based on principles. They’re nothing too fancy, you could say they’re just a summary of “how we do work here”. The nice thing about it is that you end up making a decision once and a lot of small decisions in the future become no-decisions. That way you avoid having the same discussions over and over again. These principles are a powerful tool and they help set people up for success.

One such principle is that we’re striving for self-service of the tools we’re making. Another one is deployment automation. But my main principle, my mantra is that the team comes first, that things should be done as a team.

I don’t mean that all 23 people in our organization need to do everything together, hold hands and sing kumbaya. It can be a team of 2 or 4 people, something temporary, it’s really just about asking - here, for this thing, could we do this together?

In a team, you get peer feedback on a day to day basis. You get it on a pull request, on new ideas, you’re thinking together. As a team of 4, 6 or 8 people, you can do a lot within a week, you’re always moving things forward. When working by yourself for a week - it may be a weird week: you may go to meetings, have a presentation, take half a day off for personal reasons and your whole week is gone. In a team, even if 1 person is not in the office, you still get something done.

When you start working in a team, initially things may slow down in some aspects, especially in the short term, and you need a little more process. But in the end, it makes everyone stronger, you learn a lot more, things are documented much better, you always have support even if someone is on vacation for 2 weeks or leaves the company. You don’t get that when an individual just goes off and does something on their own. You’re also thinking more about priorities, about what’s important, what we should work on and what to drop. It’s easier to assign tasks - instead of thinking “Out of 23 people, who should work on this”, we only need to agree which team should pick it up, and we hold the whole team accountable for it.

Since I joined, we changed our structure a little bit – we moved some people who were working in silos into teams, and we ended up with more-or-less 3 teams. People also started to see the value of deployment automation - when you just hit merge and the thing automatically goes to production.

Nowadays people come to me and ask “Hey, I have this thing, can you help me to make it better?” On one hand, it makes my job easier that people now trust me and believe that I have an opinion that’s worth listening to. On the other hand, it’s dangerous. Where do I get my input? How do I make sure that, let’s say, 2 years from now we’re not doing all the same things we’re doing today? In 2 years the world will have moved on, there will be different UI frameworks, there’s this serverless aspect of cloud providers that will be different or improved, some things will be easier to do than today. There may be different, better technologies out there, different programming languages, whatever it is - so how do I keep up with this? I don’t want to be considered the old guard in 2-3 years and have people laughing at the outdated way my team does things. It’s important to also be a technology scout and try to incorporate new things instead of just saying “we figured this out, let’s just replicate the same thing forever”.

It’s a bit scary how much responsibility I currently have, but also exciting how much others can learn and pick up. I’m really motivated to see others becoming better engineers, and by making their lives easier.

Have any stories to share? Reach out to info@standup-and-prosper.com to get featured on our blog!