As Director of Engineering my main job was to remove blockers for the team, be the engineering manager, which means training, education, 1on1, performance reviews; as well keep an eye and lead the technology directorion.

I wasn’t getting enough time actually coding, if that did happen it was probably not a good thing, as director of engineering you should be involved on the software development process at a high level.

I actually had several roles with scaling levels of responsibility. Technical speaking my role as Director of Engineering was very much an engineering management role, hiring, firing, performance reviews ... you know the fun stuff.

Before that I had a role as Practice lead, which was def more technical and less management, but still a good introduction in terms of mentoring and training.

Softskills become essential as you dig more into management, knowing how to resolve conflicts, give feedback, etc.

Honestly, my background and the career path planning I had a the company I used to work wasn't the best it was more of sink or swim kinda mentality.

Ownership and attitude, doesn’t matter what the specialty is (FE, BE, FS) an engineer has a good sense of ownership of the solutions they are building, is always trying to make things better and treats its work with respect.

In my mind is a higher standard of the work we put out there

Distribution is relatively simple. The tricky part is planning, organizing and actually writing the book.

My advice before you start reaching out to publishers is the following:

• Build an outline which should have the Book Description, chapters and general structure

Pick a chapter other than the first one / introduction and put a deaf together.

That will help you structure and solidify what kinda of book you are writing, a better ideas of the effort and double as prep work since you have content that publishers will typically ask for as part of any proposal.

Let me start with being good a coding doesn't make you a good developer. A good developer things pass the code and is:

• Capable of communicating clearly: We have to deal with people no matter what, be it to get requirements to other people on the team.

• Business driven:We are paid to solve problems, our tool of choice is code, but not everything needs or can be solved coding; a great developer thinks on terms of the business first.

• Think before you code: Great developers consider the implications and edge cases before you code and make sure to document those limitations.

• Documentation: No matter what write documentation for your code.

• Attitude: The days of the grumpy developer that forces his opinion down everyones throat is gone, you might be right but having a positive attitude is important too.

• Continuous learning: Great developers have an insatiable thirst for learning and continuing to improve.

Depends on what specific leadership role was being considered. The way I have structured before there where 2 main leadership roles available for developers:

• Practice Lead: 70/30 split between development and management, middle management responsibilities like performance reviews, 1on1s, more involvement with the DoE day to day.
• Team Lead: The technical go to person for a specific team/project keeps the team on track and works closely with the project management.

Overall ownership and having a good developer mindset, both are essential for leadership as well wanting to do the role and take the responsibility of leading.

Did you always have the soft skills or did you work on it? If so how did you improve?
Absolutely not, my soft skills and even communication skills where poor at the beginning, as for improving them reading and a lot of introspection, as well asking for feedback.

I highly recommend this book as a starting point:
oreilly.com/library/view/soft-skil...

I actually wrote an article about the difference between CTO, Director of Engineering and VP of Engineering, forbes.com/sites/forbestechcouncil...

CTO

I like to describe this role as “The Hacker in Chief.” He or she is the leading architect, thinker, researcher, tester and tinkerer. Typically, the CTO will be one of the company co-founders.

VP Of Engineering

The difference between the VPE and the CTO can be described in a single word: execution.

VPEs are often great people managers, solid engineers and they are responsible for making every member of the engineering team successful. Traditionally, the following makes up the VPE's core responsibilities:

• People management

• Technical leadership

• Strategy development

• Execution of the business vision

The VPE is also responsible for managing the budget of the engineering department and should be the lead recruiter when it comes to looking at engineering candidates.

Director Of Engineering

We mentioned that one of the core responsibilities of the VPE is people management. However, there can be a significant constraint when it comes to this task -- and that is managing teams of up to ten (ideally six) people. Anything larger than that represents a significant drop in effectiveness.

This is where the director of engineering comes into play. They are typically an extension of the VPE seat and report directly to them. They are in charge of managing subsets of the engineering staff and helping the VPE with the execution and technical leadership of the company.