It depends… The myriad of reasons to have a dedicated release day have often to do with synchronizing marketing, support and the other departments.

My question is what does QA mean for your org? Does it mean defect detection? Testing? Acceptance? Those are all different things. The teams i see that are able to release every day have a strict separation of Quality Control and Functional Acceptance. QC used to detect defects and regression and is handled by highly automated processes accounted for by engineering. Then acceptance is done by a dedicated product/quality team that figure out if the new functionality actually is built to spec and solves the customer problems. This also involves blogs, documentation, customer contact, release notes, tutorials and workshop for the support team etc… This second part is handled by feature flagging, so that the product teams can bèta test, run a limited release and track adoption.

It really depends on what kind of software youre running and what your relationship is towards the end user and the rest of the org. Something that is the same in all cases is that your requirements and acceptance criteria need to be very clear from the start and regression resting needs to be fully automated.

We use them. They have been incredibly helpful. The concept has spread to our product team making product decisions!

It sounds like you are already doing a great job and taking the right steps. The challenges you are facing aren’t uncommon.

When it comes to non-functionals (response times, scaling, security, cost, update speed), you need to quantify them. Bring the stakeholders and your team together and set standards. If stakeholders have unrealistic requirements, this gives the team a chance to negotiate. If your team repeatedly fails to meet the standards they agreed upon, you have a more difficult conversation.

As an engineering manager, your job shouldn’t be to know everything and predict the future. Your job is to use your technical intuition to create clarity and keep people accountable. Manage expectations and filter out the bunk between business and technology.

I hope you are doing well, it sounds like you are in a tough spot, but you can recognize it :) It’s important to remember that it’s possible your employer has unrealistic expectations of your role. Then you should talk to them about it. Expectations can be managed. If that is also not possible, it’s okay to look for a better place. We don’t have the time on this earth to take the heat for things we can’t control.

Man, this place definately has the vibe of an old timey BB forum. You recognise people in your replies like you used to. I find that I’m gawking at stats way less and I’m able to just talk to people. Engagement is way less, but maybe that’s a good thing.

It’s so refreshing. It feels like the old internet

I totally understand. It sounds like you’ve been put in a frightening spot. These transitions really hard enough to do for established managers that have worked at a company for a while, let alone for a fresh hire. It sounds to me like you are doing all the right things: putting tasks into systems and managing expectations.

A growing organization is used to moving fast and when you reach a certain size, you start spinning wheels. Very rarely do companies stay ahead of the curve and setup systems before they hit that wall. You are in the unfortunate position of having to slam the breaks.

Often a company needs an outsider influence to be able to do that. The old guard is used to going fast and haven’t developed the tools to go far yet. To me, it sounds like you are doing exactly that. Accept that there will be friction. The new company will work for different personalities. The people that take you from 5-50 are going to be completely different that take you from 50-500. You will lose people in this transition and all you can do is keep a steady course and communicate realistic expectations to stakeholders.

Something that helped me a ton during a turbulent time was implementing patrols. Now, I was lucky to be granted a lot of freedom to implement process changes. But it did really help us to minimize all the small tasks and distractions that kept coming up. Regardless of what tools you use, those little in-betweeners are by far the cause of most overhead. They never really take less than an hour to complete and they are constantly taking an engineer out of the working memory for a complicated task. Also, people love doing them, because you get a small accomplishment every few hours. It’s much more difficult to sit with a long project for weeks without much progress, but it’s easy to pickup low-hanging fruit. You’re doing well to eliminate those.

When it comes to a billion client requests, a bit of requirement engineering goes a long way. Go through the requests and try to understand the root of the problem they are trying to solve. Propose a projects around solving that problem and eliminate all the chatter while your team can focus. If the requirements for that project change too much, then that means the chatter is even more wasteful and needs to be eliminated. A smart business will recognize this.

As for expectations. Yeah, it sounds like it’s up to you te set expectations for you and your team. Stakeholders don’t have preset expectations and often look at you to set the standard. You want to bring clarity to the table. You want to have the difficult conversation about responsibility and accountability. Again, none of that has much to do with databases and virtual machines.

First of all, thank you for sharing all of this. If more people shared difficult management challenges like this, we would all feel a little bit less like imposters.

The situation you describe isn’t uncommon. I think most of us have had a stint in a shop or at least a period where we are asked to perform miracles. We are tasked with this with such confidence that it feels like we aren’t up to it. This isn’t true. The reason we are asked to perform miracles is because technology is miraculous for most people and the difference between an easy and an impossible project is completely opaque.

Now let me be clear. If you are having a bad time at your job, you should leave. Life is too short to stay with places and people of torture if you can afford not to.

But, if you are willing to give it a shot here’s my assessment. The story you’re sketching sounds like a turbulent time where the business is growing rapidly and/or has lost Engineering leadership. Engineering leadership is needed to to have realistic projects. If your job is to perform miracles, you will fail every time. What you can do is able to communicate realistic limitations to your stakeholders and negotiate consensus on what can be achieved. You need to create a situation where the business can sacrifice a 20% chance of taking 5 steps forward this quarter for a guarantee of taking a single step. A business that can’t see the value in that is dead in the water anyway.

The engineers on the other side, need to have their priorities cleared and set. You need to recognise premature optimisation, hobby projects and resume fluff and put an end to them.

This has nothing to do with Amazon lambda and everything to do with communicating arguments effectively, creating relationships of trust with stakeholders and developers.

I won’t lie. This role will cause alot of friction, but it sounds like the business has no one to tap on the breaks. In the end the real miracle would be to turn the boat around and have some predictability in the workplace.

A single race condition is a tragedy. A million race conditions is eventual consistency.

Counter point. Sounds like a c-level pet project on steroids. It doesn’t sound like anyone is planning a migration. So they are relying on a big bang.

Now… A question for the panel: how would you say big bangs on corporate software projects with actual customers typically go?

What I love most about Krazam is that in every video they make, you see the guy move up the usual tech career ladder xD