Fine Art · Professional

How can I track the progress of engineers if I am not a tech guy?

Bogdan Mirkac Electronic engineer / business development manager

October 18th, 2016

The other day I had a hot discussion with my engineers. The story is that I own a small startup and for us it is crucial to deliver on time. Of course I am not a tech professional so what do I know. I’ve constantly been asking if everything is fine, if we are on time, just to find out few days before delivery that we will miss the deadline. I will not let this happen again. How can I track the progress of the engineers? Is it necessary to employ a project manager? Then, how can I track his work?

Koby Leung Senior Software Engineer at LexisNexis

October 18th, 2016

(Edited to add back paragraphs...replying through email stripped turned my reply into a rant... :)

It's a hard problem. Even with seasoned dev in seasoned dev shops slips happen all the time. 

The job of a PM is to do the tracking and report to you when things will light up. "Tracking his work" is usually measured by tracking how much lead time he gives you when something is going to slip so that you can then control the messaging up to your clients, and measuring the delta between when he says something lights up and when it actually does. 

Canonical advice from a dev: 

 - Ship in small pieces. If you're 2 weeks from your delivery time and have seen everything except the last two weeks of work then even if/when you slip it might not be catastrophic. 

 - Related advice is to get your features in front of your customer as soon as possible. If you spend 6 months developing, release bits every month. Your 'final product' should be what your customer has already seen(and ideally already using), plus the 'last set of features' - maybe a month or two of dev work. 

 - Further along: manage your technical debt. Particularly for startups, much of the engineering may be on basic scaffolding and infrastructure to light up the first set of features. A balance needs to be struck between 'doing it right' and 'getting it done'. "Getting it done" might mean that a year down the road you need to take a hit and spend 6 months rewriting stuff...but you get it out the door faster. If you "do it right" you might take an extra month or three to get the feature out the door, but then you avoid the six month hit later. 

Which way to go depends on the business, but it's your responsibility to plan appropriately. 

Practical advice from a dev: 

If you're not technical then you need to be a 'customer' of your product. Instead of asking how things are, push to see the product as it is today - then make your own determination. 

The devs are only watching their own features. You need to watch the entire product. If you have nightly builds, crack open the nightly build every morning and take it for a whirl. 

How to make your own determination: Scrum, planning poker, kanban are all tools that you can implement to track the 'real' progress of work. The goal looks like this: Let's say your dev team is 4 people and a new feature comes in. You want to be able to get the following information: 
  1. Compared to a similar feature we did in the past, how complex is this new one? (let's say 1.5x) 
  2. Ok - so it's 1.5x more complex, and the previous feature took 1 month for developer A to complete it. Based on the relative experience, skill and situations of the other devs, this new one should take A 1.5 months, B 1 month, C (just had a child so) 2 months...etc. 

 Then you look at their schedules and your delivery schedule and allocate appropriately. To get here, you need to track individual dev's past work history and have a consistent way to measuring complexity and relative efficiency. 

Again, planning poker, scrum, kanban are all good places to look. Also look at "Open source dev process" for ideas. 

Good luck! 

Koby 
PS. Since you've read to here I'll add a plug for me: I'm a dev - need marketing/sales people. LMK if you know someone good! :) ?

Larry Shiller

October 18th, 2016

Hi Bogdan, Seems probable that your engineers either: 1) Really thought they could deliver on time and were wrong; or 2) Knew they couldn't deliver on time but didn't communicate that to you Find out which, by asking them. If it's 1), understand why their estimates/thinking was wrong. Bring in a project manager (looks like you were playing this role badly) and/or get both yourself and the team the information/training/resources to fill missing abilities/skills to keep that from happening again. If it's 2), why? What is your culture? Is it communicated? Do you behave consistently with it? To be clear, whether it's 1) or 2), it's on you: Your taking responsibility for the team's failure is the mark of great leadership.

Anastasia Titova Head of Marketing at QArea, Software Development Solution and QA

October 26th, 2016

Hi Bogdan,

That's a really good question. Luckily the right answer, as all things in life, is as simple as pie. Don't track their work - pay attention to results.

Say you need an app that does features A, B and C for a specific audience of accountant nurses. You already know what features A, B and C should feel like as they are described in the initial requirements. So checking them out is simple - do they work as they are originally intended to?

Secondly, you have a deadline. Your product should hit the market, say, next Tuesday. Is all of the functionality released timely? Are you making it within the timeframe?

Thirdly, you have a budget. Do your best to stay within limits just like you usually would on any other non-technical project.

