Software development

by

How To Hire A Strong Software Development Team

Building a strong team is a prerequisite to shipping successful, innovative and good quality products that customers love. But how do you build a software development team capable of doing it? You build it lean and mean. In How To Build A Team And Not A Random Group Of People I outlined the basics of building any team and today I will focus on building a small, agile, engineering team that will be resistant and able to execute. To recap the basics from the previous post. I would urge you to:

  • Hire for strengths
  • Hire for gaps
  • Hire for cultural fit
  • Hire the right, not the best, person
  • Hire by committee

It starts with technology

And now to our engineering team. It all starts with technology. Or does it? What technology stack will you be using? If you are hundred percent sure on programing language and technology stack it is an advantage to hire for these, but I would argue that ultimately it doesn’t matter. Unless you work on some legacy product where the technology is given by its environment or business constrains I believe that it is better to hire great, smart and talented engineers who will be able to flexibly shift between technologies as needed, than bunch of experts in one particular programming language.

Hire for smarts not knowledge

We are living in fast moving world and especially in technologies the world is moving even faster. Yes, you may be building your products in C++, Java, or .NET which could be considered stable and even old languages but if you are (un)lucky you may need to build applications (like SaaS) using whole bunch of relatively new technologies and what is worse there are constantly evolving, changing, and new are emerging. For a team that builds brand new product it may be required to learn new things as they go and as the particular needs demand.

With this in mind, hiring a great Java or .NET developer might be a good call but that is not a requirement. The most important is to hire a brilliant and talented engineer who is able to solve complex problems and pick a technology as needed to get the job done. You recruitment process needs to be aligned with this requirement. And yes, if your technology is set, then by no means, hire also for skill in a given language since it will save you time to get that person up to speed. I would suggest you check this article first Effort And Attitude Beats Talent And Knowledge.

Hire for flexibility not experience

You need some experts on your team but when developing modern software flexibility will be more desirable. When it comes to expertise you need someone with a domain knowledge. Bring a true expert who can mentor the rest of the team, but make sure the team can pushback otherwise you run into danger of the “old thinking” and any competitive advantage in the form of innovation will get out of the window.

When it comes to technology there are some circumstances when you need someone with a deep expertise in a given technology. For example, if your product needs to handle huge amount of data you may need someone who is really good at database performance, data optimization and similar topics that are difficult to study from a book and come only with experience with a particular database engine.

When hiring an expert who is focused on one technology make sure you balance the team with bunch of other people who will bring the smarts and flexibility in case the technology shifts.

You hire for cultural fit

Mindset is everything. For all this to work you need to build a sense of ownership and accountability. These things don’t come easily to everyone so your main concern should be to finding people who will identify with your goals, who will share the passion for building a great software, who will share the need to make a difference and to help solve problems for your customers. If you have these on board you keep the team together in good and bad times, you give them autonomy and they will build together something great.

So how could your perfect team look like?

As usually, it depends. It is always a question of what you are building, whether the team sits together in one time zone, what is the management structure in your company, what budget restrictions apply, what processes will be used and many other aspects. But assuming you want to build a solid product development team that will have the right skills, will be given the needed autonomy, will work within some agile processes like SCRUM, you will need these:

  • Product owner who owns a vision and requirements for the product and works closely with external stakeholders
  • Product designer who ensures the overall design of the product and that it solves the problem you set to solve
  • Architect who leads the technical direction of the product and have the final word on technologies used and any technical arguments and will be responsible for performance and scalability
  • UX designer who is responsible for designing workflows and usability
  • UX researcher who is able to gather data from customers or potential customers to ensure that feedback is gathered well in advance of the final shipping date
  • Graphics designer who is responsible for all the visual aspects
  • Writer who ensures all the textual descriptions are easy to understand for the target customers, and the right amount of text is presented
  • Backend developer, or two to build the core technology that does all the magic, deals with gathering, storing and manipulating data
  • Frontend developer, or two to build what the designers came up with and provide a great simple to use, scalable, and responsive interface to the user
  • QA dude to ensure end to end quality of the release, ensure that quality is built in through code reviews, unit tests, automation, and other means and is the last line of defense against shipping broken product
  • SCRUM master to have a servant leader who keeps the machine running and removes obstacles for the team

