We’re Go People!

Vince IarusciTeam BuildingLeave a Comment

A Core Value for all companies.

Here’s a story about an important core value that I learned during my Industrial Engineering course in college. Lloyd Bittle who was my professor for the course was a retired Industrial Engineer and his goal was not only to teach us how to improve organizational processes and systems but to become better workers and managers.

The Entrance

Without fail, every day it was the same routine. The lecture is about to start, my classmates and I are waiting for the big entrance. In walks Professor Bittle who makes his way up to the front of the room and turns the light on for the overhead projector.

The projector displays an image of a stacked red, yellow and green circle resembling a stop sign. He slams his hand down onto the green circle and points his boney finger towards my friend Terry who’s sitting beside me. We know what’s coming and we’re ready for the volley of questions coming our way.

Go People

Bittle : “Terry, what kind of people are we?”

Terry : “We're Go People!”

Bittle : “Very good Terry…that’s what I want to hear…and what kind of people are Go People?”

Terry : “Go People are motivated team players that have an open mind and are continually trying to improve their work and environment around them. They’re forward thinkers who are involved for the common good and they make things happen. Go People inspire others to become Go People. Go People are leaders.”

Bittle then moves his focus over to Sandra. This time he slams his hand on the red circle.

Stop People

Bittle : “Sandra, what kind of people do we want to avoid becoming?”

Sandra : “Stop People”

Bittle : “Ok Sandra, and why are stop people bad for the organization?”

Sandra : “Stop people wait for things to happen. They only do the work assigned to them and nothing more. They avoid taking any risks and are more interested in the status quo instead of growth and improvement. Stop people are followers not leaders. However, stop people are predictable and can be managed.”

Bittle’s eyes then focus on me while he slams his hand on the yellow circle. The answer has been repeatedly imprinted in my mind from previous lectures and I have no doubt how to answer the question…

Caution People

Bittle : “Vince, what kind of people are the most dangerous for an organization and the employees we want to avoid becoming at all costs?”

Me : “Caution People”

Bittle : “…and why should we be wary of these “Caution Employees”?”

Me : “Caution is needed as these workers are unpredictable. They are focussed on their own goals rather than the team’s goals. They take credit for other people’s ideas or work and may even try to sabotage the system or processes if it serves their purpose. Caution people will sometimes try to come across as Go People but will always be exposed for who they are in the end. Caution people are posers.”

We’re Go People

Sometimes I wonder why Bittle would continually repeat the Go People exercise over and over again, but years later I understood. Bittle’s Industrial Engineering class wasn’t only about how to improve the efficiency of a machine or process, it was about improving ourselves, teams and organizations. It’s about the type of workers, managers or leaders we need to become.

Not Now, Later.

Steven NgSoftwareLeave a Comment

From Idea To Product

A lot of people have great ideas for products. The challenge of turning those products into ideas is that the ideas are usually only half-baked. What is in your head often comes out a lot different in reality. Things don’t flow as well in the real world as they do in your head.

You can start building without a design, but if you’re designing on the fly, you’re going to spend a lot more time building whatever you’re trying to build. Trust me, I know from experience.

Of course, many of us don’t have the luxury of having a user interface designer on hand. So we download a user interface framework like Bootstrap and start building. And then for whatever reason, we find out Bootstrap doesn’t do some particular thing we want, and integrating that becomes a bit of a challenge. So then we throw that away and try some other framework. And all of a sudden, something that seemed straightforward in our head became a lot more work than we originally thought.

MVP 3.0

“In the biz”, we like to refer to building MVPs, or minimal viable products. That is to say, something with the least amount of functionality that would satisfy the requirements for an initial release. If you’re building a free consumer app, that strategy works well. If you descope the idea in your head to a minimal set of functions that can be built quickly, it will work to your benefit.

If, however, you plan to charge a significant amount of money for your product, your MVP needs a bit of polish. Nobody’s going to pay $50 a month for something that barely does anything and looks like crap doing whatever it does.

