Hacker News new | comments | show | ask | jobs | submit login
Notes on Startup Engineering Management for Young Bloods (2015) (elidedbranches.com)
80 points by Schwolop on Aug 24, 2016 | hide | past | web | favorite | 10 comments



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.


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/ 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.


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 :)


There's definitely CTO school in NYC, because we've mimicked it here in Melbourne, Australia[1]. I'd be surprised if there wasn't one for SF.

[1] And it's from whence I was first shown this article... :-)


> 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.


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


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.


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.


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


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: