Slashdot Mirror
Ask Slashdot: Transitioning From Developer To Executive?
First time accepted submitter fivevibe writes "I'm about to switch from a position where I did hands on development to one where I will be building and managing technical team. I will be responsible for designing and implementing the company's overall tech strategy. I am excited about this move but also nervous. It will require a different focus than I had up to this point, different skills, and different orientation. What should I be learning, reading, thinking about in order to make this transition successfully and avoid growing pointy hair?"
Here are some advice:
1) Read the Theory of Constraints, and use it to organize your team
2) Read about Emotional Intelligence
3) Do not try to do everything, find what has value for your position, and concentrate on this
4) Do not micromanage. If you don't know agility, try to follow a Scrum certification, I know it's dumb, but the concepts are very important. The aim is to let people self-organize, and your role is to verify their throughput.
Your role as a manager is to be sure that the work is delivered, and help the team to do that.
It means:
- communicate to your team and to your hierarchy. Everything should be clear for everybody. If it's not clear, you aren't doing your job.
- focus on your work. Stop trying to command people,. If they don't know what they have to do, it means that you didn't communicate clearly.
- remove all possible impediments to the team (you need to protect them from your hierarchy)
- be tough but fair with your team (do not let people abuse you)
Try to use the following values:
- clarity (everybody must know what they have to do, not how to do it, also act transparently)
- feedback (if something goes wrong, fix it as soon as possible. For example, detect bugs or specification inconstencies ASAP)
- trust (trust your team, let them do as they prefer, but check that the work is done correctly and in the time they promised, do not force your planning on them, let your team decide how they want to be organized, help them if they don't know)
- responsibility. Make people feel responsible about their work. If you take all the responsibility, your team won't care about your project. If you take no responsibility, the team will feel that you don't do anything for them.
I have found it is a very good exercise to let the programmers tell me how long it is going to take to get the job done. We do it in a group setting with all the peers involved. The programmers don't want to look bad among their peers so they usually set realistic dates and work hard to meet them. Each week we review progress in a group setting. This seems to work very well.
School Headmasters (among many others) have managed to do that in a lot of places over the last couple of centuries and leading craftsmen over a much longer period than that. The answer is not to do it as two full time jobs but one job with many elements.
One key thing to understand is that right now you are great with technology, but management isn't about technology. It's about people. The people you manage, your peers and leaders in other areas of the organization. People can be a lot harder to figure out than technology.
My advice is this.
1. Read "Behind Closed Doors". Probably the best book I read as a new manager. Wish I had read it before I made the leap. http://www.amazon.com/Behind-Closed-Doors-Management-Programmers/dp/0976694026/ref=sr_1_3?s=books&ie=UTF8&qid=1324299173&sr=1-3
2. The best part of my day was working with the techies I managed. Listen to them, make time for them, and stay as closed to what they are building as possible. But also remember you are their boss. You will have to force them to make bad technical choices to meet a deadline, and will have to ask them to work nights and weekends. Make sure it is mutual respect, but at the end of the day your word has to be final.
3. Understand how the company makes money. Not just selling a product or service, but really learn this. Because at the end of the day, if a company doesn't make money it will cease to be. This is valuable to learn because the more you can translate how your team fits into the revenue stream, the better leverage you will have. For example, there are two ways to look at how a team "adds value". You will either directly participate in the revenue stream, being on a product team, e-commerce, etc. Or you will be involved with "cost avoidance", meaning the company is spending less because of your efforts. This can be either time savings or accuracy improvements. The later is not too hard to quantify. If you know how many hours are saved in a process you write, add up the salaries of those who did that process, subtracting the salaries of your team. For example, if you save 100 people an hour a day with your process, with each person making minimum wage ($7.25). There are an average of 260 work days per year. This translates into 100 * 260 * 7.25 = $185,000 in savings per year. If you have one full time employee supporting the app, at 80k per year, your application is saving the company ~ 100k per year. Now of course this does not include hardware, software, training, donut expenses. It's not intended to. It is intended to get people's attention, justify funding for your team, and facilitate you getting more in next year's budget.
4. Keep good notes. You may become an Outlook operator in your new line of work. Be sure to keep important emails that record decisions. Send out your understanding of a meeting after the meeting to make sure everyone heard the same thing as you. Keep a notebook or tablet and take tons of notes in meetings. If you are in several meetings per day it can be very easy to forget who said what when. This can be important when decisions are questioned later on. Or if things go bad, accountability can be shared among the entire executive team and not focused as the new manager.
5. Hire really good people. Know that interviews are about finding the right fit for a team as well as their technical abilities. If you do this right, the rest of your work-live is exponentially easier. Ask good questions, do quizes and tech screenings. Listen to the questions a candidate asks. But trust your gut instincts.
Bottom line is remember to keep your sense of humor and humility. This can be one of the most challenging and rewarding things you will ever do, managing others. You are their boss, responsible for their work lives, and a major influencer of their personal lives and financial futures.
It's not necessarily that those coders suck, it's more that it's impossible to estimate the time to do some non-trivial new task, because there may or may not be hidden depths.
Almost completely false. Estimation is just not that hard in almost all cases, yet bring it up and people will focus on the 1% of cases that are genuinely hard rather as if that was the usual case rather than the rare exception.
Go read "Rapid Development" again for some simple and effective estimation practices. Invest in the discipline of reviewing your own work and look for objective metrics. During one phase of my career I was able to identify that creating a single fully documented and tested core model class in C++ took about a week. Based on that I could look at a UML diagram and give a pretty reasonable estimate of the time it would take to implement something. If you aren't designing or otherwise scoping features you're not in a position to make any claims about estimation anyway, because you have made no attempt to do even the most basic steps required to generate estimates.
This demonstrably false belief that "estimation is hard in the typical case" is just an excuse people use to avoid learning a new and valuable skill. That said, being able to estimate at all makes you the one-eyed person in the kingdom of the blind, which can be pretty damned uncomfortable, as well as frustrating.
Blasphemy is a human right. Blasphemophobia kills.
Most "good" managers I've met are not good because of skills or training, but from simply being personable, intelligent, and able to solve problems (real world problems, generally very different from the types of problems programmers face). It takes a minimal amount of training to get a good manager, as long as you start with the right person, who possesses those innate abilities.
As someone who recently graduated from business school I have to disagree with respect to "minimal amount of training". The more formal training the better. Especially since the poster seems to indicate an executive angle not just tech management. The MBA stuff would really help out since it offers a good overall understanding of all the pieces of an organization. Business school and MBAs are not what most around here think, I was just as guilty. One of the things that made business school lots of fun for me was seeing just how ignorant and biased I had been with respect to management, marketing, etc.
You're generalizing; there are plenty of people I know up close who were great developers and now great managers. One of them is my boss and I'll tell you what he did to get my utmost respect.
First of all, this guy was a brilliant developer. Both design and coding were always rock solid. Then when the boys from the board asked him to become a manager, we (the grunts) didn't really notice a lot. Sure, he started coding a lot less, and within half a year stopped doing that entirely. Often we wondered what he was doing all day, until one day I spoke to one the founders of the company and he was saying the guy was a bit of a pain in the ass for them. Turns out his day job was nothing less than constantly defending us, making sure we could do our job without being harassed by upper management, and creating support for any of the ideas we (the developers) came up with. In short, instead of being a manager to report to upper management, my boss focuses on ways to make us as productive and happy as we can be.
I can't thank him enough for that.
Please login to access my lawn