Engineering management lessons (2014)

There are many things that can often use improving, especially at smaller companies. Process, architecture, deployment system, reduced meetings of team, optimizing the SLM software...it's easy to get overwhelmed, especially if you have a large team, or in my case, doing the job of a tech lead and engineering manager. It is a lot to swallow. Prioritizing the most important points on what is being tackled and communicating why is very important.

I've worked in larger organizations where communications got funneled through so many managers that any problem, once it was a cross-team or cross-department issue, got lost in a giant game of telephone.

A pretty significant issue that could have been solved by a single configuration property change took nearly a month to accomplish just because the problem got lost through a miss in communications in one link of the chain.

While I agree with the general point here, I'm not convinced priorities are necessarily the right was around. Talking to customers/users usually seems to end up paying off in the long run, even (perhaps especially) if it's a bit rambling. On the other hand, it's the regular ceremonial stuff that leaves me agitated and unable to focus afterwards.

* production vs process - you can spend resources on improving process(usually tooling) to improve production but this isn't always an easy knob to tune and can have diminishing returns. "Automate all the things" is how I know you don't know what you're talking about.

* DOTs - damage over time can be brutal, question every meeting and email that hits your team. Similarly- Engineers need large blocks of time to find flow and be effective(aka void rays). That 15 minute 2pm weekly check-in may seem trivial but you're pretty much nuking an afternoon's worth of productivity.

* macro vs micro - you generally need to spend time on both. Even Sr. engineers can benefit from occasional guidance because you should know more than them(see below). (knowledge != intelligence)

* bottlenecks/'stage III' production - you can have too many resources on something.

* Some resources are much better at certain tasks than others.

* situational awareness - know the executive roadmap, your roadmap, your internal customer's roadmaps, know 'the theory of how engineers are working in your org' and the reality. Know every project in your code repository. Know about most other possibly relevant open source technologies. Mostly this is just a lot of listening and reading. Be Omniscient

* 'strats/build-orders' - similar to the above, know how the industry/competitors solve the same problems your org has (but don't necessarily seek to copy them)

That said, treating people like RTS units is also a good way be disliked and ultimately be ineffective so you have to do the whole empathetic human thing.

My rule of thumb is that if you cannot estimate your work to some degree of confidence up front then you haven't spent enough due diligence time and the design before writing code. If your task is too complex to estimate then estimate a time boxed proof-of-concept and then turn around with a solid estimate at the end.

Its my personal belief that any programmer who expects a check from an employer or a client for unbounded unscoped scope work usually isnt unreasonable. Just like any other profession.