1

I started a new role as a lead developer at a new company. They have been using an external agency for all development work and I need to ultimately take over the whole of IT and moving into a CTO role then start to build new products.

The current IT department and products, in general, are not in a bad state. We need to hire some staff, audit and test all the platforms and start to work on implementing ISO etc as well as other procedures.

I'm a little stuck on how to formally write down what I feel we should do in what priority and how to actually get them to agree to implement my new ideas.

What would be the best approach?

3
  • 1
    Have you experience of using 6 Sigma methodology? Have a look, there are lots of resources there to help you solve problems like "company currently doe snot meet ISO" or "X process is not robust". Best way to implement change is via the well established route of: Define, Measure, Analyze, Improve, Control.
    – John
    Apr 19 '16 at 10:47
  • 1
    To be brutally honest, you make it sound like you're not qualified for the job you signed up for. You're essentially asking us to sketch out an entire roadmap for a service transition as well as advice on getting user/employee buy-in. What is your management experience?
    – Lilienthal
    Apr 19 '16 at 11:21
  • I have experience building teams and products but always from scratch, I have never inherited a product and managed an external company. Apr 19 '16 at 11:57
3

I would suggest that you start by grabbing a stack of post-it notes and a pen, or stand in front of a blank whiteboard with a pen. Or both, if there are lots of things you want to change.

Brainstorm. Write down every single thing you can think of that you want to change, without thinking much about whether each thing is reasonable and when. Don't worry about it looking silly; some things will, especially a few minutes after writing them down, and that's okay. There are no stupid ideas at this point.

Once you have a large stack of raw ideas, break up and consolidate points as appropriate. Only after that do you start worrying about sorting them (by priority, practicality, cost, or whatever other metric makes sense in your particular situation). Cull the ones that are clearly not reasonable but keep the ones that might be reasonable particularly in light of your overall goals.

The result will be a very rough first draft outline for what to do and in what order. Once you have this first draft, you need to flesh out each point somewhat. The goal here is simply to make sure that someone else reading the document will have some idea of what you want to change and how implementing the change will benefit the business. Specifically, you do not want to spend much time at this point thinking about how to implement the change.

Once that is done, you will have a rough draft that you can take to management to get approval on in general terms before you start figuring out how to approach implementing each individual change on the list and where the interdependencies might be. Especially because you are new to the company, you want to take the document to management and get approval on it in general terms before you spend too much time figuring out exactly how to change points that may or may not be in line with the company's overall business plans. At that point you may want to look at methodologies such as for example Six Sigma suggested by JJosaur in a comment to the question.

2
  • +1, I would say that OP should be looking at using something like a Affinity Diagram for such a large number of changes with lots of peoples input as opposed to a brainstorm which may get out of hand quickly and not allow everyone to contribute equally.
    – John
    Apr 19 '16 at 12:01
  • @JJosaur The purpose of the brainstorm is simply to gather and write down very raw ideas. Other approaches may indeed be equally or more valid in the OP's case, depending on circumstances. Thanks for the upvote.
    – user
    Apr 19 '16 at 12:04

Not the answer you're looking for? Browse other questions tagged .