Software development is a team sport. Your individual performance doesn't matter as much as the performance of your whole team and company.
By im...
For further actions, you may consider blocking this person and/or reporting abuse
People need other people to look up to. People need leaders; and indeed, one does not need to occupy a management role to lead in engineering. However, if you want to have even more impact, I advise you to put a face and a name as author of the published articles. That will also "10x" your credibility and influenceability (not sure this is a word).
Thanks, Mihnea! That's a great point. It's not that I shy from putting my face and name on an article, but I see some tradeoffs between posting as an individual vs posting as a pseudo-"brand".
The main one is that, as a person, I have multiple interests (for example, frontend development, Agile methodologies, personal productivity, and ergonomics, to name a few). I wrote a lot about some of them in the past, and I'll for sure write about some other in the future. This dilutes the focus for the reader. You may be interested in how to advance your career as a deveoper but not interested in ergonomics or frontend.
As the TrueSeniorDev "brand", I'm probably losing a bit of personal connection, but I'm also giving the reader a guarantee that all the articles published under this brand will be focused on growing professionally as a developer and advancing your career. Which, I hope, may actually improve the credibility in the long run.
But it's for sure not an easy, black-or-white choice, and I'm still torn between the two. So your feedback is very valuable.
I see. That makes a good Preface; i feel like I needed that explanation - and I'll keep that in mind when i face a branded signature, rather than a name. Thanks for all these personal details!
Ok let me argue the toss here. We know some people are dramatically better at somethings that others. Sports make this perfectly visible to everyone. So we can expect people to be 10x better at something than someone else who is "good" at it. Professional/amateur football (soccer) shows us this every weekend.
The 10x individuals your are talking about here seem to be some kind of power mad, individually focused cohort that might be "rockstars" and "divas" all at the same time. You know, people like Steve Jobs, hell to work with but capable of greatness. I don't think those people work well in most teams, at the end of the day, to be Steve J you also need to be able to influence and control, in all other cases you are just a loud arrogant noise.
For me, the most important thing in teams I run is a lack of ego and a sense of passion for the business outcome. Preferably a very underdeveloped "everyone must do it this way, I'm right" attitude too.
I don't believe your multiplication example scales where compared to addition - I don't believe you'd get higher multiples across the gamut of tasks developers need to do in a consistent way. In other words: I believe great processes, architecture and planning can probably double or triple the performance of a team and you should strive for this, but not at the expense of saying no one can be dramatically better than anyone else and trying to slow them down because you think this.
I think a leader should accommodate the skills of the team, if someone is massively more productive use it; don't fire everyone else and try to hire a full team of people as productive as this unusually good developer; and don't slow this person down and wrap them in red tape. Leading here is about ensuring the individual participates as a member of the team and the team performs as well as possible.
Everyone on a soccer team can score a goal, but it's mostly strikers that do. They won't be able to do that without the rest of the team doing their part too.
Hi Mike,
Thanks for such a well-thought comment. I love how it complements the article and I very much agree with what you say. People can be outstanding at something and it's great to have such a star in your team. And I'd never equalize the team to the lowest common denominator, by avoiding hiring such stars or slowing them down.
The "divas" are real, though. There are players who risk tricky shots instead of passing the ball, for the sake of their own stats and stardom. And there are players who use their star power to motivate, mentor, and challenge their colleagues, boosting the performance of the whole team. So I couldn't agree more that running a team with a passion for the business outcome and a lack of ego is a critical job of a manager.
The only thing I'd argue about is that multiplication doesn't scale. I believe it scales a lot and not only for process, architecture, and planning, but also for motivation, training, tooling, communication, focusing on the outcomes, and many other areas. Imagine implementing a design system that speeds-up building new UIs by 30% in a company with 300 developers. You'd have to be a 90x dev to match that impact. (Plus be able to understand the context of several dozens of projects and communicate with tens of stakeholders at once.)
The sports analogy starts to break a bit when it comes to scaling because sport teams are small. The better analogy here is military. For a force of hundreds or thousands, tactics, supply chain, intelligence, and equipment trump the number of Rambo-like supersoldiers in the force.
That said, a military is also a great example of an emphasis on individual training, so I again agree with you that understanding and accommodating the skills of team members is an important job of a manager. And boosting the performance of the team doesn't have to come at a cost of limiting individual performance. However, if they conflict, the team performance wins.
Yes I've definitely met the divas, and the worst of those are people who are just zealots and think that they are cleverer than everyone else, but are really just highly opionated - often about something that isn't end user focused.
I also hesitated to write my initial comment because I know the point you are making and agree with it. I've been a startup CTO since 2000 and have been successful and unsuccessful at building products. Because of my preferences and my style I'm better suited to directing smaller teams and to accommodate this I've usually created smaller Team sized independent squads - but that's just not an option for many businesses.
Makes perfect sense. And I'm glad that you decided to comment. It was a great discussion! 🙇
Great read! I've been so focused on just building my skillset (beginner, self-taught), all with the mindset of an individual contributor. I always envisioned software engineering as a very solitary and siloed profession, but reality is that they're more like critical cells of an organism, each playing an important role in driving toward an end result. That result only comes to pass when all are working in conjunction with each other.
As a mental health therapist and business coach, I've spent many hours working with people on effective communication and helping teams develop a common vision they can drive toward. This gave me an idea of what it looks like to be a valuable team member in the software engineering space. Thanks!
Thanks! I'm happy that you liked it.
I think that the myth of software engineering being a solitary profession is actually rooted in reality - but an outdated one. Modern software engineering is so user-centric and done with such a huge teams, that nowadays it's more about interacting with people than with machines. So your skills put you in a very good position to grow even further as a software developer!
You make a really good point. I only kinda disagree with the last part :
I'd argue that if you do all of this you're essentially doing the job of a tech lead, and either you won't have time to do your job as a developer, or you'll be working twice as many hours (making you only a 5x dev on a per hour basis 🤣).
Still I'll try to apply your advice, it's really tempting to just try and do the work yourself because you know you can, even though in the long run it's less effective than helping the team.
I didn't mean that you have to contribute to all of the areas I mentioned. Rather that it should be possible to contribute to any of them, even without an official title.
Also, you shouldn't try to do it completely on your own. If you have a reasonable manager, they should understand the benefits of your contribution to the team, and support you in your efforts - and understand that these efforts take time. Syncing with your manager will also help you contribute where it really counts instead of guessing on your own.
But you're also right that it is, to some degree, doing a job of a tech lead (or a principal developer, or an architect, or an engineering manager - depending on which area you'll choose to contribute to). But this is the reality of how you advance your career. To become a tech lead, you need to do some of the tech lead's work first, both to learn how to do it and to prove to your company that you can do it.