Bar_Code

At a high level think of Hack as Typescript for PHP. Although they completely replaced some data structures (i.e. arrays) that couldn't be made performant in their PHP implementation. Just like their customized version of MySQL, Facebook is stuck with Hack. It's too ingrained. Their customizations to MySQL became very specific to Facebook and they pretty much stopped open sourcing changes. Hack has taken the same path. They will never outsource Hack fully because some of the customization are only applicable to them.

There is a nice compilation of articles in a github repo, divided by topic. https://github.com/charlax/engineering-management Leadership is an expansive topic and I don't think it's possible to nail it. "Turn the Ship Around" I think really nails the strategy of Functional Leadership, plus it's a true story. Keep in mind that Leadership and Management are two very different topics that people often conflate.

Ticket Evolution | New York, NY | ONSITE & REMOTE We are the NASDAQ of the ticketing industry. We have millions of tickets available in our marketplace and don't own a single one. We are small, growing, and profitable. This is an opportunity to join a stable startup. We are looking for Senior level experience in Ruby/Rails and/or Node. Experience with scaling, microservices, and ecommerce is strongly preferred. Our API is hit over 1K time per second on average. Please contact me at [hackerjobs - AT - ticketevolution.com]

EQ is definitely something that can help one in life, particularly leadership. He is certainly correct that EQ is not scientifically valid. Goleman took the valid work of others and "interpreted" it to create/support EI. It probably should be called a theory, a process, a framework, whatever. After learning about EQ, and practicing it, my leadership abilities took off. I've taught it to dozens of engineers who say they are now much more influential, better team players, and better communicators. Some have said it's changed their careers. EQ is most certainly a thing, just not a trait. It's sort of like saying being a good listener (active listening, listening with intent) is not a thing because you can't measure it.

I think you should be afraid of only knowing one technology/language. You should strive to at least play with one new technology/language per year. "language" can be flexible, like CSS, SQL, HTML. It doesn't have to be things like Go, Erlang, or Haskel. It would be nice to be at a company that encourages that. Even if you just know why people like certain languages, that would be helpful.

You're in tech, so an experience you have that is over 5 years is largely useless. What you need to leverage is your wisdom gained from the 15 years of experience. Wisdom is what separates you from someone with "only" 5 years of experience, but who can code almost as good as you and work for less. So no, there is no respect for experience beyond a number of years.

I've been in tech for over 25 years and I am more engaged than ever in what I am doing. I've been a programmer (front and back end), sysadmin, dba, network engineer, project manager, and product manager. Looking back, through all of that learning, I was becoming a better leader. About 3 years ago I stopped coding and became a full time leader in tech. I now optimize people and teams, not code and systems.

I'm still very much involved in architecting systems, which is where wisdom comes in. If I can't guide them in how to build something, chances are I can provide equal value in telling them how NOT to build something.

I would advise pursuing a role where you can impart your wisdom and leverage your many years of experience to help others and make an impact that way.

Positive Intelligence. I was able to "label" my personality and all of those of my teams and reports. I know how I need to change, and know what drives the people I work with. I never thought of the over achiever as a problem, but they "prevent" others from stepping up. Emotional Intelligence 2.0. Much easier read than the original. We are humans, driven by emotion, we need to be smart about it.

The first time I started as a developer on 1 team and evolved into a director of 6 teams, each one a new business unit. I contributed code to most of the teams I managed. I was not the one primarily responsible. I learned a lot as I went, I was very inexperienced for what was required. I learned a lot of ways NOT to do things. If I had to sum things up, I would say before I was helping "connect the dots", now I am connecting all the dots.

This time around I am purely a leader and the one primarily in charge of tech. My almost exclusive focus from the start is the people. I have to start over on most things that I evolved through previously. - I've taken on the responsibility to create and define our culture. My last job I assisted in this area. - Make sure developers have the tools to be productive. This includes reliable wifi, internet, good coffee, software, furniture, TVs for monitoring, AV system for presenting, conference rooms. - I've had to earn the trust of the existing people. Previously almost everyone was new on my teams and I hired them, so there was largely trust from the beginning. - there is churn, like you are going through. I had almost no churn on my teams previously that was not purposeful. I have to explain why the churn is ok and expected. - I have to teach developers to focus first on "why" they are building a feature, rather than "what" they are building and "how". This helps dev and product see eye to eye. - I have to teach how to interview, run meetings, do agile right, communicate. Focus on building the right things over building things right. Teach people when to be tactical and when to be strategic.

Ultimately, I have to step up and fill the gaps until I can hire and/or train people to assist in that area. Before I had help all along. For example, I've interviewed about 200 candidates in 6 months for many different roles (developer, DBA, sysadmin, product, data). Mainly because interviewing was probably the most important thing I could be doing for the company and the developers. I'd be happy to go into more detail offline.

I know what you are going through. My last job was at Shutterstock, which went from 50 people to 700 in 5 years. I'm doing it again now, we went from 60 to 90 people in 6 months.

I have found that there are inflection points whenever things double. That could be people, revenue, office space, customers, etc. When this happens, "debt" affects the company. You're probably much more familiar with tech debt, and probably architectural debt. Maybe less familiar with organizational and cultural debt. You simply can't do things the way you always have, they don't scale. http://steveblank.com/2015/05/19/organizational-debt-is-like...

Change is inevitable and required. If not managed, it could sink you. Some people will quit regardless, they were probably not the right people for the next phase. At first you don't need teams (you have 1 team), then you need to have 2 teams, them more. This change is disruptive and affects productivity and morale. Read up on team maturity models (not CMM), it will help knowing what phases you will be going through. http://www.businessballs.com/tuckmanformingstormingnormingpe...

I presented the team maturity models too my devs the last time we restructured the teams. Multiple people came to me proudly stating they were in the "storming" phase, which essentially is when you argue a lot. They knew it was a phase, and frustration was reduced.

You do need leadership as you grow. A leader is not your best developer. The HR manager may scare you because they are a "manager", not a "leader". Good managers and leader can toggle between both roles. Too many people are great managers and not leaders. Know the difference between a manager and leader, know which ones you are missing. http://changingminds.org/disciplines/leadership/articles/man...

At my daughter's school I offered to run a computer club, speak in class, redo their website, all for free. I said I would pay for all teaching materials. The head of technology rejected all offers. His response, "We use technology to teach, not teach technology". "A computer club would only teach kids to hack". "Besides, Cisco sponsored one years ago to teach about routers and it was poorly attended". I wish it was just a matter of funding.