What I'm trying to say is that you shouldn't micromanage developers. You are to manage the project.

But, in case you really need some productivity metrics to set up as KPIs for your tech team you should:

There are tools that measure that stuff as well as code quality. Check them out here: https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

PS: Here are some great materials about how a SCRUM team should operate (and deffinetely consider the SCRUM approach for your next project: https://qarea.com/articles/game-scrum-who-who-and-what-do-next

Brad Malone Partner at Navigate Management Consulting

October 19th, 2016

Ask them to "show" you what they've done - whether it's on a piece of paper, a drawing, or a prototype - the "it's in my head" means there's nothing which exists.  Then ask what's left to accomplish - that's what's important.  Remember the 90/90 rule - Engineers and developers are always "90% complete" but the remaining effort required will cost you another 90%. 

David M

October 19th, 2016

My response will be more from a communication level. The problem many engineers face when they move into the role of CEO, is 1-they lack a well rounded business background and knowledge, 2-they often struggle with larger conceptual elements and strategy of running a business.


If you are the CEO, you have to find the balance between CEO who is part of the team, and CEO who reserves the right to terminate an employee who can not properly adhere to timelines. But also, part of hiring experienced engineers is that they know their abilities.


I came in to develop and build a company of engineers once. The CEO was an engineer turned CEO, and he failed miserably with communicating the larger needs of the company to his engineers. He pretended he had the skill set of a CEO, but he never even remotely got out of engineer mode. Often times he would lecture his engineers about deadlines. He liked to talk more than listen (not a trait of a leader). On the other hand I would pull the engineers aside and ask them what they needed.


There was far more buy in. They felt valued, and I saw their motivation and productivity increase dramatically. If you can convey the importance of deadlines to you and them, and illustrate that the deadlines benefit the company and through that the engineers because you value them and care about their careers, you will see increased productivity.


Have you asked your engineers why they come to work? What do they value about work. What is it that their families enjoy. Maybe it's a two week cruise they have never been on. Find the way to reward results. Maybe one of them has a dream project or product that aligns with your company somehow. As they finish the current projects, perhaps you can support them on their passion project.


You can apply all the software programs, project managers in the world. If you don't understand what moves your employees as human beings and professionals, you will continue to struggle to get results.


But if you have done this, and you have instituted weekly deliverables, and you find your engineers are not performing as they should, you have to be the CEO and with that role comes the difficult task of letting people know they must perform.

Ross Jones

October 18th, 2016

Happy to help more, but the key in JIRA would be to have estimates in each ticket. And make sure your user stories are defined. If they need time to do an estimate, give them a bit and then meet to discuss timelines. 
Meet daily to discuss any blockers in your standup, and then weekly for more detail on project timelines. Keep it structured. 

Ross Jones

October 18th, 2016

Use something like JIRA, you can get a startup license, or use it cheaply as their SAAS offering. It's easy to setup and will help manage your development ops. 

Joanan Hernandez CEO & Founder at Mollejuo

October 18th, 2016

Hello Bogdan,

As per your profile, you're an electronic engineer (also an IEEE member). In my book, you apply as a 'technical person'. So you can't manage a colleague?

Being an engineer is being part of projects, any project! A lab to be delivered is a project, for example. If you manage that, you can manage a project with a colleague.

Which tool you'll use? it depends on you. But if you can't manage that colleague or a team, the tools won't help you out.

Best of lucks!

John Anderson

October 18th, 2016

I agree with Koby. Long story short, have smaller deliverables more often, or, break larger deliverables into smaller deliverables, and adopt more Continuous Integration/Nightly Builds. This way, you'll be expecting 'something' to be 'done' every week or two. Better yet, you'll be able to see the current state in the nightly builds, done or not. This will help you keep an eye on the overall quality of the product as well.

Between more frequent delivery dates, and some good CI practices, you can have an objective look into the state of the project every day and know about slips at a time that something can be done about it.

Siarhei Harbachou Specialty Market Researching

October 25th, 2016

Hi Bogdan.
Im professional IT PM, so can give advice. Almost all engineers provide too optimistic estimates of tasks duration. There is trick how you can accommodate this sad fact.
You need to add extra time next time you work with them, but don't tell them about it :). Just be prepared for delays.

If you work with engineers for first time you can do such trick  - multiply their estimate by 3.14 (Pi). Sounds strange, but this figure (~3) is widely used in IT and have serious statistical evidence.
If you can manage yourself do it, you save some money, you can hire PM later when get first traction.