Management Short thoughts

More thoughts about management.

I wrote this as my answer to an application question for a remote company a few years back. It’s a bit outdated, but I thought I’d share it anyway.

In a broad sense, to me management is about people and the things that stop them from achieving what’s important at an individual, team and company level.

It’s about understanding and helping solve the issues stopping a team from being in their A-game, which starts with the individuals and ends with the company as a whole. If a team has issues because people are distracted thinking about how bad their CI solution is, or someone is blocked every morning because they aren’t getting the information they need from another department, it’s a manager’s job to find out and help the team come to a solution. The best solutions come from the people closest to the work, but the responsibility of finding and facilitating the resolution of those issues is on the manager; sometimes that means just supporting the team on a decision they made, and sometimes it means solving it yourself in one way or another.

I believe one of the best things you can do as a manager is becoming skilled and comfortable at delegation and facilitation, and always pushing yourself to delegate larger and more important work to the people who demonstrate they can do it. It means you are comfortable looking from outside, coaching people to excel at their assignments, and being accountable for work that you had very little to do with in the day to day.

It’s about delegating authority, rather than only tasks.

You have to be comfortable saying no often and explaining your rationale as needed, but you also have to be able to check yourself and reevaluate If someone comes to you with a concern about a decision you made.

Understanding and communicating the value of what we’re doing so that others have the context to make smart decisions is one of the most high value things you can do as a manager. People deserve to understand why their work actually matters, and they produce much better work when they do.

An effective manager should be comfortable switching between coach and the person being coached, being able to put yourself in a position to ask questions to get to the root of a problem without letting your ego get in the way.

Being a decent manager can mean being aware that you have very little control and still owning up to whatever the team is achieving or not. It’s finding the time to be connected to the work that the team is doing and being able to facilitate decisions, but not letting yourself hide from problems in the comfort of coding. It’s also remembering that your work touches real people with real lives.

Management Short thoughts

Ensuring new tech leads get a chance to succeed

When assigning technical leads, take care to put them in a situation where they will succeed easily, especially if this is their first time with a tech lead role. The tech lead role is one of the most challenging roles to go into because you live in a sort of limbo where you are still mostly doing IC work but have much more responsibility.

If it goes badly the first time, you might lose a high potential IC over a project that was doomed from the beginning. Try your best to set up all your new tech leads for success, and eventually you might just get lucky and find your replacement in one of them (you know, for when you’re hit by a bus or a bike or something).

Management Short thoughts

Engineering Management feels slow sometimes.

The rewards come slowly compared to individual contributor work, but they tend to be more interesting to me because I can see the impact of my work on people and projects in a more global way. It can be someone finally getting that promotion they have been working hard to get, features shipping with a reasonable cadence when you were struggling to get things out before, or realizing the risk you took 3 months ago by firing someone had a large positive impact on your team’s productivity and happiness.

Engineering management is extremely rewarding, and even though you don’t see things changing on the day to day as much as you do when you’re an individual contributor, you can usually look back a month and find something you influenced that impacted your team and/or your company.

Management Short thoughts

Pragmatic engineering management.

I tend to approach engineering management decisions as I do software development: small adjustments most of the time, big refactors only when the potential long term rewards are worth the risks and there’s no other viable solution.

Like in software engineering, the context in which we make decisions matters. The strategies that make sense in a small, 3 dev team don’t really scale for a larger group. The decisions we make to create an initial prototype to prove an idea are different from what we’d do for production applications, but it’s important to remember that doesn’t make them invalid, it makes them good decisions for the context in which they were made. The same goes for teams. The way you manage a 3-person team is not the same as with a 20-person team, and that’s ok.

Management Technical Debt

Technical debt – where the value hides.

[this is a short, not fully developed blog post – consider it “in development”] I’m getting into the habit of learning in the open, and I think part of letting go of the idea that I need to do everything right is allowing my incomplete ideas to be in the wild.

I think a lot about technical debt. What it means, what makes it happen, how we get rid of it. Mostly, I think a lot about the fact that no matter what you do, you always go and create it again.

Debt seems to be a poor analogy for something that occurs no matter what. It’s essentially impossible to not create technical debt, because time passes, and time itself creates it. Software becomes deprecated, packages stop being maintained, a new security patch is released, and you need to change your code.

