

How Stripe Builds their Software - dalerus
http://blog.airbrake.io/devops/how-stripe-builds-software-an-interview-with-cto-greg-brockman/

======
dalerus
I found this part interesting:

"We found that combining project management and engineering into a role held
by one person cuts down on a lot of communication overhead. It’s always the
case that the person who understands exactly what we’re trying to build is
someone who also understands all of the technical details of how exactly it’s
built."

I find that in my office a lot of the project management is done by
professional project managers. Rarely do they understand the tech/engeering
piece, and it really makes it hard to communicate deadlines or timelines.

Having only worked in three total development offices I have limited
experience here. How does most tech companies handle PM work? Is it done by
experienced developers? Or simply the middle-management types?

~~~
snorkel
A good project manager has to be technical enough to understand the the
details, ask the right questions, and make informed decisions, but also
important to be able communicate cleary with business stakeholders in a
language that non-technical stakeholders understand such as cost, timelines,
priorities, and risks.

Engineering is an art, and a good PM can coordinate the artistry in a way that
provides certainty and clarity to the stakeholders who only want to know when
will the art be ready for public consumption, they don't want to know how the
art is being made, but when will it be done and how much will it cost. There
are many great artists but they only know how to communicate with other
artists and talk about art, but when dealing with patrons you have to talk a
little about art and mostly about business.

When a company starts talking about hiring PMs that's a sign that the business
managers feel the development work needs to be more coordinated and they need
more clarity about what all these developers are working at on. If a business
manager were to ask a developer what are you working on, and the answer is a
deeply technical component without any clear context of how that component
matters in the bigger picture of the business, then that business manager will
go ask HR to hire some PMs to talk to instead.

------
mason55
_> We often do unscalable things for as long as possible and then figure out
how to fix them later._

Funny... just yesterday we had pg's post about doing things that don't scale
as long as you can
[http://paulgraham.com/ds.html](http://paulgraham.com/ds.html)

~~~
siong1987
pg's advice on doing things that don't scale isn't new. He told us the same
thing when I was in the YC S09 batch (4 years ago).

So, with 4 years (maybe more) of data, I am sure that the advice works really
well for most YC startups. And, that's probably why pg decided to wrote an
essay about it.

------
easytiger
I'd be more interested in the content of the tasks. Development methodology is
fairly meaningless unless you understand the scope of the problems people are
solving.

