Management Issues at Tech Start-ups

I’ve worked at NGOs, startups, and larger companies. I’ve done tech support and managed infrastructure. I’ve been a security consultant. All of these work environments were different, but when issues emerged that threatened an organization’s very survival, they fit patterns that are now all-too familiar. I’ve had infuriating conversations with leaders about these issues over and over again. I’ve been the canary in the coalmine so many times that I still find myself checking for feathers, but I still love building things and being competitive. If you want to spare your team the same pain, and make better products, read this and ask yourself whether any of this is familiar.

If you work for a growing company, you need to think about these patterns early. In order to move from startup to a serious competitor in a sector, growing companies need to set in place processes that enable expansion. These processes must be documented, and taught to new coworkers.

Gather ‘round, whippersnappers, and hear me expand on these vital points:

– Designing something correctly in the first place is easier than fixing it at a bigger scale later.

– Embrace more structure, and less chaos. More planning, fewer ad-hoc workarounds.

Important note:

Repeat after me: “A bad implementation of an idea does not render that idea invalid.” It’s entirely possible that you tried something, and did not do it well. This is not a reason to abandon the concept entirely.

The Core Issue

This is applicable to all areas:

You hired people with skills. Use those skills. In order to do this, you need to respect that technology specialists can teach you about technology, and people with management experience can teach you about management.

Treating people as competent inspires them. It gets the best work from team members. It also creates an environment where people can ask for more training when needed. Second-guessing work and micromanaging people drains motivation, is insulting, and ultimately makes people leave the organisation. It makes people hesitant to ask questions, which discourages innovation, peer support, and asking for help before something ends up being broken in production. Ask the specialists on your team what they need in order to get the mission done. Provide it. Ask yourself whether you are more interested in winning an argument and demonstrating rank than getting things done. Having to defend commonly-accepted practices, both technical and social, is a waste of everyone’s time. Set goals, set the key performance indicators, document them, and stick to the plan. Any changes must be agreed on and documented. The alternative is moving goalposts, which sows distrust.

Embracing Chaos

Too many processes are:

ad hoc; varying according to individuals and teams; not documented at all; not documented in a useful way.

This is a problem because:

It prevents teams from working effectively, because inefficient workarounds proliferate. A process that is trapped inside the brain of one person is not available:

– When they are not at work (vacation, illness, leaving the company entirely)

– When they are doing other work

A process that is documented in varying formats, scattered across databases and wikis and emails:

– wastes time on scavenger hunts

– wastes time on interoperability issues — document formats, credentials, etc.

– frustrates people

– is an obstacle to updates

It delays on-boarding when no one has bothered to write down:

– How a given task is done

– What tools are used, and who is the admin for said tools

– Who to ask for help

– How to ask for help

Common opposing points:

“I don’t have time”

This is false. Writing down a process once takes less time than explaining it many times. If you need to explain something to more than one person, then you need to document it. Documenting plans, meeting notes, product portfolios, etc. saves time discussing what various things are and how they are used. “Discuss, reach consensus, and document” instead of “discuss, reach consensus, don’t document, discuss again because people remembered the discussion differently, reach consensus again, don’t document, discuss again because people remembered the discussion differently, reach consensus again, don’t document, repeat ad nauseam.”

“Documentation is out of date as soon as it’s written”

Consider the following statements:

“I don’t put fuel in my car, because it runs out.”

“I don’t brush my teeth, because I just have to do it again in a few hours.”

Objecting to documentation makes just as much sense.

The need to update documentation is not a valid argument against the existence of documentation. When processes change, documentation changes, and becomes a record of why things were done one way, and why they changed.

In fact, documentation can accelerate the development of better methods. How can a colleague tell you the process could be better if no one agreed what the process should be, no one wrote it down, and discussions on improving processes are locked away from everyone else in email, chat logs, or face-to-face meetings without notes?

In some jurisdictions, you have to write documentation to comply with regulations. Good luck getting through a security audit without it.

“If we write things down, then people will stop talking to each other.”

The written word has been a useful form of human communication for thousands of years. Meanwhile, people still use verbal communication. Written documentation is the foundation that enables more useful discussions, because many simpler concepts are already explained before the trainer and trainee talk in person. Talk in person, take meeting notes.