Technical debt is a great analogy for the fact that you can incur technical debt to be able to get to market at some point. You take on some debt, you plan to repay it. It starts to generate interest. You pay a heavy amount in interest, and if you don’t, it snowballs, until it consumes all available resources. In that sense, technical debt is the perfect analogy. It’s easy enough to explain it to finance, who understand risk management and how to use debt responsibly; they know how to wield debt in ways that benefit the organization, much like engineers often use some tech debt to get ahead. It’s harder to explain to people who have never taken on debt on purpose, who don’t see it as a tool but only a burden; debt, both financial and technical, are tools to be deployed.

But isn’t debt always bad?

Not really. Some technical debt is almost inevitable. What’s not okay is to let it create a ball of debt that never gets repaid. What was a good decision yesterday can quickly become a bad one if nobody takes this resource consuming debt into consideration.

It’s a bad analogy if you think about the fact that if someone offered to take all your financial debt away, swipe it off entirely, you probably would jump at it.

If I offered a magic wand that takes your technical debt away, and you said yes, you would be throwing away a lot of money that you can never get back, rather than finding yourself with a lot more money to spend.

Your technical debt is where your product hides valuable lessons, and to take it away without rebuilding that knowledge is foolish; it’s why rewrites can be dangerous if not done with care and with a focus on enabling progress rather than eliminating all problems.

The fact that a lot of the important things in your product are hidden in layers of technical debt may be the reason that it’s hard to get rid of it; it contains important learnings, important rules of the business, things that you need to understand to be able to rebuild without that flavor of tech debt.

More than once, I’ve seen myself or others attempt to remove important business considerations when we rush to “clean things up” that don’t make sense. A gnarly bug-fix that wasn’t well documented. An edge case fix that took weeks to identify and solve at the time, with code that looks like crap but serves a percentage of your users well. As you refactor, the risk is that you may introduce different tech debt into your code. That’s not necessarily a bad thing. Some tech debt is dangerous, and some tech debt won’t be considered debt for months or years. But you know it’s going to appear. You may not see it now, or tomorrow, but 6 months from now, some new developer will surely point it out, and you’ll be dreaming to rewrite it again.

When I talk about technical debt being a feature, I know many engineers scoff at the concept. 

If only management let us do it right the first time.

I’ve seen engineers spend weeks arguing for the correct interfaces, the perfect APIs, the  amazing search system they would implement, if only they had the time. I’ve seen managers like myself give them that time. I’ve also found myself arguing fervently that baring a rewrite nothing could save us… and I’ve been wrong on both sides.

With all the time in the world you plan, you procrastinate, you argue with your peers and reach decisions that seem great, perfect even at the outset… solutions that 6, 12 months down the line are not quite good enough.

I advocate for a continuous improvement approach because it’s the only thing I’ve seen that works. Even then, I’ve never seen a team take it to the point where tech debt is swiftly addressed without guilt. I work to get my teams there.

When I think about the future of a tool, maybe 12 months from now, I think I want us to go “ah yea, this bit of tech debt is there because ….” and have a perfectly sane explanation for it. Not “we were in a rush” but “we needed to do X, this was the solution that made sense due to time constraints”. Even better, I want teams to be able to admit: “This was the best solution we could find at the time, but now we know more.”

I don’t want teams to ashamed of tech debt, I want teams owning it, being able to articulate why it exists, being able to articulate how they will address it, and solving it.

I want teams to proudly state that they refactored an old piece of code that caused trouble without the tingle of guilt that the code was there to begin with. I want product managers to ask what the impact of the debt is, and to make decisions as partners, with engineering, on how and when to address it.

I want teams to operate with safety and be rewarded for it.


The fallacy of the brilliant jerk.

Early days

The signals were there from day one. One of your direct reports asked a question and Adrian answered with a mocking tone. You told yourself you’d have a chat with him after your next meeting. By the time your meeting is over, they are all cracking jokes together. You shrug it off, thinking it’s all in your head.

By the end of their first week, Adrian has built a new module that got the VPE’s attention. The VPE tells you how impressed she is with the new hire and congratulates you on your choice.

