Tag: culture

  • Low Process Culture, High Process Culture

    Low Process Culture, High Process Culture

    When I changed jobs in 2020, I went from a low-process culture to a high-process culture (or: what I perceive as high-process, all things are relative). It was a bit of a culture shock.

    The process stressed me out. For instance, my previous job did not have performance review. You were supposed to submit feedback every ~6 months – which I had always understood to be inconsistently enforced (I typically managed to do feedback for my directs every 6-9 months). So, coming into my first performance review, somehow my first ever as a manager despite years of experience, was something of an Ordeal.

    To be clear, what stressed me out was the process. I really struggled with the template I had been given. And then I finally submitted what I’d put together, only to get the feedback that I had written everything as a list of bullet points.

    Well, yes. The template had been a list of bullet points. Hence: my struggle.

    My boss gave me a helpful piece of advice. He told me that if I knew what to do, I should just do it, and then fit the process to it. It helped a lot.

    Time passed, and we came to the next performance review cycle. This time I was less caught up on my own struggle, and had more insight into how other people were approaching things in the role of “feedback reviewer”. From this vantage point, it was clear that having a performance review doesn’t guarantee great, or even good feedback – because that depends so much on all the other feedback that happens in between.

    But, it’s better than nothing at all.

    In Thanks for the Feedback, one of the frameworks is the difference between “evaluative” and “developmental” feedback. Evaluative feedback tells someone where they stand (and whether or not someone gets promoted is inherently evaluative). Developmental feedback tells someone how they can improve. If someone only gets developmental feedback with the evaluation, the evaluative feedback will override everything else. Being great at performance reviews (if there is such a thing), requires consistent developmental feedback the rest of the time – a product of accepting that people are unlikely to fully process the developmental feedback in the review.

    The second review cycle was still stressful, but for entirely different reasons. Largely it was stress about whether or not people would get promoted, and anxiety about telling people if they didn’t get what they wanted. In short – it was healthy, unescapable stress. Not stress about process, or the stress of a manager who last gave feedback last review cycle.

    Perhaps a less emotionally charged example, consider the release process. Any release process has a checklist. And I believe such a checklist is essential. But the checklist is about the release process and not what is being released. A great release is defined by what is in it – exciting features. A bad release is also defined what is in it, a bug, that causes a problem (and another process: that of running an incident).

    The checklists maintain adequacy. They are necessary, but insufficient.

    We have checklists for onboarding. We’ve worked hard on improving them. But I knew our onboarding process was better when the checklists failed, and people stepped in anyway to ensure the outcome – the success of the new person. The mindset of the team was one of collective responsibility, the checklist was just adequacy.

    I believe the judicious application of process is a super power. But I also believe that process is necessary, but insufficient. Process as a super power makes the unclear, clear, and supports a mindset shift that leads to something more.

    But like all super powers, used the wrong way, process becomes a bind and a distraction. People focus on the mechanics, rather than what they’re supposed to accomplish and why. They start thinking their job is to perform the process, rather than the desired outcomes they’re looking to achieve.

    Stepping back to consider the contrast makes more clear to me why the low-process culture didn’t really bother me, or (for the most part) impede me from the things I wanted to do. I was willing to create what was necessary in order to achieve the outcomes I wanted. At the same time, it gives me more empathy for the people who I saw really struggle without it. There is no clear starting point or agreements about how things work in a low-process culture, and that can be very overwhelming.

    All of this is not to complain about a higher-process culture. It is a relief to have a starting point for most things, even if I don’t agree with all of it. But process is inherently a mechanism of standardization and enforcement. There is no way to enforce greatness – we just enforce adequacy, and should be cognizant of the limits of that.

    A company with a performance review process won’t necessarily mean you have a better manager or a better growth path than an organization without one. It just makes it harder for managers to fall short of the absurdly low minimum of some amount of somewhat reasonable feedback on some specific cadence.

    No release process will guarantee a great release, just like no onboarding checklist will ensure someone is successful. But – they can help you avoid known pitfalls such that your release doesn’t explode and your new hire isn’t still completely lost after their first month.

    But it’s always worth considering what process makes sufficient, and what you’re really aspiring for. Sometimes adequacy is the goal, but when it’s not, the process is usually the least of it. What are you optimizing for?

  • The culture of process

    The culture of process

    My latest in LeadDev…

    One of the challenges we face as engineering managers is how people react to process differently. Sometimes it’s like we’re talking about entirely different things – we propose something we expect to be lightweight, and people react like we’re instituting TPS reports or time-tracking in six minute intervals (normal for lawyers, everyone else: hell no).

    Continue reading…

  • Over-Engineering Culture, Hacking, and Complexity

    Over-Engineering Culture, Hacking, and Complexity

    Bora Ultra Two Dark Cult (6)
    Credit: Flickr / Glory Cycles

    I was talking to a fellow escapee of The Conglomerate and we were talking about over-engineering culture. In the sense of “lol things built because it was time for someone to get promoted” and in the sense of complexity.

    The thing about layers and layers of (debatably necessary) abstractions is that they make things that should be simple, complex. Which makes people feel stupid. The last change I committed there I was adding one field… and I had to change > 15 files. The biggest problem I had? Was thinking I must be doing something wrong because it couldn’t possibly be this hard to add one field, right?

    I think of hacking as fixing one corner case only to make two more for later. So, reflecting on this, this is also true of a culture where things are hacked together. Because when hacks build on each other again and again, the result is that simple things become harder (and slower) than they should be. It makes people feel stupid.

    We often talk about these two cultures like they are completely separate but this is not true. They feed on each other.

    • Hacking can be a result of over-engineering culture, because things that can’t be done “correctly” may as well not be done properly at all.
    • Hacking can be a reaction to an over-engineering culture, because people tired of things being so hard want to move fast and break things.
    • Over-engineering can be a reaction to hacking because someone bitten by too many corner cases decided that it would be better if everything were a perfect circle.
    • Over-engineering can be a reaction to hacking because perfectionism can be a reaction to things constantly breaking.

    Personally, I like to think about the medium term. Essentially this means: don’t hack things because hacks are short-term. But just because there might be a reason why something won’t expand to fulfil some other purpose doesn’t mean that it should be generalised (yet). If that scenario is uncertain, and not in the current timeframe, document and move on.

    Hacking to over-engineering isn’t a scale, it’s a circle. At the darkest part where they meet, simple things are hard, and engineers trying to get to grips with it feel stupid. Thinking about it, I’m not sure whether that codebase that required fifteen files to be changed to add one field was over-engineered or made of hacks, but does it matter? The effects were the same. Move slowly, with things that barely work.

  • Honey, I Left the Tech Industry

    Honey, I Left the Tech Industry

    Checkmate
    Credit: DeviantArt / KineticEcho

    Nearly a year ago I wrote The Day I Leave The Tech Industry. That’s not when I published it… I sat on it for months. I worried that I was revealing too much of myself, that I would put it out there and… crickets. That I would feel even more alone that I already did.

    That’s not what happened. It still gets traffic but worse (or better? I don’t know) it comes up in conversation. A friend talks about her next career decision, says “I keep thinking about your post”. It gets referenced when someone leaves. Turns out, I captured something that many of us felt. What an amazing thing, as a writer. What a horrifying thing, as an industry.

    I think I wrote it on this miserable day, one where I didn’t sleep, got to my desk incredibly early. No-one else was there yet, so when I started to cry no-one saw me. I IM’d with a friend, who convinced me I should just go home.

    Some guy was being a jerk. In fact the interesting part of that story is that my manager at the time noticed, and did something about it, and a few days later I actually felt optimistic in a way that I had not considered possible. Of course, there is a vast gap between a colleague who actually respects you and one who is problematic enough that anything actually happens to them. I’ve written about the patterns, about the “nice” undermining, some of which I’ve experienced, others only witnessed.

    The thing is, when you have reached that point where you want to leave, it never goes away completely. It’s always there, and you come back to it on days where you don’t see any reason to stay.

    I know this because I had first reached that point at least 6 months earlier. I had decided it was time to leave and I had made a plan. I checked off the practical things on that list – I relocated so that I was no longer on a work permit, I took care to get a short lease on my apartment, I consolidated bank accounts from countries I had lived in, I filed my tax returns. I responded to recruiters, trying to get a sense of what was out there, and I worked at building up my profile externally.

    Finally, six months ago, I asked myself what I was waiting for? Why was I waiting out my job like it was a prison sentence? Because this had been The Plan I had made a year earlier? I had already given up my apartment, decided what I was going to work on… my fear was no longer what if I left but what if I stayed? What if I got just comfortable enough, but never actually happy?

    I printed out my resignation letter. I didn’t bother with headed notepaper. I had a 1:1 scheduled with my manager. Before it, there was a meeting with a recruiter I hadn’t managed to evade, trying to get me to reconsider doing Corporate Feminism (something I had quit around the time that I decided to…quit). She asked me, “if there any way to change your mind?”. I thought about the piece of paper in my pocket, and said “no.”

    My manager was nice, he had always been nice. His manager was also nice. I was amazed how well I had concealed my plan to leave. They were generous with my exit contract and by the end of that week… I was gone.

    Since then I have been travelling (often to speak), and writing, and working on Show and Hide. I have not found the words to write long-form about the why or the how. I have made short quips about how “I only get mansplained to on twitter now”, or commented on no longer having to answer to a white dude. But short quips cannot capture the complexity of what it has meant to walk away.

    The biggest freedom has been the liberation from the cognitive dissonance from a world that told me I had Made It as an engineer when I felt so unhappy. From the cognitive dissonance of an organisation that seemed to believe the problem was entirely a problem of graduation rates whilst I and my friends experienced otherwise. I do not recall when I last cried. I no longer worry that I am going mad.

    But, this is what I expected. The unexpected has been vastly more interesting and encouraging.

    I am more confident as a developer. I actually feel more capable.

    I have rediscovered a joy of programming and engineering and testing and creating that I had forgotten.

    I get to embrace the breadth of my interests, Show and Hide combines my love of photography with my obsession with mobile.

    It feels like most of what I learned in the last 2 years I learned in the last 6 months.

    I feel like what I do know is more appreciated, as I get to share more of what I’m doing technically.

    I learned how to have opinions again. I did not realise I had stopped bothering, I guess there was always some dude telling me what I should think, mostly on topics that did not matter enough to fight about. This was weird, and hard, but gradually… liberating.

    Of course it is not all joy. Some days the amount of bitterness I feel makes me sad. The vindication of finding other women with similar stories. The jealousy of those who thrived in a good environment. The inadequacy when something causes me to ask myself “should I just be more resilient”?

    Of course the fact that I didn’t need to be more resilient is a huge measure of financial privilege. And I still, rationally, believe that we shouldn’t have to be that resilient. Or brave. As my friend Julie observed, “It’s nice that you think they’re all brave, but they shouldn’t have to be. They’re not going to the frontlines of a war zone. They’re going to write code.”

    What does it mean to say I’ve left? Because after all, I still write code. I still speak at tech conferences. In some way I seem to others more in tech, because I am more visible in tech. Now that I no-longer work at a somewhat insular place, fear a PR nightmare around something I said, I can be.

    Perhaps the meaning lies in the boundary it creates for me. The way it allows me to emotionally disconnect from things that would otherwise be more upsetting. I don’t have to care, I left. Of course it’s bad, that’s why I left.

    And yet I still comment on the tech industry. I was re-reading something that I wrote about calling “male allies” out and empathy and it occurred to me that perhaps the point I wanted to make was that pointing this stuff out is in fact a compliment – it’s taking the time to show someone that you believe that they can do better.

    That I still comment on the tech industry is that kind of compliment. I believe you can do better. Some days I even think we will.

  • Process, and Culture

    Process, and Culture

    developed cross-process by Provia
    Credit: Flickr / kakki****

    As an individual, I have habits, and I have processes. The processes are things that aren’t quite natural enough to be habits, yet.  I think process helps me create a framework that helps me be effective – at work, and in life. For example, having a schedule for my blog. Posting something on Monday, Wednesday and Friday means I write more, even if a lot of it isn’t very good. Some more general rules.

    • Do the most important thing first.
    • Eliminate known unknowns.
    • Finish, don’t 80%.
    • When feeling down, do something active.
    • In the morning, get up then stay up.

    The book The Power of Habit (Amazon) is an interesting one. One story is that of Alcoa, which became one of the safest company in the world after Paul O’Neill became CEO in 1987.

    Becoming the safest company in the world meant a whole lot of process. But, with a shared goal that everyone could agree with – safety – the process wasn’t the goal, the culture was.

    I’ve long thought that good process is invisible. And software engineers like to disagree, one because they are somewhat ornery, but also because software engineers are often allergic to process, to anything that looks like interference in their (our) craft.

    And my realisation from reading that is this – good process is invisible, because good process gets called culture, instead.

    Meetings are process. Transparency, is culture.

    Post-mortems are a process. Accountability, is culture.

    Deadlines are process. Shipping, is culture.

    Quotas are process. “Meritocracy“, is culture.

    Slogans are “culture”, without process to back them up.

    “Mobile is crucial!” is a slogan. “We ship on mobile and desktop simultaneously” is culture.

    “We value a diverse team” is a slogan. A sea of white males, is culture.

    “Don’t feel the trolls” is a slogan. The harassment of women online (and off), is culture.

    As an engineer who likes and appreciates process more than your average engineer, I take from this realisation a few things.

    Firstly, when you try to create or add process, it has to fit with culture. It’s the difference between “We’ve agreed we want to expand our outreach, but that we don’t have enough information to prioritise. Here is how we can address that. We will try this for [period] and then evaluate.” and “Here’s a form to fill in when you want something.”

    Secondly, a slogan is meaningless without some process. This is the difference between “It’s a key priority! We must figure this out!” and “These are the resources and goals allocated to this” – and the numbers reflect it’s importance.

    Thirdly, this explains why people who are convinced they are in a meritocracy exhibit higher levels of cognitive bias. Why have a process for a problem that doesn’t exist?