Notes on Startup Engineering Management for Young Bloods (2015)

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.

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

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.

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.