stocktech

To answer your specific questions: 1) User authentication was a centralized service that managed roles and permissions. We integrated with LDAP so that we would only authenticate current employees or contractors, then the service would look up the appropriate permissions. We delegated management of roles/permissions to a business owner in the department and our IT team handled LDAP.

2) Each app was separate - each had 1 app, 1 database, 1 project board. I think the real benefit with this was a simpler mental model while working with the systems, but this came at the cost of managing shared services/packages.

We used frameworks that were more opinionated so that each app made similar assumptions and used the same tooling. I started the team using C# MVC, but we moved to NodeJS on the backend to reduce context switching between FE/BE. The big thing is consistency so that each app's codebase looks and feels the same. When you're jumping between apps, you don't want a day long ramp up period.

Similarly, I made sure all devops type tasks were streamlined. We did CI/CD before our product teams did and had full test suites. Preview environments were setup for developers and users. And everything was documented with guides. We could clone our project blueprint repo and deploy it in 5 minutes. A working CRUD app could be done in a few hours.

One unnecessary thing I choose to do was create SPA frontends. With our blueprint and shared services, it reduced the complexity, but it really gave the team something to learn/dive into. I think that little bit of "sexy tech" went a long way for morale and recruiting.

If I had to do this all over again: 1) I'd do a better job defining the team's value proposition. Those basic CRUD apps could be moved to a no-code platform. The team should be focused on apps where proprietary engineering will benefit the company most. Some of my apps had estimated value-add of $5mm+/year, but we would still get pressure from the execs to make a new app that would save the company 50k.

2) Similarly, I'd make sure my team was separate from rest of the org, as long as it makes sense. When we first got started, I was under a product director. As we grew, we never really found our own space in the org and got pulled in different directions. fwiw, I left the org because they wouldn't promote me.

3) I'd start with each app being separate then move to 1 app per department. We worked towards this as we grew and multiple apps needed to be integrated with each other. I think I moved too late though and our integrations reflected it. Especially as we could have justified a small team for each department, it would have made sense. As a management aside, I wanted to be more agile and form teams around projects - 1 app, 1 database, 1 project board, 1 team. It worked fine, but something something Conway's law.

Some things I think I did right: 1) My engineers did everything - project management, roadmaps, engineering, etc. Even when we had dedicated project managers, my engineers were always in the room because the business doesn't know what they want. We had a number of BIG wins because my engineers could come up with non-obvious solutions. I also gave my team the autonomy to solve the business problem whatever way they saw fit.

2) I hired people who cared more about solving problems than the tech. I encouraged doing more design work than engineering and spending time with our users. This led to better UX, better domain knowledge, and very happy users.

3) I advertised the shit out of our work. Multiple departments have similar work and when we'd build an app that did one thing, I'd go to another department and see if it would help them too. Some of our apps started as a copy/paste and evolved in their own right. I'd also send an email to our senior leaders every time a new app went live with a small description, a gif of functionality, and the estimated value-add. Most of time, we'd add something to our roadmap as a result. I was also good at networking within the org, for whatever reason, so I was able to be proactive in some regards.

BLDBTR is a BI environment that gives teams full control over their data. It decouples performance metrics from process and structure so that as your org or code structure changes, your metrics can change with you. At one org, we moved from functional teams to a project based, matrix type org structure and only needed to adjust a few group by queries in the chart builder.

Having this tool has also allowed me to see stats that I otherwise wouldn't have or would need to manually compile. For instance, how much do my managers code? Are my contractors worth the investment? How long does it take a new engineer to ramp up - and what does the ramp up look like? Whether you're an engineer, manager, or executive, you can see the metrics that are the most meaningful to you.

Right now, it's integrated with Github, but I'd love to talk to more people about the tool before opening it up. Let me know what you think!

What makes engineering metrics hard is that every team is different. We can talk about cycle time, deploy frequency, bug counts, but not every team can pull the same levers and those levers don't always yield the same results. So the teams and the manager need to know how to create metrics that matter and metrics that the team has the ability to affect.

You also need to take into account what is organizationally important. I've been in startups that valued deployments more than quality and enterprises in compliance heavy industries that valued quality over deployments. If your metrics don't align with your culture, it never feels right.

Then the biggest thing is to not compare teams. This is a game of "better than yesterday", not a competition. As a team, you want to find what equilibrium is and use your retro to find ways to iterate. As you have more discussions around performance, you'll find more things to measure, you just need to decide if it's worth it.

BLDBTR is a BI environment that gives teams full control over their data. It decouples performance metrics from process and structure so that as your org or code structure changes, your metrics can change with you. At one org, we moved from functional teams to a project based, matrix type org structure and only needed to adjust a few group by queries in the chart builder.

Having this tool has also allowed me to see stats that I otherwise wouldn't have or would need to manually compile. For instance, how much do my managers code? Are my contractors worth the investment? How long does it take a new engineer to ramp up - and what does the ramp up look like? Whether you're an engineer, manager, or executive, you can see the metrics that are the most meaningful to you.

Right now, it's integrated with Github, but I'd love to talk to more people about the tool before opening it up. Let me know what you think!

And the reality of the situation is that these metrics will be brought down to the individual level and used in performance management. As a manager, I'll have to track that 1) I'm measuring things that matter and 2) that engineers have control over the metrics.

I also don't treat the metrics as a silver bullet where changes need to be investigated and not managed to.

There's definitely risks and some managers probably do this poorly, but I think metrics are useful and if done well, are effective.

The above is a great post that should get you 90% there. Having a good career ladder in place makes performance discussions relatively easy and plays into the larger picture of setting expectations and giving feedback. If your overall organization doesn't have a career ladder, you can call it an expectations framework within your team. At the end of the day, you just want to be able to articulate what the expectations of each level is and have discussions around that.

The goals you've listed work well. For instance, in your expectations, you could have a "Quality" section that outlines all engineers must have tests for their code. The hard part here is thinking through the reaction your expectations will have. After all, any metric that can be gamed, will be gamed. You also want to make sure that you're creating expectations on things engineers can actually control. This will be the single best thing you do to communicate what is important to the team.

As for individual performance metrics, I've never found anything that made me feel good about it and I've since stopped trying to create any type of measurement. Individually, I look at meeting/exceeding expectations and leave it there.

One more thought. As you're new to the team, I'd involve the team in the conversations around raising quality. Their buy-in will be important.

https://www.vspatial.com/ https://immersedvr.com/#features_tag

I also wanted to comment on the website. It's simple and I love it.

I've heard the "everyone is an analyst" line too, but from business intelligence vendors. We still hire data analysts and developers though.

I do think there's a gap between what SAAS reporting offers and what is needed. For instance, I just led a giant JIRA API data integration that had a significant reporting aspect. Don't even get me started on the Salesforce project.

Baremetrics for XYZ definitely seems like a worthwhile opportunity though.

Especially if he's non technical, I don't know how much he's in a position to judge your work. How would he know what's over complicated or not? I do think bad deployments and wide estimates are fair criticisms though. Do you think your work is over engineered?

What type of work are you doing? I run full stack web engineers. Typically, I'll see over complicated data models from newer grads who try to third normal form everything or engineers who want to rewrite functionality our framework gives us. Some engineers think the problems are super complicated and make the solution match. Some engineers just overlook a different way of doing a thing and back themselves into a very complicated corner.

I don't know if there's a book that can give you the answer either. It's really a problem solving challenge where you need to find the solution with the least amount of steps possible while optimizing for your requirements. Without a team behind you, it's tough to change your perspective (assuming it's an issue at all). I'll have my engineer diagram the system then ask what we can remove, then we go over things together. Maybe finding similar open source projects could show you other solutions?

Agile as a solo developer is more of a expectation tool in that your manager will be able to see what % of work is done and what's holding you up. Agile could be a Trello board you share with your manager or just an excel sheet where you list out the requirements (and the sub-chunks) and the status of each. The important part is breaking out the work into manageable chunks.

Second, I'd talk with your boss more about "communicating too much". Especially if you're already having problems, you'll want to keep an open line of communication with your boss to let him know where you're succeeding and struggling. I'd try to figure out what kind of communication they're looking for and develop a plan around that.

Third, over complicating solutions is a tough problem to overcome, especially alone. Is your boss technical? Was he a developer? Who's your mentor in all of this? Can you give an example on how you've over complicated something? Without knowing anything, I'd encourage you to spend more time designing and less coding. Design the solution first and take time to look for ways to simplify it.

Fourth, timeframes are always hard. I agree with agile and would encourage you to read up on it. Even splitting a project into milestones could help.

Who do you report to in the structure? What's the culture elsewhere in the company? If the culture is positive elsewhere and upper management seem like decent people, I'd go over your manager's head and explain what's going on to an executive. This sounds like a bad manager scared to have a difficult conversation. Outline specific events, with dates and relevant people, then put it in business terms. Employee retention, work quality, motivation as it relates to deadlines/innovation, etc. Whatever personal perspective you want to add, I'd keep it in a separate section because if they care, it'll be obvious what the impact to you is and if they don't care, they can focus on the business cost.

I guess if you're feeling really empathetic, you could talk with the abusive coworker directly, but that's a risk. Even just trying to connect with him as a person - asking him how he's doing or something non-work related.

I'm sorry you're going through this and I hope you find a way out. If it was me, I'd tell the boss that I won't work with $abuser and to go fuck himself if that's a problem. Apparently that kind of behavior flies.

Thinking about this recently, I've attributed some of my failure to my youth. I use to be in such a hurry to be successful. Maybe it was ego or ambition or a twisted sense of competition with all the other 20-something founders, but building because you're "behind" definitely wasn't the right approach. And because I was in a hurry, I never stopped to really invest in an idea. I'd build something in 6 months and if I didn't see any traction, I'd move on to a totally unrelated idea instead of pivoting - truly throwing away my efforts.

I'm in my 30s now and life's slowing down. To some degree, my dreams of uber-success have died and I don't really feel that same hunger I use to. Maybe it's complacency, maybe it's just my age and refocusing on things that make me happy.

Don't get me wrong, I still work on side-projects, but I'm approaching it from a place of building on my strengths, rather than reinventing the wheel every 6 months. So I'm not changing ideas anymore, but pivoting to semi-related ideas where my work builds upon itself. I'm also focused on an industry I've been working in for the last decade. I've been able to reach out to my network to brainstorm and discuss the value I'm bringing to the table.

Who knows what will happen, but I'm not in a hurry anymore and I've found enjoyment in work, life, and my project.

* Tell me about a time when you disagreed with a coworker/manager.

* Tell me about a time you had to persuade someone to see your point of view.

* Tell me about a time you caused a major production issue.

These are pretty standard behavioral questions. The key is to focus on a specific example, not a hypothetical. Look for their impact and their actions.

At the end of the day, Typescript is one way Microsoft is competing with Facebook. The only reason you want native JSX is because React won the framework wars. If Microsoft can win with Typescript, they'll have a larger say in the future of Javascript and then web development in general. They'll never move away from javascript.

But here's the thing, there are examples of commercializing open source software. Red Hat, MeteorJS, GhostJS, and more that I can't remember. These companies add value and most are appreciated. Your business model ignores this and feels like a "fuck you, pay me".

If I was you, I'd find a way to keep OSS exactly the way it is, but make consulting around those OSS projects extremely easy.