I was recently a lead developer and asked to manage the team by the team. I noticed running the team can't be generalized in one size fits all, some people just want clear descriptions of projects to work and and some people want to over engineer and make a 1 day thing a 2 month job no matter how you say it should be done. Problem is how do you handle a engineer that says something can't be done in 2 hours? Well so far I have sat down with them and showed them it can be done in 2 hours, beyond that argue with me enough and I may be forced to rethink your employment. It hasn't come to that yet. most of the room follows my instructions and we are kicking butt, there's a small part of the room that wants to be dramatic about everything, their computer isn't good enough "needs 64 gigs of ram for their command line", the tools aren't good enough etc etc - basically they have management envy and that's my only struggle right now.
Let’s have no managers, instead of managers with no engineering experience
61–70 of 150 posts
Re: Let’s have no managers, instead of managers with no engineering experience
#62How about no managers with no management experience. I've seen countless senior devs promoted to eng/dev management roles who were either clearly not ready for the role or were simply not the personality to "lead".
Re: Let’s have no managers, instead of managers with no engineering experience
#63Earlier quoted context omitted.
My experience is that a good non-technical manager will develop a relationship with a member of their team that fills that gap. Most of the "good" manangers I've worked for were good because of their soft skills.
I mentioned that approach, yes. But it can backfire if the team member is makes big mistakes. The non-technical manager will have a hard time identifying bad decisions before they blow up.
>I mentioned that approach, yes. But it can backfire if the team member is makes big mistakes. The non-technical manager will have a hard time identifying bad decisions before they blow up.
Why do you assume an out of date and no longer practicing manager will have a better chance of catching errors than causing them? There is a reason you hire experts and that reason is not so you can ignore them. If you're afraid of a single point of failure then you foster a collaborative blame-free culture where the engineers cross check each other.
I've had managers who would agree with you and generally they were bad managers who hadn't realized they were no longer Senior ICs.
Re: Let’s have no managers, instead of managers with no engineering experience
#64I tend to agree that managers of engineers should have engineering experience. I think my reasons would differ from those of the author and many other engineers: it's much less charitable toward engineers. One of the best reasons to select managers who have been engineers, in my opinion, is because they know how much bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices.…
> I tend to agree that managers of engineers should have engineering experience. What about managers who have had experience like a decade ago and don't do much tech experience anymore. I am stuck in such management chain at work where some guy up top thinks he is technical enough to dictate solutions based on couple conference youtube videos that he watches. Half knowledge and false sense of technical prowess is mor…
Most of the technology in use today isn't that different from what it was 10 years ago. It's a bit faster and has slightly different packaging. Any manager who last did engineering as an individual contributor ten years ago should be perfectly fine engaging in a technical discussion today at the level a manager should be doing so.
Re: Let’s have no managers, instead of managers with no engineering experience
#65Earlier quoted context omitted.
That's not true in general, I've been in environments where a team of 10+ very motivated individuals worked together without a manager. It's not common though.
But you still have people doing the job of a manager. Someone has to set meetings, someone has to call out issues, someone has to communicate with upper management and other teams. No-manager really means distributed management or an informal manager. Because the essential work a manager does has to be done by someone.
Sure, that work still has to be done. But if you start off by thinking of it as "the job of a manager" then you're assuming your conclusion.
Re: Let’s have no managers, instead of managers with no engineering experience
#66Earlier quoted context omitted.
I've never had a scrum master across 7-8 companies. Usually it was a rotating role, or a manager/tech lead. But certainly not one person dedicated to it.
Yeah, it's supposed to be a role for a dev to play for 10 minutes a day. Unfortunately I've seen people with it as a job title. They were the absolute joke you'd expect.
spotify seems to have a few professional scrum masters and it seems to work for them. I'm less interested in typical cynicism and more interested in how this gets done -well-. Any spotifier's care to comment on having fulltime scrum masters?
edit: It seems they are called "Agile Coach"es.. is that any different?
Re: Let’s have no managers, instead of managers with no engineering experience
#67I often institute a “just” $1 jar. Anytime “why don’t we just” or “it’s just” is uttered you have to put a dollar into the jar. This applies to engineers, managers, myself, everyone. The idea is breaking the habit of trivializing work that isn’t. Something like a dollar jar is fairly effective as a notifier but doesn’t necessarily replace the habit with a better one. Nevertheless the game itself seems to help even if…
I like this idea. I wish more of the places I have worked had explicit guidelines around how to work as a team (e.g. don't trivialize work that isn't). It doesn't take many poor timed comments to shut down a team's discussion.
Re: Let’s have no managers, instead of managers with no engineering experience
#68> It’s better to have no management than unqualified management. If you’ve ever been on a project with more than 1 or 2 people without a manager—or where the manager doesn’t do their job—you would know how insane this sounds. It does not work. Once you’re coordinating groups of people you need a manager to keep them working together towards a common goal.
The best teams I've been on have done well without much management at all. Mostly the managers were there to shield the team, the rest of the time the managers just got out of the way.
On the very best projects, individuals will step up and lead for a while, then decide to do other things and let someone else run the show a little. Maybe it will be feature ownership, or to handle a different phase of a product in its ship cycle. (Meanwhile there will be managers behind the scenes, hopefully not many, making sure that forms are getting filled out, HR duties are attended to, and nonsense meetings are canceled and kept canceled).
Most of the places I've worked could have used less management. A lot less.
Re: Let’s have no managers, instead of managers with no engineering experience
#69Sometimes we engineers do a poor job of communicating complexity: we have un-communicated assumptions that we think the listening party shares. Which sometimes lead to this: "You could prepend the words “it’s just” to anything, it’s not going to change the fact that you sound completely ignorant and will ignore any challenges that your team communicates to you." I have often found it effective to counter "just-justif…
> "Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases", "See, that's exactly why we shouldn't write any/so many tests!" - A product owner I know...
"Manual QA then? That will be even slower than automated..."
Re: Let’s have no managers, instead of managers with no engineering experience
#70Example? I’ve experienced too many instances of just-justification, where a manager has said something like, “it’s just JSON”, or “it’s just UI”, or “it’s just talking to the backend”. This not only unravels their credibility in knowing anything about software, but it also devalues the work that a software developer needs to do to build a working product.
Well, I've had engineer colleagues use that kind of language at me. It's a type of bullying really, and it doesn't necessarily correlate with technical cluelessness.