
Notes on Startup Engineering Management for Young Bloods (2015) - Schwolop
http://www.elidedbranches.com/2015/10/notes-on-startup-engineering-management.html?m=1
======
jetsnoc
Good article. As you get into the day-to-day work, I find that most things are
far more meaty and have more depth than the examples here. I understand that
the audience and length of this post surely couldn't "solve all the things."

However, it would be nice to have the management version of a rubber-duck, a
pair, a mentor, a consultant or a life coach for people in our roles. I don't
know if anyone else shares this opinion but I would be interested in a virtual
meet-up where CTOs of startups and small businesses discuss best-practices and
work through issues. It could be as simple as a mailing list. I suspect
meetups and groups like this exist in-person but I live very far from the bay
area and we're rural enough there simply is nothing nearby. If nothing like
this exists, I would be willing to work and work hard with others to set it
up. I think it would be so valuable to me that I wouldn't mind putting a lot
of effort into getting it going.

I would also pay real money for the right mentor/CTO coach. Surely there are a
number of passionate CTOs/Past CTOs that wouldn't mind passing on their legacy
and mentoring me? If any of this at all sounds interesting, my email address
is in my profile.

~~~
akurilin
Exec / C-level startup coaches do exist, they tend to be pretty pricey though.
I had a chance to chat with [https://www.reboot.io/](https://www.reboot.io/) a
while back, they seem to be a good place to start. We tried putting together a
CTO meetup here in SF several times, but it's worse than herding cats,
everybody is super heads-down in the work 24/7.

~~~
jetsnoc
Thanks for the share, I will look into it. I wonder if their isn't as large of
a demand for this type of support system in SF? Everyone seems very connected,
has a VC network and may even have a seed-operated Alumni network and mailing
list. I agree, they probably have their head down and are building their
product. As they should. When they come up for air though they probably have a
half-dozen mentors at their disposal. I'm not sure, that of course is all
conjecture :)

------
skewart
> Whatever you do to your direct reports will probably flow down the chain. If
> you disrespect their time, they will disrespect the time of their direct
> reports.

'Everything flows downhill' is one of the fundamental truths of organizational
culture and management. An indecisive CEO begets flip-flopping, stressed-out
managers, which begets unmotivated employees. Act the way you want people in
your organization to act and things will take care of themselves - well, it's
not quite that simple, but, you know.

~~~
eru
That's actually very confucian. That's why they were very concerned with the
conduct of the emperor.

------
donw
Having done a decent amount of work in helping startups build and scale their
product teams, there are a few big areas where I have seen startup founders
really struggle with managing their teams:

1\. Kindness

I put this one first, because it is important.

You, as a leader, wield some pretty incredible power within your team, and
need to use that power responsibly. Before you say or do something, imagine
how you would take it if your lead investor, or your mentor, were to say or do
the same thing to you.

Kindness is not the same as "niceness". You should be honest and direct. But
at the same time, human beings _do_ have emotions, and those emotions _will_
impact their work. Be sure to acknowledge success, and treat failure
tactfully. Feel free to set the bar high, but make those expectations crystal-
clear, and work to help your people exceed those expectations.

Under no circumstances should you be insulting, demeaning, or angry. All have
a highly negative business value.

Kindness is _powerful_. It promotes clarity, growth, and close collaboration,
and _must_ be a core part of your leadership philosophy.

2\. The Power of Training

As a manager, you need a plan for up-skilling your employees.

For two reasons: One, you are not going to find that perfect match of skill-
set and culture fit. You will probably find plenty of people that are a good
fit, but lack an exact match on the skillset. Two, offering both prospective
and current employees mastery over their craft is a fantastic hiring and
retention tool.

Also note that "culture fit" does not mean "we all drink beer on Fridays
together". It's more "I would be happy with this person joining my team
tomorrow, even if they don't have all the right skills yet."

My go-to solutions for up-skilling employees are pair programming with regular
rotations, team workshops, and scheduled beach-time (where an employee can
spend a week building or learning something new, which they then share with
the team). I even have a workshop specifically to teach pairing in a fun way,
because pairing actually isn't as simple as "have two engineers work on the
same machine".

3\. The Three Hats

A team where people just build what they think is most important as
individuals, or that spends endless amounts of time debating priorities,
usually isn't a team that ships a lot of value.

There are three roles, which I like to think of as hats that a person can
wear, within a product team: the Product Owner (representing the interests of
the business), the Designer (representing the interests of the end user), and
the Engineer (the person that actually builds the thing).

Each of those hats comes with authority over a certain set of decisions, For
example, Product Owners have authority over the direction of the product and
the priority of implementation, and are responsible for ensuring that the team
builds the right thing for the business.

Distributed responsibility is the same as no responsibility.

This is not to say that people should be dictators. Engineers and Designers
can (and should!) offer up ideas for new features or suggest that Feature Z is
more important than Feature A. But the final decision is made by the Product
Owner, and nobody else.

Sometimes people need to wear two hats. A Designer or Engineer might also need
to be the Product Owner. This is not ideal, but sometimes unavoidable. In that
case, work to ensure that they wear each hat for a contiguous block of time on
a cadence that matches the iteration length. Context switching is _expensive_
, and you want your team members to do a little of it as possible.

There's more, but this is a pretty good start.

------
siliconc0w
re manager writing code: It should be mandatory - least you become one of the
'non-technical' managers that seem to revel in just how far they've gotten
from the day to day. You need to intimately understand your team's workflow,
the dev environment, the build system, the deploy process. You need to know
whether 'switching to X' is a good idea. You need to quickly surmise whether
"building y" is a hard or easy problem.

If your SDLC makes it 'unrealistic' for you to find an hour or two to complete
even a small point story then you already have suspect a pipeline.

~~~
Animats
Microsoft used to have the policy that you had to write code unless you
supervised over 100 people. Do they still do that?

~~~
btown
Not sure about the policy, but a few years back I heard from Qi Lu (who now
runs Applications and Services) that even though he manages far more than
that, he still attempts to _read_ code regularly, even if his schedule doesn't
permit him to write code himself. I'm sure his senior engineers are more than
happy to ask down the hierarchy "send the code you're most proud of, or
something that represents a critical piece of infrastructure or bottleneck to
understand, and it'll be read all the way up the chain." In fact, now that I
think about it, the morale side effects probably make this a great practice!

On a separate note, that tidbit has stuck with me years later - I heard it as
an intern, and I think it's one of the things that really solidified in my
mind that I could stick to my technical roots even if I went all the way down
the path of engineering leadership. As I find myself writing more and more
specs these days, I'm glad to be reminded of it.

