Hacker News new | ask | show | jobs
by dnndev 1834 days ago
As a CEO and long time developer before then... its complicated. High performance teams are killed by managers unless they stay out of the way and then whats the point right? Managers are great for managing clients, but not devs.

Low performance, bare minimum devs, sure need reminding and pro-ding to get anything done... yes, you need managers to babysit.

Companies with heavy management usually have mediocre at best devs and little to no innovation. They have great sales and support - this keeps them alive.

Captain obvious here - there is no one size fits all. Do what makes sense at your org and take home a paycheck or leave and start your own business - there has never been a better time!

7 comments

'High performance teams are killed by managers unless they stay out of the way and then whats the point right'

The point is two-fold. First, creation and maintenance of a high performance team as the company grows is worth someone focusing on, not just hoping it happens organically (sometimes people, especially new hires, need to know "yes. You are really free to make this decision yourself. I'll back you on it." Likewise, sometimes people doing good work need someone who can spend the time to highlight the value of it to the rest of the business, to effect a promotion). Second, ensuring other needs of the business inform that high performance team, WITHOUT interrupting it, are also worth focusing on.

These are both true regardless of the environment, but become bigger needs the larger the company is.

"creation and maintenance of a high performance team"

Managers do this? right, right. I would say managers at best dont mess it up. Creation and maintenance of high performance team comes from within. The surrounding support certainly helps, but to say a manager creates and maintains this is a bit of a stretch.

"ensuring other needs of the business inform that high performance team"

I have found if it needs to be known or communicated it will happen. High performance teams are not just coders (another fail from managers) they are intelligent people who can read and write emails and know how to speak to other humans. This may be the stereotype of some hot pocket eating teenager in a closet from the movies but that is certainly not the case in most professional environments.

So for the first, I am explicitly describing managers in an agile, team lead style. But, yes. Managers, first and foremost, hire the team. Ideally from feedback, but ultimately the manager is responsible for the team's formation. But then the manager also has to help smooth out bumps along the way. Having someone objective who can help smooth out disagreements can be HUGE. Likewise someone who can give feedback to individuals; a large personality can be a huge asset to the team, but can also leave others feeling alienated; someone who can help carve out space for those others to speak up, and to help coach the person filling the room how to recognize that and also to carve out space for others, is immensely helpful. And maintenance includes progression, both for individuals and the team; devs are often focused on what they're working on, they're not evaluating how to get their work recognized, and more junior ones often aren't evaluating how to grow themselves. It also includes HR issues; having someone who can do the legwork for your Visa sponsorship, for instance, frees you to do real work. A good manager is basically the team's admin assistant as well.

For the second, of course they are. You have to take the two statements I made together. There is a spectrum; at one end are devs working on what they feel is important, but not knowing they're not working on what the business feels is important. At the other is the business deciding everything the devs do, oftentimes changing priorities every week. Having one person as a middleman there can be immensely helpful. That may look like a manager saying "Hey Bob. Jane has this need; work with her to understand and implement it", and handling everything off to a dev, but the point is that the manager, A. Gave Jane (and everyone else) one person to reach out to initially when it came to their needs of the team, B. Helped determine that Jane's need was a priority against all the other needs, and C. Gave Bob permission to ignore all other incoming requests and direct them back to the manager, to focus on Jane's need. That is not to say Bob is not reading and writing; it IS to say that Bob can benefit from someone keeping him from being interrupted by every person in the business with a need who thinks he might help.

This feels right. I also believe that what people need are LEADERS and not MANAGERS. I'm sure there are plenty of examples of the two on the web.

The challenge I see a lot of managers have is that they look to much at an engineer as a widget and not literal human that is just as capable as the manager (most the time). There are often times no lines between roles and responsibilities and every shop does that slightly different, and not based on some framework they masterly put together, but just something based on how the pieces fell in place with some help from previous experiences.

I just wanted to say also - _most_ engineering managers are not good managers. They were good engineers that are in the unfortunate process of the Peter Principle.

'High Performance Devs' I've found tend to build the things they want to build.

I've yet to meet the kind of superstar dev who is also superstar market and customer oriented.

That can be challenging as a lot of important innovation doesn't come from customer feedback and you need talented people to do those things as well.

This is very true. Most shops have an R&D team for long term innovation and other devs like myself who love customer feedback and want to deliver solutions now.
I have not heard this about "most shops", in fact I have never worked in an org with a functioning software R&D team (unless you count enterprise architects choosing vendors).
No but I've seen similar dynamics play out at most companies. Broadly, "product teams" focus on customer feedback and delivering value to customers, at the expense of technical debt and lots of fickle requests. "Infrastructure" teams are heavily insulated from customers and deal with a more long-term roadmap and fewer changing requirements.
Product and Engineering need to be peers in this regard.

I think Spolsky said it best about the dynamic between managers, product and developers

https://youtu.be/A3-ijSmDQ3c?t=983

just an observation: if you moved from developer to CEO without significant time as a Dev or Eng manager you have very different skills and focus. CEOs of all but the smallest companies are playing checkers; Dev Managers play chess. This isn't some sort of insult; we need to focus on individuals with distinct skill sets and characteristics. CEOs can't and shouldn't be concerned with this level of detail.

It's also uncharitable to split teams into either high-performance special ops teams vs. mediocre, low skill / low potential teams. Two trends make this distinction meaningless: GROWTH and SCALE. If these don't apply then you can totally let the team self-manage. FANG companies typically have all those rockstars you're looking for and multiple levels of technical management.

Google even tried to go without managers. They backpedaled pretty quickly. https://www.inc.com/scott-mautz/google-tried-to-prove-manage...
Even if CEOs "can't and shouldn't be concerned with [individuals with distinct skill sets and characters]" (not a point I'm conceding, what makes you think a CEO's job is "checkers" compared to the chess of a Dev Manager who is realistically 2-4 levels below them in the organization?
High performance teams are usually created by good management. If you change the management then bad management can easily undo that. My best managers have been deeply technical people with good people skills, an interest in management, and willingness to get out of the way and no longer make the decisions they made when they were a developer. Management is a lot more than babysitting it generally involves a lot of coordination up and down the organization to ensure the team is doing the right work in terms of organizational and customer priorities. Good management can give you what to work on while leaving you to decide the how.
The role of the manager is to ensure the team can get on with their jobs, to celebrate their success and have their back when things don't go according to plan. Unfortunately most manager can't help to start interfering with the team and go for a top down driven management style.
oh, and any given dev can switch from high performance to bare minimum depending on the project, week of the month, what they ate for dinner last night, etc.
Same could be said for a manager.. or a manager that gets bad devs or devs that get a bad manager. This is the value of a hands-on ceo that does not have their head in the sand.