Loading...
Answers
MenuHow can I manage my developers' performance if I don't understand IT?
Answers
Whenever you assign them a task, break down the task into small chunks. Make the chunks as small as you can (within reason, and to the extent that your knowledge allows), and tell your devs that if any chunks seem large, that they should further break those chunks down into bite size pieces.
For instance, for the overall task of making a new webpage, _you_ might break it down as follows:
1) Set up a database
2) Make a form that takes user email, name, and phone number and adds them to database
3) Have our site send an email to everyone above the age of 50 each week
When your devs take a look at it, _they_ might further break down the third step into:
A) Set up an email service
B) Connect it to the client database
C) Figure out how to query the database for certain users
D) Have it send emails to users over 50
You can keep using Asana, or you could use something like Trello which might make more sense for a small company, and might be easier to understand and track by yourself. In Trello you'd set up 4 columns titled, "To Do", "Doing", "Ready for Review", "Approved" (or combine the last two into "Done")
You might want to tell them to only have tasks in the "Doing" column if they/re actually sitting at their desk working on it. For instance: not to leave a task in "Doing" overnight after work. That way you can actually see what they're working on and how long it takes, but that might be overly micro-manager-y
At the end of each day / week when you review the tasks completed, look for ones that took a longer time than average (since, on average, all the tasks should be broken down into sub-tasks of approximately the same difficulty). Ask them about those tasks and why they took longer to do. It may be because they neglected to further break it down into chunks as you had asked (in which case you ask them to do that next time), or it may be that some unexpected snag came up, or it may be a hard task that can't be further broken down.
In any case, listen to their explanation and you should be able to tell if it sounds reasonable, and if it sounds fishy, google the problem they say they encountered. You'll be able to get a better feel of their work ethic and honesty by how they answer the question, without worrying as much about what their actual words are. Make sure that when you ask for more details about why a task took longer, you don't do it in a probing way. Make sure they understand that you're doing it for your own learning and to help predict and properly plan future timelines.
Hello,
I've worked on software development projects for several years. I occupied different positions, from developer to team leader and project manager.
From my experience, you don't need to have similar competencies than your employee to be able to supervise his or her work.
However, you do need to be able to evaluate the solution proposals (for example, if a particular piece of software, when complete will resolve your business need), the work estimates and the quality of results.
To measure the efficiency of the developers, for each project you will need to answer two questions:
1. Is the proposed solution the most fitted, considering the alternatives?
2. Are the developers using the minimal amount of time to achieve the required quality?
For the first question, your developers should be able to explain you, in layman's terms, the different alternatives to achieve the solution, the pros and cons, and why they are advocating for one particular alternative. Generally speaking, the high level description of a software project shouldn't be obscure for a someone with business experience and a minimal description of the technologies involved. If you can't understand them, then there may be a problem with the developers' qualifications or work attitude.
The second question may be somewhat more difficult to answer. Control comes at a cost, so you need to find the trade-off between excessive control on one extreme and lack of visibility on the other. The developers should be able to explain you the tasks they need to perform to deliver the solution, and the work estimates should be agreed upon with you. As time goes by, and you track the time of tasks through Asana and other tools, you should be able to validate new estimates based on previous work on similar tasks. You may also use benchmarks on software development for comparison purposes, especially for simple and repetitive tasks, common to many software development project.
If you don't have the time available to be involved on project management, you may consider the option to hire an additional person for the role. But I would recommend this if the new person can also add value to your software development project (for example, by bringing seniority to the team and development capabilities to the team, not just as a supervisor). Otherwise, it may be an unjustified overhead.
If you have any follow up questions, I'll be happy to help through a call.
Regards.
I am going to start by saying that hiring someone to oversee the progress of 2 resources is a bit of an overkill. Also, it is important to understand what kind of development they do for you. I am going to assume it's some sort of a web tool, in any case something that has an interface, with features that are easily evaluated by a non technical person.
I have led quite a few teams so far and there were a few cases in which I wasn't very well acquainted to what they were doing, at least at first.
What helped me gain some control and some confidence in the work they were doing was an Agile approach. Of course, I am not talking about a full Agile implementation, but the Sprint approach to building software is a very handy trick.
Basically what you want to do is set up with them a feature backlog - things that you want them to develop in the near future. After that, as my predecessors have already said, ask your developers to break the features into smaller tasks, none bigger than 8h. If it's bigger, in 95% of the cases it can be broken further.
Now establish your sprint length - it's usually 2 weeks. The trick is that at the end of the 2 weeks, you developers release a piece of working code. It may not be complete, but it has to be working.
You plan with them the 2 weeks, based on their own estimation of the broken down tasks - so basically you keep adding tasks to the sprint list until the sprint capacity is full. In your case, sprint capacity would be 2 devs * 8h/day * 10 days.
Don't worry if, in the beginning you will not be so sure on their estimates... given time you will start to get a real feeling of how much tasks should take without having a real IT background. Keep on asking all the questions you need to understand the details of their estimations. What needs to be modified, what are the implications, what are the risks, what areas are affected by this change and need to be tested, etc.. should be questions you usually ask.
Also, working closely with them in this manner will give you the advantage of controlling their work quite closely without falling in the micro-management pitfall.
Hope this helps.
You need to have a software development process in place. Agile methodology is one of the most popular at the moment. It links product features to actual code released in fixed periods of time (iterations or "sprints").
Using this framework, product owners can get an estimate for each proposed product feature and manage available resources (developer's time in this case) accordingly.
The most viable option is hiring an experienced software project manager (part time), who can get development process on track, so that you can concentrate on managing business, not IT. Alternatively, you can assign additional responsibilities on one of developers to standardize and oversee your development process.
If you have any questions, don't hesitate to contact me, I'm sure I can give you a lot of good insights.
I've been a developer off and on for 16 years. I have also been a team lead, a CTO and a CEO. This is a very common issue and like most common issues contains a counter-intuitive solution.
I'm assuming that reason you are asking the question, to begin with, is that you suspect these two developers are not working fast enough.
Primarily this comes down to trust. You mentioned that you were not an IT guy. That begs the question as to how you were able to hire these two developers in the first place?
Perhaps you had an IT consultant hire them for you? If you hired them yourself then you do in fact have something to be concerned about.
What I know about developers is that it takes a good developer to hire other good developers. Hiring developers without knowing anything about development is a recipe for bad outcomes.
See, the thing is if you know beyond any doubt that these two developers were qualified to do the job when you hired them and you are paying them a salary commensurate with that skill then you have nothing to worry about in general.
Using whatever project management strategy whether it be SCRUM/Agile or whatever is not going to make a bad developer better nor will it make a good developer even better.
If you are not sure that you hired the best people for the job then the best thing to do is to find out ASAP by hiring a consultant to come in and evaluate the situation.
This need not be a huge undertaking and shouldn't require a lot of money. The consultant can look at the project history and give the developers a few skills exams to see where they are at on the knowledge scale of the codebase you are working with.
If the consultant comes back with bad news then you should have the same consultant help you screen new applicants to replace either one or both developers. Yes, you will lose time by doing this up front but you will save even more time over the long run.
If you hire 2 new developers who have been vetted by a person who knows how to tell a good developer from a bad one then you will have nothing to worry about and you can trust that what they are doing in terms of speed is appropriate.
If these 2 developers you have are in fact up to the task then ask yourself are they getting paid what they are worth? Under paying a developer is also a recipe for bad outcomes.
Whatever you thought you were saving in hourly fees or salary is going to come out of lost time because the developers are not motivated to help you succeed.
After all, what's in it for them? If they have no equity in the company then they know they are just hired guns and can be let go at any time and have no real stake in what you are trying to accomplish.
It very well could be that they are underperforming but that is either because they are not experienced or skilled enough for the task or they do not feel valued by you and have no real incentive to bring their A-game.
Another important point to realize is that developers are constantly being beat-up by unrealistic requirements from the marketing/admin side of the house.
If you are not a developer that 10% of what is viewable on a screen is the tip of another 90% in code that is making it happen and that interacts with many other moving parts in the code.
What appears to be a simple new feature request or change to a layman is in fact not a quick thing at all. If you have hired a good developer you can trust that they will be honest about the time it takes to implement and in that case you must lower your expectations to fit with the reality of the situation.
It all comes back to making sure you start with a good developer and for that, you certainly need someone who knows how to tell the difference between good and not good.
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” must have a different skill set than the team members they manage. If you are 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 is very possible. And, if you out your back into it, non-technical managers can earn big-time respect from their tech savvy teams. Here is how to manage a software development team without technical credentials:
1. First, it is important to understand that project management is a big deal. To effectively manage a project from concept to completion is an intense undertaking, and one that often goes under sung by product/software developers. If you are 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.
2. 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 will 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 will be a successful manager. You can also do things like this:
I. isolate the parts of your approach that are working (and those that are not)
II. identify stumbling points and plan for avoiding them in future iterations
III. track progress towards, and make accurate projections for completion
3. 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 do not achieve that goal, something has gone wrong. Maybe it is with your coders. Maybe it is with the product. Or maybe it is with your process. The point is there is a problem. And if you listen to your roadmap, it will tell you where it is. 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 cannot overwhelm your developers with impossible expectations. It does not require a technical background to know that impossible expectations cannot be met. It is your job as project manager to ensure your team can work effectively without getting burned out. 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, do not spend time building it.
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath
Related Questions
-
How much should I charge to develop a WordPress site?
Take the # of hours it takes you to do it and charge $50/hour. That's the price. Eventually you can charge $100/hour but that will require a bigger customer. If the customer is small < $1M in gross sales per year - charge $50/hour If the customer id medium < $1-5M / sales - charge $75 Over $5M - charge $100 The challenge you'll face is clearly defining the expectations and handoff so that you're not stuck doing stuff that you can charge for and always getting interrupted from past customers.DM
-
What are the SaaS B2B expectations when paying annually - annual paid annually or annual paid monthly? Is a discount necessary (i.e. 20%)?
Most Software as a service vendors generally don't book annual deals except in highly specialized cases. Most customers prefer to be able to cancel/change anytime they choose. Also, deals done "offline" end up actually often being more trouble than they are worth to administrate especially for a $2988 ticket. Generally, companies don't view prepaying for SaaS products a year in advance as a "convenience" (to them) so if the debate is internal (not customer driven), I'd set this debate aside until it's requested by the customer. Most customers will request a discount to pre-pay annual service. Happy to talk this through with you in a call, to work through the specifics of your situation in more detail.TW
-
What are the key accomplishments for the first year of a startup?
A generalized question can only get a generalized answer. The most significant accomplishment is validating that the product you have built is a fit with your target market. This is demonstrated primarily by engagement (the people who sign-up or who previously visited, continue to return) and secondarily by growth, ideally based on word-of-mouth or viral growth but effectively converting paid traffic is a great second prize. Other significant accomplishments include: Not running out of money Recruiting and retaining great talent who believe in the founders' vision. Your loved ones not thinking you're as crazy as they thought you were a year ago. I'm happy to talk to you in a call to give you more specifics about what you want to set as your goals more specific to your startup.TW
-
What learning path do I have to take to become a "full-stack" web developer?
If I was just starting out, I'd consider learning Meteor (https://www.meteor.com/). It's just entered version 1.0 and after working with it for a little less than a year I do have some issues with it but it still makes for a very solid framework that gets you up and running very fast. You would only need to learn Javascript, and you can slowly work your way towards nodejs from there (which Meteor is based on) if you want to, or you could get the basics down and focus on learning design if you prefer.KD
-
How do you manage a developer who's slow, especially when you have a small budget and you don't feel like you'll get things done in time?
Usually Programmers are only slow when they don't know how to solve a particular problem. So they will spend a lot of time researching and a lot of trial & errors to solve a problem. It is important that before you engage a programmer on a project, you break down the entire project into simple, easy to understand modules. Let him give you an estimate of how many hours he will require to complete each of the modules. Example: a typical site will have a login module, registration, My account, profile etc. So let him estimate how much he will require to do the login. You can go even detail here. (e.g. how much extra time if you were to implement Facebook/Twitter Login?). Once he start developing, track his progress closely and make sure he is following his given timeline. If he goes over his budgeted time on a module, talk with him and see what went wrong. It is often seen that they may be wasting their time on something very insignificant that you may have asked him to implement, but you can totally go by without it too. So by understanding what is taking longer time, you will be able to prioritise things better. You definitely need some tools to get this done. Google Spreadsheet or Excel works just fine. But if you don't mind spending a few bucks there are many agile project management tools that you might look into. Here is a list, google them all and sign up for trials: * AgileZen * Agile Bench * Assembla * AssiTrack * Blossom * Basecamp * Breeze * DoneDone * Eidos * Fogbugz * GreenHopper * Jugggla * Kanbanpad * Pivotal Tracker Or the reason why he is slow can be purely non-technical. Sometime your developer may don't share the same level of enthusiasm as you about the idea that you are working on. They often don't often see the "bigger picture" (since you don't share everything with them explicitly). If you can somehow get them excited about what he is a part of, it will work like a drug :) He will work day and night without questioning you. But you need to work equally as hard as him. The moment he sees that you are the boss and he is just the guy doing work for you -- his mentality will shift from being part of something to being the low paid developer. Ultimately its all about motivation and making him a part of your venture. After all he deserves it, if he is really playing a crucial role in the entire development.SK
the startups.com platform
Copyright © 2025 Startups.com. All rights reserved.