Questions to ask when building software engineering teams

Why a knowledge base or company wiki solution is important to building high-performance dev teams

Founder, robot with feelings. From planet Aiur.

📖 Table of contents

Answer questions instantly

Build beautiful documentation portals that answer questions for your users, developers or team.

Software development is brutally hard. Software engineers don't perform well, and are all the same. My business is slowed down by the development team. Let's hire lots of cheap developers. Let's put in strict processes, things will improve.

If this sounds like your mental voice, it's most likely you who is screwing up your business the most.

Your competitors will eat you alive even if just some parts of your business are weak.

So what can you do? Because you clearly have some critical issues at hand.Get into your stoic mode, and find the answer to these 3 questions:

  • How do we create a high performance team?
  • How do we make software development less complex?
  • What do we measure and improve?

How do we create a high performance team?

Software engineering is a relatively new field. We can almost say it's immature, but not really, because this will most likely never change.

The way we practice it is always changing, and changing at a pace much faster than other fields are.

But remember, you are ultimately dealing with people. No matter what process you choose, no matter how much you push, it's all about the human spirit.

You have to create the environment for people to thrive, and get out of the way.

So what are the characteristics of this kind of environment?


First, you have to realize they are probably smarter than you are, even if they don't seem like it. Not in all areas, but in problem solving they most likely are.

So don't go telling them 'your solution', tell them your problem, and document the problem in the best possible way. Include all corner cases you can think of, include deep rooted relations and then get out of the way. It's a lot more simple said than done, and it's not going to work at first, but you have to keep refining your problem description skills.

On their side it's probably a new thing too, because they're not used to this way of doing things, but in the long run it will pay off.

Low pressure

Most of the work engineers do is mental, and it doesn't happen when they write code. That's why being in a constantly stressful environment will most likely result in a negative impact on their output.

The "are you done yet?" type of environment will cause them to come up with half-baked solutions which will be good for the next month, but will drag you down in the long run. Remember, building your business is not a sprint, but a marathon.

Find a way to balance your need for features now with your need for stability and quality work. This will give you the competitive edge you're looking for.

That said, humans don't perform well in zero pressure environments either. That's a recipe for disaster. It's really hard but each of us has to find the balance which is most adequate for our businesses.

Low process

Remember how everybody hates bureaucracy in government? Or big corporations who adapt very slowly and lose market share to the newcomer?

Most of the time, this is a result of process, or rules. The more process you have, the less output you'll get. Engineers as humans, can only tolerate a certain amount of rules. And those rules are accepted only if they understand the purpose of. Hire a consultant to teach your team 'the rules of new Agile Scrumfall', and see what happens when your team tries to implement.

Your solution here is to think from first principles.

Ask: What is the minimum process that works for us?

This means thinking about your current situation - people, product, customers. When you come up with an answer, remember this is not a permanent solution.

Re-do the thought process again next month, and next year when your situation changes. Next month you might need even less rules. Remember, the process is perfect when there's nothing left to remove.

How do we make software development less complex

Most of the time, software development is not a linear process. It's not like when your factory builds sneakers and each worker can make between 20 and 30 speakers a day.

It gets worse when you realize that you can't predict when features should get finished. When you eventually release to your customer, you receive feedback and even small changes sometimes result in unexpected times to develop.

When some of your developers leave your company and you hire new ones, they almost always say that the codebase is crappy. You should believe them, if you always pushed for having new features NOW.

When they get enough knowledge about your product to write useful code, it might take them too long to do it, and they might blame it on the code. Again, you should believe them. Give them the benefit of the doubt, and trust them. Always re-assess, but trust by default.

Sometimes, just accept that it's a complex process with many moving parts. Don't try to optimise too much. Remember, unnatural ways will hinder your team's output.

What do we measure and improve?

Hours in the office, lines of code, story points, git changes, are all terrible metrics. This has been proven again and again. Some things you should measure that are more useful but still don't tell you the whole story are:

  • how many times per day/week does your team release in production;
  • how fast can code get from a developer's machine to production;
  • how fast can your team address production bugs;
  • how well your team's solutions addresses the problems your customers are facing;
  • how well your team communicates internally and externally.

More frequency in releases means you have a well oiled machine, delivering more value incrementally to your customer.

If code moves fast from local to qa to production environments, also means that critical issues can get addressed fast, features can get shipped fast, and you'll be able to impress your customers with your agility.

Even if you have a well built QA team, it's a fact bugs get through, building software is hard. What really matters is if bugs are addressed quickly. If perfect software existed, it would most likely impress nobody. Having agility in solving problems impresses everybody, because they know how others handle it -- most of the time, slowly.

The most underrated thing to measure is customer experience and engagement. Does your team provide the correct solutions? Even if you have all of the above in check, does it matter if they deliver things nobody wants?

Another underrated thing to measure is how your SD team communicates with other teams or customers' teams. Are your engineers prepared? Do they speak fluently? Is everybody on the same page? Does everybody have the same knowledge? Often times, bad external communication means bad internal communication

Good internal communication is paramount to building a high performance team. All high performance teams are on another level when it comes to how they communicate. It's not about using Slack or even face to face communication. Using Slack for this is very naive, because often people communicate 1 to 1 and information becomes siloed. When they communicate useful knowledge on a Slack channel, it's really easy to have it buried in the mountains of messages.

It's how they communicate over time, asynchronously. It's how they pass on hard earned knowledge from one to the other. It's how fast they can onboard new developers. It's how good they are at communicating with juniors and training them. It's about how fast they can reach the information they need. High performance teams are always very good at these things!

This is where solutions like ours can help your team become badass.

Archbee Wiki provides an easy to adopt solution for internal knowledge sharing that is specifically tailored to software development teams. We've studied many teams and their workflows, we've identified common usecases and coded them into our software's DNA. When your team picks Archbee, you are guaranteed to see upsides like team happiness, synergy and productivity within less than 3 months of using our product.

Frequently Asked Questions

What are some key challenges in software development?
Expand FAQ
Software development involves complex processes that are hard to predict and regularly changing. Hiring a lot of cheap developers or implementing strict processes often does not solve these challenges, and can even hinder progress in the long run. It's important to address fundamental issues such as how to create a high-performance team, how to make software development less complex, and what to measure and improve.
What are the suggested ways to create a high-performance development team?
Expand Button
A high-performance team can be created by promoting autonomy, keeping pressure levels low, and implementing a low process environment with minimal essential rules. This requires treating the engineers as problem solvers, providing them a stress-free workplace, and considering current factors like people, product, and customers in defining the processes.
How can software development be made less complex?
Expand Button
Software development complexity can be mitigated by accepting its non-linear nature. Unnatural ways of over-optimizing should be avoided, as they can obstruct the team's output. When changes are required based on customer feedback or new hires join the team, they should be trusted and given the benefit of doubt.
What should be measured and improved in a software development context?
Expand Button
Traditional metrics like hours in the office or lines of code are ineffective. Instead, metrics such as release frequency, speed of code from developer's machine to production, speed of addressing bugs, effectiveness of the team's solutions for customer problems, and communication quality should be considered. These contribute to demonstrating value to customers, solving problems swiftly, and improving internal and external communication.
How does Archbee Wiki contribute to improving a software development team's performance?
Expand Button
Archbee Wiki provides an easy solution tailored for internal knowledge sharing within software development teams. It helps in better asynchronous communication and faster onboarding of new developers. Using Archbee can lead to increased team happiness, synergy, and productivity within less than three months.


Knowledge Management