For me a great thing to learn from software development is daily integration builds - whatever work is being done, build it as the complete sellable product every day. This way you will get good at making the saleable product
sorta. as someone who is an EM, so i guess take the bias with a grain of salt, the difference between a really good EM, and someone who warms a seat is astounding. the really good ones have strong opinions, can coach well on a variety of topics (e.g effective communication, organizational thinking), and understand the technicals at least from a level of where you can see how your direct reports are doing. they also understand the economics/business of a company and can foresee which teams are dead-ends so they can offer good advice to direct reports to grow careers.
the ones who warm seats are glorified project managers. no real advice beyond "should we do standups, when are retros" and basics like running a board, or taking notes during meetings. usually pretty disconnected from the day to day, no strong opinions on the actual hard stuff, just topical high level advice. plenty of those in the field, and its unfortunate because its not a hard science, so they tend to BS their ways into these positions and make a lot of money.
either way, managers aren't going anywhere and no amount of code will automate them away.
background:
- what i liked about management was leverage, and being able to influence strategy, etc more than i could as a regular IC. Also coaching and growing people.
- what i was "meh" on was the very time consuming mechanics of mgmt, 1/1s, perf reviews, sprint mechanics, status reports, interfacing with HR machinery etc.
So i wanted to create an IC role where ideally I could have large scale influence, and still participate in the strategy and high level decision making at a company. I did NOT want to go back to IC to be left alone to code hard things in a corner. Thats a totally valid path too that ive heard from some, but not for me, so just calling that out.
So creating the role:
- you need to be at a company that believes in (or has already established) an IC leadership track that parallels the management track. That means there should be IC levels that match (in pay and responsibility) to manager, director, VP levels. Facebook, google, big tech all do this now. Creating and paying for a non-management ladder is kind of the "put your money where you mouth is" - if the company wont do this, they wont take IC leaders seriously when push comes to shove.
- one way to do it is to pair an IC role with a senior mgmt. eg, there is an eng Director in charge of payments, so there should be a single technical IC in charge of payments tech. They work together on shaping the overall strategy for their unit - the EM & IC lead are responsible for the same domain. Notably, these folk dont have to be on a specific delivery team, rather they work with each delivery team in their unit as needed.
- the senior roles come with real responsibility and accountability... if you are the payments lead IC, you're making technical decisions with consequences in the millions or 10s of millions of $$, in terms of risk but also in terms of engineering opportunity cost. A rough proxy for "how senior is this person" is "what would it cost us if they were wrong". Make that clear to the business side, take responsibility, justify decisions in business/commercial terms. It will be received well and you will be taken much more seriously as a strategic stakeholder.
- you can still coach and grow people, just on your own terms without the formal reporting structure. Better to me.
anyway enough rambling - and YMMV this is all advice that applies to what I wanted to do with my role. Others may have different goals. Happy to talk more if you have questions, email in profile.
This is also the reason why penalizing performance reviews don't work. It causes lower morale within the time and nobody really feels aligned with the company. Everyone is out there looking out for themselves.
But there are either better ways to do these things, or they still require coercive (supervisory) activity.
So planning. yeah it's important. Have a clear goal and work out what you need to achieve it. Frankly the new intern can achieve most of that in one day, and all the senior team can easily do it. And prioritise it. The hard part is where you have multiple parts in parallel. Sometimes people think they are some Moriarty style genius who can direct each part to develop and land with precision six months in the future. Total bill ox. If you aren't doing daily integrations you aren't co-ordinating and so you aren't "planning".
Yeah there is a function of logistics - but that's spreadsheets and gaming out scenarios - not a "management task" but certainly a "management input" - and if instead of giving it solely to managers you just published it to the whole org such logistics would be available to increase discussion and awareness (ie the workers would understand the plan better and not need managers)
Resource allocators - pretty much as above - plans, resource budget all different sides of same coin.
Aligning goals ... that's incentives. That's easy - pay me. Otherwise ... looks a lot like coercion.
I wish there were a consistent answer to this, but part of the reason management is hard (and I won't deny there's plenty of useless managers) is that people is very variable and you need to adjust your approach depending on the organization composition.
> So planning. yeah it's important. Have a clear goal and work out what you need to achieve it. Frankly the new intern can achieve most of that in one day, and all the senior team can easily do it. And prioritise it.
There are plenty of teams and situation where this is hardly "easy", particularly at very large companies. Relative priorities are not always clear, many teams demanding your team's attention and understanding what is "best" for the company and company goals, the team and individuals is non-trivial. You need to align all of those. It requires constant communication (hence why managers spend time on meetings, reading presentations, reading roadmaps from other teams, 1:1s with their team to understand their personal goals, etc);
> and if instead of giving it solely to managers you just published it to the whole org such logistics would be available to increase discussion and awareness (ie the workers would understand the plan better and not need managers)
Even in organizations where the information is open and all documentation, meeting notes, spreadsheets, etc; are open people struggle to understand and some just want the summary (I'd say most); they don't want to know how the sausage is made outside maybe have an understanding of the process (and some not even that).
> Aligning goals ... that's incentives. That's easy - pay me. Otherwise ... looks a lot like coercion.
Maybe is that easy for you. A lot of people want something else from their careers and as a manager you have to align what the organization wants with what the individual(s) and teams want as much as is reasonable to maximize their satisfaction (retention, performance, etc; is better if you achieve this).
We are talking about software, and software is eating the world - but the great thing about software is that you can deploy it in different environments and monitor the results. Now of course "prod is different" but, the "difficult" bits you are talking about are all "how can we alignnincentices so that the ten big projects all land successfully and deliver in two years". You cannot. No matter how big brained you are no matter how many meetings. It's impossible.
So just integrate the whole fucking lot early, run a series of prod like data through it, build a couple of teams that run this integrations and they tell everyone the current state of the ten big projects. Everyone will align around those test rigs pretty damn quickly, and the ceo only needs to beast one team regularly to make sure they are not favouring anyone too much.
Or even better run two test rigs or theee and triangulate the results.
Expensive yes but damn it will get results.
And it removes a huge layer of "management status reports". What is the status of the ten projects? go look at each test rig.
As for "people don't want to read the open docs" - that's not what Inmean. people don't want to read the minutes of the board meeting because the decision has already been taken and their views don't matter. Democracy works differently - people will take an interest when their votes directly influence which stupid project gets ten million this year. And importantly politicians will arise internally - who will explain and advocate for certain projects amoung the voting base - they will be like FDR and gain power and be called traitors to their class.
And finally - no. aligning incentives is easy. Pay me.
If you are basically saying we should throw our hands up and give up at any kind of project management, then yeah, a significant part of engineering management is not needed. You seem to be basically saying all can be solved by http://programming-motherfucker.com/ and I get it, sometimes as a sw engineer that's all I wanted to do, but the reality is that often you need coordination and project management to get results you (or the organization) wants in a timely fashion.
> Democracy works differently - people will take an interest when their votes directly influence which stupid project gets ten million this year.
Democracy is super slow for decision-making and not everyone is equally qualified or invested to have a vote. I'm not talking about even "board meetings" here. I'm talking about having a freaking doc with 10 potential projects a given team could tackle this year. Who is going to curate those 10 projects? justify why they are needed or relevant that we should spend time on them? who is going to decide who works on what? as I said, democracy and consensus-building is slow and often will just mean "the most opinionated or stronger personality wins". You need a skilled eng manager to navigate complex conversations and keep everyone aligned on why a given project was picked.
> And finally - no. aligning incentives is easy. Pay me.
I guess this sums it up. You personally may only care about being paid, but that's not everyone. Your whole view is a simplistic take on what it takes to make you specifically happy and that's why you think is easy.
For co-ordination it is waaaay better to have some overarching vision clearly articulated (maybe a blog to keep it simple) and then an awful lot of integration early and often.
Any group of management that thinks it can do-ordinate better than actually integrating against working software needs a reality check. If the organisation finds what is integrating is not what it wants (pretty much all projects) then early delivery finds the answer quickly
I mean this is totally what Agile Methods means. It's just the higher up / programme management process does not recognise this chnage - they think things can be planned - they can't they can only be predicted and predictions chnaged based on up to date information.
And it cannot be that they understand it because their salaries depend on it.
And maybe I am being mercenary- but paying people almost always gains their compliance for a while. and either you take that short while as a given or you only hire people whose personal vision aligns to the desired company vision - sadly i think we will see far more "political companies" - not for example democrat / republican but climate change / social justice aware - and your personal views will be meaningful at higher levels. but that is probably true anyhow, it's just implicit