Lots of people, huh? The good news is that not all of them need to be actual full-time employees but many of the roles can be combined. You probably don’t need a full time UX researcher and can combine it with the Product designer or other role. You don’t need full time Writer and can combine him with another role. And you definitely don’t need full time SCRUM master. That is a virtual role that can be even regularly rotated across the team.

The bad news is that for this to work really well you need to build in redundancy. You may get one strong UX designer but you need someone else on the team who will have at least decent UX design skills. Why? To be able to deliver even if your main UX guy goes on vacations and to actually constantly challenge the main UX guy and to be able to challenge the expert and keep him at his best. And the same applies to any other role. What does it mean for the software developers? Well, it leads to the need of hiring a full-stack developers rather than experts focusing on niche. You get one strong frontend guy, but anyone on the team needs to be familiar with frontend technologies and step in. You may have one strong backend guy (most likely the architect) but even the frontend guys should be able to write backend and deal with databases.

So again, when you are building your next team think about expertise, smarts, flexibility, culture, and redundancy.

 

What is your recipe for building a great engineering team? What sort of people would you require to build a new successful product? Do you have a completely different approach to building software development teams?

Originally posted at LinkedIn.

by

Good And Bad Software Engineering Manager

What does it take to be a successful manager in a progressive software development company? What are the traits you need to have to build solid software development teams and ship great products? I have recently read a great book The Hard Thing About Hard Things by Ben Horowitz and in one of the chapters he is pointing out something he wrote years ago when building his product management team: Good Product Manager / Bad Product Manager. This made me think about what does it take to be successful as software development manager and this is what I came up with…

Good engineering managers understand the development process, constantly strive to improve it and make sure team follows what was agreed. They understand the key priorities for the team and are able to make difficult decisions when the team is being forced to handle more than possible. Good engineering managers take it on their shoulders to have the tough discussions with other stakeholders. They challenge the team’s estimates and push for as realistic view of the work as possible.

Bad engineering managers push the team to follow the process mindlessly without understanding that the process is just the means to some end and not the end by itself. They are afraid to make difficult decisions. They would rather push the team to provide unrealistic estimates than face the other stakeholders and tell them that the requirements are not doable.

Good engineering managers know the industry and what is the standard. They are constantly in touch with Product Managers, Sales and Technical Support to know what the market looks like, what the product strategy is and why there are certain priorities in the product. Bad engineering managers wait for product management to tell the team what to do and are not able to provide the engineering team the big picture.

Good engineering managers focus on creating value for customers. They drive the team to focus on reducing issues related to installation, upgrade, integration, supportability and maintainability. They negotiate hard with product management to limit the amount of technical debt. Bad engineering managers just stay away from any engineering related decisions on the product.

Good engineering managers understand the content of the release, what is behind every single feature and are able to explain the current status even when woken up in the middle of the night. Good engineering managers know what is the product team working on every single day, they are actively identifying issues and risks and drive them to resolution.

Bad engineering managers are just proxies. They rely on information fed them by the team leads. They bring no real values neither to the project, nor to the team. Bad engineering managers communicate poorly outside of engineering, and frequently hide the issues in the hopes that it will get somehow resolved. When being asked for the status, content of the release or biggest risks they have to go back to the team and ask.

Good engineering managers provide feedback, raise risks and issues and make sure these are discussed and resolved. Good engineering managers ensures that the teams follow the best engineering practices and that these are shared between the teams. Bad engineering managers don’t even know what their product does, they treat people as numbers and have no idea who the best and worst performers on their teams are. They take no interest in understanding the technologies and people. They are essentially just administrators who shuffle paperwork around.

Good engineering managers own the escalated issues from Sales and Support and ensure their prompt resolution. In urgent or sensitive cases they are willing to jump on a call with a customer to explain the situation and discuss the steps to resolution. Bad engineering managers hide from responsibility and hope that someone else will have the difficult conversations when dealing with customer issues. They always point to problems somewhere else rather than fixing real (or perceived) issues within their teams.

Good engineering managers regularly communicate with all stakeholders and build good relationship with them in the times of peace so when there is a hot issue to be resolved they can tap into the pool of goodwill and resolve it promptly and to everyone’s satisfaction. Bad engineering managers just sit back and talk to other stakeholders only when being triggered by them. They don’t care about relationship building and then they are unable to resolve issues without escalating to higher management.