A week later, a senior engineer is looking frustrated. She’s sitting next to Adrian, and they seem to be discussing the new module your team is building. You take her aside and ask what’s going on. She explains that Adrian keeps derailing the discussion to shit on our tech stack. He starts talking about migrating the backend to a new language he started learning last month. You have a talk with him, and for the first time you see it: he thinks criticizing the languages and technologies you are using without context makes him look smart.  

Nobody in this team gets promoted above senior unless there is strong evidence that they are able to help others grow. No senior engineer hoping for a promotion suggests spending millions of dollars on a migration based on personal preferences. You make sure he understands this, too. They nod, but not even 24hs later, you get a lengthy rant about your organization’s technology stack. The word “incompetent” is in there. You can’t believe you got yourself into this mess.

More likely than not, you have a jerk somewhere in your organization.

Most of us have worked with the so-called “brilliant” jerk. This is the person who speaks the loudest and cares about one perspective only: their own.

The jerk is always looking for something to criticize. If they can’t find anything, they will derail all conversations towards the things they want to discuss, like the fact that they really hate the technology choices made by a CTO 3 years ago, or their dislike of the code review process, which they assure you they don’t need to go through because they are very talented. 

They don’t have time to help unless there’s an opportunity to bring someone down.

When a junior engineer asks a question, the rest of the team jumps at the chance to be helpful, while the jerk looks for a way to nitpick their word choices. When the junior engineer asks “How do I import a component in the React framework”, they answer “It’s not really a framework” with a snarky link, without even giving them the information they need.

We’ve all been inconsiderate at one point or another, but the jerk will find as many opportunities as possible to bring people down. Their intention is not to educate. They just want to look smart.

The complaint

It only takes 3 months for the first official complaint to reach you.

You get a DM from Felipe, one of your senior engineers. They want to have a meeting with you today. As soon as you get the message, you get a knot in your stomach. Ten minutes later, Felipe has told you that Adrian is not a good fit for the team. Apparently, Adrian told Susan that she needs to stop wearing make-up if she wants to be taken seriously as an engineer.

You ask Adrian to explain, and he says it was a joke. He goes on a rant about the good old days, which you have to assume means “2019”, because they barely have 5 years of industry experience. You shake your head and explain that’s not an appropriate joke. For starters, it wasn’t even funny. You tell him to apologize right now. He nods, and the conversation is over.

Knowing you can’t go back to your desk until you calm down, you stay in the conference room for a few minutes listening to music.  It only takes 15 minutes for Susan to knock. She tells you that Adrian refuses to apologize for his behavior. You tell her how much you value her as an employee and assure her that you’ll deal with this. When you ask Adrian, he says he apologized. It turns out that Adrian’s version of an apology is “I’m sorry you were offended”. You explain how that’s not an apology at all, and you ask him to try again.

It’s 5pm, and things seem far from resolved. You bring Adrian back for a candid conversation. If this happens again, you will escalate it to HR. You know HR won’t help you unless they see Adrian as a risk to the company, but that seems to scare them into behaving for a while.

Fear is driving you to make bad decisions.

A more experienced leader would have fired Adrian that day, but this is your first time dealing with a so-called “brilliant jerk”. You think you can solve this. You think his contributions make up for the problems he caused. Furthermore, you’re scared your boss is going to think you don’t know how to hire good people. Your brain is spinning, and you feel like a failure.

A week later, Adrian yells in a meeting because someone else broke the build. He seems to have forgotten he caused a major production incident two days ago by ignoring the team’s processes. When that incident brought a client’s site down, everyone rallied to fix it. Not a single engineer pointed out who was to blame. That’s the culture you always wanted to build.

Trust has been broken.

A while later, Susan leaves. You don’t have to ask. She’s leaving because you didn’t act.

You failed to recognize the importance of this situation, and now it’s too late.

By now, it’s been almost a year. Now the jerk is a feature of your company, someone who nobody knows what to do about, or at least they won’t tell you… because in all those days, weeks, months, your brain played a little mind trick. Once this person started acting like a jerk, you started valuing their technical contribution as if it was the most brilliant code you’d ever seen.

Your team got the message: none of you are as valuable as the jerk.

Nobody wants to work with a jerk.

When the jerk receives something broken, they broadcast it. But when they push something broken, they get direct, one-to-one feedback from the person trying to work with them. This is how they stay employed. This is how they keep a reputation for being brilliant.

