Growth requires failure

I currently work for a boutique consulting firm. When I joined it was 5 people. The company is not new and has weathered multiple tech economic winds and come out the other side. The main draw of this organization to me was/is it's culture.

At 5 people it was easy to maintain a culture of autonomy, small touchpoints, and a lack of structure. As we've grown to ~20 people and brought on more junior people we've experienced what I would consider growing pains. We've tried a lot of different things to provide an environment for our juniors to grow, to varying degrees of success, but the exercise in general has had me reflecting on ways I've tried to bring people up in the past and the many, many failures I've had.

How I Grew

Part of this reflection is appreciating how I grew and how lucky I was. From my first internship I was put in an environment where I was working with above average people who took pride in their work, took calculated risks and saw their job as more than just ticket monkeys. I was working at a large company but in a division that felt scrappy, a group of people who had mostly all worked together before and were there working with each other again because they wanted to. As part of this I was paired with a very senior engineer on what was affectionally referred to as a "Batman and Robin" team. We owned a Kafka cluster in the 0.X days and were responsible for leveraging it to redo some email marketing workflows. There was a lot of grunt work, a lot of learning and a lot of manually scaling EC2 instances and leveraging RPM and Chef (this was all pre-docker).

I did well, and "Batman" and I were a good team. Because of the amount of work and responsibility we both had it was impossible for him not to delegate things to me wholly. Entire deployments and systems were written from scratch by me following his examples as well as architecture and design. For a 1st year developer I had (at least the illusion) of an immense amount of impact.

The ownership went both ways though, we were on call for each others work and when things went wrong we worked together to figure them out with an understanding that neither of us wanted to be woken up in the middle of the night.

Eventually our product succeeded, we handed it off and both went on to do other things that needed help. Credit to management for taking a risk on a scrappy team of two, it wasn't the usual model and I don't know if it would always work but it worked wonders in our case and I credit both the structure and the engineer I was paired with for my early growth as compared to others I know.

How I've Tried To Grow Others

The "Batman and Robin" model doesn't actually work in most cases from my experience. At least for me personally it leads to frustration, resentment and eventually a supreme lack of trust. The only time I've worked in this model and worked it was more like "Batman and Batman" with folks who I consider more my equal. In all other cases my "Robin" has not properly picked up the responsibility slack has treated it more like a job than a point of pride and in general been less of a value add than I'd like to think I was in my early career.

That model also doesn't scale. At most big companies I've worked there isn't a 1:1 ratio of juniors to more senior engineers it's more like 1:3 and even then half the senior+ folks are useless anyways.

My first team that I lead was culturally extremely strong. We had a group of mostly-good people but we instilled a sense of excitement, cooperation and responsibility that made people proud of their work and proud of our team. We were efficient and accurate, so much so that we ran out of work (which lead to me leaving). While the culture was good while I was there, I can say that many of the people who worked on that team didn't actually stick to the lessons we were trying to teach and the way we were solving problems.

At my next lead role I tried something different, strictness enforced at the code level, something I hoped would not erode when I left and guided by simple whims of who was on the team, something more concrete. I wrote static analysis rules, complex build time enforcement and exhaustive tests. This worked well while I was on the team, PR noise went to a minimum and by the time something reached my desk there was no quibbling on "nit" style PR comments but rather high level interactions and software abstractions (which perhaps those conversations should have been happening earlier but that's a different issue).

When I left that team however things started to devolve. Engineers who had previously been following the rules started breaking them. Started turning things off because they didn't understand them. Engineers who had worked on the team and enjoyed the codebase and the workflow didn't understand why their new team was so much worse. They didn't connect that strictness with the efficiency and speed of the team.

On later teams I tried to express more concretely how these things were related but the reality is that unless you're the one writing those rules it's hard to connect them to larger outcomes.

The Role of Failure

The conclusion I've come to now is that failure is the mode for growth. Trying things, living with them, experiencing them. You can tell people all you want about why something is correct, realistic, etc but it's all just conjecture until they experience it for themselves. As a consultant I'm often bridging this gap with clients (relating a principle, technology or outcome to their existing experience) but it's more difficult with junior employees, who may have warped incentive structures from other jobs or be afraid to admit they can't draw the connections you're trying to show them.

At a consulting agency we have a duty to the client to demonstrate that they're getting their moneys worth. They need to be able to trust that they can hand something off to us and we'll implement it not just functionally but in a way that if we were to go away they would be able to take over. We have to build software that instills confidence in the product they're buying (our labor).

This means we don't have the luxury of failure. Our reputation is based on our ability to deliver without that failure, and the economics don't work if we have someone off to the side burning money failing. Why would a client pay for that?

We'll see if this pans out and I'm not going to give up trying new things but I'm more and more convinced that maybe the type of work I like (boutique consulting) just isn't conducive to developing junior folks.