Slashdot Mirror
Transitioning From Developer To Management?
An anonymous reader writes "After 15+ years as a code monkey, mostly doing back-end systems design / development, I was surprised by recent developments at my workplace that have resulted in my being transitioned into a dual architect / managerial role within the next few weeks. While I am somewhat confident at this point in my career in my experience and training for an architect-type position, I have serious concerns about being able to properly fulfill the role as manager. Aside from 'Become a manager in 2 days' type books, what resources would you recommend I look to for guidance in this transition?"
Project+ and CAPM are geared towards your need, with the PMP focused more towards very well-seasoned project managers.
I just recently became a lead and know from the projects I've worked on, that I would be a better manager. So I'm finally doing something about it and pursuing the project management path. I just picked up the All-in-One CAPM/PMP exam guide and the recommended study path for the CAPM is a month. As with most jobs you'll learn the bulk from doing it, but the cert won't hurt and may give you the jump start and mind set to help you get started.
some folks love certs and some hate them, but I've never had issue with getting them and I've always learned a few things along the way no matter how well I thought I knew a particular topic.
Creationists are a lot like zombies. Slow, but powerful and numerous. And they all want to eat our brains.
As an engineer / architect who has had to deal with some frustrating management (most of it indirect, fortunately), I've found these two blogs to be both enlightening and useful for feeding to managers. Rands especially, as a developer who moved into management with a purpose, has some very insightful commentary. He's also recently published a book, which I'm planning on giving to some of my favorite managers (who despite their sincere desire to treat us well, sometimes have a hard time understanding the geeks they herd.)
f tware-Engineering/dp/159059844X)
Rands on Management: http://www.randsinrepose.com/cat_management.html
Rands's Book: http://managinghumans.com/ (Direct to Amazon: http://www.amazon.com/Managing-Humans-Humorous-So
Joel on Software: http://www.joelonsoftware.com/
Good luck! It's great to hear about people who care enough to want to do it right.
I had this really stupid class in college called "Organizational Behavior". To this day, I still don't know what I was supposed to learn in that class. Despite the class being boring and pointless, the professor was actually a very interesting guy. He said something one time that always stuck with me: "Leadership is the reduction of uncertainty." If you think about it, it's true: your employees have to be certain they are doing the right thing, be certain of the requirements, and be certain they will get the support they need. Your customers have to be certain that you're meeting their needs. If you can do all those things, than you're probably doing a good job.
I also agree with the "good manager = good buffer" statement, but I'd even take it a step further. Great managers have requirements analysts, support personnel, etc. get the information from the customer. Then they form a plan and assign tasks to their development team. In my experience, this works rather well.
I'm totally going off on a tangent... back to your original question. Karl Wiegers' Software Requirements and More About Software Requirements are both geared towards requirements analysis, but have a lot of info that anybody in IT (and especially project managers) would find pretty useful... Both are worth checking out. I've also heard lots of praise for The Mythical Man-Month, but I've never gotten a chance to read it. Besides those, I would skip books on general management techniques and go straight for anything on software engineering or project management. The R.S. Pressman website probably has even more recommendations.
When I was leading a development team I considered my primary role to be an umbrella for the developers. I did my best (frequently not good enough) to insulate them from the assorted pressures of the management team (political, revenue/sales, deadline etc...).
All this is sort of avoiding the primary, fundamental issue: when you are a manager you have the power (and responsibility) to fire someone.
This is the real rub. Can you do it?
In my case, I came to a decision that I needed to fire a developer who was completely inadequate to the position. Only this: she was one of the sweetest, kindest people I have ever met. Additionally, if I were to let her go, she would be sent back to India - forcing her husband to also go back. It would have been devastating to them.
So what to do? She was not able to perform her job function and it was costing the company revenue. On the other hand, I wouldn't have been surprised to see Bambi walk up and eat out of her hand whilst blue jays perched on her shoulder (this is how kind hearted and sweet the girl was).
And I had to fire her.
So I tried.
And failed.
I came to find out this about myself: when confronted with a tearful employee who says she'll do anything, including work for half the salary if only I won't fire her - I cave.
This turned out, in the long run, to be one of the worst management decisions I've ever made. I agreed to keep her on at a reduced salary. She continued to perform inadequately but over time she had been with the company long enough that dismissing her wasn't an option.
Everything she wrote ended up having to be completely rewritten and she wasn't learning from experience or coaching. Even though she was working at a reduced salary, she ended up costing the company a high multiple of her salary in lost productivity, alienated clients and rework costs.
So what was the "right" thing to do in that situation? On the one hand, I felt a moral imperative to help this kind, tender and wonderful person. On the other, I had a commitment and moral responsibility to the company I worked for.
Finally, I reached the correct solution: I resigned my position as manager of the team.
As I'm sure you've noticed, I am personally not suited for management. I will never put myself in that situation again.
Just because I'm a talented developer, doesn't mean that I have the ability to make tough managerial decisions when they are called for. Those are two different skill sets, and one of the reasons that I tend to not resent my managers. Firing someone is brutal, and unless you are comfortable with those types of decisions and _sticking_with_them_ I strongly recommend that you avoid the managerial gig and stay in development.
-Clay
Drinking habits can be dangerous. You can choke on the cloth and the nuns will wonder where their clothes are.
I am currently finishing that same class. I agree, I have little clue as to what I was supposed to actually learn.
Mythical Man Month is a good read, I highly recommend it. Sure, it is full of things that you'll say "no duh" when you get done reading it, but you'll have read it and you'll know for certain not to make those mistakes. Plus you can whip it out when other managers ask you about software stuff and you'll look impressive because they haven't read it.
I would say this: be lazy. Try to avoid doing anything that makes more work for you and your team than is necessary. That doesn't mean that you should avoid work... it just means that you need to apply yourself and your team in the most efficient way possible.
I would also say this, don't be afraid to be certain of something and never be afraid to be proven wrong. If someone proves you wrong, concede the point and move on. Don't get stuck following a bad decision with justifications. Get back on track and move on.
Good luck too!
42 - So long and thanks for all the fish.
This guy, "Hacker X," signed on to do a bunch of stuff, and just flat-out didn't do it. He was working from a remote location much of the time, which made it harder to realize what was going on, but once we caught on, and he didn't improve after remonstrating with him, we knew he had to go.
The catch was, how do we fire him? By email? By phone? This seemed a little cold since, well, he was a friend. Heck, it would be cold even if he wasn't a friend.
It just so happened that I was going to a conference I knew he'd also attend, and the plan was to fire him there. Once there, however, I was torn -- fire him at the start, and have him upset through the conference, or wait until the end (but personally be sweating it out through the whole conference). My gf at the time was there, and I talked it through with her a couple of times and decided to wait to the end.
So, just before lunch on the final day I pull "Hacker X" aside and tell him he's fired. If anything, he's relieved -- he'd known he'd been a useless drag, and felt terrible about it. I get him to sign some paperwork, and he tries to refuse his severance. I get him to take it anyhow.
I get back to the cluster of people waiting for lunch, and my gf is there, and asks me how it went. "Better than expected." Other folks ask what's going on, and I explain -- "I just had to fire a friend, Hacker X. Never had to fire anyone, much less a friend. I was pretty freaked out, but he took it well." Another guy in the group who'd made the transition from techie to manager a couple years before me says "yeah, been there before, done that." "What, you had to fire a friend?" "No, I had to fire Hacker X..."