But in either case, you need to build something before you build everything. You can’t achieve feature completion in version 1.0. In my experience, the best products I’ve used tend to be the 3.0 version. Microsoft Word 3.0 was the pinnacle of the application, in my mind. While some useful features have been added in the two plus decades since 3.0, most of it has been cruft and wiz-bang features that marketing types use to justify a paid upgrade from existing users.

Back to the 1.0 thing. When you’re building a product, you need to figure out what your killer features are, and then decide what the bare minimum for each of those features can be built in a relatively short period of time.

When we started out building Assign It To Me, Vince and I each had our own grand visions of a perfect 1.0 release that had everything under the sun and the kitchen sink. We learned pretty quickly that if that was our release list, we would never, ever release anything.

You can’t get to a 3.0 if you don’t have yourself a 1.0.

Less. Much Less.

So we descoped. We pared down the functionality down to the minimum set of things that would make our application worth using.

  • Project management. Check.
  • Task Level Time Keeping. Check.
  • Project health dashboard. Check.
  • Task Level Collaboration. Check.

There are a few other things that we included, but all of those features had to be in a minimally viable state.

But that’s not all. When you’re building a software-as-a-service (saas) solution, you need the infrastructure to handle subscriptions. Whoa. More scope. Shoot me now. All of a sudden, there’s more to build than just a client app.

  • Web application server. Check.
  • Database. Check.
  • Secure Payment Processing. Check.
  • Multi-tenant architecture. Check.

I think you’re starting to get the picture. It took us a while to get the core infrastructure and base application in place. And we had to say “no” to a lot of features while getting to 1.0 (Vince can attest to all the pushback I’d give him every time he had a good idea for a new feature). The best thing you can do while getting to 1.0 is to push as much as you can into your backlog. Get a solid foundation and make sure you design it to be expandable. But be careful not to overdesign. Just don’t design yourself into a tiny box. Once you get that foundation, adding things gets easier.

Not Now, Later

When we reached 1.0, our application wasn’t the prettiest thing out there, but it was serviceable. It worked, and it did what it needed to do. Making it prettier was easy, because all the hard parts were now in place. Since hitting 1.0, improvements have been coming at a furious pace. If we tried adding some of our latest features to the 1.0 version, we would have never released. Seriously. We’d still be developing.

The path to 1.0 was not smooth at all. We hit roadbumps, got demotivated, made progress and then got re-motivated. This vicious/virtuous cycle is pretty typical, but if you’re looking to make a product, it’s not an insurmountable task. The key is to manage your releases and to be ready to look at some of your less important features and say “Not Now, Later”. Focus on getting something out. If you’re self-bootstrapped, it’s unlikely that you’re going to get an A+ product out on your first try. Pare down your product and aim for a B product instead. It’s much easier turning a B into a B+ and then into an A than it is to start with nothing and end with an A+.

One of Vince’s favorite sayings is “continuous improvement over delayed perfection”. It’s much easier said than done, but if you can find the discipline to adhere to that saying, you’ll get better results faster.

Not Invented Here

Steven NgSoftwareLeave a Comment

Reduce, Reuse, Recycle

When you’re building an application, it makes sense to take advantage of as many open source libraries as you can. These libraries can often save a lot of time… or not.

Fit or Misfit

When you’re building an application, it’s easy to fall into the trap of assuming your Google results for some function you want will actually do what you want. While these libraries can be pretty good at what they do, they tend to come with three common pitfalls.

First — Some libraries are trying to be everything to everyone. The programmer(s) have done a fantastic job of building a complete piece of functionality and have trapped all sorts of edge cases. This isn’t a problem if you’re OK with the library’s out-of-the-box functionality, but if you’re trying to do something very specific, you may quickly find yourself trying to ram a square peg into a round hole.

