We often find companies or teams reluctant to hiring growth talent (A.K.A Juniors or Trainees). Among the typical excuses, the most common ones are “the team has a very aggressive roadmap” and “the problems the team solves are too complex.” Although these might be legit, I’m biased towards thinking that most of the times it’s just management unable to working with different seniority or insecure about the ROI.
“Software is eating the world” sentenced Mark Andreessen on August 2011 on his famous essay published by The Wall Street Journal. He made references to a wide range of topics, from which I find this one particularly interesting: Virtually every company should become a software company. This concept has become a cliché, and I’m trying not to make it super extense, but providing some examples on how software companies are leading their (not software) industries (let’s call their vertical industries for abbreviation).
I recently had to hand off the teams I had been managing for the last 2 years. Luckily, it’s because I was promoted and started running a new department that doesn’t include those teams. Thinking about the knowledge transfer to be made, I realized that I wouldn’t be able to track the tons of information to be transmitted if I didn’t make notes. This wasn’t just about what the teams had been doing, but also about what I had come to envision for them in the future. So, I spent a week collecting all the topics that came to mind in order to write a handoff document for each team, as a way to better organize the discussions around this process.
Abuse against any minority is wrong. It has always been wrong but these days it is simply unacceptable. Do you see how simple that enunciate is? This is something we might all agree and yet, abuse is still there.
The first time I read about the “Conway’s Law” was in the context of an excellent book: “Building Microservices” by Sam Newman. The law states that: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”.
If I already have your attention, let me tell you that this is not the place where you will find the meaning of the “Owner vs. Victim” theory which can be found in bazillions of different sources. It will be generally explained, though, since we are talking about it. This article is more about the pitfalls of people reading people and how misusing this theory could lead you to miss important communications.
It’s an Engineering Manager responsibility to guarantee the team health measured in terms of qualities such as performance, commitment, accountability and predictability (among lot of others). However this can’t be forced by the Manager. It’s actually the team effort and its proper channelling the decisive factors for achieving these goals. Because these are goals, aren’t these?
While I was reading “Elon Musk”, on a bus while commuting home, I couldn’t help laughing of an email he sent to all SpaceX employees regarding to the misuse or excessive use of acronyms. The subject line was: “Acronyms Seriously Suck” (you can figure out the acronym for it by yourselves).