Taro Logo
2

How can I improve technical architecture across the entire company?

Profile picture
Senior Software Engineer at Other24 days ago

Hello Taro!

I'm working as tech lead in company of approximately 500 people, we are creating tech products both internally and for external clients with a data-science focus.

As part of my yearly objectives, I'm working on improving technical architecture decisions across the company, and I'm looking for best practices, advice and references on the subject.

In the past we have faced some issues such as:

  • tech lead looking for feedback on a target architecture not finding anyone willing/ready to do so
  • an internal product whose code was so poor it had to be almost completely rewritten.
  • teams struggling to solve a problem that had been already solved in other part of the company.

Actions I have been considering:

  • encouraging the use of Architecture Decision Records
  • set-up a team of senior technical profiles that could be mobilised to review an architecture

In general I'm weary of any solution that would:

  • remove accountability from engineers
  • create coupling between unrelated projects
  • add a lot of meetings

Thanks a lot!

68
4

Discussion

(4 comments)
  • 3
    Profile picture
    Engineering Manager at Mistplay
    24 days ago

    I read this question and my first response is to add a major +1 because I would also like to know. Honestly at a 20 person and now 250 person company I have tried and failed to influence company level decisions and that has contributed to a feeling of burnout from time to time more than anything else.

    However I recently have found success based on a class I took that provided specific steps. 1) Build trust with folks through genuine work and non work conversations where your focus is on listening. 2) When you have a great data driven idea, again start the meeting by asking questions of what the other persons current mission, goals, and values are. Then introduce your topic by offering to help with their mission, goals, or values. Be prepared to change your idea to fit what they need, or walk away if it doesn’t line up.

    I’m giving a presentation on this approach and how it applies to chatting with folks across teams, your manager, or direct reports on May 17th: How to Influence without Authority.

  • 2
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    24 days ago

    I would start off light: Push every project to go through a system design review before any code is written. At 500 people, you definitely need this level of process. Tactically, get everyone to follow the advice here: Frontend System Design Masterclass - Building Playlists

    So that's what I think you should get people to do. Now the hard part is getting people to actually do it. There's many components there:

    • Build deep relationships and accrue social capital. Understand people's incentives
    • Come up with a clear evidence-based case on why this culture/process shift would be impactful
    • Consider starting off locally and applying the change to just 1 team. Figure out the kinks of this transition and be a feedback sponge. After you get it to work with 1 team (will probably take at least 2-3 months), then you can spread it to other teams
    • Be patient as changing behavior takes a long time

    Here's a good case study from me that covers all of these angles: [Case Study] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project

    I recommend these too:

    • 1
      Profile picture
      Tech Lead [OP]
      Ekimetrics
      24 days ago

      Thanks a lot, this is very actionnable.

  • 1
    Profile picture
    Eng @ Taro
    24 days ago

    On the individual side,

    I agree with Ryan about greasing the wheels by having genuine connections with your colleagues at work. Before the project begins, have 1:1s with different stakeholders because and talk about the challenges that your project will solve. You'll be able to gauge everyone's initial reaction to see whether your project is on the right track. It will also make your project easier to get buy-in for the future because the stakeholders have already been primed with what to expect in your project.

    On the company side,

    A mandate to create a design doc before any changes are made is very important. I am guessing that's what you mean by Architecture Decision Records. The tradeoff is that there may be a lot of upfront meetings in the short term, but the final design would have go through multiple iterations of criticism which will lead to a more robust architecture in the long-term.

    tech lead looking for feedback on a target architecture not finding anyone willing/ready to do so

    This may be more of a failure on the organization or company level. A poor architecture will continue to cause pain to engineers (and users) for years depending on the scale of the project. I would make sure that more senior engineers know that getting involved with these architecture decisions reflects very well on them, so they don't think that these decisions/meetings are just a burden on top of their other work. They should get acknowledged for attending these meetings and finding the best solution. It should even be part of their job responsibilities.