stuff tagged with "leadership"
In Praise of “Normal” Engineers
đź”— a linked post to
spectrum.ieee.org »
—
originally shared here on
A lot of technical people got really attached to our identities as smart kids. The software industry tends to reflect and reinforce this preoccupation at every turn, as seen in Netflix’s claim that “we look for the top 10 percent of global talent” or Coinbase’s desire to “hire the top 0.1 percent.” I would like to challenge us to set that baggage to the side and think about ourselves as normal people.
It can be humbling to think of yourself as a normal person. But most of us are, and there is nothing wrong with that. Even those of us who are certified geniuses on certain criteria are likely quite normal in other ways—kinesthetic, emotional, spatial, musical, linguistic, and so on.
Software engineering both selects for and develops certain types of intelligence, particularly around abstract reasoning, but nobody is born a great software engineer. Great engineers are made, not born.
I read this article twice last night. I haven't come across any article that spoke to my massive professional anxieties/impostor syndrome as well as this one.
One of my biggest pet peeves with being around smart people is when people explain things using big words. It feels like it takes so much more effort to understand tough concepts when they are saddled with jargon and ACT words.
I also enjoyed this point about building teams:
We place too much emphasis on individual agency and characteristics, and not enough on the systems that shape us and inform our behaviors.
I believe a whole slew of issues (candidates self-selecting out of the interview process, diversity of applicants, and more) would be improved simply by shifting the focus of hiring away from this inordinate emphasis on hiring the best people and realigning around the more reasonable and accurate right people.
It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams; where inclusivity is a given both for ethical reasons and because it raises the bar for performance for everyone. Inclusive culture is what meritocracy depends on.
When you lose your shit, you lose your leadership.
Eight Words Instead of Six
đź”— a linked post to
staticmade.com »
—
originally shared here on
When someone asks if you “need” something, there’s an implicit weight to that word. Need suggests dependency, maybe even weakness. It’s the difference between someone offering you food and asking if you’re hungry. One feels generous; the other feels like you have to admit to a deficit.
So I changed the question: “What’s the most important thing I can help you with this week?”
Noting this for the future.
This doesn’t just apply to the workplace, either. I’m in an era where my friends are having their second (or third+) child, and adding more burden on them by making them decide how I can help them with their burdens feels counterproductive.
Another case: my wife’s been busy with graduation at her school. Instead of asking her how I can help her deal with organizing the caps, gowns, diplomas, and tassels for 600+ students, I should have asked her what’s the most important thing I can help with.1
-
Even if the answer is unrelated to that task, it’s nice to know I can help her overall burden by doing things like “handle the kids’ after school transport” or “provide a shoulder rub” or “finish the laundry.” ↩
I want to make it clear any motivated human can execute the skills of a good manager — leadership comes from everywhere — and, more importantly, I believe managers tell you where you are. Leaders tell you where you are going. It’s a philosophy thing.
Five Behaviours to Become an Effective Staff-Plus Engineer
đź”— a linked post to
infoq.com »
—
originally shared here on
This talk helped me articulate a few key arguments that I can use to counter myself when in the throes of impostor syndrome-related attacks from my inner monologue.
Basically, a “staff-plus engineer” is anyone in a technical role that is higher than a senior engineer. These are sometimes referred to as principal engineers, staff engineers, etc.
The big difference between staff-plus and individual contributor path is that an IC role is one you go down when you truly want to contribute as an individual, often acquiring such an expertise in a specific domain that you just do your thing alone.
A staff-plus role requires collaboration, often leading teams, but always being the lynchpin which helps be the voice of technical leadership across multiple teams.
The responsibilities of a staff-plus role include (probably) writing and (definitely) reviewing code, providing technical direction, mentoring and sponsoring other engineers, providing engineering context to non-technical people, and being involved in strategic projects which aren’t shiny but are critical to the success of an organization.
I think I came across this talk at a timely point in my career. I have been tasked with doing staff-plus engineering work ever since starting my first company, and it’s honestly the stuff I love the most.
I’m not a developer who loves to write code. I love writing code because it results in a tool that makes someone’s life easier. What brings me joy is in doing the discovery work needed to clearly articulate the problem and charting a course that’ll lead us to a solution.
All I Need to Know About Engineering Leadership I Learned From Leave No Trace
đź”— a linked post to
jacobian.org »
—
originally shared here on
I saw Simon Willison share this article and thought it was too good not to share it myself.
We respect wildlife in the wilderness because we’re in their house. We don’t fully understand the complexity of most ecosystems, so we seek to minimize our impact on those ecosystems since we can’t always predict what outcomes our interactions with nature might have.
In software, many disastrous mistakes stem from not understanding why a system was built the way it was, but changing it anyway. It’s super common for a new leader to come in, see something they see as “useless”, and get rid of it – without understanding the implications. Good leaders make sure they understand before they mess around.
Or, as the footnote succinctly puts it: “find out, then fuck around.”
This article also taught me about Chesterton’s fence, a principle that says “don’t destroy what you don’t understand”.
What matters isn’t being applauded when you arrive — for that is common — but being missed when you leave.
There’s a world of difference between insisting on someone’s doing something and establishing an atmosphere in which that person can grow into wanting to do it.
The speed of the leader is the speed of the game.
Leading into a world of unknowns, a world where you don’t have the answer, the best you can do is to ask better questions, as well as help those around you to do the same.
Good listeners don't just absorb energy; they magnify it. They elevate it. They enrich it by the questions they ask and by the attention that they're paying to this person who's trying to communicate an important idea we're feeling.
Power doesn’t always corrupt. Power always reveals.
The Tim Ferriss Show - Jim Collins
đź”— a linked post to
tim.blog »
—
originally shared here on
I read Good to Great a few years ago, but I admittedly never finished it. After hearing this interview though, you'd better believe I'm gonna go back and pour over it.
This interview with Jim Collins was absolutely awe-inspiring. Among the nuggets I took away from this episode:
You should strive to be a "Level 5 Leader", which means you are simultaneously headstrong and humble. You have to put your organization before any personal gain.
Jim organizes his time according to the 50/30/20 rule, which means he spends 50% of his time in a given 365 day period on creative activities, 30% of his time teaching, and 20% of his time on everything else.
On that same vein, Jim has a spreadsheet where he tracks how many hours a day he gets creative pursuits, and in any given 365 day period, he has to have over 1000 total hours. He also tracks what he did on a given day, as well as a rating from +2 to -2 for how he felt on that day. I've been trying to do something similar with tracking the big three things I need to get done each day, and I think I should expand that out a little bit to include these variables.
You should not do what you’re good at, but do what you’re coded for. This really struck a chord with me, because I think I'm pretty good at developing, but I'm pretty sure I'm coded to be a leader.
There was a lot mentioned around the flywheel principle, and I think this is something we're just starting to see happen with our own business pursuits.
There's a ton in this episode, so I'm going to stop writing in order to let you start listening.
The Schmidt List: Moving from Development to Management with Ryan Johnson
đź”— a linked post to
schmidt-list.com »
—
originally shared here on
I had to laugh out loud when Ryan said, "Oh shoot, I'm giving away my entire playbook here," to which Kurt replied, "Don't worry, nobody listens to this show."
This episode of The Schmidt List (which you aught to subscribe to, by the way) was particularly timely as we are working to hire our first full-time employee at The Jed Mahonis Group that wasn't already a good friend of ours.
Some of the key interview questions I will (shamelessly) borrow and use in our upcoming interviews include:
What gets you excited to go to work every day?
You're looking for something other than "co-workers". Something related to the job itself is ideal.
What do you think of automated testing?
As Kurt put it, this is essentially an updated "tabs vs. spaces" question. The aim is to get the developer to walk you through their reasoning for one thing or the other, and regardless of their answer, the big takeaway is whether they can justify their position.
What are you excited about in tech?
This is in lieu of the classic "what is your current side project" question, which I've never really been a fan of for the reasons they mention in the episode. Instead, this question allows you to see if they are keeping up with the industry and have thoughts on its direction.
In addition to these hiring nuggets of wisdom, the rest of the episode is a fantastic resource for anyone who is going to be moving into a role of managing developers. Two thoughts I took away:
1) Empathy, above all else, is what makes a team flow. A manager needs to be empathetic to the struggles that an employee may be going through (including changing requirements, stresses outside of work, etc.). Equally important is ensuring team members are empathetic to the struggles that their manager may be going through (including changing requirements, stresses outside of work, etc.).
2) Giving negative feedback to reports is important, and it's time to stop being Minnesota Nice about it. Not giving negative feedback is simply narcissistic and selfish.
