Developer to Manager: What Are You Doing Wrong?

In the world of technology, a funny thing happens. People who have technical backgrounds, technical experience, technical education climb the ranks within the company and then become technical managers. Now, think about this for a minute. A person with a technical background who has only ever worked in technology is now expected to have the skills, the wherewithal, and the understanding of how to no longer manage technology, but to manage people. Handling people and handling technology are two very different things, in case anyone is unclear about that.

The developer who now finds himself in the interesting situation of becoming a manager will go on to, simply put, either become a successful manager or an unsuccessful manager. And it should be noted that just because he's climbed the ranks within the company, doesn't necessarily mean he was first a successful developer. Unsuccessful developers and successful developers go on to become both successful and unsuccessful managers and you can't necessarily predict which way it will go.

Let's examine the possibilities here and see who ultimately ends up being the most successful and why.

The Unsuccessful Developer Who Became a Successful Manager

First, just because someone wasn't a successful developer doesn't mean they won't be a successful manager. Many times, this developer could have the technical experience and knowledge, possibly have a high EQ (emotional intelligence), and he may be good at assessing people's skills, and navigating office politics. This could be exactly the reason he/she, despite not being the best developer, was able to rise through the ranks at the company. Perhaps this developer has an excellent grasp on business logic because he spent so much time growing and learning at the same company. This may make him an excellent manager for handling the team inside the company, but what he may lack is the outside knowledge of what is going on in the technical industry.

It's likely that he has kept up with the tech stack that the company is currently using, but may not be well versed in the latest technological developments or be the best person to advise the company on tech from a high level. This manager may try to do POCs on newer technologies and see what can be made to work, change the team, or rely on the company's already approved vendors to continue working. Typically, these already approved vendors are actually recruiting companies or simply recruiting companies masquerading as consulting companies and primarily handle recruiting only. These recruiters are not the ones who have worked in technology or even have a technical staff below them helping to vet the recruits.

So, what will the successful manager do? He will bring in a consulting vendor that has a track record of proven success with world-renowned experts and an ability to successfully deliver projects time and time again. A company of experts such as ours will approach the situation much differently than the typical recruiting/consulting vendor. Our company will come in and meet first-hand with the team and the managers and understand the tech and the business from the ground up. Our team will then be able to tailor a plan specific to not only the tech stack, but specific to the business needs of the company itself. We will assess the current architecture and devise a plan that is the most cost effective and beneficial to the company overall.

To illustrate this, I will share an example of a client where our team was brought in for 18 months and ended up staying only six weeks - by choice! The client brought us a project that was to last 18 months and had a budget of more than $10 million. The project was to move the company from web forms applications to MVC. Once our team came in and reviewed the current web forms and the current needs of the company as well as the future needs, we advised them that the application did not need to be rewritten at all. You see, they were wanting to move everything to MVC along with a CQRS pattern that was being implemented incorrectly for more than a year. Whereas, in actuality the previous app they were using was easily scalable to the extent needed given the both the current and future state of the business. (Trust me, I know the benefits MVC brings to the table. And I know the pros and cons of CQRS and where it makes sense or not. In fact, we have moved many clients from Web Forms to MVC as well as implemented CQRS in many projects successfully. However, in this case, it was just not the right thing to do).

This was not a company that was going after the Facebook or Twitter kind of audience or user base. They could have had separate applications for customers and servers for those and kept separate ones for larger customers and smaller ones without any issues. A simple move from web forms to MVC was better for testability and good code, but it ultimately wasn't the right move for this particular company. The company ran its own tests on this advice and ended up in agreement with our conclusion. In six weeks, our team was out the door and the client saved tens of millions of dollars in not implementing a project that wouldn't work and wasn't necessary. The project that was scheduled to take years to complete, was completed in just a few weeks. The business was not hampered by a failing project and the customers were happy because the changes made improved the company's overall functionality. The company now had the option to reallocate the money saved toward its core business, improving its bottom line.

The lesson here as the manager is that it's always best to be aware of what you don't know and don't be afraid to ask for help. If you align yourself with the right kind of experts who are willing to help make you successful, then both you and the company will ultimately succeed. Our company understands that doing the right thing for the client is always more valuable than making the money from projects that shouldn't be done. Other recruiting companies continue growing and keep their bench stacked with developers so they can keep placing them and making sales goals, but they are never actually consider if this work should be done in the first place! We don't keep a bench, so our company actually needs to complete projects and have our experts move onto the next client or project. We can, of course, continue to provide whatever support the client needs following its completion, but it's more important that the project is completed. It's all about supporting the company first, not just that manager. Once that company or project is successful, the manager will automatically be successful too.

Final manager takeaway: Don't feel pressured to get it done all alone and isolate yourself, it's too costly.

The Successful Developer Who Became an Unsuccessful Manager