Second — In a lot of cases, these libraries are black boxes. Documentation can be hit or miss with these libraries. The examples work great, but when you try to write an example tailored to your needs, things get dicey. You don’t know how well the libraries scale with large amounts of data without doing your own testing. In some cases, you also don’t know how secure the code bases are. Sure, you can dig into the code, but the reason why you even considered the library was to save time, effort, and headaches.

Third — Since most libraries are borne from a programmer’s own need, they are developed with themselves in mind. That is to say, there’s an opinionated design. The API or data structures are a certain way, and they may not match the way your application is built. They may also be a mismatch for the other libraries you’re dependent on. Just figuring out the learning curve for remapping your data structures could take longer than if you wrote your own library from scratch.

Not Invented Here

Someone wise once said “If you think something is easy, you probably don’t know what you’re talking about”.

Thinking you can easily build an application by just grabbing a pile of pre-written libraries is a trap. Are you going to add D3.js to your application just so you can put a single pie chart on a single page in your application? That’s a lot of code to be adding just for a small feature.

Unless all of those libraries you wanted were written by similar thinking people (pro tip: they’re not), you’re going to be dealing with a bunch of different programming styles and API invocation approaches. Integrating a pile of code written by a bunch of randos may not be technically difficult, but if you’re trying to do something non-trivial, integrating that code is going to be time-consuming. First you have to learn how each library works, and then you need to make the libraries talk to each other. And then you need to make sure that upgrades to one library doesn’t break anything relying on the other libraries.

In some cases, you’re better off writing your own new code. And you know what, it’s not the end of the world.

Be Selective

Let’s be clear, it makes no sense to re-invent the wheel if you can at all avoid it.

So what should you do? In building Assign It To Me, we’ve gone through a litany of different libraries. When we discuss adding a feature, we always see if any wheels have been already invented and whether they fit on our car, so to speak. If they don’t we have to make our own wheel.

In general, I find that large libraries that do more than I need tend to be a bad fit. The best libraries are the smaller, “do one thing really well” libraries. They’re easier to decode and integrate. Because we try and ensure that mobile users can use the same set of code, payload and dependencies matter. Or more clearly put, I don’t want to deal with sizable pieces of new code or dependencies on libraries I don’t already use. For example, we don’t use jQuery in any of our client side code. I’m not going to add an extra 100KB or so of code to our client app just so we can do something trivial. Heck, I’m going to need convincing even to do something non-trivial. The cost is that I lose access to hundreds of canned user interface libraries, but it hasn’t been nearly as big as a hindrance as it would seem.

From my perspective, it pays to be hypercritical about including any new libraries in your code. All of your externally sourced libraries move at their own pace. As mentioned earlier, an upgrade to one library can lead to a litany of negative side-effects in your other libraries.

There’s a delicate balance between being able to show forward progress quickly by using some canned code and making sure that the rest of your code base is clean and performant. Do evaluate and consider open source libraries for your applications, but don’t be afraid to write your own code either. Remember — a lot of open web frameworks were written because existing frameworks didn’t do the job that the programmer needed. It doesn’t mean that you need to eventually rewrite all the third party libraries you’re using. But if you outgrow them, it’s better than being dependent on someone else’s work and update schedule.

A Defining Moment

Steven NgProject Management, SoftwareLeave a Comment


If you look for project management software, you’ll find a ton of apps. A TON. Basecamp, Mavenlink, Zoho, Trello, Microsoft Project… the list goes on.

And yet, Vince and I still made Yet Another Project Management App. Are we crazy?

If you ask people who know us, they’ll probably say that there is indeed a little bit of crazy in us.

But that’s not why we built a project management app. I’ve worked with Vince since 2005, and we’ve been billing consultants for most, if not all, of that time period.

Project management tools are great for tracking your project completion, but they’re not quite what you need when you’re a small billing organization who can’t afford full time, dedicated project managers. Your projects are run and owned by consulting or team leads who are often hands on, writing code or doing other project delivery tasks.