“Code is documentation.”

False.

“This spreadsheet is documentation.”

False.

Any variation of “‘This thing that is not actual documentation’ is documentation.”

False. Documentation is documentation.

Solutions

Establish consensus on documentation. Note that this does not include debate on whether documentation should exist. It should. I’m glad we had this chat. Onward.

Where is documentation displayed? Is it only an internal resource, like a wiki that allows comments and tracks revisions? How about a customer-facing resource that can help people with their questions when your support staff are asleep? Good documentation is great for business. Decide on this, then set up a schedule for first drafts, review, publishing, and updating. This can be a combination of a set schedule, along with updates when products are changed. Decide who is responsible for writing, reviewing, and updating. Lots of people can work on documentation, but someone needs to coordinate and keep the project on track.

Communication

Core Issues:

If you have multiple physical locations or remote teams, you need to define some processes. Scattered communication means duplicating efforts and roles that are not defined. Prioritising face-to-face communication over communication that is accessible to remote teams will result in a lack of coordination, and a failure to get the benefit of expertise in the remote team. Even if you have one small office, set up your communication guidelines so they will scale.

Meeting culture

Meetings can be useful, or they can be a massive obstacle. They can be enjoyable, a necessary evil, or just evil. A few guidelines make the difference:

– Meetings need to be scheduled in advance.

– Meetings need to have an agenda.

– Meetings start and end on time.

– Meetings need someone to take notes, this duty needs to be shared, and the person needs to be told in advance.

– Interrupting people is rude. Do you want the best ideas, or only ideas from loud people?

– Have someone facilitate the meeting to make sure everyone gets a chance to speak.

– Phone ringer off — either be fully present, or do not attend a meeting.

– Laptop lids down — either be fully present, or do not attend a meeting.

– If there are no open points to be addressed, cancel the meeting. This is great for morale.

If you do this right, meetings get shorter *and* more productive.

Lack of common understanding

Words need to have meaning. For example, if one person in a team does not understand something such as the meaning of Agile project management, the term “Agile” has ceased to be useful. If you want to modify a framework to fit your use case, great! You don’t get to modify the official definition, however — describe it accurately as a variation on a theme.

Too many discussions are repeated because consensus is not maintained.

Failure to acknowledge the damage that interruptions cause

Multi-tasking is a lie. The studies were done with young, tech-savvy people at prestigious universities. Interruptions make Stanford students unable to do basic arithmetic. There is only faster context switching, in other words, the time it takes to return to a state where one can work effectively on the problem that one was focused on before the interruption. In organisations that fail to limit interruptions, the productive time lost can be measured in hours a day. This is costing you money. In organisations that fail to limit interruptions, failure can also be measured in serious mistakes. This could cost you your business.

Failure to acknowledge multiple ways of communicating

This is a typical failure pattern in organisations. If the organisation is led by people who work in one discipline only, the others suffer. For example, a legal firm will be dominated by lawyers’ ways of working, harming the tech teams. A technology company may fail to heed the advice of the legal team. Why is this important? Multidisciplinary teams are more effective.

Common opposing points:

“This team needs to adapt to the way we communicate because this way is better”

This ignores decades of research into communication styles that vary according to discipline, individual personalities, culture, and learned working styles. For example, a ticket system is a useful and way for teams to communicate with tech colleagues for industry standard several good reasons:

– it prevents interruptions it prevents the requestor from moving the goalposts, which wastes time and is extremely annoying.

A ticket is:

– a way to establish what success looks like

– a miniature forum for discussing solutions

– a forum for requesting help from colleagues. For example, a Windows admin may need information on doing something in Linux and vice versa.

– a record of what people have been doing, which is useful for management.

– a record of recurring issues that belong in documentation and/or known error databases

– a way for remote teams to remain connected

“If I can’t interrupt then there will be emergencies that we can’t react to”

In a genuine emergency, people may interrupt.When everything is treated like an emergency, nothing is an emergency. If someone who is logged in as root on a production server is interrupted by someone who could have written an email, chat message, or ticket instead, you may end up with an emergency.