You hear “not-jerk broke the build” from them all the time, but you rarely hear “jerk broke the build”.

Nobody wants to hire a jerk.

You would never hire an incompetent jerk. Every little annoyance becomes a reason to remember how many times they saved your ass in a tight deadline. In those moments, the jerk starts to become not just a jerk, but a brilliant one.

You tell yourself you’ll talk to them once that new feature is done. It can’t be that bad, right?

Is the brilliant jerk really brilliant?

I want to give you a moment to think back on your jerk. The one that’s still in your team, the one that your boss admits “is not that great with people, but he sure is smart!”. The one who works alone because their teammates gave up on pleasing them.

Think critically. Take your time. If you ignore the impact they have on your team’s morale and just focus on their technical capabilities, are they really that great? Do you need them, or are you just scared of what you need to do next?

I will make a wild bet: they probably aren’t as critical to the company as you want to believe. They seem great when they save you from a last-minute problem, sure. But did they also cause the problem? Think back. Did they really save you? I bet they caused the issues more often than not.  That release they just saved? The deadline may have been met without heroics, if your team had not been busy dealing with a jerk’s bad attitude and going back and forth on decisions all month long trying to please him. The deadline may have been reached, if you had fired the jerk when he acted that way towards Susan. Susan may still be here, and Felipe wouldn’t be looking for work as you sit down to negotiate yet another deadline.

What about the really brilliant ones?

We generally want to believe that jerks are brilliant, because hiring and keeping someone who is both an average engineer and a jerk for a long period of time would make us look even worse than we already seem to be. The thing is, it’s very rare for someone who is a giant problem for your team to be performing at senior+ levels in their work, because engineering is a collaborative activity, and the highest performers are those who push their teams further rather than make them dependent on them or bring them down.

Sure, there are some who are truly competent if they can work alone. But realistically, all jerks cannot also be amazing engineers, despite the myths that we have been fed over the years. Even if you don’t account for the damage they do to their teams, it’s just not worth it.

In the end, it doesn’t matter how smart they may be.

It’s not worth it. Stop fighting a lost battle.

Next time you excuse the jerk in your organization, ask yourself if they are a net positive. What would happen if this person gave their notice tomorrow? Would someone in your team fight to keep them? Or would they be counting the days until they are gone?

Is keeping this person in the team so important that you are willing to lose your ability to hire and retain great people? Are you willing to continue to prioritize them over their team’s mental health?

If there’s a chance that you are just making excuses for the benefit of your own ego, it’s time to have a chat with your team.

Your team will respect you more for it. Given enough time, all of us will end up hiring a jerk at some point; what we do about it matters just as much as the fact that we did it. Mitigating the damage is the next best thing if you failed to prevent it. Stop making excuses, and work to rebuild the trust that’s been broken.You will respect yourself more for this, too.


Some newbie thoughts about Roadmaps

TLDR: from my perspective as a CTO-doing-product-manager-stuff, the key part of building a roadmap is not what the document says, but what I learn and the connections I make through building it and maintaining it. If I just throw a bunch of features in a planner with no clear alignment to the org’s goals and user needs, that’s not a roadmap, that’s a wishlist. I get confidence in our roadmap when at any given point, I can direct people to it and explain how the future we imagine links to the things in the document. From an engineering perspective, I always appreciated roadmaps when it was clear why something was in there, because it told me there was a plan and not just a bunch of unconnected things in a Trello board.

Roadmaps can be intimidating, both to read and of course to create. If they are good, they can be useful in helping stakeholders and users understand where a product is going and gaining alignment as it gets updated with collected inputs, but they often deviate not into a tool for clarity but one of pressure.

With pressure to deliver on made up deadlines come stressful release cycles, and with stressful release cycles come low quality features that get shipped just to get it done before the made up deadline.

After a while, so many things deviate slightly from the plan that nothing makes any sense. It’s no longer a matter of pushing a schedule by 3 days but one where plans for an entire quarter are delayed and inconsistent. As a team grows, this becomes an ever bigger problem; executives expect results consistent with the growth of the team, and the teams are now demanding a cleanup of all the mess they had to create to reach the deadlines that someone else imposed.

