User Centric software development teams

Last week I wrote about the importance of strategic User Experience design and a transformation toward a user centric organization. A mention briefly the requirement of multi-skilled and multi-functional engineering teams, but before going into that I want to take you back say 15 years.

In the mid nineties the bulk of software engineers either worked on the Windows platform or on some kind of mainframe. I was part of the first group and remember very well that Microsoft encouraged us the follow the Windows DNA (if I remember well) that basically was marketing speak for three tiered solutions with a data, business and user tier. The story was nice and correct, but the implementation was hard. The technology based on COM and DCOM was just difficult to get deployed and hard to get robust. Many decided to ignore and just build very fat client applications. For this engineering teams used their favorite development tool, for instance Visual Basic, Visual C++, Delphi, DBase, FoxPro, etc. and an engineer would cover a chunk of functionality from the database up to the user interface. Working on the user interface was more focused on following the Windows style guide as it was focusing on the user and how the execute tasks. The companies successful in this era differentiated based on their technology capabilities, as I also said in the importance of strategic UX article.

Fast forwarding to today we can also see that Microsoft consistently have been telling us to separate the business logic from the user interface and always has provided tooling and architecture patterns to do so. We also see that the scope of solutions we need to offer today has has become much broader. Depending on your solution you might need a native Windows and/or Mac client, a web client (including one working on tablets) and mobile clients for iOS, Android, Windows Phone and Blackberry. The number of platforms, each with their specific engineering challenges, has exploded and at the same time we want to transform the business to have a more user centric focus. This is your challenge of today.

The generic software engineer from the mid nineties is not going to solve this challenge, you need specialists for each individual area. If you ever watch Pimp my Ride on MTV you see that there is a specialist for the bodywork, interior, sound system, engine, wheels, etc. and they all work together to deliver the end product. In software development, unless you want to settle for mediocre, you need exactly the same, a specialist for every single little detail of the solution.

Since you want to be user centric you have to start with the user interface. For web applications you need real web developers, those guys that together with your designers can really make a beautiful web front end. They know everything about HTML, CSS, Javascript and the available libraries to make compelling dynamic web pages. They don't need to worry about the business logic and database, all they do is bridging between the designer and the API guy that understands how dynamic web applications are made, but also realizes that the API is used by many other clients. At the same time your iOS, Android, Windows, and Mac client engineers talk to the same API guy. The API guy translates the business logic into a usable API to be used by all his front end buddies. He knows everything about web services, REST, XML, JSON and other API standards. He realizes that API access needs to be safe and secure and does this with today's standards on authentication. The API guy bridges the gap between the user interface and the business logic and since he is close to the logic he is also the one that can really talk to the logic engineers that know everything about complex algorithms, object models, functions and procedures. Finally the logic engineers work with the database engineers to realize a perfect data storage model. Here you go, you need at least five different expertise's: Front end engineers (depending on the platform), API guys, logic engineers and database engineers and an architect to set guidelines and direct the final solutions.

If you're an engineer reading this you have to decide who you want to be and study to become one. It might sound harsh, but you won't survive if you don't specialize. If you're a manager reading this you have to review your team and/or organization and restructure, reeducate and rehire to make sure you get the right expertise in the right place.

Scrum brought use multi-functional teams that build end to end solutions, however there is a limit to the size of an effective scrum team. It might not be possible to fit all in a single team and you might have to rethink the scope of your solutions. What if the API is the end product? In this case your scrum teams can deliver up to the API and other teams than deliver the various client solutions. This scales better in your organization and allows easier outsourcing of expertise you don't have or is to costly to gain. This especially might be true for developing many different mobile clients.

Great software can only be delivered by a team of specialists.


Insightful, looks like the least costly is the API as the end product, then car loads of evangelism to get your API adopted and somehow revenues flowing.

Perhaps another by-product I learned about having lunch with a Google Engineer (a hiring program). There's no people managers, only engineering and product mangers (which I agree with). Adoption metrics and analytics guide developer progress. This allows for faster product development cadence but requires a culture of freedom and results. 


I like this concept The technology based on COM and DCOM was just difficult to get deployed and hard to get robust.,very good quality conent info sharing,nice to hosting reviews

SXSW panel "When Your API is Your Product" with Twilio, SimpleGeo and SendGrid


I enjoyed reading this a lot... I really hope to read more of your posts in the future, so I've bookmarked ,Thanks for commenting.,I am so excited, 
looked everywhere for a tutorial on adding this slider! Can't wait to see the others!
cheap hosting reviews

amazing blog on the engineering development team.

Good article

Interesting article.

After few times involve in major projects, I'm a bit "boring" with methodology even who those so call "major vendor", a professional approach, enterprise solutions, it may ends up with frustration and complain from users.
The Ego is always is the issue. From technical point of view always technical interest, the other side business interest rule, company interest first, being a customer rule the demand.
"User Centric" Let's imaging like part-time programmer, daily basis paid after the job done.
User asked "Can you do this kind of software within 1 day with $$$ pay?"
Developer answered "ok sure, I can do that"
Face to face meeting, user point out the way he likes, and the developer able to deliver on the spot, in the end of the day done, get paid, software launch.
Deliverables phase by phase sometimes get things drag or un-productive. Communication breakdown, information chain leaking, misperception, and other communication based problem drives the design skid from its redirection.
I have 10 strong developers to serve 30 users on their demand, no problem on the financial. Put aside all of ego, trash out traditional style approach.
I plan to bring out all developer to meet with users in a hall and start work together, based on well proven framework, get the job done faster, better, meet the demand and bring in much profit.

Post a Comment