In this instance, the developer likely has the ego that he/she was a successful developer and so assumes he/she will be a successful manager. Quite (un)surprisingly, this doesn't work. As previously noted, the skills needed to be successful at tech and at management are quite different. Typically, these managers will try to work within the company's system of already approved vendors because they believe it will be too challenging to bring in a new company for a few reasons:

• the manager will lose credit for the success of the project if an outside team delivers it.
• the company and its consultants will embarrass the current employees on their technical knowledge; and
• the manager will be overconfident in his management abilities due to his previous success and he may underplay the importance of what the business needs to accomplish.

Let's examine these reasons here. The first reason is that the manager feels he will share the credit or lose the credit entirely for the success of the project. This will not happen with a company like ours. Our team is coming in only to facilitate, help the project succeed and then move on to the next project or client. We firmly believe the credit should stay with the employees of the company and no one else. We also don't believe in shaming the employees on their technical knowledge. Our company works on all sorts of technologies, from archaic frameworks to the latest cutting edge tech. We examine what architecture the client has in place and review the goals of the client and provide advice, training, and a plan for improving, updating, or completely changing the architecture in a way that makes sense for that business. We will also conduct on-site training for the team and make sure they are implementing best practices and have reviewed the foundational concepts before moving on to teaching new ones. It's important that the client have the tools to maintain the project once our team leaves as well.

Lastly, the manager may underplay the importance of the business and its goals because he thinks he knows what is best for the company given his success in the technical field. This is extremely short-sighted and works well for no one. Perhaps the business is housing a brittle code base for decades that hasn't been well-tested or well-architected and the business requirements keep changing. The manager must remain in sync with what the business is trying to accomplish because ultimately the tech is there to serve the business needs, not the other way around! To help with this, our team comes in and does a health check on the code base to see where you are and fix a lot of issues in the already existing framework in order to improve the architecture overall. It's easy to rewrite everything and still not get it right; whereas our team will work to refactor a lot of code and do design changes that can make the already existing architecture infinitely better.

Let's consider this example from a different client. The top architect of this client was a fan of a certain well-known developer who had written books and created his own framework. Within a month of us coming in, we were able to bring in this developer and have him work on the architect's project on a contract basis. This architect later told me that he learned more in six months working with this developer and our team than in his entire career! He admitted most of what he was doing was completely wrong and he didn't realize he wasn't upholding the fundamentals until our team of experts came in. A lesson learned many times over is that managers are made successful or unsuccessful by the team underneath them.

Another real-life example is Steven Sinofsky of Microsoft who had been successful many times with multiple Microsoft products before he was put in charge of the Windows team. He was the brains behind Windows Vista. He planned to make it the coolest Windows version ever created; However somewhere things went terribly wrong. Not many Microsoft partners were able to release the correct drivers by the time Vista was released and most early adopters experienced major issues attempting to use it. It also didn't end up being anywhere close to the best Windows version ever released because he made the mistake of thinking that he knew best and didn't pay attention to what the consumers were actually wanting in the product or what had made the past products successful. The lesson here is that even someone at this level can create a product that was a failure. His mistake was in assuming that because he had previous success, Vista would automatically be successful too.

Final manager takeaway: Don't let your past success hinder your future success.

Advice for All Current and Future Managers

Here is some parting advice to all current and future managers:

• Ask for help when you need it:

  Good managers bring legacy knowledge and experience with the code base. They know how the systems run within the company and they know who to talk to within the corporation to get things done. The right relationships must be in place and the right approval channels navigated to ultimately get a project to succeed. This is hugely necessary and successful managers know how to handle all of this.

  What good managers also know is that they don't bring to the table is what experts do. Our team of experts bring their technical expertise and the experience of having worked with so many different companies. The POCs that the client is doing today, we've already done it. We've already had production level code on it and we can make it work. We have a network that can bring you the top experts in any technology you want to work on.

• If the company succeeds, you will succeed.

  Managers are competitive and get into company politics and forget that at the end of the day, it's only about the company. It's about the company's success and if company is successful, then you will be successful.

  There have been situations where we went in and some of the executives were not in favor of doing the right thing and we realized that the only person who is open to using us is a developer or an architect. A few years later, it became apparent that those executives made big mistakes putting tens of millions of dollars in some recruiting company that did not take them to success and later they were fired or they quit their jobs. Whereas, if you look back, the same architects or developers who worked with us were able to move up as executives in the same company because of the success of our team of experts.

• Call us before it's a 911 call :)

  There have been plenty of instances where we are brought in way late in the game when the house is under fire and we have still been successful. Most of the time, we can come in and take care of things in a timely fashion, but expecting overnight success even with an expert team is hard because so much groundwork must be done. Real success is forged when the proper foundation and expectations are set. It truly must be a team effort between the company and the manager and our team to get everyone the results they want.

I hope these tips were helpful to you wherever you are in your career, whether you are currently a developer or a manager, or even in tech at all. Click these links to learn more about our consulting and training services so our team can help make you a successful manager.