There must be a process for setting priorities and sticking to them. In medicine, alarm fatigue kills patients. On ops teams, alerting fatigue kills servers. In every industry, interruptions kill focus, productively, and team cohesion.

The person who constantly interrupts must understand that they are hindering their own goals as well as the rest of the team.

Tools

Core issues:

You get what you pay for. Free software is free as in freedom, free as in no costs for licenses, but also free as in puppy. In the first few months (or longer!), that shiny new open source software is going to chew through time and morale unless you have a plan for training it. Time and morale cost you money. But it was “free”, right? Wrong.

A tool can not be set up as a minimal viable product, then left as-is. You pay for licenses for products that had a UX team involved, or you pay in consultants’ fees and/or in time wasted because a tool is not fit for purpose.

A tool is only worth something if people use it.

Multiple tools for the same function waste time and energy, and sabotage coordination. Consensus needs to be reached, with more weight given to the teams that use the tool most often, as long as the tool is reasonably accessible to other teams. A command line interface is not accessible to non-tech teams, and tech teams must not be subjected to a broken GUI with quirks that take time to learn.

Spreadsheets are not a Database

Some people really love Microsoft Excel. I try not to judge people for their strange lifestyle choices. You do you. However, there comes a point where we must face a sad reality:

At a certain number of spreadsheets, which you may have reached a while ago, a company needs a database. If you are keeping track of hardware or a lot of data, set this up before you end up doing an archaeological dig through years of neglected inventory.

As with any project, a plan needs to be formed before any new tool is adopted:

What is stored? What is displayed? Who is responsible for any manual data entry?

When are configuration items first set up?

When do items need updating?

What sort of monitoring systems should be developed/installed to automatically update the database? The weakest link in any database is manual entry.

What should reports look like?

What security measures protect the data?

How does one access the database? You’ve got an access control policy anyway, right? Right?

Solutions

No matter what you are setting up, be it internal systems or a new product, sufficient resources must be dedicated to the project. Setting up a database can increase efficiency, or it can be a waste of time in comparison to the process you put together with spit and duct tape in your garage. The difference is the following:

A product evaluation and implementation process, consisting of:

– end user requirements analysis

– stakeholder meeting

– design document

– comparison of top contenders

– decision on tool adoption

– list of features that need setting up

– plan for data migration

– plan for end user education

Silos and Measurement

Whether you are running your own infrastructure or keeping track of a few laptops and the work of freelancers, you need to know:

– What hardware costs

– What development of software costs

– What support costs

– How much of these resources are being used by specific customers.

Otherwise a scenario like this occurs:

Because there is no basic product portfolio with operations costs, Sales offers a product for $40,000. In the best case, it costs $50,000 to run. Because the service level is poorly documented, the customer makes tech support requests but does not pay for services in excess of their contract. It ends up costing $55,000. Because none of this is tracked, no one knows to change the contract so that the customer pays for services used, so that enough operations people are hired to cover the amount of work needed, thus avoiding delays in responding to customer requests, burnout, and turnover.

In addition, capacity planning suffers when there is a disconnect between Sales, Accounting, and Dev/Ops. Either customers are lost, and the company has hardware that is not earning its keep, or business opportunities are lost because no one is matching procurement lead times to the sales pipeline.

Solutions

Get an accountant or financial officer to evaluate costs. Document these costs. Decide on the profit margin range for products. In the best case, make a tool to calculate customer offers and use these data for capacity planning. Otherwise, you may find yourself running out of money, and unable to live up to all the awesome things your customers are excited about because your marketing team worked hard on outreach.

Bust some silos. This doesn’t have to be complicated. Have a weekly meeting, and get each team lead to answer three questions:

– What did you do last week?

– What are your plans for next week?

– What do you need from other teams?

Again, these meetings may be long at the start. Stick with them. They are worth it.

Conclusion

It’s never too early to get organized and build a team culture to be proud of. Getting clever people in a room and having them bounce ideas off each other, keeping vital information in peoples’ heads, and not having roadmaps for projects may work for a time, but it’s not sustainable. Plan ahead for your ideas to take off, enabling you to hire more people. Write things down. Decide what success looks like and how to measure it. Do all of this while being kind to your team. Now get out there and take out your competition.