Brian Sharp with a beautiful post on the problematic nature of reviewing creative work. Brian's way to look at project development as a subtractive process is spot on. Throwing in features, code and complexity doesn't mean providing more value, so the fastest engineer might get more attention than the one who dares to ask "why do we need it?" or come up with suggestions to provide the same value by taking out stuff or working on a new direction. Are you helping to build the right things? Are you setting the right expectations with your teammates? With your boss?
As always, something to start the weekend with a huge smile on your face. I just hope no hacker from North Korea is reading these lines. If so, my apologies master. I mean well.
This post made me think of some of my own challenges at work. What will kill our ability to scale the team? To have fun? To do great work? To help others be effective? Using pre-mortem and pre-parade can be great tools to inspire innovation.
This post is a must read, especially if you care about your teammates' growth. I don't think that only engineers should write. Writing helps to improve your communication skills, to gain confidence in your ideas, to teach, to inspire. This paragraph is so important to remember: "Even if nobody reads your essay, writing it will make an impact on you. It will clarify your opinion on a topic and strengthen– or even weaken– your beliefs. The process alone of putting jumbled thoughts into concrete words is valuable."
Henrik Kniberg with another great post on how Squads at Spotify monitor and visualize their health as a team. If you're leading big teams, this can be a great model to try out. I believe that the key in this model though, is to understand the trends. Are we moving on the right direction? Are we fixing what prevents us from moving forward, or are we busy optimizing the irrelevant? Do we know how success would look like in 3 months, so we can see if this trend continues?
"You are a signalling mechanism to the team about what's important and what's not." - understanding that choosing a management career path is radically different than being an individual contributor is still not clear enough to many. It's our fault though, as we promote people often by their technical expertise alone, regardless of their aspiration to lead or even worse - if they want to become the manager for the wrong reason.
Dan Ackerson raises an interesting point I believe we should pay more attention to, and that is to invest in our "Technical integration platform for early development feedback." - The reason this platform is so important I believe, is because it encapsulates the confidence the team has in its deliveries and a monitor to our execution rhythm. It encourages others to own their failures, and understand how their work might affect the whole team.
I feel that this 3rd post can nicely complete the previous two posts. This time, Kirby Frugia (an Engineering Manager at New Relic) with his lessons learned on making the transition from an engineer to an engineering manager. Really loved "Your successes are often achieved through others" and "Managing yourself first" sections.