There’s a lot to love about this presentation from Andreas Klinger, the former CTO of Product Hunt on how to lead engineering at an early-stage company:
A few things that really resonated with me…
The first is that hiring great people (people that are better than me and who could effectively do my job better than I could) is where the bar should be, full stop.
If you don’t believe this person can not only have that type of impact personally but also corporately, then, move on. Are they going to become a system-wide force multiplier? Make the hire!
Figuring out the difference between management and leadership is a life-long process and is also something deeply personal in nature (as it should be) but this is an area that I need to improve on constantly.
I want to spend much more of my time in the leadership area and much, much less time managing.
This made me laugh… and then cry… and then I wiped a tear (or two) from my eyes… … I feel as if I’ve gone back and forth on my beliefs and feelings around organizational design 100 times in my life – hell, I’ve blogged about every organizational style and practice out there and have ping-ponged in practice more than I’d like to admit.
What I love is that this calls out what we know to be true but what we often ignore (at our own peril). Hierarchies do exist but knowing if they are more explicit vs implicit and understanding how they actually function in day-to-day interactions can sometimes be difficult to uncover and/or understand, especially new team members.
It might be worth even outlining this explicitly for your team and making it a talking point during a next all-hands meeting (if you haven’t already done it).
This slide was an amazing reminder because it makes clear what the
output should be without defining (or demanding) that a specific model of execution be used (although some of the expectations may have very few choices in terms of execution).
The first example is a good one:
We do pull requests reviews every morning.
The beautiful thing is that this clearly describes what is going to happen at a specific time during the day and then leaves the professional, trusted adult to do whatever they need to do to get those
PRs ready for every morning review.
Does it really matter that they finished out their work days in advance or if they were working super-early-morning to get them done? Does it matter what tools they are using? Not really. None of those specifics matter insofar as they don’t negatively impact others, of course, but this allows high levels of agency within the organization and that’s a very good thing.
I talk about this plainly often and everything on this slide is entirely true. Any process that we create now will most likely have to change and/or be entirely scrapped and rebuilt quickly (just like software).
Keeping them simple saves folks time and energy and doesn’t entrench the organization with too much system-debt early on.
Refactoring these systems should be something just as explicit as the system itself – meaning that a healthy, mindful, and self-aware organization is actively thinking about refactoring on a consistent and perhaps even periodic cadence (e.g. once a quarter the leaders review older / old-ish processes and slots them in for review and/or dedicate time to refactor).
This slide resonated with me the most because so much of my frustration typically finds itself centered in the fact that I’m lacking context on decisions that are being made (and the processes that are codified out of systemic, repeatable decisions) but can often conflate and confuse my frustration as being related to the people involved (which is very rarely the root of the problem).
Being able to delineate between being frustrated with people vs frustrated with (the lack of) context is paramount.
What a beautiful reminder here… and this one too:
I love this:
Speed = The Right Work. Yes, yes, and more yes.
This slide I would have loved to hear more in-person from Andreas but I think I understand what he’s positing here.
The one thing I can definitely agree with is that building individual and corporate momentum (through iteratively becoming faster as individual contributors and the aggregate team output) directly impacts confidence and bolsters resolve for everyone involved.
You feel when things are sluggish and if morale is increasing or decreasing for the team or if it’s not. Sometimes it’s an overwhelming sense of dread and other times it’s euphoric; optimizing for the latter and not the former is, obviously, a good thing.
This is an area that I need to improve on quite a bit… I’ll just leave this here for myself. Yikes.
Treat your organization like software:
- Create small units
- Share ownership
- Reevaluate best practices over time
Treat people like capable adults:
- You can either hire driven, intelligent people or…
- Micro-manage people (to death)
Every problem is ultimately your fault:
- You defined the process
- You hired the team
- You guided them
Yup. Time to get going.