Not Technical? That could be a great thing for project managers. Here’s how to manage a software development team without a technical background.
Let’s face it… Bosses and managers often get a bad rap (especially the ones that are perceived by their teams to be less technically qualified than they are themselves).
But the fact is, those who “run the show” have to have a different skill set than the team members they manage.
If you’re a boss, you know that to be true, but you might still be wondering how to effectively manage a technical team of software developers without a technical background.
Doing so may sound dubious, but it’s very possible. And, if you out your back into it, non-technical managers can earn big-time respect from their tech savvy teams.
Here’s how to manage a software development team without technical credentials...
Manage a Software Development Team: The Big Picture
First, it’s important to understand that project management is a really big deal. To effectively manage a project from concept to completion is an intense undertaking, and one that often goes undersung by product/software developers.
If you’re struggling to win the faith of your dev team, the best way to earn their respect is to make their lives easier. And the best way to do that is through a consistent and structured process.
You see, the biggest secret to effective technical project management is that the greatest managerial traits are totally non-technical. While technical training can sharpen your skills, coding knowledge is 100% NOT necessary to running a seamless development project.
Practice Process (because your product will only be as good as your process is)
Roadmapping is key to a great process...
Managing a software development requires structure, and structure requires something like a map. A product development roadmap, to be precise, and a dang good process in place to follow it.
You’ll find that a great process not only makes YOUR job easier, but it makes coding easier for your developers, too. No matter who they are, your team craves a clear path towards your goal and if you can give it to them, you’ll be a successful manager.
TIP: Your product development roadmap can be home to many mini-roadmaps, too, each of them leading to a different piece of your overall goal. In other words, different applications or features can be mapped independently so long as the same process is used to execute each feature segmented from the original goal.
Creating and adhering to a carefully planned roadmap will keep your process strong, but it also gives you a unique ability to check-up on your team.
Using your product development roadmap as a guide, you can accurately monitor and evaluate the performance of your developers which, as the manager, enables you to do your job more effectively.
You can also do things like this:
isolate the parts of your approach that are working (and those that are not)
identify stumbling points and plan for avoiding them in future iterations
track progress towards, and make accurate projections for completion
And one more key thing...
When using a solid roadmap, you can use it as a yardstick for measuring the performance of your developers themselves. This is not to suggest that you should use it to back your coders into a corner, but that you can use it as a proof of expectations.
If your team has agreed to reach a certain point at a certain time, but you don’t achieve that goal, something has gone wrong. Maybe it’s with your coders. Maybe it’s with the product. Or maybe it’s with your process.
The point is, there’s a problem. And if you listen to your roadmap, it will tell you where it is.
What else is great company to a solid roadmap?
A mock-up. A work-flow model. Or, better yet, a prototype.
Often, you and your developers can work together to create a thorough prototype of the product to be built. This cultivates team spirit (really, it does), and it ensures a unified understanding of the project going forward.
That unity is crucial to a strong Agile process. And a strong Agile process does a lot of things for you including enabling you to control the level of work you strap to your coders during any given iteration. Because, of course, you want progress fast, but you can’t overwhelm your developers with impossible expectations.
It doesn’t require a technical background to know that impossible expectations can’t be met. It’s your job as project manager to ensure your team can work effectively without getting burned out.
Is there a better way?
If production speed is extra critical, instead of asking your dev team to build everything from scratch, find out if you already own anything that can be repurposed. Adapting existing code can accelerate your process big time.
Review each task in your roadmap to be sure nothing in that backlog is already in place. If so, or if that thing is not a fundamental or imperative piece of the product software, don’t spend time building it.
The Next Phase...
Divide and Conquer
Here’s where software development gets even more fun-- the coding part. Now, this is not necessarily your area, nor should it be, but it is your job to oversee it. Or, at least, it’s your job to enforce a process strong enough to ensure that great code is the only possible outcome of your team’s coding process.
You can do that with the aforementioned tools and with a nose for delegating tasks to your team members. If it works for your team, you can also implement an established criteria with which your team members divide work equally (relatively speaking) among themselves.
But don’t let your coders become dev-hogs. The good of the product outweighs the good of just about anything else, and your developers control the good of your product. Don’t let them get bored.
Ensure that exciting tasks get fairly assigned among your developers, and that the monotonous or brain-melting items are not consistently landing on the same coder's task-list.
This way, your developers won’t get type-cast but, rather, they’ll continue to mature into more diverse, more adaptable coders.
Remember, sharing is caring!
Challenge your team work together, to share the good and the less-good backlog items, and, ultimately, to grow into better coders.
In this area, coding experience is almost irrelevant. Instead, your leadership skills are instrumental. It’s you that understands how to guide and encourage your team; it’s you who pushes their creativity, you who enforces the process, and you who speaks for the product.
Honestly, you deserve some heartfelt applause for that…
Now you know that you shouldn’t lose any time building software that doesn’t HAVE to be built, nor skirmishing over which coder is going to take-on which project. So what’s next?
To put it bluntly, you have to test the tarnation out of everything you intend to put into production.
Investing in Testing!
Depending upon your operation, your team can write and perform tests for their team members’ code, or you can automate the testing process.
Thoroughly testing software should be the norm. If you are not testing your code, you’re doing it wrong.
If you let this step slide simply because you yourself don’t have the development experience required to test code, remember that your team is there for YOU. Use your coders as your consultants, hire a QA department, or invest in automated testing.
In either case, you have to be positive that your code is solid, that it does everything you wrote it to, and that it won’t break even if you try to break it. Interact with your product and implement necessary feedback before you deploy it to production.
Unit testing is absolutely necessary.
Code review is absolutely necessary (this includes reviewing your code for weakness, especially if you’re building software that will store private or protected data).
As it happens, a solid peer code review strengthens your code, your product, your team, your team members, and, consequently, it’s also good for team spirit. :-)
Establish a peer review process that will catch imperfect code before it wreaks havoc in production. Make everyone accountable for their part in the development process, and tool code until it satisfies expectations of design and performance.
So now you have some software…
You’ve reviewed your product, and approved your product, and now you have a perfect piece of software. Whether it’s a just a slice of your overall goal or it’s the whole enchilada (baked and smothered), you’ve made it!
But you might not be done…
Before you push your software out of the nest and into the real world, you have to have a safety net in place. You know, because it might not take-off like you expect. You might have to roll it back.
This plan can be intensely involved or it can be as simple as the push of a button. That depends on your project, but a rollback plan must be in place. Despite the care you’re team has put into the code so far, the fact is, things go wrong, and software deploys can be volatile. Always be prepared to revert new code.
The Summit
NOW your software is done. You’ve tested, reviewed, deployed, perfected, and everyone deserves a genuine pat on the back.
YOU, however, are not done yet…
As the project manager, you now have to review the entire process…
Whether your project went off without a hitch or it put you through the ringer, you have to understand why. Review each item, each iteration, and analyze these components with your team.
Here are some questions you’ll want to ask…
Did we achieve our overall goal?
Did our overall goal change during development and, if so, why?
How accurate were our original estimations of time and effort?
What is our working velocity? Can we add more work to iterations? Do we need less work in iterations to be effective?
How can we increase our working velocity?
Did anything unexpected happen?
Was the code buggy and, if so, why?
It’s also important for you to assess the overall performance of your team and your individual team members. You can do this independently of your team, together with your team members, or both!
Keep lines of communication open.
Be approachable to your team members.
A great software development process is strengthened by constructive feedback and accountability.
TIP: People perform better when they know they’re going to be held accountable for their performance. This doesn’t mean you have to micromanage them or become the secret police, but it means you should build your process around accountability. It means, you need to establish habits that enforce accountability.
And what about that product?
Now that your software has made it into the real world, how is it performing? Are there surprises? Do you need to make improvements? Are there code or feature gaps that need to be filled?
Review the aftermath of the full project development experience, and refine your process accordingly.
Wrap Up…
In summary, you got this.
While no one will tell you technical experience is a bad thing, it’s far from the most important thing. In fact, you don’t need it at all to be a successful software project manager.
Instead, the secret to a strong product launch is a well-oiled development process and a project manager who is not afraid of leadership.
Honor your non-technical skills, review and refine every approach, enforce accountability, and you will be a effect product development manager.
Are you ready to take your product development to the next level?
This free email course can help >>