Good engineering managers understand business priorities and are willing to shift resources around as needed. They leverage teams around the globe and are willing to help other products outside their own sphere of responsibility. Bad engineering managers are unwilling to release their people to other more important products being afraid of losing power. They are always looking for excuses why their product is more important and don’t keep the business needs in mind.

Good engineering managers are heavily involved in recruitment understanding that only by getting the right people on-board they can build first class products. They develop their people and provide opportunities. Good engineering managers understand that only by building a strong team under them they can get to the next level themselves. They take no short cuts and know that developing people takes time and effort. They know that one of the key tasks of successful leader is to inspire the team, set clear expectations and provide feedback. With this in mind they are actively participating in on-boarding of new team members and ensure that every person on the team know what is the expected behavior, what makes this company successful and what will make him successful as well.

Bad engineering managers focus so much on politics and numbers that they forget about the people who do the work. They don’t provide feedback, and don’t talk to their teams. Bad engineering managers spend the time only with team leads and delegate any interaction with the rest of the team to his team lead. Bad engineering managers are so busy dealing with current issues that they are not able to build scalable team that would eventually prevent the issues in the first place.

Good engineering managers are able to use money wisely and train the team to do the same. They understand that only because there is a budget for something it doesn’t need to be spent if there is more cost effective way to solve the problem. Bad engineering managers constantly complain that there is not enough budget for all the things they would like to do without trying to work around it and come up with less expensive options.

 

What is your recipe for a great manager responsible for software development? What are the skills and behaviors you are looking for?

Originally posted at LinkedIn.

by

Good enough is the new great

Having background in software engineering, being developer for couple of years, managing products and software development teams for a long time I was constantly facing decisions of what is the right balance of developing products fast and in a good quality. And what does good quality actually mean. What are the right criteria to decide whether a product is ready to be released? How do you know what is the best for the customer and you?

What I have observed is that the incremental value of spending more and more time and money to make the product perfect is limiting to zero. Having the product “perfect” will most likely not bring more money, it will not get you more customers and it will not be appreciated by the customers you have as the differences will be just too marginal or taken for granted. And what does “perfect” mean anyway…

You always have to ask what you are getting with each incremental investment and what is the opportunity cost (as our economist friends would say). What does it bring and what does it take away to implement a new feature to enhance the product or to fix a particular low impact issue? What does it bring? You will feel good. You will have a better product. Customers may or may not notice. Customers may not even care. What does it take away? Time and money you could have spent on something else!

To illustrate that you don’t need to have this mindset only on the big scale but also in everything you do on daily basis just consider this example. You are a busy person. You have to deal with tons of tasks every day. When you get email from your boss asking about status of a particular project what do you do? Do you spent next half an hour writing a long email with all the details of what is happening, all the issues and how you solved them? Or would you rather just write a short executive summary stating that the project is on time as planned, when the delivery date is and that there is a minor risk because of flu season so people could get sick and you will keep him appraised?

The first report takes thirty minutes, the second takes five minutes. The first provides too much information that is not making it better but in fact is making it worse as your boss will have to spend ten minutes reading it and trying to understand the implications as compared to thirty seconds the second report would take. So you spent twenty-five more minutes than necessary writing something your customer (boss) doesn’t need and because of that you had to skip a mentoring session with one of your subordinates.

So never ask “Is it the best we can do?”, because the answer is always “No, of course we can do better, add more features, make it more shiny.” Better question is “Is it good enough for what we/customers need?” You don’t need all the bells and whistles, you don’t need to gold plate everything. As long as you meet the minimum criteria you and your customers have, you are done. And you have done a great job, in fact much better job than if you spent another year and tons of money to make it nicer and shinier.

Just make sure you provide what you promised, what you expect, what your team expects, and what your customer paid for. By providing more you spend time, money, attention on something that doesn’t bring the value. Rather go and build second product, or spend more time with your team, or innovate your processes, or spend more time with customers on the next big thing.

Twitter type summary: “Don’t ask your team whether this is the best they can do, but rather whether this is good enough for what the customers need.”

How do you know that your job is done and product is good enough? Do you push your team to do the best they can or to do what needs to be done?