Roadmaps should be a guideline that invites conversation. I am not even sure they should exist beyond a quarter, except in very loose terms.

Roadmaps aren’t a collection of deadlines. When we place a deadline, it should matter. It should mean that is the absolute latest date in which we can deliver safely, not just that someone in the C suite will have a tantrum if it’s not done.

Roadmaps should not every detail, but should bring clarity to how things connect to each other. Details are best left to the moment when the teams will work on implementation, since that’s when you have the most information available to make those decisions. Roadmaps, I believe, should not be detailed lists of tickets that someone will code as they are.

Roadmaps should enable creativity. Teams should be given the freedom to explore solutions to a problem rather than being presented with the complete solution; it’s the people closer to the work who are often able to draw the correct implementation and cut the scope to deliver as much value as possible within a constraint.

Roadmaps should be a tool for clarity, which in turns enables autonomy and better decision making.

Reasonable roadmaps cannot be built in 30 minutes meetings in a vacuum.

Analyzing customer usage, insights, feedback. Talking with users, with support, with stakeholders. Figuring out what the space looks like outside your org. Figuring out if the current state aligns with the organization’s vision for the future. Understanding in detail the why. Comparing what would not get done if this other thing gets scheduled. Understanding the trade-offs and being able to explain them. This is hard to do if your product manager doesn’t have time to think. Give product teams space to think deeply, rather than just react.

In the end, it’s not so much the formal roadmap that matters in a very small team, but the process and learning that got it done.

Roadmaps are not just the what, but the why, when, and for whom.

Managing while Remote

Remote work is not a catch-all excuse for bad team communications.

When you have offices, a lot of your communication happens face to face, and most of those interactions aren’t documented anywhere. Jeff said “paint the walls red”, and Anna’s team did exactly that. If this happened in a hallway chat, there is no documentation of why they decided to do it, or when. If there are no meeting notes, you can’t easily go back and say “this discussion happened on April 2nd, 2018, these 3 people were involved, this is how it was decided”.

Let’s think of your remote team now, and what the process looks like for them. Even the most bare-bones setup for a remote worker involves some kind of chat system with the ability to search, e-mail, and meetings scheduled through calendar invites or by calling through your chat system. If you aren’t taking meeting notes, it won’t be an easy-to-find path, but you may still make it back to the source if all comms happened digitally. This means you have a few ways in which you decide things, how you communicate casually, and how you show what your organization values.

Before we move on, lets do an overview of some methods used in each environment.

Where meetings happen

Office-only meeting types: Hallway, Coffee breaks, Lunch, Go to someone's desk, Meeting in a room. Remote-only meeting types: none. Shared meething types for office and remote: Video calls, Chat apps.
Where do meetings happen?

Who gets invited

This one is a little trickier. Remote environments often require that you are aware of multiple time-zones, which introduces an extra layer of complexity not found in offices. While there are ways to make it work, it’s still something to take into account. In both offices and remote environments, it’s good to be mindful of the vacation calendar and working hours, in any case. People sometimes go on vacation or take long weekends, for starters, and they may need to pick up kids, care for their parents, and a million other things outside the workplace.

In both remote and office environments, the tell invited should be the ones you need for a decision or discussion.

How decisions & decision-making is documented:

Office decision making: a whiteboard? (I've seen it happen!). Shared across office and remote: Meeting notes, Chat, Decision framework documents, or nowhere


What happens after a decision is made

Both Remote & Offices have two options: act on a decision, or do nothing.

How people’s achievements are made visible

Remote and Offices both share similar ways to recognize someone publicly or privately: Meeting, Chat, Performance reviews, or others, like an event.

What did we learn from this comparison?

I can see you going “But this doesn’t prove anything!”. And you’d be right. It doesn’t. What it does, however, is show you that in remote companies the main communication blocker is in casual settings, not formal decision-making such as communication of goals or onboarding people into your cultural values. You no longer get to just tap Jeff in the shoulder(**) to discuss an important issue, or find them in the hallway(**) you now need to DM them or email them.  The inability to do things remote prevents you from doing? That is also culture.

In a remote company, you can’t try to hide your lack of healthy team culture and values with a ping pong table and a few after parties. You have to do the work. You should still do the work in an office, but that’s not the topic of this blog post.

Your team can gain alignment just as well, and it’s more likely that you will know at the very least who decided what, and how it was decided. In most remote environments, it’s unlikely that something happened without at least a message in your internal messaging system (ie: slack), and if you follow some good practices like note-taking, sharing back decisions, and creating agendas for your meetings, you will have a detailed log of how something came to happen, plus more opportunities for people to give their thoughts in a structured or unstructured fashion.

Culture is not ping pong tables and beer. Culture is who gets promoted, who gets a raise, who gets hired. Culture is also firing that person who is being a jerk to all your support teammates. It’s how you treat your customers, and whether people get promoted for being excellent at their jobs. Culture is the behaviors you reward and punish, and you can do those things just as well in a remote team.

I’m not saying remote work is perfect or easy (it’s not!), all I’m saying is that we’re giving remote work too much credit for its ability to create more dysfunctional teams than offices create.

We can create dysfunctional teams with unclear culture in both environments, but we have arguably more hard data about our culture when communication is optimized for asynchronous communication.

(**):  please don’t do this, even if you’re in an office. It’s an easy way to make sure decisions are made without involving everyone needed, and it distracts people.

PS: lots of people don’t do well in offices. Lots of people don’t do well remotely. For those groups, it’s obviously detrimental to do one or the other. What’s important to remember is that both groups exist and that some are in-between (need a balance, which can also be just fine).


Managing while Remote Process & Change management

On experiments and improving our release cycles

[This post was originally published in Q1 2020]

A few weeks ago I killed one of my own experimental attempts to fix how we work, and replaced it with a different one, adjusting for the problems found in the first iteration. It took less than 24hs to involve the correct people, get their buy-in, and even iterate on my experiment definition to enable someone to be a lot more empowered so that our team can move faster.

It had been less than 24hs since we started the new experiment when we got the first big improvement. From a pull request being approved to it being in production, in 24hs. It used to take several days, because someone would approve, then it would be merged by the person sending the pull request (if it was a teammate), and then the merger would send it to QA. That would often add 24hs to the QA process just in tickets sitting there waiting.

In those 24hs, more tickets would get merged, adding to the workload of our QA and to the amount of things that could go wrong. Even with a plan to do weekly releases (our last iteration was doing some changes that could bring down release cycles from monthly to weekly, and it was not super successful even if we did improve our cycle time)

Recognizing when something isn’t working.

Our first attempt at improving our release cycle was a compromise. Because of historical reasons, we never made releases a very big priority until this year, so for months now we have been doing small improvements that bring us closer to our goal: when things are ready, they go out. In our last iteration, I decided that we would do weekly releases to production as a “baby step” towards releasing just as soon as something is ready.

The idea was that we’d get better at the release process, then shorter the cycles. So what improved

  • Releases went from monthly or longer to weekly or every two weeks.
  • Someone who had usually not done releases before started doing them.
  • Releases started getting more documentation on what was going live, we committed to always tagging and thanking contributors in release packages, and we started working towards ensuring docs get started on time. Release tags were going out, finally, in a timely fashion.
  • Releases got everyone collaborating to get them out. It used to be something that happened very much on the background, and they became a more active part of our weekly check-ins.

With 4 or more major improvements, you could say we succeeded. The reality is that we got a lot of good “side effects” of making releases a priority, but we didn’t get as close to “just in time” releases as we need to be.

The iteration of this experiment with weekly releases failed because the goal wasn’t ” improve a lot of important things”, the main goal was “a ticket should never wait more than a week to be in production once it’s sent for testing”.

We knew this, because we documented the goal from the start. It was clear that was where we wanted to be for this to be considered a success.

After doing this recap of “what is going well” and a very frustrating week when my release was not getting… well, released, I decided to kill this experiment, and start fresh with the “just in time” improvement.

There was some push back to doing releases weekly, with a general feeling that it’d take too much time out of the week, so I expected the same for “just in time”. What I found instead was that everyone accepted it pretty fast. To be honest, this hasn’t been something I’ve opened up for negotiation all that much. I’ve said time and time again that being able to release often is non-negotiable.

Does it feel shitty to do that as a leader who tries to bring everyone into big decisions? yea, totally. I feel shitty writing it here, too. But I also feel it’s the only correct decision. When long release cycles are your biggest engineering team cultural debt, and there’s a lot of people in the company who haven’t seen a release cycle that makes sense in many many years, you have this internet stranger’s permission to be the person who says “No, this actually will be done this way”, even if it costs you points in the short term. Explain until it gets boring, follow up, hear the team’s concerns, but make a decision.

As long as you reserve your right to be stubborn about 1 or 2 things and not all the things, I think this is a reasonable approach. If you are making all the decisions yourself, then you’re in trouble and need to go fix that, first.

Without releasing, the impact of the code you write is nil, or negative even, for a long time; the time you spend writing code consumes valuable resources (money, other people’s time, you time) without producing any value for long periods of time.

It may sound counter intuitive that if you can’t achieve weekly releases you should go for daily/just-in-time, but I think it’s actually the only way to go. If you can’t achieve weekly releases because something always goes wrong early in the process, the only possible solution is to minimize chances of “things going wrong” being a problem. Things will always go wrong, so it’s minimizing the impact of each thing going wrong and our ability to respond that matters the most.

We minimized this risk by making the person in charge of QA the one responsible for merging pull requests. Rather than make it so that developers merge their PR once they are ready, we are putting this responsibility in our QA so that he’s the one making the decision on “can we add this ticket to our testing environment, or not?”, and then deciding if a ticket makes it to production based on the results from testing.

Long term, I want us to have enough automated test coverage, observability and safety nets to do more releases, more often, faster, with less risk. For the moment, this is providing speed that we never had until now, and just enough safety to keep us sane.

Management Managing while Remote Process & Change management

Building product development processes.

Early in my career, I used to think process was something people introduced because they were bored and had nothing better to do apart from bothering us, the productive,  bread winning devs that built the thing.

Years later I found myself working with a team that had all the elements of a process and none of the glue that holds it all together. There were strict rules for some things, zero rules for others, and no idea of why each rule was introduced or how. “Why do we do it this way?” was something I asked a lot…  always coming back with little to show for, or a very unsatisfying answer like “that’s how the previous manager did it”.

Process and tools were all pain inducing, with little to no regards of what the team actually needed to succeed, what their own pains were, how they could solve those pains or mitigate them.

And so, I did exactly what anyone with no previous management experience tends to do: I made the team work exactly like we worked in a previous team I had been a part of… a team were things just got done and quality was always a concern… a team of senior engineers with almost zero things in common with this new team except for the fact that we were building something.

I was looking at process as a series of steps instead of a framework that helps us achieve what we need.

I was thinking of the process as a thing we would have some day in the future, not the thing we already had. It was messy and undocumented, but we had a process, and you can’t really push for something new without understanding what came before.

Somehow, the new process took. It became “how we work”, and we were vocal about it. We would argue with other teams when they looked down on us for doing code reviews. We would suggest using git and explain why we wanted every release to be tested and tagged. From time to time one of us would mess up, and we would try to adjust how things worked, and step by step things would get better.

Years later, that process had been tweaked by many others, and it was ours instead of mine. It had grown and learned, and it was no longer “Romina’s thing”, it was our thing. It was cause for many disagreements and valuable discussions, for many issues that could have been prevented if we had seen the error in our ways, but also of many moments of joy, many innovations, many attempts to make it better, shinier, more useful, and for that I’m grateful.

Your team having a process is a journey, not a goal. Your team already has a process. It may be messy, undocumented, and maybe they don’t know it exists, but it’s there.

To create a process, you need to first find the one that already exists. You can’t dismantle something you don’t understand. I mean, clearly you can, but believe me, it’s a lot harder.

Your shiny new product development process is not very useful until it’s collectively owned, and it’s definitely not useful until people who have been there a while stop needing to constantly go to documents to figure out how it works.

It should be simple, it should prevent errors, it should help you identify issues when they happen.

A good process makes your work feel easier, I almost want to say it should bring some joy.


PS: Imposing a process on that team worked, at a surface level, because people were genuinely scared of what would happen if we didn’t change things fast. It wasn’t successful, and it certainly wasn’t easy until we had gone through many iterations and collectively changed it for the better. While it was “my” process, it felt forced and awkward. When it finally became our process, things got increasingly better, and it no longer depended on me to make it happen.