These project owners are busy. They don’t want to be bogged down with chasing down team members for status reports and don’t want to be thinking about the real dollars involved with running a project, even though it’s their heads on the line when the project goes south.

Having run/owned projects myself, I’ve tried all sorts of tools – Excel, JIRA, Fogbugz, Microsoft Project. And none of them really did what I needed them to do. And what was that? Give me a constant overall picture of how my project was performing and being in-my-face when potential issues were arising. Having some time saving reports would also have been nice. I used to spend 2 hours a week per project collecting information from team members and compiling a status report. I’d rather have been coding.

The reason why there are so many project management apps on the market is simple. Different people have different ways of running projects, and one application can’t address everyone’s needs.

Assign It To Me

So that’s why Vince and I created Assign It To Me. We wanted to make a tool for us. We know there are plenty of small to medium sized billing companies that are just like us. Companies that cared about running projects well, that had to keep an eye on the profitability of their projects, and who usually had leaders who weren’t certified project managers who ran projects and were hands on in the project delivery.

Aside: If you’re wondering where the name “Assign It To Me” came from, Vince and I were struggling to come up with some fictitious, unique name that was easy to remember and had a .com domain available. When Vince and I divide up work, our most common demand to each other is “Just create a task and assign it to me”. The phrase is easy to remember and spell, and heck, we said it all the time, and boom. The rest is history.

So fast forward more months than I’d like to count (let’s save that for another blog post), and Assign It To Me turned into a real app on the web. It’s not perfect (is anything?) but it’s finally gotten to the point where we’re very proud of what we’ve built and are incredibly excited about adding new features. We “dogfooded” the application the whole time we developed it. And we think that made the application better, and more flexible. Vince and I use the app in very different ways on a daily basis. That Assign It To Me lets us manage projects differently is a testament to the benefits of eating your own dogfood while building an application. We used to sell enterprise software that made it obvious that its developers didn’t actually use the software. We didn’t want to do that, and, and in our own delusional minds, think Assign It To Me was made with love.

Who, What, Why

So back to the defining moment. We have discussions all the time about who Assign It To Me is intended to benefit, what makes Assign It To Me so different from our competition (many of which are great apps), and why those people should use it, since that ultimately defines what Assign It To Me is all about.

Who is Assign It To Me for? In a nutshell, it’s for small to medium sized companies who charge by the hour for their services. Digging deeper, these companies aren’t at the scale where they can hire full time project managers to run their projects. Also, these companies are owned by one or a few owners who need to keep an eye on the profitability of their projects so they can keep their company afloat. Keep in mind, however, that 80% of Assign It To Me’s functionality overlaps with other project management tools, so other people can still use it to run projects.

What makes Assign It To Me different is the 20% of its functionality/design that isn’t in other project management applications. Making money through well run projects is the mantra of Assign It To Me. Most project management software is just about the project. We try to capture the small pieces of seemingly trivial information that help inform company owners and project owners how their project is performing, and whether there may be any risks to the project’s success. We get that it’s not rocket science, but we try to deliver this value in ways that also make life easier for project owners and their team members.

And that’s why we think billing companies should use Assign It To Me. Wouldn’t you love to know if your project is healthy or sick? Wouldn’t your team members prefer to focus on their actual work than dealing with administrivia? Wouldn’t project owners prefer to let an application do some of the grunt work of running a project while giving them more time to do work? And wouldn’t it be great if the software was affordable enough that you didn’t have an excuse not to at least try it? In a nutshell, you only pay for project owners, and in most cases, it can pay itself off with a billable hour per month per project owner. We think Assign It To Me will save you more than that hour a month.

Watch This Space

So now you know what Assign It To Me is all about. Keep an eye on our blog (or subscribe to the RSS feed). Vince and I will be posting here regularly on a multitude of topics related to project management, running a consulting business, running a software business, and building an application.