
Hi TTTTeam,
மாலை வணக்கம் (maalai vaNakkam), Buenas Noches, and Good Evening from New York City!
I’ll be sharing some tweets I loved and a thought I had.
Some Tweets 🐦

I am on a team that’s destined to fail.
My team is a centralized-only software architecture group.
Years ago, before my current job - I’d never seen a group like this before. And then I joined my current job. And then I realized why it exists.
The software systems were built 1 project at a time, by contractors (developers on managed-outcome contracts).
Managed-outcome contracts contain requirements that define what the software system must do - nothing more, nothing less, for the contracting team to get paid.
All of the knowledge the contractors accumulated building those systems was lost. None of these contractors needed to consider how their system interacted with the existing ones - let alone think about how they'd be extended or scaled.
The business used developers on managed outcome contracts because they do not cost the company in perpetuity - like a full time employee would.
The projects were run, optimizing for profit and blind to the harm they were doing to the in-house software teams. The in-house developers had little context. They knew none of the idiosyncrasies of the systems they’d inherited from the various managed outcome contracts over time.
So, engineering management attempted to plaster over the dysfunctionality of the software organization with an architecture group.

In a properly functioning org, the lead developers working on that project would have made many of these decisions. This decisions would be based off shared understanding of where programs run and data lives. This is architecture.
However in this dysfunctional org, the newly created architecture group made all these important decisions and the in-house developers had little shared understanding.
All non-obvious questions were funneled to the architects.
The architects spent all day making decisions on things they never contributed code to, reviewed a pull request for, or been on-call for.
Developers got used to idea that anything tough was above their pay grade. Architects were told by management they didn’t have time to code - they had important decisions to make. I know this because I’ve been told this to my face.
Luckily I knew who told me this was full of shit.
This operating model has many downsides
It stunts the growth of every person in the organization. Engineers are not expected to learn on their own. Architects are expected to make decisions on systems they don’t have adequate context on.
The architects become a bottleneck for decisions. Being quick and decisive is a side-effect of high confidence. With their increasingly rusty coding skills, the architects can’t validate their hypotheses. So instead, they waffle and default to “more discussion” and design-by-committee.
The architects who still code disproportionately shoulder the number of decisions made (hi, this is me.) It’s so frustrating to work with developers whose brains have been trained to not engage curiously. It’s like working with a chatbot from the 90s.
The better I’ve gotten at making decisions, the more problems come my way. From developers who are more checked out than I remember. With an understanding so low, it takes 45 minutes to understand what the actual problem is (minus the rambling context vomit I have to cut them off about).
This model is fundamentally flawed. My management knows too. Otherwise, they wouldn’t give us unlimited PTO and I wouldn’t have taken 13 weeks last year (and 11 weeks PTO the year before).
Without those 13 weeks, I would’ve snapped at work. And the organization could not stand every person taking 13 weeks PTO. It’s inherently unstable.
I’m not making decisions for the in-house teams anymore. I’m raising the expectations of those teams. I’m here to weigh-in (if you ask in good faith). But ultimately it’s your system. You have to start making the decisions and bearing the consequences.
If you won’t try to solve your problem, I’m not interested in helping.
A Thought 💭
People spend years living “immersed” in a culture without becoming proficient in a language.
Last year, I worked 1-on-1 with Idahosa Ness, the creator of the Mimic Method to improve my Spanish (and Tamil) accent and listening. In case you missed it, here’s the pointer to part 3.
The 4th exercise we did was "Practice Echoing the Melody of Native Speech".
The reason people miss proficiency is because immersion is not only the physical location, like Mexico City - but also where we put our attention. Passive immersion is not enough.
Especially when we are beginners, it can be frustrating to interact with a language at the word level. Without knowing at least 30% of what’s going on, it will eventually become too mentally taxing and you’ll start tuning out.
However, it’s much easier to interact with a language at a level below the words - at the melody level.
I did the 4th exercise with the "Easy Spanish Youtube" intro vid. Even though Idahosa doesn't say it in this video, he wants you to clap softly and hum the melody.
The two min video took me like 8-10 minutes to clap and hum at .5x speed. I did it twice before sending him the 3rd attempt.
I could feel my brain physically buzzing after the “Practice Echoing the Melody of Native Speech” exercise. It was the first time I realized that even such a seemingly imprecise reproduction of a target language could be so beneficial. It seems ridiculous.
I didn’t believe it until I did it myself (watch me learn below!)
Before I started learning a second (and third) language, I thought the words were the primary building block of communication. But through this work, I realized words are just a small, abstract part. That there are more elemental, concrete, universal constructs underpinning the listening (and speaking).
When in conversation, there’s usually a bunch of background noise. Even in your native language, you’ll miss up to 20% of a conversation and you fill in the gaps. But in your native language, you’re more okay with that 20% gap.
So why not extend that same grace to yourself in a language you’re not experienced in, yet?
I'd love to hear any feelings you felt while reading this and until next time - be easy.
With Love,
Janahan 💜
Whenever you're ready, there are 2 ways I can help you:
1. If you’re looking to break past the senior software engineer glass ceiling, I’d recommend starting with this affordable course. It’s the secrets I’ve learned from going from a mid-level to a Distinguished Engineer in less than 4 years. Join 75+ students from over 15 countries.
2. If you want to grab coffee in New York City, hit reply to let me know when you’re in town ☕
> In a properly functioning org, the lead developers working on that project would have made many of these decisions.
Even though I’m not an architect, a lot of applicable points from me as a contractor. I’d add that it’s not just decision making but also documenting the decision and reasoning in a living document that’s key to institutional knowledge.
In 2017 I was offered this architect role in an organization I didn't accept. I knew I would code a lot less for more money, but somehow I didn't see that paying off in the long run.
So far, I only have upsides from how many different things I can do, and I'm really glad I didn't narrow myself down to this architect role.