Taro Logo
Profile picture

DoorDash Career Development Videos, Forum, and Q&A

Grow Your Tech Career at DoorDash

DoorDash, Inc. is an American company that operates an online food ordering and food delivery platform. DoorDash went public in December 2020 on NYSE and trades under the symbol DASH.

What does a good Tech Vision doc look like?

Senior Software Engineer [E5] at DoorDash profile pic
Senior Software Engineer [E5] at DoorDash

I am about to start writing a multi year/multi quarter Tech vision doc for my org. To give a bit of background, my org contains 4 teams (1 front end team, 3 backend teams). All 3 backend teams (~20 engineers) work on a big monolithic service containing around 40 different APIs. Of the 3 backend teams, 2 of them work on Product features and the 3rd team (my team) is the Platform team which works on clearing tech debt, architectural enhancements, migrations, etc. For the last few quarters, the entire Platform team has been working mostly on clearing tech debt added by Product teams. The product team engineers have a very tight deadline, so their designs and code are bad or not well thought through.

My vision is basically to split the monolithic service into 3 services with clear separation of concerns and let the product teams be in charge of their own destiny. The reasoning behind this is that I feel like Platform team has been stuck in a perpetual cycle fixing bad work done by Product teams. There is no time for Platform team to enhance the capabilities of the platform. I spoke about this to my manager and he is very excited for me to come up with a vision doc and offered whatever support I would need.

So, given the context, I have the following questions:

  • What does a good tech vision doc look like? What sections should it have? Currently, I have the following sections: Motivation, Future Architecture (Splitting the Service), Deploying in the new world, Automated end - end tests in the new world (we don't have end - end tests currently)
  • How do I "sell" this vision to my management chain (my manager is onboard with the general high level idea), Principal Engineers, Product engineers in my org? I know the Product engineers are not gonna like the monolithic service to be split and will push back. How can I convince them?
  • What pitfalls should I be aware of while doing this work?
  • What upfront legwork can I do before I present this doc to everyone?

Appreciate your help in advance!!

Show more
1 Comment